敏捷-生命週期

前情回顧，上一節咱們瞭解到，敏捷起源的背景、宣言、原則；也對以上作了初步的梳理。今天咱們開始揭開敏捷神祕面紗的第二層「生命週期」。提到「生命週期」詳細大夥必定不陌生，誠然IT語言：C、C++、C#、JAVA等都有一套本身的生命週期，大夥也玩的賊溜。今天吶，不講開發語言的生命週期，將敏捷的生命週期。

提到敏捷的項目生命週期，要先從傳統型的提及。咱們是否習慣了先作計劃（需求調研)->分析文檔->肯定需求->設計(原型)->肯定->編碼->測試->實施交付->諾曼底D日(噩夢的開始)；或者是這樣的需求->設計->實施->諾曼底D日重現。

看到這裏，別吃驚，爲什麼我重複提諾曼底D日，在諸多影片中，該行動被塑形成英勇悲壯受世人傳頌。但我要說的是，IT界不提倡這種英勇和悲壯。IT不提倡我的獨立做戰，注重團隊合做+和客戶合做+靈活的策略=持續有質量的輸出。

團隊有多種形式，人員形形色色，也有多種實施方式，咱們要在一個個成功/失敗的項目中總結其特性，造成一種行之有效的團隊管理方法。在這裏，忍不住說一句：「不要畏懼失敗，要正視失敗，從中提煉出供團隊、成員學習、改變的一些正確的經驗和方法。

從上面咱們能夠看出，我所提的兩種方式能夠概括到」預測型生命週期「，何爲預測型生命週期？這是一種傳統的方法，和ASP同樣古老，即提早進行大量的計劃工做，而後一次連續執行，直至項目編碼終結。在該過程當中，不會有任何的商業或功能的交付。這種方法有效，也有弊端。這裏只講弊端，設想一下這麼個場景，A集團下分部IT，某天接到A的指示，作一個OA系統。OK，部門負責人開始走」分析->設計->建立->測試->交付「這麼一個流程。邏輯上沒有問題，但A只有在IT部交付那一刻，才知道軟件的功能。該過程期間A一直在想，這羣人在作什麼？是否是在偷懶？進度沒法得知，那麼，獎金、KPI怎麼算？IT部負責人在人員氣氛不穩時，向A申請經費或時間來活躍氣氛，A會贊成嗎？每每是開始A對IT部很信任，越日後信任度越低，天然各類福利待遇會逐漸減小。團隊成員會以爲被無情壓榨，部門負責人也至關委屈，長久以來，效率低、士氣低、人員流動性大。上節咱們有講過團隊人最重要，人才流失產品質量每每大折扣。最終兩個結果，1.負責人引咎辭職；2.產品嚴重不符合預期，後期不斷的修改，人員怨聲載道，工期一拖再拖，項目以流產了結.....

迭代型生命週期：這種方法容許對未完成的工做進行反饋，從而改變和修改工做的方法，項目複雜度高、變動頻繁適用這種方式，天然」瀑布式\預測型生命週期「也適合這種方式。優點在於反饋-更改，進度可控，質量可控。相信不少企業在用這種方式。

基於第一種的方式，咱們更改下故事；小A接任上一任負責人，負責項目開發。小A基於以往踩過的坑，決定採用按期向總部交付，那怕軟件不完整，也要交付。

咱們來看看小A是怎麼作的，每次交付時，會在集團區裏進行彙報：

1.本週期更新了什麼。

2.參與人有哪些。

3.測試人員有哪些。

4.下次預估會交付哪些內容。

收穫天然受到集團的好評，集團知道進度可控，對IT部信心增長，那麼集團/客戶會更放手讓團隊去施展。筆者一直認爲」一個好的領導，作事要有策略、手段。敏銳感知團隊、客戶的動向，發現異常後及時經過必定的手段進行調整，將利益最大化。而不是，踩着部下向上爬..一味的去迎合客戶、上級，會翻車的。「

