前情回顧，上一節(jié)我們了解到，敏捷起源的背景、宣言、原則；也對以上做了初步的梳理。今天我們開始揭開敏捷神秘面紗的第二層“生命周期”。提到“生命周期”詳細大伙一定不陌生，誠然IT語言：C、C++、C#、JAVA等都有一套自己的生命周期，大伙也玩的賊溜。今天吶，不講開發(fā)語言的生命周期，將敏捷的生命周期。
提到敏捷的項目生命周期，要先從傳統(tǒng)型的說起。我們是否習(xí)慣了先做計劃（需求調(diào)研)->分析文檔->確定需求->設(shè)計(原型)->確定->編碼->測試->實施交付->諾曼底D日(噩夢的開始)；或者是這樣的需求->設(shè)計->實施->諾曼底D日重現(xiàn)。
看到這里，別吃驚，為何我重復(fù)提諾曼底D日，在諸多影片中，該行動被塑造成英勇悲壯受世人傳頌。但我要說的是，IT界不提倡這種英勇和悲壯。IT不提倡個人獨立作戰(zhàn)，注重團隊合作+和客戶合作+靈活的策略=持續(xù)有質(zhì)量的輸出。
團隊有多種形式，人員形形色色，也有多種實施方式，我們要在一個個成功/失敗的項目中總結(jié)其特性，形成一種行之有效的團隊管理方法。在這里，忍不住說一句：“不要畏懼失敗，要正視失敗，從中提煉出供團隊、成員學(xué)習(xí)、改變的一些正確的經(jīng)驗和方法。
從上面我們可以看出，我所提的兩種方式可以歸納到”預(yù)測型生命周期“，何為預(yù)測型生命周期？這是一種傳統(tǒng)的方法，和ASP一樣古老，即提前進行大量的計劃工作，然后一次連續(xù)執(zhí)行，直至項目編碼終結(jié)。在該過程中，不會有任何的商業(yè)或功能的交付。這種方法有效，也有弊端。這里只講弊端，設(shè)想一下這么個場景，A集團下分部IT，某天接到A的指示，做一個OA系統(tǒng)。OK，部門負責人開始走”分析->設(shè)計->創(chuàng)建->測試->交付“這么一個流程。邏輯上沒有問題，但A只有在IT部交付那一刻，才知道軟件的功能。該過程期間A一直在想，這群人在做什么？是不是在偷懶？進度無法得知，那么，獎金、KPI怎么算？IT部負責人在人員氣氛不穩(wěn)時，向A申請經(jīng)費或時間來活躍氣氛，A會同意嗎？往往是開始A對IT部很信任，越往后信任度越低，自然各種福利待遇會逐漸減少。團隊成員會覺得被無情壓榨，部門負責人也相當委屈，長久以來，效率低、士氣低、人員流動性大。上節(jié)我們有講過團隊人最重要，人才流失產(chǎn)品質(zhì)量往往大折扣。最終兩個結(jié)果，1.負責人引咎辭職；2.產(chǎn)品嚴重不符合預(yù)期，后期不斷的修改，人員怨聲載道，工期一拖再拖，項目以流產(chǎn)告終.....
迭代型生命周期：這種方法允許對未完成的工作進行反饋，從而改變和修改工作的方法，項目復(fù)雜度高、變更頻繁適用這種方式，自然”瀑布式\預(yù)測型生命周期“也適合這種方式。優(yōu)勢在于反饋-更改，進度可控，質(zhì)量可控。相信很多企業(yè)在用這種方式。
基于第一種的方式，我們更改下故事；小A接任上一任負責人，負責項目開發(fā)。小A基于以往踩過的坑，決定采用定期向總部交付，那怕軟件不完整，也要交付。
我們來看看小A是怎么做的，每次交付時，會在集團區(qū)里進行匯報：
1.本周期更新了什么。
2.參與人有哪些。
3.測試人員有哪些。
4.下次預(yù)估會交付哪些內(nèi)容。
收獲自然受到集團的好評，集團知道進度可控，對IT部信心增加，那么集團/客戶會更放手讓團隊去施展。筆者一直認為”一個好的領(lǐng)導(dǎo)，做事要有策略、手段。敏銳感知團隊、客戶的動向，發(fā)現(xiàn)異常后及時通過一定的手段進行調(diào)整，將利益最大化。而不是，踩著部下向上爬..一味的去迎合客戶、上級，會翻車的。“
扯遠了，還有個好處是，通過這種方法，項目在開發(fā)過程中，方向不會偏離，質(zhì)量有保證。組員不會因為無休止的修復(fù)未預(yù)料到的需求，加深組員對產(chǎn)品、對團隊、對領(lǐng)導(dǎo)者的信心，逐步像敏捷過度。這種就是增量型生命周期。
再講一個故事，最后一個。小A通過"增量型生命周"發(fā)現(xiàn)，隊員已經(jīng)習(xí)慣這種高效的方法來工作且收獲頗深。小A決定換一種方法，即采用故事、將故事拆分成一個個章節(jié)，通過卡片、時間盒的方式進行研發(fā)。
真正做到客戶/領(lǐng)導(dǎo)/組員對當下工作清晰明了，每日組員主動領(lǐng)取任務(wù)，通過看板、軟件等方式進行質(zhì)量進度管理。Scrum/負責人一定要合理分配時間盒、嚴格按照約定的時間進行掌控。小A深知人是有惰性的，要懷疑一切，故小A無時無刻在調(diào)配組員在工作中需要的各項組員，嚴格把關(guān)，真做到”領(lǐng)導(dǎo)分配->組員領(lǐng)取“到”人人主動拉去任務(wù)，領(lǐng)取->反饋“的過度，人人都是團隊的小主人，領(lǐng)導(dǎo)負責人即使仆人。正是通過”需求->分析->設(shè)計->創(chuàng)建->測試“這種方式基于”迭代的敏捷生命周期方式“，將需求隔離，限制WIP，小A職務(wù)獲取了更高一步的提升，團隊人員收入也進行了一次大的調(diào)整，客戶/公司利益得到最大化，實現(xiàn)雙贏。
當然還有基于流程的敏捷生命周期：從TODO List中提去部分功能開始工作，而不是按照基于迭代的進度計劃開始工作。工作流的價值就體現(xiàn)出來了，限制在制WIP數(shù)，便于及時發(fā)現(xiàn)問題，減少需求表更式的返工，有團隊、業(yè)務(wù)方?jīng)Q定規(guī)劃、產(chǎn)品評審與回顧。
”需求變更->分析->創(chuàng)建->測試->限制WIP數(shù)“流程進行開發(fā)，是流程性敏捷生命周期的特點。WIP是豐田最早提出并應(yīng)用的，關(guān)于WIP將會在專門的課程講，此處不贅述。
迭代和增量型時敏捷生命周期的兩個重要概念：
迭代：像素描或臨摹，通過每一次的交付，反復(fù)求真的過程，使軟件/項目的質(zhì)量越來越清晰，從而提升軟件/項目的質(zhì)量。
增量：像拼圖，每次交付多一點，通過功能數(shù)的不斷累積，使軟件/項目的質(zhì)量越來越清晰，從而提升軟件/項目的質(zhì)量。
相信看到這里，大家可能有疑問，講了這么多，到底哪個合適，能不能兩個都用？恭喜你，你已經(jīng)步入敏捷的開發(fā)模式中了。
混合生命周期：項目并不是使用單一的方法，醫(yī)生通過”望聞問切“來診斷病人，項目也不例外。需要通過各種組合，根據(jù)周期的不同來組建適合團隊的敏捷方式。例：”預(yù)測、迭代、增量、敏捷：迭代型、增量型“的組合或協(xié)調(diào)（仆人）式的方法，Scrum、看板、XP等要素構(gòu)建一個跨職能的方案，來指導(dǎo)小組成員，包括沖刺計劃、日立會、評審、回顧/復(fù)盤的方式進行敏捷項目開發(fā)。項目管理的目標是在特定的環(huán)境下，采用最好的方式創(chuàng)造最大商業(yè)價值。
最后在啰嗦一句”沒有固定的一種模式，只有符合當下的多種組合“，團隊的經(jīng)驗水平、客戶合作度、項目需要多個團隊合作、組員缺少敏捷方法的經(jīng)驗等都應(yīng)列為考慮的因素。
”在我漫長的一生中，有多少小小的子彈和霰彈落到了我的身上，不知從哪兒飛來，擊中我的心靈，于是給我留下許多彈傷。
而當我的生命已近暮年，這些數(shù)不盡的傷口，開始愈合了。
在那曾經(jīng)受傷的地方，就生長出思想來。“《思想的誕生》附送語錄
