企業敏捷擴展的四項必備規則
2015-11-24 17:44:11來源：InfoQ評論： 點擊：
敏捷方法早就證明了其在同地協作的小型團隊中的效率，該方法能完美適應以靈活和速率著稱的團隊。但是，當超越團隊層面向組織規模擴展時，敏捷實踐就需要面對企業發展現狀，比如分布式團隊、多組件項目和傳統資源管理。
事實上，無論組織多大型、多復雜或者多分布，都能采用敏捷實踐，尤其是Scrum。Scrum實踐在超過100人的復雜企業中的伸縮性非常好，能夠在組織轉變過程中給予足夠的重視。下面是在多團隊企業層面實施敏捷時需要遵循的四項規則。
1.明確定義大規模敏捷意味著什么。
對敏捷開發的誤解導致許多組織以一種絕對錯誤的方式冒冒失失的一頭扎進敏捷，進而無法避免這種誤解，甚至更糟。一些與敏捷相關的誤解主要是人們認為Scrum無法準確提供支持組織規劃的項目進度表。然而，事實是Scrum開發有足夠的前期規劃和分析方法，并且在支持組織規劃方面，比其它大部分開發方法更有效率。
首先，敏捷實踐易于管理和優先級的特征范圍，使其能夠輕松地利用固定資源滿足最后期限，讓項目成本更具有可預測性。其次，基于優先級完成特性，而不是將它們捆綁到規劃階段，這樣有助于消除最終你想要變更、擴展或者取消已經完成的功能的風險。
大規模Scrum包含了所有常規Scrum的可用特性，和已經證明了的在多團隊、多站點的大型環境中能夠有效連接Scrum構建模塊的具體要素。舉個例子，假設客戶參與了規模擴展；隨著Scrum團隊希望從客戶候選人中獲得不同的技能集，可能需要建立一個獨立部門負責管理客戶參與。
另一個例子是，在一次迭代中集成所有團隊致力于一個產品的輸出，實現一個潛在的可交付的產品增量。這可以通過以下方式實現：
跨越組織協調‘完成標準’，實現為每個團隊完成的故事、特性和缺陷定義驗收標準。
建立Scrum的Scrum會議，幫助解決跨團隊問題和依賴項。每個Scrum團隊應該指派一個代表參與聯合沖刺評審，從而提高項目進度的整體可見性。
2.揮手告別瀑布式的習慣。
即使是對敏捷實踐有著明確的理解也不一定能從試圖修改Scrum基本規則，以適應長期形成的瀑布式習慣中拯救組織。并且這種做法是極其危險的，因為它面臨著最終實施兩種方法最糟糕的特性，摒棄兩種方法的優勢的風險。
敏捷可以通過持續的需求分析、設計、構建/集成和測試獲得。此外，所有這些活動的界限都是模糊的，所以任何在里程碑處試圖映射到階段的嘗試都是無效的。不過，仍然有一些組織滿足于Scrum的‘前期分析，前期設計/持續開發’帶來的改變，并在開發工作中重新引入瀑布流程。我曾經參與過一個項目，該客戶依賴Scrum來提高他們正在開發的軟件產品的價值。不幸的是，公司不愿意放棄他們使用多年的正式需求審核程序。這樣一來，盡管他們確實提高了團隊性能，但是在每個沖刺交付中他們還是在增加特性值方面滯后。只有公司允許靈活創建和管理產品待辦事項列表，他們才能保證在每次沖刺會上交付有價值的產品增量。
另一個常見的錯誤實踐是，當在多個團隊之間分裂大量共享的產品待辦事項列表需求時，沿著任務線而不是功能切割用戶故事。更好的方法應該是考慮將每個切割片作為更大功能的一個獨立可驗證的功能片，實現其在所有跨應用架構層的實施，其中應用架構包括：用戶界面、業務邏輯、數據訪問層和數據庫。
3.理解敏捷方法不是魔法。
轉向敏捷無疑可以通過提高軟件品質和改善客戶關系幫助企業潛在地提高他們的業務底線。它同樣可以幫助組織工作，但是它不會教導團隊的每個成員，使他們成為各自領域的尖兵。走向敏捷需要耐心，因為需要加強團隊協作強度；一個跨功能的團隊在開始大步向前之前需要運行數個試點沖刺。此外，團隊所有成員需要學習新的過程技能，這會在初始階段減緩團隊的進度。
建立敏捷團隊和過程僅僅才開始了一半；為了協作和穩定運營，仍然有很多工作需要完成。應對這一挑戰的一個方法是與具有成熟Scrum使用者的團隊協作。例如，我們的一個客戶在項目交付時處于敏捷轉換過程中。他們在整個企業建立和運行敏捷團隊，并期待獲得穩定的速度和可預測的發布。當與項目過程進行同步時，我們發現該公司具有產品待辦事項列表管理和發布計劃的問題。好消息是，發現問題是整個過程中最復雜的部分。僅僅經過兩個沖刺后，公司成功加強了團隊，改進了計劃并且給利益相關者提供了一個更好的如何發展其產品的主意。
同時請不要讓敏捷成為管理依賴的拐杖。當然，管理者將會為環境設置好整體基調，通過平衡一個穩定系統傳統的管理方法，和一個自組織系統更具創新的管理方法，在團隊的形成、發展、改善中扮演一個重要的角色。但是，當涉及到監管自我管理的跨功能的Scrum團隊時，傳統項目經理的世界將會發生翻天覆地的變化。因為他們需要面臨更多的挑戰，比如學習新項目預算確定流程，團隊人員配置，項目進度建設和協調其它部門的援助和支持。在Scrum中，團隊自己決定每次沖刺時他們需要承擔承諾的范圍。留給項目經理唯一的工作就是利用Scrum過程的透明度，確保沒有過高或者過低的承諾發生。
4.以人為先。
Scrum不是一種開發方法，而是幫助組織工作、提升團隊效率的一個框架。Scrum團隊是以使成員能夠加速到他們最大的生產力的方式組織起來的。為了實現這個過程，需要結合許多要素。
工作的組織：100%奉獻到特定團隊中去，在沖刺階段不間斷的運行，沒有強迫加班的可持續發展的開發步伐可以避免在員工效率，質量和生產力上的損失;
工具的可用性：Scrum的力量來自團隊成員之間的協作，這同樣適用于遠程或者離岸的大規模產品開發。因此，需要協同作業工具來支持每個團隊成員發展的可見性，從而實現相互的承諾。當然也有很多專門設計的解決方案——從即時通訊解決方案，用于共享信息的Wiki服務器和文件庫，到網絡攝像頭和產品演示的共享桌面。這些方案將不在同一地點工作的團隊成員，異地產品經理和離岸團隊連接起來。
企業培訓：赤裸的熱情和轉型的承諾還不足以使研發團隊和項目經理在敏捷環境下有效率地工作。為了始終滿足在組織范圍內已經建立的高標準，應該發展一個長期穩定的企業培訓政策，為團隊成員提供初始和持續的發展培訓。
卓越的技術：專注于實現最佳團隊速度和快速交付可工作的功能時，絲毫不應該向交付代碼的質量妥協。應該確保Scrum團隊的所有成員精通——或者至少熟悉——這種卓越技術的實踐和工具的使用，比如TDD，同行代碼評審，持續集成和自動化測試。
敏捷軟件開發宣言以個體和互動高于流程和工具這樣的價值觀更好地實現軟件開發開頭。在這方面，能立即考慮到的方面是跨研發團隊以及團隊成員之間的交互。但是，這同樣有助于將與客戶的交互帶入一個全新的層面。加強客戶參與需要團隊適應客戶當前的情緒、態度、需要和需求。客戶將要表現出不滿的跡象時，為了維護未來客戶的參與力度，團隊可以，比如說，從首選的高交互討論形式更改為更內斂、訪談式的討論形式。
最重要的是，始終著眼于客戶。最后，員工生產力和客戶滿意度才最有助于實現組織層面的敏捷目標。
關于作者
Ivan Kot是Itransition的部門經理。他最初的職業是開發者，在web和移動研發項目中擔任不同的職位，并最終將注意點轉移到項目經理和團隊協作上。他目前的職責是項目監督和與企業客戶建立良好的業務關系。作為一名經過認證的Scrum Master，Ivan能夠確保項目管理的完成遵守了指導方針和最佳行業實踐。他每天的座右銘是，“如果要做，就要做到最好。”
聲明：項目管理培訓師在線網登載此文出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其描述。其原創性以及文中陳述 文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請瀏覽者僅作參考，并請自行核實相關內容。
如果你對本網站有好的建議請點擊網站底部的“投訴與建議”和我們取得聯系。
請您注意：
·自覺遵守：愛國、守法、自律、真實、文明的原則；
·尊重網上道德，遵守《全國人大常委會關于維護互聯網安全的決定》及中華人民共和國其他各項有關法律法規；
·嚴禁發表危害國家安全，破壞民族團結、國家宗教政策和社會穩定，含侮辱、誹謗、教唆、淫穢等內容的作品；
·承擔一切因您的行為而直接或間接導致的民事或刑事法律責任;
·您在項目管理培訓師在線網“評論”中發表的作品，項目管理培訓師在線有權在網站內保留、轉載、引用或者刪除；
·參與本評論即表明您已經閱讀并接受上述條款。
