關於敏捷開發和憋個大招兩種開發方式的思考

      憋個大招的開發方式很是不適合團隊合做，並且極其容易致使項目延期。

      當你沒見過更優秀的溝通合做方式的時候，你覺得如今的開發方式和合做方式就是正常的樣子，其實本質來講就是見的少，遇到的少，但是話又說回來，當咱們以爲合做方式很是累的時候，爲何想不到去尋找更加優質的合做方式呢？僅僅只是在被動承受着這樣的合做方式。

      或者說能夠不能夠這樣理解，公司在項目最初期的時候，是不適合敏捷開發的？就是要集中精力先出一個能夠用的版本？

      不對，不是項目初期不適合敏捷開發，任何階段的項目都適合敏捷開發，敏捷開發原本就是兩到六週的一個時間段，在項目初期急需出成果的時候，迭代週期根據須要和規劃進行適當的延長，最顯著的例子好比移動端，一般來講web 端的發版要比移動端更加靈活一些，所以移動端就須要更長的迭代週期，可是測試周最多不要超過兩週，而且能夠中間加入一個過渡周，即開發的同時和測試二者並行，和測試溝通好開發這邊會先進行哪些需求的提測，一次迭代週期過長對於項目的穩定性來講不是一件好事，同時對於開發人員來講週期過長會致使代碼質量顯著下降，bug 增長反而致使了更多的問題，所以兩或三週一次迭代，小步快跑，能讓項目更加靈活，同時各方都能以最快的速度看到成果和初期的效果，這也是敏捷開發的優點所在。

      採用敏捷開發的方式，配合諸如 worktile、Teambition等企業協做平臺，能夠很好的實現各方的信息同步、項目進度管理、項目週期規劃、OKR 定製等各類事務，避免溝通全靠吼的合做方式，至少在合做方式上能讓各方達到一個比較滿意的狀態，具體的執行和產出就須要各個層級的領導人去進行監管和溝通。

      每次迭代開始時，需求評審完畢以後根據現有開發人員數量進行初步開發估時（n*8*5，n 表明開發人員數量），若是項目時間不緊張，按照嚴格的時間標準進行開發，能夠超出10%-20%的估時工做量，可是絕對不能再多了，由於超出預期的估時會有很大的風險形成上線延期，敏捷開發中延期的後果是很是嚴重的，由於每次迭代週期是相對獨立的，若是又一次延期，那麼必將影響下一次迭代，若是出現兩次延期，就至關於少了一次迭代，這是得不償失的，對於各方對接部門的影響也是很是大的。

 

敏捷開發迭代流程必定要根據當前項目狀況和團隊狀況進行制定，根據執行過程當中出現的各類問題進行討論並進行流程微調，不斷的讓流程更加適合於本身的團隊。

 

上述想法是在剛畢業時進入一個一個高效的敏捷開發團隊中所學到的，人最大的優點就是不斷的反思調整總結，最終找到更加合適東西，若是在現階段發現錯誤，那麼及時調整，作到更好。