敏捷式流程

什麼是敏捷？

    敏捷是指能夠讓團隊思考更加有效，工作更加高效，並且作出更好決策的一組方法和相關理念。

敏捷能夠帶來的直接效益

1. 專案可以按時完成。
2. 專案會交付高質量的軟體。
3. 專案的程式碼結構優良且易於維護。
4. 不會交付無法為使用者帶來價值的軟體。
5. 開發人員不用加班。

敏捷軟體開發宣言

1. 個體和互動高於流程和工具。
2. 可工作的軟體高於詳盡的文件。
3. 客戶寫作高於合同談判。
4. 響應變化高於遵循計劃。

敏捷的核心

    敏捷是一種思維模式，所有敏捷方法的重點都是改變團隊的思維模式，正確的思維模式有助於團隊成員共享資訊，從而共同做出重要的專案決策，而不是讓經理獨自負責所有的決策。

敏捷小試-每日站立會議的困惑

    一個專案經理想要在團隊中開展每日站立會議，卻驚訝的發現並不是所有人都立即表示贊同，有的人覺得每天的會已經夠多了，又要增加一個會議，會耽誤自己開發程式碼的時間，會導致加班。

    那麼這個時候專案經理就要給大家說明，站立會議不僅僅是為了檢查團隊成員是否偏離了自己的計劃，還要嘗試李解群策群力下計劃可能要發生怎樣的改變。要讓每個開發人員意識到，在專案中所有人都是平等的，都是專案的決策者，在站立會議中可以聆聽其他專案參與者將專案開發到什麼方向，一個優秀的開發人員不僅對自己的程式碼有想法，而且常常對整個專案的發展方向懷有見解。

    即使還是仍然有人覺得每日站立會議就是倉促的彙報每日的進度，那麼從長遠角度來講，站立會議還是有必要的，他會對專案經理自己和整個團隊都有幫助。

瀑布式流程

瀑布式的一般流程

    首先會有人對要開發的軟體寫出一份詳盡的描述。然後將這份文件交付，由使用者、經理和主管同意後，將這些描述寫一份需求文件，再將這份需求文件交給開發團隊進行構建，最後測試團隊介入，驗證完成的軟體與需求文件是否匹配。

瀑布式流程經常遇到的困難

1. 需求說明書經常變化，到達開發團隊手中的那一刻，需求說明書可能已經不是很準確了，當開發團隊完成軟體構建的時候，需求說明書可能已經面目全非了。經常會出現客戶中途反悔，要求開發和最初計劃完全不同的功能。又或者出現客戶和客戶經理以及主管確定了要更改的功能，但是並未即使通知開發團隊，直至最後才發現做的不是所要的內容。
2. 即使團隊完全理解了需求，需求不予變更，也會常常因為使用糟糕的工具，而且在軟體設計和架構設計上遇到了很多困難，結果團隊總是開發出有很多bug的軟體，並且往往混亂而不可維護。又或者需求變更了，但是開發人員並不願意捨棄大量已經編寫完畢的程式碼，就會在現有程式碼上商定出一個修改方案，這樣完成的修改極易出現bug。

瀑布式流程缺點

1. 過分嚴格的文件。
2. 糟糕的溝通。
3. 程式碼中的大量bug。

瀑布式流程完成優秀軟體的特點

    雖然瀑布式流程有一些缺點，但是仍然有很多優秀的軟體是使用瀑布式流程完成的，並且穩定的需求並不是瀑布式流程成功的唯一因素。優秀的瀑布式流程開發的軟體都有如下特點：

1. 溝通順暢。開發團隊會不斷的與使用者、經理和主管溝通，確保所有的修改都在最開始階段。
2. 實踐得力。積極引入程式碼審查以及自動化測試。階段性的進行程式碼審查，自行檢視程式碼中的問題，並且引入自動化單元測試，輔助定位。也就是說，要求團隊主動思考bug是怎樣產生的。
3. 多數文件很少開啟。大部分瀑布式的團隊都明白，寫下計劃的重要性遠遠比嚴格執行這份計劃要重要的多。