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

這是一次一個面向老板出產品的經歷，一個傳統互聯網公司想要轉型成移動互聯網公司的關鍵節點上，當時經過很長一段時間的產品調研和業務流程的梳理，每次會上都會有近十個總監級別的各個部門老大。

由于每次意見不統一，僵持不下，導致產品一拖再拖。最后老板迫于壓力，在4月1日給出了一個命令，必須在4月20號做出來一個能看的產品。

迫于無奈，在4月10日進行封閉式開發，9天的時間完成了一個電商類型的小程序，已經面向酒店和公司的兩個后臺系統。

正是在這樣的情況下，才能夠體會到敏捷開發小而快思想的精髓。

第一點，我們遇到的問題

盡管，前期我們有進行一個相對比較長的研究，但是并沒有梳理形成一個完整體系。在整個研討會上，也沒有形成一個明確的產品目標以及產品的形態。以至于一直停留在梳理業務流程上，沒有一個比較實質的進展，即產品原型、產品架構幾乎空白。

面向老總出產品最尷尬的是他們不在意后臺系統，也就是他們往往會忽略后臺系統的工作量。公司又面臨了資金緊張裁員、UI團隊需要多方共用，一些系列問題。

總結一下我們遇到的問題：

1. 產品設計幾乎需要從0開始；
2. 大量的后臺系統開發工作量沒有被正確評估；
3. 研發團隊人數不過；
4. UI團隊無法All In。

以上的問題，當我們一起討論分析，如果想要快速滿足老板的需求，必須進行封閉式開發，而且整個團隊需要嚴格的控制和監管，降低風險，那么就必須要有一個更高效的協作方式來完成目標。

所以，我們選擇使用敏捷開發的團隊協作方式。

第二點，什么是敏捷開發

敏捷開發（Agile Development）是一種以人為核心、迭代、循序漸進的開發方法，通過快速、高效的反應速度，積極、高頻的溝通為客戶提供一條暢通的指揮通道。

開發方式一般分為：Scrum 和 XP。

Scrum： 團隊最佳人數控制在5～9人，一個迭代為四周時間，不允許需求的變更。

XP：更側重于測試驅動開發，一般迭代為1到2個星期，允許等量工作量的需求替換。

在整個開發過程中，因為技術團隊、產品團隊的成熟度還不高，無法提供完整的XP模式開發方式，而項目有偏向于使用XP模式。

綜合考慮，我們在Scrum和XP模式下吸取各自的優點：

1. 允許中途變更等量的需求，因為在整個過程中，很有可能面臨老板的新需求，必須做到快速響應；
2. 嚴格按照優先級進行開發，因為時間短，User Story之間很有可能存在依賴關系，如果沒有按照優先級進行開發很容易導致團隊有些成員很忙，有些成員符合無法達到飽和；
3. 采用產品經理驅動項目進度，而不是使用TDD模式，主要原因是因為整個技術團隊在TDD模式上未實踐過無法做到自我管理的程度，只能通過產品經理人肉測試和項目跟進；

第三點，我們怎么選定工具

敏捷開發是一種快速響應需求的開發方式，不同于傳統的瀑布式開發，在管理流程上也就不同。產品經理通過采集需求，整理出產品需求池（Product Backlog），然后輸出到研發團隊進行工作量評估、實現可行性，最后根據優先級進入到迭代需求池（Sprint Backlog）進行一輪迭代。

再通過每天的站立會進行對需求完成情況的審核，控制風險。

以下是一個完整的產品迭代的過程：

通過什么會議進行管理？

通常情況下，一個敏捷開發需要以下的會議來把控研發的進度：

1. Sprint 需求規劃會議
2. 項目立項需求同步會
3. Sprint 功能規劃會議
4. 估算會議——根據項目情況合并到 Sprint功能規劃會議
5. 每日立會
6. Sprint 評審會議（Review Meeting）——根據項目需要舉行
7. 項目復盤會議

當然，我們根據當時時間緊迫，在盡可能表達清楚需求的情況下，降低溝通的時間，這也導致了后續出現了一些問題。比如：整個團隊對項目的理解不夠深入，在開發過程中會存在一些偏差，導致需求返工的情況出現。

敏捷開發需要依靠什么工具進行管理？

在高強度的開發中，如果沒有一系列工具進行管理，將會讓整個項目失去控制。

敏捷開發的工具主要有：

• Excel 需求池，用于管理需求，一般分為產品需求（Product Backlog）和迭代需求（Sprint Backlog）；
• 任務看板，主要用于管理需求狀態，跟蹤延誤的需求，查找成員是否成為絆腳石；
• 燃盡圖，查看用戶用例（User Story）是否按照計劃如期完成；
• 計劃撲克牌，防止研發因為考慮不全導致預估工期不準確。

第四點，敏捷開發實踐過程及結果

成員組成：一個產品經理、一個交互設計師、一個后勤、3個后端工程師、3個前端工程師、機動UI設計團隊。

成果：完成一個小程序、兩個系統后臺。

實踐過程：

整個TAPD工作流設計：

產品規劃 => 交互設計 => UI設計 => 實現中 => 產品體驗 => 缺陷

缺陷的處理流程：

新 => 已接受 => 處理中 => 待驗收 => 已驗收 => 已關閉

我們在整個過程中，嚴格遵循以下幾個原則：

1. 產品設計需要拆分高內聚低耦合的模塊，設計并且及時輸出最小可用單元，保證項目不會產生類似瀑布流開發的模式。
2. 每日完成手頭上的需求才算完成當天的工作，確保每個人的需求能夠完成保證進度。
3. 每日晚上十點進行審核，事實上，為了讓大家能夠繼續加班到凌晨的小技巧，也確保缺陷不過日。
4. 每個模塊需要完整的走過工作流，也就包括缺陷，出現問題及時調整。

實踐遇到的問題：

• 剛開始團隊磨合工具，沒有及時變更工作狀態。
• 預留給產品設計的時間太少，導致產品設計并沒有太全面，邊界條件未充分考慮。
• 需求排優先級出現錯誤。
• 需求會沒有被重視，導致開發過程中需求重新開發。
• 測試環節節奏比較混亂，沒有從頭到尾測試聯調。
• 產品更新原型，缺少比較好的同步工具，讓所有人一直都是使用最新的文檔。

通過9天時間封閉式開發產生的數據：

由于離開上家公司的時候沒有整理出來這些資料，大致上，我們通過9天的時間完成了：

• 需求點大致上有300+個，采用前后端分開提需求點；
• 測試并且修復400條bug，基本上做到日清。

最后，注意事項

并不是所有的項目都適合用敏捷開發，在項目沒有特別明確的目標，團隊技術水平太弱、需要工期本身比較長無法細化顆粒度的情況下，使用敏捷開發會存在很多問題。

比如：

• 響應無法做到及時；
• 對工具的使用無法快速適應；
• 沒有明確目標，缺乏緊迫感。

等等一系列問題，都會讓整個敏捷開發變得不敏捷。

導致整個項目的燃盡圖呈現下圖這樣：

而正常的燃盡圖應該未關閉的線段貼合基線：

不過，嘗試使用敏捷開發小而快的開發思想在自己的項目管理過程中也是不錯的。

參考資料

1. 敏捷開發之Scrum掃盲篇
2. 敏捷開發（agile）中story
3. 讀書筆記Scrum 總結
4. 瀑布式開發、迭代開發、敏捷開發、XP與SCRUM的區別

本文由 @UShow Jack 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議