敏捷爲何在企業中鮮有成效？

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"從差不多2005年一直到現在，我都在或多或少做着一些敏捷工作。而到了2021年的今天，我對敏捷的現狀感到有些失望了。就像大多數踏入敏捷世界的人們一樣，我過去和現在都是敏捷宣言的支持者。我個人嘗試過XP、Scrum、看板、SAFe、Scrumban，也看過很多人的經驗總結，還參加過很多會議、看過很多Youtube的主題視頻。有些人，比如說Jez Humble就曾試圖解決我最熟悉的企業世界的問題，企業界也恰恰可能是我幻滅的起源。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"所以，下面的內容會從大企業的角度，而非初創公司的角度來探討敏捷開發的問題，因爲初創公司的所有流程都可能隨時變化。本文還會從北歐商業文化的視角切入，在這種文化中企業想解僱不合適或表現不佳的員工遠不像美國那麼容易。另外在某種程度上來說，大多數敏捷思想領袖似乎都來自英國。換句話說我是在提前聲明，我覺得有一些文化問題會影響敏捷方法的成功與否。總之本文會有不少吐槽，也會有一些關於我們如何在企業軟件世界中做出改進的想法。不管怎樣，我也是沒有銀彈的。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"免責聲明：這不是一篇科學論文，所以我不會在文末寫上引用來源，基本上這都是我自己的觀點和經驗，我也很清楚我的觀點有時會同敏捷思想領袖的思維方式相悖，我對此表示遺憾。"}]}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"我對“企業”這個詞的定義"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我曾經開玩笑說，企業級（Enterprise）軟件公司指的是那種所有事情都龐大而笨重的公司，這種說法也有一定的道理。雖然這些公司並非生來如此，但更多會因爲傳統、恐懼和激勵而變成行動遲緩的巨獸。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"大企業的管理人員往往缺乏技術背景，或者就算他們做過技術工作，也已經有十年或更長時間沒有真正撿起過自己的手藝了。企業架構師一般也會是這種情況，這個崗位完全沒什麼用途，還成爲了許多敏捷工作的障礙。SAFe中設置了這麼一個角色，但在我熟悉的其他敏捷方法中都沒有它的位置。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"大企業，還有公共服務組織也是一樣，在很大程度上是被對失敗的恐懼所支配的。高層管理人員對股東負責，公共組織裏則是對政府和選民負責。他們不想看到中層管理人員去冒險做一些沒有得到高層批准的事情，所以一般來說負責開發工作的中層管理人員並不會因爲冒險行動而獲得獎勵，他們的任務是循規蹈矩、完成目標。如何實現這些目標，如何打造“太大而不能失敗”的項目，就是另一個話題了。但如果你的獎金取決於你影響範圍之外的項目的成敗，你也得研究其中的門道纔行。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在公共組織裏，你也會非常害怕壞消息，所以所有重大決策當然都應該由第三方諮詢公司來審覈，反正他們也並不知道你在做什麼。這種情況有時也發生在私營公司中，但情況沒那麼嚴重。基本上這是一種“找好背鍋人”的心態，並且是敏捷的天然障礙（現在更好的說法似乎是“靈活”）。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"許多大企業也很喜歡企業架構師這個崗位，因爲架構師應該有大局觀和產品願景，併爲開發團隊提供可以遵循和實施的設計方案。問題是這種架構師要麼就完全不具備一線的開發經驗，要麼就是十多年沒親自上過陣了。直到2017年，我還碰到過有企業架構師團隊堅決捍衛SOAP和企業服務總線。在那個6-7人的架構師團隊中，只有一個人有編程經驗，而且上一次編程是在他9歲的年紀。所以他們給出的方案往往都是些過時的設計，甚至完全不切實際，同時它還拖了開發團隊的後腿，造成了許多困惑。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"但是怎麼辦呢，總得有人來負責對吧？"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"自組織團隊"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"大多數敏捷方法都有某種自組織團隊的概念，這本質上是和大企業文化相矛盾的。所以根據我的經驗，這些自組織理念只能是紙上談兵。在敏捷的理想概念中（比如大家的榜樣Spotify），團隊可以自己控制很多預算；可以自己踢掉一些成員；只從外部架構師那裏接受建議，而無需強制遵守後者的要求；團隊成員都活力十足、思想成熟，並一心想着爲公司實現最大利益。確實有的團隊做到了這些目標，成爲他們中的一員是一種樂趣。然而，在大型企業內部，情況往往並非如此，原因有很多。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"簡單來說，這些因素包括："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"缺乏技能"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"缺乏動力"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"缺乏業務理解"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"對團隊內部地位的挑戰"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"支配型團隊成員"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"學習自組織過程中出現的組織問題"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"價值未能交付"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"其中，想要修復最後一個問題，就得先把前面的都搞定纔行。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"缺乏技能"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這可能是敏捷支持者談論最少的一個問題。似乎所有傳授敏捷方法的人們都從來不承認有時團隊成員不夠出色這一事實。他們都說錯在管理層，因爲他們沒有給出足夠的信任、教育和授權。我在管理層和團隊兩邊都呆過，我得說這種說法就是瞎扯。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"的確，管理層，就像公司過時的做事方式一樣，確實會帶來很多障礙。但也確實有些人永遠都不應該被允許去寫代碼，他們永遠都學不會編程。我某種程度上同意Edsger Dijkstra的觀點，他認爲被允許進入計算機科學領域的人實在太多了。我自己可能不符合他的標準，但這一觀點還是成立。有些人永遠學不會編程。我見過的這種情況太多了。具體的問題可能更復雜一些，比如說有人能寫點代碼，但搞不懂分佈式編程，或者沒法真正瞭解客戶的需求。這裏說的也不光是技術技能，還包括與業務部門交流的能力，這樣你才能指出他們設想的解決方案中存在的問題。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"缺乏動力"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"大企業一般會有很多開發人員需要遵循的代碼標準、標準架構和語言，而且大多數都是垃圾。如果你像我一樣喜歡使用最好的工具來完成工作，很喜歡學習新東西，那麼經過十五個年頭還在寫Java或Javascript可能就沒什麼動力可言了。如果最關鍵的部分，也就是業務主題本身也很無聊，或者你根本無權對業務指手畫腳，那麼你所做的也就會是正常上下班打卡，正常完成KPI，但肯定不會有什麼激動人心的突破。這種問題很容易通過管理層來解決，但管理層通常不願意這麼做，原因還是主要來自對未知的恐懼。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"缺乏業務理解"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"用戶故事本來只是一個說明，是同業務部門（PO）就他們想要的特定特性達成的共識。但在大企業中這一部分經常會出問題，他們把故事變成了完整的需求規範，而開發人員就成了需求到代碼的翻譯器。與其這樣，還不如沒有用戶故事比較好（這會讓人想起從UML生成代碼的可怕例子，他們是有多想擺脫程序員啊）。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"根據我的經驗，軟件要取得成功就要求開發人員理解系統的“why”和“what”。我見過那種獨斷專行搞出來的用戶故事，開發人員資歷很老（好多年經驗），在項目中也幹了一兩年，但因爲寫故事的人啥都不懂，所以業務效果幾乎爲零。你可以爭辯說，糾正PO的錯誤並不是開發人員的工作；但我的反駁是，系統的實際實現人員應該和實際業務人員一樣瞭解業務規則，往往瞭解得更深纔對。我經常參加開發人員\/支持人員糾正業務人員所提出的假設的會議，因爲後者已經忘記了他們自己早些時候制定的一些規則。系統就是業務，實現人員應該意識到這一點。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"對團隊內部地位的挑戰"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在敏捷環境中，團隊中的所有人都應該是平等的。雖然產品負責人和Scrum Master顯然同開發人員有着不一樣的崗位描述，但每個人的意見還是有着同等的價值。有時，當進展不符合預期的情況下團隊會加上一名負責人，但這並不是真正的敏捷實踐，而是一種應急方法，一般用來應對質量太低或團隊輸出太低的情況。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"然而，如果你在大型組織中的職位是高級架構師，或者你身處某個非敏捷組織中，權力比其他人更大，那麼強行讓所有人平等總會引發怨恨、爭鬥，或者團隊根本沒把心思放在應該做的事情上面。在這種情況下，想打造一支同心協力的團隊可能並非易事。項目經理面臨的情況也差不多，大多數敏捷方法中都沒有這樣一種角色，所以他們往往會被選爲PO或SM，但到頭來做的還是PM的工作，因爲他們只會做這個而已。高層管理人員需要非常瞭解權力結構或者打破權力差異，否則一線人員往往難以發揮應有的貢獻，你可能無法獲得有價值的意見。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"支配型團隊成員"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"有些人就是不適合與其他人共事，除非他們真的被委以領導重任。我多次經歷過這種麻煩的狀況，其中一些團隊成員要求加入另一個團隊，因爲某位同事的行爲非常霸道\/有侵略性。這破壞了團隊本應具備的凝聚力和領域知識。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果這種情況持續發生，而且再多的談話或回顧似乎也無濟於事，那麼最好的辦法是擺脫那些支配型的成員，或者給他們分配單獨的任務——如果他們確實是優秀的開發人員。這自然也是說起來容易做起來難，因爲在公共服務部門或大型企業中解僱人員幾乎是不可能的，除非人們犯下了嚴重錯誤甚至罪行。我覺得敏捷世界中大多數思想領袖都沒有針對這種情況給出妥善的解決方案，主要是因爲他們從未在工會等背景下工作過，所以實際上並不知道該如何應對。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"學習自組織過程中出現的組織問題"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"大多數敏捷支持者喜歡把引入敏捷工作方法過程中的失敗歸咎於管理層，事實確實如此。敏捷並沒有給中層管理人員安排什麼角色，只把他們看作是一種障礙。因此，由於他們沒什麼事情可做，因此如果出現一些阻力也是不難理解的。另一方面，我也多次見過組織對敏捷文化的期望是來源於管理層，這種期望通常是從遵循Scrum或SAFe開始產生的；當結果不符合預期時，大多數經理會認爲他們的工作是做點什麼來改變狀況，這也是很合理的想法。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"不幸的是，關於“他們應該做什麼”這件事，很少有什麼好的建議。如上所述，你的敏捷團隊表現不佳的原因可能有很多，有時這個原因是出於管理層的不切實際的期望。然而，負責開發團隊的每一位經理都要對權力鏈條上游的某個人負責，而且當團隊覺得自身遇到了不切實際的期望，或被告知不要包裝某個解決方案時，他們往往會忘記這一點。爭論的焦點往往是開發團隊想要提供很好的質量，但有時實際上更重要的是證明某些事情是可行的，然後再修復那些邊緣情況。被取消的項目什麼都提供不了，而且開發人員常常忘記，給經理一些東西向最高管理層炫耀，可能會爲真正的項目爭取來資金。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當然，我們也存在組織障礙，比如運營、安全、測試和開發是不同的部門，傳統上他們不是作爲一個團隊來互動，而更像是對手。在這些情況下，一線人員完全可以責怪（高層）管理人員。不幸的是，出於多種原因，管理層很少願意打破界限，其中許多原因與保持管理層次結構有關，還有一個原因是除了開發人員外，其他人也要對產品負責。如果這不是你的責任，而你的角色只是提供建議或需求（比如說安全部門），那麼你真的背不了鍋。這對某些人來說是一個舒適的角色，但卻不利於交付高質量的軟件。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"價值未交付"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當團隊沒有交付管理層期望的價值時，一般來說各種各樣的指導委員會都會採取行動。我們可以做些什麼來降低風險？這往往會讓管理層引入更多的微觀管理操作，或聘請外部敏捷教練，以試圖引導團隊朝着管理層想要的方向發展——一般來說是爲利益相關者提供價值。當指導者被傳喚到CEO辦公室並解釋團隊沒能交付價值的原因時，利益相關者並不真正關心架構、重構或技術債務。這一點，根據我的經驗，有時很難讓團隊成員理解。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"基本上，如果你無法正常交付，就會導致團隊被施加更多的流程和控制，結果最優秀的那些人往往會選擇走人。解決這個問題的唯一辦法是和團隊認真地談一談，如果團隊還是沒能交付價值，就要判斷是不是目前的期望是無法做到的，還是說一些團隊成員在做自己的事情、包裝代碼、一直在重構（完美是夠用的大敵），等等。在第一種情況下，管理者應該取​​消或修改項目；在第二種情況下應該替換一些團隊成員，換上更有緊迫感的人。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"SAFe和Scrum的經驗"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"大多數大企業選擇的敏捷框架是SAFe或Scrum。SAFe是一個令人厭惡的框架，我真不想聽到有敏捷教練說服我用它。它是一個可怕的框架，基本上就是瀑布掛了個敏捷的幌子。這些團隊不是自組織的，他們有發佈經理和架構師組等。只要看看官方的SAFe圖表，你就會知道它不是很敏捷。"}]},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/9f\/a9\/9f43402dd3ebb4b117c1d603eb12e7a9.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"簡而言之，不要用它。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Scrum更復雜，也是一個更老的框架。如果你沒有出現需要立即修復的生產問題，並且管理層也能理解根據Scrum模式手冊，你只有50%的時間實現了目標，並且你的PO沒有充當項目經理，他也具備領域知識，並且知道這就是他的目的，並且你的Scrum主管也真的能夠消除障礙，那麼這個框架就可以正常工作。不幸的是，Scrum僅適用於一個團隊，因此你需要有明確定義的有界上下文才能設法擴展它。SAFe是一種擴展Scrum的嘗試，這很可怕。Nexus似乎是一個更好的選擇，LeSS要簡潔很多，所以也好得多。但所有的問題都在於Scrum真的不打算以企業期望的方式擴展。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Scrum和SAFe都沒有告訴你如何做估算，但普遍的共識是故事點。故事點應該是一些無量綱的東西，但在實踐中總會等同於時間。8個故事點=一名開發人員的1個衝刺，或類似的東西。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"據稱故事點的發明者Ron Jeffries似乎後悔了，這裏有一份有趣的參考資料："},{"type":"link","attrs":{"href":"https:\/\/ronjeffries.com\/articles\/019-01ff\/story-points\/Index.html","title":"","type":null},"content":[{"type":"text","text":"https:\/\/ronjeffries.com\/articles\/019-01ff\/story-points\/Index.html"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"所以基本上當你試圖計算速度（沒有方向的速度標量）時，你交付的是時間\/時間=一些和價值沒關係的數字。理想情況下，你的故事應該具有CoD（延遲成本）值，這樣你就可以說我們交付了10000美元\/2周的價值。這是有實際信息的，但故事點只會給你一個隨便冒出來的數字。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"通常你的估計也就能到這個地步了，但利益相關者一般會將它們視爲承諾，因此只需堅持使用T恤尺寸（s、m、l），並將它們與CoD搭配來確定優先級即可。理想情況下，你會知道你的速度有多快，所以能夠用T恤來加速你的衝刺。但這種情況很罕見，因爲你的團隊很難穩定，一直都在招聘新人。產假在發達國家是真實存在的，還有6周的假期。敏捷中有一大類“無估計”場景，它們確實有道理。如果它很重要就好好研究一下，否則就別這麼做。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在實踐中，我的經驗是Scrum在大企業中運作得不是特別好，而且大多數開發人員發現各種儀式都很無聊或令人沮喪。站立會議，實際上是一個小型計劃會議，被視爲某種狀態會議。一般來說，儀式，特別是如果你再加上積壓微調的話，是很浪費時間的。你很容易會把15%的時間花在會議上，此外還要參加一些必須參加的團隊外會議。在後面的這些會議中，你實際上會與其他人清理各種事情，或參加什麼公衆會議，但這類會議在Scrum中是沒有安排的——Scrum認爲PO應該瞭解領域的一切知識。他們很少做到這一點，所以如果你是公司在某個領域的一號人物，那麼你預計至少要花20%的時間在會議上——實際上往往會有50%。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Scrum還爲團隊成員設定了一個非常高的標準，這是沒有多少團隊能夠實現的。在最近的一次Pod演講中，Jim Coplien談到swarming是最重要的Scrum模式，但要實現這一點，據我所知，所有開發團隊成員都必須是全棧開發人員纔行，這在企業界是非常罕見的。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"簡而言之，有了合適的人員和合適的組織，Scrum是可行的，但這種情況下大多數方法也可以。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"管理者在敏捷企業中的角色是什麼"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一些思想領袖認爲，經理這個職位似乎只是在製造問題，但當然必須有人負責招聘和解僱人員、建議給人加薪，並且在總體上確定方向，還要做出不受歡迎的決定，例如取消某些項目或技術上沒有成功的實驗。但做這些事情的人們會不斷地把他們深陷其中的坑挖得越來越深。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"經理的職責之一是讓他的團隊儘可能找到最優秀的成員，不僅是技術上最好的，而且是個性和心態上最棒的。我對自己過多關注技術這一事實感到內疚，我也不該假設人們可以像成年人一樣解決問題。畢竟，這就是敏捷教練告訴我的。可是在現實世界中並不是這麼回事，因爲我們業務環境中的大多數人都厭惡衝突，並且有充分的理由。你不應該因爲不同意什麼事而在工作場所受到辱罵。因此，團隊成員之間的分歧有時到最後會需要管理者來解決。不幸的是，當事情走到這一步時，通常唯一的解決方案是將互相對抗的團隊成員分成不同的團隊。當同一團隊中的成員多次發生這種情況時，正確的解決方案可能是擺脫他們，無論他們的技術有多優秀。如前所述，不幸的是，這幾乎是不可能的，然後你最好的辦法可能是將這些團隊成員隔離在他們自己的小任務上，並希望他們自己退出。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"爲薪水、培訓等用途尋找資金當然是經理的責任。當然有些公司嘗試安排一個公共的教育資金池，你可以一直花到池子空了爲止。我可能是一個憤世嫉俗的人，但我覺得這種池子放出來第一週內就會被瓜分完畢——也許有一些人真的會爲別人着想，但反正我是會先把我的份額保下來！"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在我看來，爲團隊設定方向是經理的職責，因爲他通常是最接近業務側的人，並且最瞭解業務的財務信息。理想情況下，他也會懂一些技術，並且能夠阻止別人重複一些實驗，或者做一些被經驗證明不可行的事情。當然，如果你的團隊有足夠的經驗，他們應該能夠決定什麼時候以及如何在事情不順利的時候轉向。但團隊往往會滋生驕傲自滿的情緒，以至於偏離正軌，這對公司是不利的。有些經理經常不得不做出艱難的決定來拔掉某人的小項目的插頭，因爲除了小項目的主人以外大家都看得很清楚，那就是它永遠不會變成有用的東西。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"改進建議"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在我們生活的非理想世界中，尤其是在大企業公司中，我已經意識到，如果敏捷項目要在企業中取得成功就需要管理人員，但也需要合適的團隊成員。一項大多數人都認可的共識可能是，做出正常軟件的最大障礙是人，他們可以是經理、PO、開發人員、利益相關者或是其他任何人。不幸的是，我聽到的大多數敏捷思想領袖只會抱怨經理缺乏能力，而不會抱怨團隊成員缺乏足夠的技能，在我看來這是錯誤的。之所以會這樣，可能是因爲團隊成員在各種會議等事務中是這些思想領袖的直接目標羣體。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"基本上，你需要在所有職位上都有合適的人選才能取得成功。這很難做到，原因有很多，比如說企業形象不佳、薪酬過低、權力結構太深、缺乏開發文化、無法解僱表現不佳的團隊成員，等等。但無論如何，這都是成功的關鍵所在。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果公司的官僚主義氛圍成爲了正常工作的障礙，那麼即使是最好的團隊也無法取得成功。獨立的安全部門、荒謬的網絡配置、持續的業績評估和KPI爲核心的戰略，都是這種官僚主義的例子，它們會將團隊關注的焦點從生產高質量軟件這個目標轉移到其他事情上。管理層需要消除各種障礙，這些障礙中也包括一些人員。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果你安排好了團隊和外部環境，你還需要一個流程來讓你的團隊專注於最重要的事情，即創建軟件。我會選擇儘可能低複雜性的方法，可能是類似看板的設置，擺脫PO和SM，讓團隊與實際用戶或利益相關者會面，通過事件風暴和故事映射會議提出所需的計劃，然後與經理以及實際的最終用戶或利益相關者的一些代表（如果可能）一起確定優先級。PO代理可能在某些地方起到作用，但我個人從未真正體驗過這種感覺。尤其是在大型項目中，你會有首席PO，還會有子PO負責實際的故事寫作。這與只安排一個PO的基本理念背道而馳，這種理念中這一位PO的頭腦中應該對系統有實際的瞭解。你要經常與利益相關者一起重新審視計劃結果，獲得反饋，並根據反饋重新確定優先級。但做這些事情的時候都要讓團隊參與進來，這樣每個人都會了解哪些纔是重要的事情。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一個關鍵技巧可能是建立一個像樣的CI\/CD系統，並在部署變得太慢時重構它。在一個git push和能讓你看到的結果之間通常應該不超過一分鐘。自動化測試當然也是這裏的一個重要部分，但它不是放在單元測試級別。如何做測試又是一大堆細節要談，其中有一些非常固執的TDD信徒會指手畫腳。我可能會在另一篇文章中討論這個主題，但總的來說，所有事情都要適度，當然啤酒除外:)。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"另一個有爭議的話題是強制拉取請求，它最初是爲極度分佈式的開源團隊設計的（這種團隊中長延遲是可行的），並且很適合那裏。在商業環境中，它會大大減慢每個人的速度。儘管很多人都在推薦它，但根據我的經驗，代碼審查非常無聊，因此沒什麼意義可言，每個人都坐在那裏等待別人來完成工作。我個人很討厭它，並且寧願去相信人們自己會做好本職工作，並且如果出於某種監管原因強制要求某種控制策略的話，我可能會把驗收測試改成某種結對編程練習的形式。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"結論"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Brooks那句沒有任何銀彈的老話仍然是正確的。在我看來，進步的唯一途徑就是在團隊中找到更優秀、技能更多樣化的人才，這樣每個人都不僅僅是技術人員，而且還會了解業務目標，也可以瞭解經營業務的動態。在一個企業迫切需要更多開發人員的世界中，這似乎只是一個白日夢。我知道這是一種憤世嫉俗的想法，但在大企業中，有太多人不知道自己在做什麼，但他們很擅長誇誇其談，說服其他無知的人們，讓別人以爲他們自己很清楚自己在做什麼。如何大範圍解決這個問題呢？我不知道，而且很多人也應該承認他們也不知道。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"原文鏈接："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/medium.com\/@gramr\/why-agile-rarely-works-in-the-enterprise-816561515549","title":"","type":null},"content":[{"type":"text","text":"https:\/\/medium.com\/@gramr\/why-agile-rarely-works-in-the-enterprise-816561515549"}]}]}]}