敏捷開(kāi)發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法，通過(guò)快速、高效的反應(yīng)速度，積極、高頻的溝通為客戶提供一條暢通的指揮通道。而作者經(jīng)歷了九天的封閉式開(kāi)發(fā)，在文中跟大家分享這次敏捷開(kāi)發(fā)的實(shí)踐經(jīng)歷。

這是一次一個(gè)面向老板出產(chǎn)品的經(jīng)歷，一個(gè)傳統(tǒng)互聯(lián)網(wǎng)公司想要轉(zhuǎn)型成移動(dòng)互聯(lián)網(wǎng)公司的關(guān)鍵節(jié)點(diǎn)上，當(dāng)時(shí)經(jīng)過(guò)很長(zhǎng)一段時(shí)間的產(chǎn)品調(diào)研和業(yè)務(wù)流程的梳理，每次會(huì)上都會(huì)有近十個(gè)總監(jiān)級(jí)別的各個(gè)部門(mén)老大。

由于每次意見(jiàn)不統(tǒng)一，僵持不下，導(dǎo)致產(chǎn)品一拖再拖。最后老板迫于壓力，在4月1日給出了一個(gè)命令，必須在4月20號(hào)做出來(lái)一個(gè)能看的產(chǎn)品。

迫于無(wú)奈，在4月10日進(jìn)行封閉式開(kāi)發(fā)，9天的時(shí)間完成了一個(gè)電商類型的小程序，已經(jīng)面向酒店和公司的兩個(gè)后臺(tái)系統(tǒng)。

正是在這樣的情況下，才能夠體會(huì)到敏捷開(kāi)發(fā)小而快思想的精髓。

第一點(diǎn)，我們遇到的問(wèn)題

盡管，前期我們有進(jìn)行一個(gè)相對(duì)比較長(zhǎng)的研究，但是并沒(méi)有梳理形成一個(gè)完整體系。在整個(gè)研討會(huì)上，也沒(méi)有形成一個(gè)明確的產(chǎn)品目標(biāo)以及產(chǎn)品的形態(tài)。以至于一直停留在梳理業(yè)務(wù)流程上，沒(méi)有一個(gè)比較實(shí)質(zhì)的進(jìn)展，即產(chǎn)品原型、產(chǎn)品架構(gòu)幾乎空白。

面向老總出產(chǎn)品最尷尬的是他們不在意后臺(tái)系統(tǒng)，也就是他們往往會(huì)忽略后臺(tái)系統(tǒng)的工作量。公司又面臨了資金緊張裁員、UI團(tuán)隊(duì)需要多方共用，一些系列問(wèn)題。

總結(jié)一下我們遇到的問(wèn)題：

1. 產(chǎn)品設(shè)計(jì)幾乎需要從0開(kāi)始；
2. 大量的后臺(tái)系統(tǒng)開(kāi)發(fā)工作量沒(méi)有被正確評(píng)估；
3. 研發(fā)團(tuán)隊(duì)人數(shù)不過(guò)；
4. UI團(tuán)隊(duì)無(wú)法All In。

以上的問(wèn)題，當(dāng)我們一起討論分析，如果想要快速滿足老板的需求，必須進(jìn)行封閉式開(kāi)發(fā)，而且整個(gè)團(tuán)隊(duì)需要嚴(yán)格的控制和監(jiān)管，降低風(fēng)險(xiǎn)，那么就必須要有一個(gè)更高效的協(xié)作方式來(lái)完成目標(biāo)。

所以，我們選擇使用敏捷開(kāi)發(fā)的團(tuán)隊(duì)協(xié)作方式。

第二點(diǎn)，什么是敏捷開(kāi)發(fā)

敏捷開(kāi)發(fā)（Agile Development）是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法，通過(guò)快速、高效的反應(yīng)速度，積極、高頻的溝通為客戶提供一條暢通的指揮通道。

開(kāi)發(fā)方式一般分為：Scrum 和 XP。

Scrum： 團(tuán)隊(duì)最佳人數(shù)控制在5～9人，一個(gè)迭代為四周時(shí)間，不允許需求的變更。

XP：更側(cè)重于測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，一般迭代為1到2個(gè)星期，允許等量工作量的需求替換。

在整個(gè)開(kāi)發(fā)過(guò)程中，因?yàn)榧夹g(shù)團(tuán)隊(duì)、產(chǎn)品團(tuán)隊(duì)的成熟度還不高，無(wú)法提供完整的XP模式開(kāi)發(fā)方式，而項(xiàng)目有偏向于使用XP模式。

