原敏捷開發專案啟動

確定人員，保持小而靈活的團隊。

先行開發確定需求，不浪費所有人的時間，實際是把整體的開發時間都提前了。

相對於瀑布流，團隊所有成員一次把專案的所有細節都研究詳細了，再開始開發工作，這裡面有個弊端是，我們發現每次需求過來的時候，通常情況下大部分的邏輯設計都還是相對清晰的，而卡出的地方往往佔少部分，完全沒必要把所有的人都拉到一起確認，開會是個很耗時間的東西，一兩天很容易就廢掉了。

這種情況下，其實那些「大部分清晰的需求」是可以先行開始，只需要專案負責人或者scurm master來和產品確認有問題的部分，然後轉達給其他成員，保持團隊資訊透明。

分析到什麼程度？

流程可通，預留時間給團隊成員，和產品確認問題，最多兩天時間。

只要成員可以根據需求順利的估算時間，而且估算時間本身不太需求特別細節的追究，別把實現方式放到估算中討論，把問題放到領取這個故事的人，減少在多數人參加會議情況下的時間。而且時間估算本身就是預估，是乙個參考值，在總體的時間上達到乙個平均值就可以。

雙向溝通，相互講解

首先產品給研發講解需求，然後研發拿到需求詳細分析，再給產品講一遍，保證開發前理解無偏差。

確定本次迭代目標

這點非常重要，必須讓大家都非常明確本次目標，開發範圍，要做的事情。

scrum master

scrum master一定要把自己從**中解放出來，不要抱著領故事寫**，推動團隊順利進行更重要，團隊建設和完善，需要更多時間思考。

原 敏捷開發 專案啟動