為什麼有些公司敏捷實施不成功？

    介紹

    常聽說有公司實施敏捷失敗？本文研究探討了那些經常被忽視，卻導致敏捷實施失敗的組織級原因，也討論了為什麼這些組織級原因並不是很容易能發現，並提出了一些處理此類組織障礙的潛在策略。本文的目標讀者是負責預算的管理人員，儘管技術人員可能也會對此感興趣。

    敏捷的歷史觀

    敏捷實踐從哪裡起源，因何而起源？這個問題將我們的注意力直接轉向一些公司的大規模軟體開發工作，這些公司要麼開拓市場並以出售其軟體作為主要收入來源， 要麼將它們的定製軟體視為其業務的主要競爭優勢。我們將此類公司稱為X。敏捷不是起源於從事固定報價軟體開發工作的公司的IT部門的，而我們把這類公司成為Y。

    為何這個問題重要？

    答案在於X和Y公司是如何從財務角度看待開發工作的。在X公司，軟體開發工作被視為一種投資，而且是為公司的未來所做出的首要投資。而在Y公司，開發工作 是小規模的，只是被看成是有時間界限的並需要去跟蹤的一筆開銷。X公司的經費是劃撥給團隊，Y公司的經費則是劃撥給專案。請將最後這兩句話再讀一次。

    在X公司，敏捷方法能成功；在Y公司，敏捷方法則將失敗。

    在固定報價軟體開發中，軟體開發工作是要在某個時間點結束的。為了獲取專案經費，需要你預先定義範圍，進行估算，分配資源，開發，測試，實施，然後將其交給支援部門。這是Y公司所採用的方法。

    而在時間和材料（time and materials）決定經費的情況下，公司做出決定，有必要組建軟體開發團隊，因為未來會有很多需要開發得很好的專案。他們會在預算期內（1年，2年） 估算可以承受的開發團隊大小，並據此分配資源，然後決定專案範圍和安排進度。這是X公司所採用的方法。

    發現區別了嗎？在X公司，總是有軟體在被開發。這一活動沒有結束點，團隊經費據此劃撥。所以，在基於時間盒的迭代中，把任務放入backlog、按優先順序排序、進行估算和評審才有意義的。

    而在Y公司中，他們通常只為某個預算期的一些子集（例如3個月）的工作劃撥經費。在此之後，就沒有更多的錢或者公司不願再撥出額外款項了。他們不希望維持 一個長期的開發團隊，因為他們負擔不起，再說也不會有足夠的開發工作使團隊一直有事可做。因此，就必須通過嚴格控制和強有力的專案管理來確保3個月後專案能交付。

    從財務角度來看，敏捷是一種奢侈品。它假定你始終有一個軟體開發團隊，並且總有開發工作。它假定你的團隊每年都能得到經費支援，並且你作為管理者，不必擔 心需要按單個專案來劃撥經費。作為敏捷管理者，你主要關注於日程安排、範圍和團隊能力。預算是每年或每兩年才需要考慮的事情。你根據公司所面臨的經濟現狀 向上或向下調整預算。成功的標準，則主要集中在一段時間內所交付的功能。

    在Y公司，你可能被分配了5萬美元，要在3個月內完成專案。制定預算和控制費用至關重要，它們決定專案成功與否。管理者會在資本週期的不同時段得到按照項 目劃撥的經費。你可能按時交付了所有功能，但如果超過了預算，也不會被視為一個成功的專案。作為這家公司的一名經理，你需要關注專案管理三角形的方方面面。你的團隊可能是臨時性的，並由合同工組成。在這種情況下實施敏捷是個錯誤...甚至可以說是個低階錯誤。為什麼呢？

    估算

    關鍵在於估算。

    在敏捷軟體團隊中，只有當你開始工作的時候，你才對其進行估算。就Scrum來說，你僅僅估算下次迭代的工作。因此你怎麼能知道產品需要多長時間完成呢？ 你不可能知道。而且，你確實不在乎這點。因為你將持續在每次迭代中交付功能。只要產品經理和QA說你有個足夠好的產品，它就可以作為正式版本釋出。你也許 有一個猜測值，但是直到團隊對它進行估算….你真不知道它還需要多長時間。

    在固定報價專案中….你的估算需要在最開始就進行。公司會問你需要多少經費來構建此應用程式，因為他們不想無休止地資助它。他們希望它能結束….最好是早 一點而不是遲一點。資金是有限的，而且你的專案，雖然可能是必需的，但不會被看作對公司的未來至關重要。它的投資回報率甚至可能為負數。如果你回覆公司的 領導者說；“我不知道此產品需要多長時間完成...請為團隊提供一年的經費，然後我們看看每次迭代後會它會是什麼樣子”，那你可就犯錯了，其結果很可能是你被解僱了。

    第二種情景中，如果我在取得經費並僱用團隊成員後告訴他們：“我們將使用Scrum”。他們將會估算下次迭代的工作。他們會假定他們的估算被認真對待並且你會據此給予他們時間去完成工作，而不管他們的估算是否適合你初始的專案經費。這很公平的，只是不幸的是，你作為管理者將處於難受的位置，因為你需要提交 預算/日程變動，並且/或者要在初始估算被證明為不準確時削減專案範圍。最終你無法管理專案還因此得出結論.......“敏捷這事兒行不通”。

    這裡的錯誤在於假定公司的領導者瞭解並且從上至下地致力於實施Scrum和敏捷原則。從他們要求你估算完成專案所需的經費這一細節，可以察覺出實情與假定大有出入。如果他們問的是，“在後面三年需要多少經費來維持一個軟體開發團隊？”那麼我們就會明智地從敏捷觀點出發著手處理了。

    真正難題

    因此，什麼才是公司實施敏捷的真正難題？這可以概括成以下幾點：

    敏捷假定公司需要長期的軟體開發工作而不是短期的專案。

    敏捷經常被公司管理層假定為是一種對預算沒有影響的開發流程。但事實並非如此。

    開發團隊假定領導者明白實施敏捷對於預算層面意味著什麼。

    我們不應低估這些問題的複雜性。開發人員和團隊往往對預算毫無概念，所以他們不知道從財務角度是怎麼解讀敏捷開發的。對於這一點，在網路上很多關於敏捷的 文章中體現得很明顯。同樣，管理人員往往對開發和特定的敏捷實踐一無所知。實施敏捷需要通過培訓來減少這兩個世界之間的衝突和誤解。

    所以，試圖在一個固定報價專案中實施敏捷實踐會有什麼後果呢？本質上，這其實就是給瀑布專案批了層敏捷的“羊皮”。

    故事點

    敏捷團隊經常使用故事點來衡量當前工作的複雜性。每次迭代中完成的點數確定了他們的速度（每次迭代點數），同時基於速度可以向管理層提供一個估算，用於表明某個給定的迭代能完成多少工作。

    如果你來自像Y那樣的從事固定報價專案的公司，你的第一個問題就是：“這怎樣和時間聯絡起來？又如何計劃成本和投資回報率？”事實是：不能。並且也不打算能。重申一下，敏捷學家假定你正在為一個軟體開發團隊而不是一個軟體開發專案提供經費。

    在X公司，你甚至可以用漢堡包或香菸作為參照，來估算每個迭代的工作。這沒關係。你總會在某個時間點完成這個產品（根據要求增加/減少功能）。唯一真正的問題是：何時我們能稱之為完成然後作為產品釋出？團隊經費並不取決於工作量的估算。

    而在Y公司，專案經費直接與工作量的估算相關。至關重要的是，我們將其與時間緊密聯絡起來。因為我們的成本動因往往是以小時來計算的。故事點在這裡毫無意義。

    ScrumMaster vs 專案經理

    “敏捷不需要專案經理。”你曾聽到過這種說法嗎？這種不經意的嚇唬會使傳統型專案經理提心吊膽。然而，這一說法是對的。如果你假定團隊每年都能得到 經費，並且經費不受專案工作量影響，那麼組織和管理開發工作就的重點將是技術指導、任務和風險管理。這種情況下根本不需要時間表和預算，ScrumMaster就足夠了，他能更好地完成任務。

    不過，如果你在像Y這樣非敏捷的公司工作，那麼傳統的專案管理實踐不僅有效，而且對於控制預算和工期偏差來說是必要的。這種情況下，就需要開發團隊的領導去儘量節約公司的每一份寶貴資源，並且需要具備一個準CEO的技能。

    在有經費支援的開發團隊中，專案經理的角色的確被改變了。而固定報價專案開發團隊則沒有。

    每日站立會議

    因為種種原因，敏捷使用每日站立會議。這其中包括：激勵團隊成員、緩解風險、彙報工作、問責、建設團隊等。即使在固定報價瀑布式的專案中，這也是個好主 意，沒有理由不繼續使用這一實踐。但從事固定報價專案的團隊必須意識到：你並不是在真正地實施敏捷開發，最後期限正在悄悄地逐步逼近。你還可能需要權衡時 間需要。每日站立會議應該很短。但當你只有三個月的經費時，即使每天15分鐘也得累計並考慮在總開銷之內。

    迭代評審

    有充分經費的敏捷軟體團隊會漸進式地回答何時能完成產品這個問題。在每次迭代（例如30天）結束後，他們都會進行功能評審，並評估產品釋出的準備情況。同 樣，這也是個能被用於固定報價專案的好主意，但需要去引導業務負責人理解：迭代評審是一種緩解風險和問責的方法，而不是對已完成產品的演示。

    迭代規劃

    迭代規劃的確假定你是在一個有經費支援的團隊中使用敏捷。它需要確保你的成本已知，預算週期固定，並且團隊做出的任何估算都不會嚴重破壞你的預算。在固定報價專案中使用迭代規劃基本上肯定會導致混亂、預算差異、和/或功能丟失。

    燃盡圖

    燃盡圖展示了一個特定迭代中完成功能的進度。它們是對一段時間內團隊業績的衡量，但並不能用於闡釋離專案完成還有多遠。如果我們將所有燃盡圖都總結在一 起.....它們可能能夠說明這一點。但鑑於燃盡圖通常被嚴格地用於衡量專案開發工作量，所以即使這點也並不是總能被做到。

    在固定報價專案中，問題通常不是團隊在一個時間段內完成多少功能，這真的不重要，重要的是在經費允許的時間段內所有的功能都必須完成。

    因此，在固定報價專案中使用燃盡圖和迭代會向團隊和客戶傳遞錯誤訊號。

    總結

    首先，我建議不要試圖在固定報價或基於專案劃撥經費的情況下嘗試實施敏捷。取而代之，作為經理，你應該評估你的公司是否能夠支援敏捷實踐以及一支人員配備 齊全的開發團隊。如果能，那麼你應該實施敏捷...它能運作良好；如果不能....那麼你最好明智地堅持使用傳統專案管理實踐。

    如果你確定你的公司有足夠資源和工作負荷來支援軟體開發工作，但沒有使用敏捷，那麼問題就涉及到如何使管理層相信敏捷對於開發工作是有意義的。戴頂變革管理和銷售的帽子....你會需要它們的。

    其次，專案經理和ScrumMaster不是一成不變的角色和頭銜。在一家公司，專案經理/ScrumMaster可能要負責預算；在另一家，他們可能不負責。有時候，在一個傳統組織結構的公司 中，他們可能有直接下屬；而在另一家，組織結構可能更偏向於矩陣式，專案經理/ScrumMaster沒有直接下屬。我提到這些差異，是因為有關敏捷的文 章，就像所有的著作，都是從作者的觀點出發的來闡述。往往一些在某些情況下能起作用的過程或技術會被拔高說成萬能的過程或者技術.......然而實際情 況是該組織和角色都能很好地適應這個過程和技術。如果角色和組織發生了變化，它可能就不會再起作用了。在敏捷vs瀑布開發的部落格圈中，這種背景資訊經常缺失。

    最後，有關敏捷的爭論往往被比喻成一種哲學的戰爭。但是，從我的經驗和角度來看，這種混亂很大程度上是誤解的產物。很多時候，一個技術經理並未全面仔細考 慮實施敏捷的商業內涵。同樣，業務人員則常將敏捷誤解為與他們如何提供經費無關的“一些開發工作”。在我的職業生涯中，很幸運，這兩類問題我都遇到過，並 且找到了解決之道。通過這些，我也才深刻地理解了有關預算的假定：這個導致敏捷實施失敗卻常常不被識別出來的原因。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-626036/，如需轉載，請註明出處，否則將追究法律責任。