扯遠了，還有個好處是，經過這種方法，項目在開發過程當中，方向不會偏離，質量有保證。組員不會由於無休止的修復未預料到的需求，加深組員對產品、對團隊、對領導者的信心，逐步像敏捷過分。這種就是增量型生命週期。

再講一個故事，最後一個。小A經過"增量型生命周"發現，隊員已經習慣這種高效的方法來工做且收穫頗深。小A決定換一種方法，即採用故事、將故事拆分紅一個個章節，經過卡片、時間盒的方式進行研發。

真正作到客戶/領導/組員對當下工做清晰明瞭，每日組員主動領取任務，經過看板、軟件等方式進行質量進度管理。Scrum/負責人必定要合理分配時間盒、嚴格按照約定的時間進行掌控。小A深知人是有惰性的，要懷疑一切，故小A無時無刻在調配組員在工做中須要的各項組員，嚴格把關，真作到」領導分配->組員領取「到」人人主動拉去任務，領取->反饋「的過分，人人都是團隊的小主人，領導負責人即便僕人。正是經過」需求->分析->設計->建立->測試「這種方式基於」迭代的敏捷生命週期方式「，將需求隔離，限制WIP，小A職務獲取了更高一步的提高，團隊人員收入也進行了一次大的調整，客戶/公司利益獲得最大化，實現共贏。

固然還有基於流程的敏捷生命週期：從TODO List中提去部分功能開始工做，而不是按照基於迭代的進度計劃開始工做。工做流的價值就體現出來了，限制在制WIP數，便於及時發現問題，減小需求表更式的返工，有團隊、業務方決定規劃、產品評審與回顧。

」需求變動->分析->建立->測試->限制WIP數「流程進行開發，是流程性敏捷生命週期的特色。WIP是豐田最先提出並應用的，關於WIP將會在專門的課程講，此處不贅述。

方法	特性	動做	交付	目標/成果
預測型	固定	整個項目期間執行一次	單次	管理成本加大
迭代型	變化	重複直到正確爲止	單次	正確、有效
增量型	變化	對給定的增量執行一次	頻繁部分	速度
敏捷性	變化	重複直到正確爲止	頻繁部分	將客戶利益最大化

迭代和增量型時敏捷生命週期的兩個重要概念：

迭代：像素描或臨摹，經過每一次的交付，反覆求真的過程，使軟件/項目的質量愈來愈清晰，從而提高軟件/項目的質量。

增量：像拼圖，每次交付多一點，經過功能數的不斷累積，使軟件/項目的質量愈來愈清晰，從而提高軟件/項目的質量。

相信看到這裏，你們可能有疑問，講了這麼多，到底哪一個合適，能不能兩個都用？恭喜你，你已經步入敏捷的開發模式中了。

混合生命週期：項目並非使用單一的方法，醫生經過」望聞問切「來診斷病人，項目也不例外。須要經過各類組合，根據週期的不一樣來組建適合團隊的敏捷方式。例：」預測、迭代、增量、敏捷：迭代型、增量型「的組合或協調（僕人）式的方法，Scrum、看板、XP等要素構建一個跨職能的方案，來指導小組成員，包括衝刺計劃、日立會、評審、回顧/覆盤的方式進行敏捷項目開發。項目管理的目標是在特定的環境下，採用最好的方式創造最大商業價值。

最後在囉嗦一句」沒有固定的一種模式，只有符合當下的多種組合「，團隊的經驗水平、客戶合做度、項目須要多個團隊合做、組員缺乏敏捷方法的經驗等都應列爲考慮的因素。

」在我漫長的一輩子中，有多少小小的子彈和霰彈落到了個人身上，不知從哪兒飛來，擊中個人心靈，因而給我留下許多彈傷。而當個人生命已近暮年，這些數不盡的傷口，開始癒合了。在那曾經受傷的地方，就生長出思想來。「《思想的誕生》附送語錄