綜合考慮，我們?cè)赟crum和XP模式下吸取各自的優(yōu)點(diǎn)：

1. 允許中途變更等量的需求，因?yàn)樵谡麄€(gè)過(guò)程中，很有可能面臨老板的新需求，必須做到快速響應(yīng)；
2. 嚴(yán)格按照優(yōu)先級(jí)進(jìn)行開(kāi)發(fā)，因?yàn)闀r(shí)間短，User Story之間很有可能存在依賴關(guān)系，如果沒(méi)有按照優(yōu)先級(jí)進(jìn)行開(kāi)發(fā)很容易導(dǎo)致團(tuán)隊(duì)有些成員很忙，有些成員符合無(wú)法達(dá)到飽和；
3. 采用產(chǎn)品經(jīng)理驅(qū)動(dòng)項(xiàng)目進(jìn)度，而不是使用TDD模式，主要原因是因?yàn)檎麄€(gè)技術(shù)團(tuán)隊(duì)在TDD模式上未實(shí)踐過(guò)無(wú)法做到自我管理的程度，只能通過(guò)產(chǎn)品經(jīng)理人肉測(cè)試和項(xiàng)目跟進(jìn)；

第三點(diǎn)，我們?cè)趺催x定工具

敏捷開(kāi)發(fā)是一種快速響應(yīng)需求的開(kāi)發(fā)方式，不同于傳統(tǒng)的瀑布式開(kāi)發(fā)，在管理流程上也就不同。產(chǎn)品經(jīng)理通過(guò)采集需求，整理出產(chǎn)品需求池（Product Backlog），然后輸出到研發(fā)團(tuán)隊(duì)進(jìn)行工作量評(píng)估、實(shí)現(xiàn)可行性，最后根據(jù)優(yōu)先級(jí)進(jìn)入到迭代需求池（Sprint Backlog）進(jìn)行一輪迭代。

再通過(guò)每天的站立會(huì)進(jìn)行對(duì)需求完成情況的審核，控制風(fēng)險(xiǎn)。

以下是一個(gè)完整的產(chǎn)品迭代的過(guò)程：

通過(guò)什么會(huì)議進(jìn)行管理？

通常情況下，一個(gè)敏捷開(kāi)發(fā)需要以下的會(huì)議來(lái)把控研發(fā)的進(jìn)度：

1. Sprint 需求規(guī)劃會(huì)議
2. 項(xiàng)目立項(xiàng)需求同步會(huì)
3. Sprint 功能規(guī)劃會(huì)議
4. 估算會(huì)議——根據(jù)項(xiàng)目情況合并到 Sprint功能規(guī)劃會(huì)議
5. 每日立會(huì)
6. Sprint 評(píng)審會(huì)議（Review Meeting）——根據(jù)項(xiàng)目需要舉行
7. 項(xiàng)目復(fù)盤(pán)會(huì)議

當(dāng)然，我們根據(jù)當(dāng)時(shí)時(shí)間緊迫，在盡可能表達(dá)清楚需求的情況下，降低溝通的時(shí)間，這也導(dǎo)致了后續(xù)出現(xiàn)了一些問(wèn)題。比如：整個(gè)團(tuán)隊(duì)對(duì)項(xiàng)目的理解不夠深入，在開(kāi)發(fā)過(guò)程中會(huì)存在一些偏差，導(dǎo)致需求返工的情況出現(xiàn)。

敏捷開(kāi)發(fā)需要依靠什么工具進(jìn)行管理？

在高強(qiáng)度的開(kāi)發(fā)中，如果沒(méi)有一系列工具進(jìn)行管理，將會(huì)讓整個(gè)項(xiàng)目失去控制。

敏捷開(kāi)發(fā)的工具主要有：

• Excel 需求池，用于管理需求，一般分為產(chǎn)品需求（Product Backlog）和迭代需求（Sprint Backlog）；
• 任務(wù)看板，主要用于管理需求狀態(tài)，跟蹤延誤的需求，查找成員是否成為絆腳石；
• 燃盡圖，查看用戶用例（User Story）是否按照計(jì)劃如期完成；
• 計(jì)劃撲克牌，防止研發(fā)因?yàn)榭紤]不全導(dǎo)致預(yù)估工期不準(zhǔn)確。

第四點(diǎn)，敏捷開(kāi)發(fā)實(shí)踐過(guò)程及結(jié)果

成員組成：一個(gè)產(chǎn)品經(jīng)理、一個(gè)交互設(shè)計(jì)師、一個(gè)后勤、3個(gè)后端工程師、3個(gè)前端工程師、機(jī)動(dòng)UI設(shè)計(jì)團(tuán)隊(duì)。

