最適合App的開發模式——敏捷開發

傳統的軟體開發模式需要經歷問題評估、計劃解決方案、設計系統架構、開發程式碼、測試、部署和使用系統、維護解決方案等過程，如下圖↓

採用傳統軟體開發模式的最大問題是開發週期過長，迭代速度慢。移動網際網路行業發展速度快，需求不斷變化，產品更新迭代的頻率高，基於移動網際網路的以上特點，就引入了Scrum這個敏捷開發框架。

Scrum簡介：Scrum是一個敏捷開發框架，是一個增量的，迭代的開發過程。在這個框架中，整個開發週期包括若干個小的迭代週期，每個小的迭代週期成為一個Sprint，每個Sprint的週期建議為2~4周。在Scrum中，使用產品Backlog

Scrum的流程如下圖↓

Sprint 計劃會議

Sprint計劃會議前，產品經理所要實現的產品需求（產品Backlog）以使用者故事（即從使用者的角度去描述使用者所需的功能）的形式確定下來，並畫出原型圖，UI根據原型圖完成設計稿。產品經理同時確定各個產品需求的優先順序。

Sprint計劃會議期間（一般為2天），開發團隊的成員不應該做任何開發工作，要將全部精力放在把產品需求分解成一個個開發任務，並估算開發時間。

估算開發時間需要注意以下幾點。

1、對於所需要使用的新技術，要估算學習和調研的時間。

2、根據統計，每個程式設計師每天的有效工作時間是5個 小時左右，其他時間都被溝通、喝水、休息、上洗手間等瑣事佔據，如果某個任務估算超過5個小時，那就代表了這個任務完成需要超過一天的時間。

3、開發人員對於開發任務的估算儘可能精細，一般來說，每個任務的估算時間不應該超過5個小時，如果超過5個小時，就應該把這個任務再細分為多個更小的任務。只要儘可能精細地估算任務，總體估算時間是大概精確的，因為有的任務估算的時間比實際完成的多，有的比實際完成的少。

最後根據產品經理的優先順序和開發人員的估算時間，確定這個迭代週期最終的開發任務和其對應的優先順序，即完成

日常開發

App開發中，App通過API和App後臺互動，後臺人員可以先設計好相關的API並讓API返回假資料。

開發過程中遇到任何問題，必須及時找相關人員溝通。為了保證溝通的效果，可以採用下面的方法。

1、如果不是非常緊急的問題，可以等相關人員休息的時候再溝通。

2、解決一個問題，先梳理好情緒，溝通的時候對事不對人。

Scrum中有個關鍵的職位“Scrum master”，Scrum master一般有技術總監擔任，團隊和外部的溝通必須統一通過Scrum master。Scrum master的最大作用是遮蔽外部對開發團隊的影響，使開發的進度和開發的效率得到保證。

在開發的過程中需要注意：一個Sprint Backlog中，需求不能變更，UI確定後原則上只能做小修改。產品有新需求，下一個Sprint Backlog再考慮。

每日例會

每日例會前，團隊成員應該整理各自的任務列表，包括：

1、昨天完成了哪些任務，每個任務使用了多少時間，沒完成的任務估算還要多少時間。

2、剩餘的開發時間

例會中產品經理和開發團隊的成員都要參加，如果可以的話，讓運營人員和市場人員也參與進來，這樣可以使團隊每個成員都對公司的產品有個整體的瞭解。

每個人在例會上報告一下3方面的事情。

1、昨天做了哪些工作？

2、今天準備做哪些工作？

3、有什麼工作需要其他同事配合？

注意避免在會議上討論問題，如果真的需要討論，請在會議後和同事討論，不要浪費整個團隊的時間。

測試和修復BUG

產品開發完成就進入測試和修復BUG的階段。

測試人員把測試得到的問題提交到BUG管理軟體，每個BUG應該包含3個部分。

1、問題描述和重新步驟

2、測試人員

3、負責解決這個問題的人員，如果測試人員不知道具體負責人，把這個問題提交給技術總監，由技術總監指定解決問題的研發人員。

評審會議

在測試和修復BUG完成後全體人員開評審會議。相關開發人員在評審會議中向全體人員演示APP的功能。

回顧會議

研發完成後開回顧會議，每個成員都在會議中提兩點。

1、這輪迭代過程中做得好的地方。

2、這輪迭代過程中做得不好的地方。

這個過程走兩輪，即每個成員都要提兩點做得好和不好的地方。注意當一個成員提出自己的意見時，其他成員不做任何的評論。

及時反饋

可以通過建立相關QQ群收集意見，在APP中可以增加一個意見反饋的功能。

總結

敏捷開發不是萬能的，敏捷開發更適用於需求多變，開發週期端的專案。