背景

隨著組織架構(gòu)的調(diào)整，產(chǎn)品越來越期望能夠快速驗證自己的猜想假設(shè)。作為技術(shù)負(fù)責(zé)人必然不想壓榨組員，然后準(zhǔn)備從工作流程下手。

過程

關(guān)于優(yōu)化工作流程，業(yè)內(nèi)很早就開始推崇敏捷開發(fā)。但是，敏捷開發(fā)適用于所有公司嗎？不見得。
其核心原則卻深深令我著迷。

主張簡單、擁抱變化、你的第二個目標(biāo)是可持續(xù)性、遞增的變化、令投資最大化、有目的的建模、多種模型、高質(zhì)量的工作、快速反饋、軟件是你的主要目標(biāo)、輕裝前進(jìn)

基于此，我決定基于敏捷開發(fā)創(chuàng)造一套屬于我們自己的敏捷開發(fā)流程。

關(guān)于瀑布式開發(fā)

瀑布模型式是最典型的預(yù)見性的方法，嚴(yán)格遵循預(yù)先計劃的需求、分析、設(shè)計、編碼、測試的步驟順序進(jìn)行。步驟成果作為衡量進(jìn)度的方法，例如需求規(guī)格，設(shè)計文檔，測試計劃和代碼審閱等等。
瀑布式的主要的問題是它的嚴(yán)格分級導(dǎo)致的自由度降低，項目早期即作出承諾導(dǎo)致對后期需求的變化難以調(diào)整，代價高昂。瀑布式方法在需求不明并且在項目進(jìn)行過程中可能變化的情況下基本是不可行的。

關(guān)于敏捷開發(fā)

敏捷開發(fā)以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)。在敏捷開發(fā)中，軟件項目在構(gòu)建初期被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。

兩種模式對比

瀑布開發(fā)

• 客人到餐館來點菜（新項目）
• 不確定客戶想吃什么的時候，通常選好餐廳后會先看看餐廳的菜單（客戶往往提不出具體的需求）
• 根據(jù)圖文菜單，客人點了十個菜（根據(jù)原型和設(shè)計稿，基本確定了需求）
• 后廚開始準(zhǔn)備（項目啟動）
• 根據(jù)客人的下單配菜，炒菜（基本上不會主動去了解完整需求）
• 半個小時了，菜還沒上桌，客人餓極了（項目啟動后很長一段時間客戶什么都看不到）
• 再過了二十分鐘，十個菜都一起上來了（項目最終一次交付）
• 客人說，有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重復(fù)了想換掉（我是買單的，我要變需求）
• 這時候大堂經(jīng)理來了，說，“味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經(jīng)炒好的那兩盤菜也是要算成本的”（瀑布的壞處，需求變更比較麻煩）
• 于是，后廚只給客戶加了鹽，加了辣
• 客人吃完，不是很滿意，下次不來了（沒有滿足需求）

敏捷開發(fā)

• 客人到餐館來點菜（新項目）
• 不確定客戶想吃什么的時候，通常選好餐廳后會先看看餐廳的菜單（客戶往往提不出具體的需求）
• 根據(jù)圖文菜單，客人點了是個菜（根據(jù)原型和設(shè)計稿，基本確定了需求）
• 后廚開始準(zhǔn)備（項目啟動）
• 配菜、炒菜，先上了兩盤，讓客人嘗了嘗味道（先提供可用實例給客戶用）
• 客人說還不錯，后廚繼續(xù)準(zhǔn)備后面的菜，陸續(xù)上菜（不斷迭代，不斷測試）
• 上菜過程中，客人突然發(fā)現(xiàn)有個菜的味道太淡了，讓后廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）
• 又上了兩盤，不夠辣，又拿到后廚加了辣（敏捷的壞處，需求沒有提前明確，反復(fù)迭代，增加了工作量）
• 到最后兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）
• 客人吃完，很滿意（基本滿足了全部的要求）

迭代流程管理

我們是用teambition來管理的。下面是一個簡化的tb流程，根據(jù)自己的業(yè)務(wù)可以靈活調(diào)整
歡迎大家討論，如有疑問可留言私信

敏捷開發(fā)流程圖

scrum2.0.png