成果：完成一個(gè)小程序、兩個(gè)系統(tǒng)后臺(tái)。

實(shí)踐過(guò)程：

整個(gè)TAPD工作流設(shè)計(jì)：

產(chǎn)品規(guī)劃 => 交互設(shè)計(jì) => UI設(shè)計(jì) => 實(shí)現(xiàn)中 => 產(chǎn)品體驗(yàn) => 缺陷

缺陷的處理流程：

新 => 已接受 => 處理中 => 待驗(yàn)收 => 已驗(yàn)收 => 已關(guān)閉

我們?cè)谡麄€(gè)過(guò)程中，嚴(yán)格遵循以下幾個(gè)原則：

1. 產(chǎn)品設(shè)計(jì)需要拆分高內(nèi)聚低耦合的模塊，設(shè)計(jì)并且及時(shí)輸出最小可用單元，保證項(xiàng)目不會(huì)產(chǎn)生類似瀑布流開(kāi)發(fā)的模式。
2. 每日完成手頭上的需求才算完成當(dāng)天的工作，確保每個(gè)人的需求能夠完成保證進(jìn)度。
3. 每日晚上十點(diǎn)進(jìn)行審核，事實(shí)上，為了讓大家能夠繼續(xù)加班到凌晨的小技巧，也確保缺陷不過(guò)日。
4. 每個(gè)模塊需要完整的走過(guò)工作流，也就包括缺陷，出現(xiàn)問(wèn)題及時(shí)調(diào)整。

實(shí)踐遇到的問(wèn)題：

• 剛開(kāi)始團(tuán)隊(duì)磨合工具，沒(méi)有及時(shí)變更工作狀態(tài)。
• 預(yù)留給產(chǎn)品設(shè)計(jì)的時(shí)間太少，導(dǎo)致產(chǎn)品設(shè)計(jì)并沒(méi)有太全面，邊界條件未充分考慮。
• 需求排優(yōu)先級(jí)出現(xiàn)錯(cuò)誤。
• 需求會(huì)沒(méi)有被重視，導(dǎo)致開(kāi)發(fā)過(guò)程中需求重新開(kāi)發(fā)。
• 測(cè)試環(huán)節(jié)節(jié)奏比較混亂，沒(méi)有從頭到尾測(cè)試聯(lián)調(diào)。
• 產(chǎn)品更新原型，缺少比較好的同步工具，讓所有人一直都是使用最新的文檔。

通過(guò)9天時(shí)間封閉式開(kāi)發(fā)產(chǎn)生的數(shù)據(jù)：

由于離開(kāi)上家公司的時(shí)候沒(méi)有整理出來(lái)這些資料，大致上，我們通過(guò)9天的時(shí)間完成了：

• 需求點(diǎn)大致上有300+個(gè)，采用前后端分開(kāi)提需求點(diǎn)；
• 測(cè)試并且修復(fù)400條bug，基本上做到日清。

最后，注意事項(xiàng)

并不是所有的項(xiàng)目都適合用敏捷開(kāi)發(fā)，在項(xiàng)目沒(méi)有特別明確的目標(biāo)，團(tuán)隊(duì)技術(shù)水平太弱、需要工期本身比較長(zhǎng)無(wú)法細(xì)化顆粒度的情況下，使用敏捷開(kāi)發(fā)會(huì)存在很多問(wèn)題。

比如：

• 響應(yīng)無(wú)法做到及時(shí)；
• 對(duì)工具的使用無(wú)法快速適應(yīng)；
• 沒(méi)有明確目標(biāo)，缺乏緊迫感。

等等一系列問(wèn)題，都會(huì)讓整個(gè)敏捷開(kāi)發(fā)變得不敏捷。

導(dǎo)致整個(gè)項(xiàng)目的燃盡圖呈現(xiàn)下圖這樣：

而正常的燃盡圖應(yīng)該未關(guān)閉的線段貼合基線：

不過(guò)，嘗試使用敏捷開(kāi)發(fā)小而快的開(kāi)發(fā)思想在自己的項(xiàng)目管理過(guò)程中也是不錯(cuò)的。

參考資料

1. 敏捷開(kāi)發(fā)之Scrum掃盲篇
2. 敏捷開(kāi)發(fā)（agile）中story
3. 讀書(shū)筆記Scrum 總結(jié)
4. 瀑布式開(kāi)發(fā)、迭代開(kāi)發(fā)、敏捷開(kāi)發(fā)、XP與SCRUM的區(qū)別