如何讓敏捷軟著陸？

當前，敏捷已經成為了2018的熱詞，執行敏捷研發模式的專案多數都是從瀑布模型轉型過來的，瀑布模型是一套根深蒂固的傳統流程，如果硬著陸的話，很容易折翼。筆者在各類專案敏捷實施過程中，總結了一些接地氣、可操作的經驗，思考如何讓敏捷軟著陸，給大家提供參考。

因地制宜

縱觀目前正在實施的敏捷實踐，成功案例有一個共同的特點，就是“因地制宜”。敏捷實踐有很多種，看板站會、持續整合、單一主幹、測試前移、影響地圖、測試驅動、結對程式設計、Scrum、故事地圖等等，在敏捷的實施中沒有所謂的最佳實踐，只有更合適，更有效的實踐。團隊在透徹理解敏捷理念的基礎上，能夠結合自己的專案情況靈活應用敏捷，才是真正的敏捷。

案例一：A專案已成功引入業務人員參與，打通了敏捷的前端，達到從市場需求到研發過程的“業技融合”的狀態。

案例二：B專案與測試部門合作，將測試環節前移，用TDD最佳化程式碼設計，提高程式碼可測試性，同時“測研結對”促進交付速率的提升。

案例三：C專案需求分批次下達，團隊上下對Scrum敏捷框架有一致的見解，專案在開發側開展Scrum實踐，推進專案追求卓越的技術、良好的設計、高效的溝通。

案例四：D專案建設的系統需求穩定，屬於核心類系統，使用傳統瀑布式研發方法相當順暢，應遵從實際繼續沿用傳統模式，可借鑑敏捷思想中的看板、站會等管理實踐，促進溝通與協作。

問題驅動

敏捷並不是萬能的，不能聽說別人用了敏捷之後，效率提高了百分之多少，成本降低了百分之幾等等，就盲目地去追趕這股“敏捷風”。

不同的業務條線，專案情況各異，還是應該由問題驅動、對症下藥，先收集當前的研發模式有哪些問題，分析一下，到底是人的問題、技術的問題、還是流程的問題，如果真的是流程問題，那就再看，是需要全盤替換，還是僅僅吸取敏捷裡的若干特色工具或方法即可。舉兩個案例。

案例一：某系統在建設過程中，專案經理面臨專案規模大、專案進度把控難、團隊溝通不順暢的問題。如果專案全盤引入Scrum的全套流程，前期就需要投入大成本在學習和磨合上，同時交付也會下降，這是專案團隊無法容忍的結果。專案組從最迫切的溝通問題出發，先期引入了Scrum的“看板”和“每日站會”，讓整個專案進度變得直觀透明，同時讓溝通更及時快捷，其他流程保持不動，這種對於專案組成員來說，學習成本最低，基本不會影響交付。專案組在實施一段時間後，反饋的確解決了他們的實際問題。

案例二：專案人員技能參差不齊，初級人員總是成為交付的瓶頸，專案組希望引入敏捷來提升交付速度。首先，專案組對敏捷的概念認識是有誤區的，敏捷≠快速交付，它強調對需求的快速響應能力，敏捷不是一顆靈丹妙藥，吃了就可以日行八百里。其次，敏捷團隊，強調的是自組織，自管理，對每個人的要求都相對較高，但是從實際角度出發，不可能每個敏捷團隊的人員配比都是高階人員，所以建議在初期組建時，以老帶新，慢慢來，透過若干個迭代的打磨和成長，讓整個團隊都能達到自組織和自管理的“理想”狀態。

所以敏捷的引入，一定要切合實際要解決什麼問題，而不要為了敏捷而敏捷。

基本要求

來點實在的，筆者不得不說一些基本的硬體要求，那就是首先要有一塊板子。哈哈，不開玩笑，說的是真的，下面的幾點搭建了最基礎的著陸跑道，為著手嘗試敏捷的專案提供參考：

1.  看板一開始最好是物理看板，不需要追求漂亮完整，只追求簡單。

2.  物理看板的話，需要白板紙、木紋膠帶、各種顏色和形狀的便籤。

3.  指定專人關注看板改進，把握三個核心：視覺化價值流、顯示化流程規則、控制在製品數量。

4.  改進看板，改進不一定是成功的，但是提出改進是職責。思考流程是否順暢，內容是否上板。

5.  建立每日站會習慣，每天固定時間固定地點，設立獎懲制度推進每日站會，促進團隊溝通協調，及時暴露問題。

6. 所有要求和規則顯示化。

7. 三個角色，Scrum Master（SM）、Product Owner（PO）、Team。SM需要有較高的軟技能，對技術要求不高。可以由有能力、熟知Scrum人輪流擔任。PO對技術要求比較強，熟知需求，負責產品價值最大化。Team包括團隊中的設計、實現、管理人員，負責實現產品需求。

敏捷源於多種實踐方法，大家都在不斷的嘗試、實踐、發展敏捷研發方法和技術，並引入工具探索實踐。綜上，在團隊對敏捷思想達成共識，“因地制宜”制定適合自己的敏捷實施策略，從“問題驅動”來思考敏捷切入點，同時建立敏捷實施的基本規則，後續根據每個迭代總結回顧，最佳化流程，踐行Scrum的核心理念：持續改進。

作者：付雲攀 陳炯 趙亞莉

中國農業銀行軟體開發中心