世界上不存在這樣一種方法：

只要套用，就可以寫出完美的軟件，無論使用的哪種設計模式;

但確實可能存在一種開發方式，可以幫助我們一步步構造出需要的軟件和架構——這有可能就是敏捷開發。

相對于軟件開發流程，有一門專門的學科——軟件工程。最早接觸軟件工程，是20年前在北電貝爾北方實驗室工作的時候，當時的開發流程是這樣的：

其他主流的瀑布式開發流程也大致如此。然而，隨著技術的演進，尤其是互聯網的發展，BS架構的廣泛應用，用戶反饋的及時響應成為了可能。從90年代開始逐漸引起廣泛關注的一些新型軟件開發方法出現了，如XP ( Extreme Programming )，Scrum 等，統稱為敏捷開發。敏捷開發主要是通過高透明性、可檢驗性和適應性來管理復雜性、不可預測性和變化。

以Scrum為例，典型的開發模型如下：

這是一張被廣泛引用的圖片，還有一張爛大街的圖片就是Sprint 的流程圖：

難點在于一個sprint周期有多長，個人覺得Sprint周期的長度要依賴于你能在多長時間內保證在Sprint期間的需求不發生變更。

敏捷是一種方式，不是單純的方法，通過各種的行為方式來實現目標。

首先是，Sprint 計劃會議。計劃會議要有足夠的時間，最好至少8個小時。取出部分產品需求做成sprint需求，并寫成索引卡。確定并細分每一個索引卡的故事(User Story), 然后進行工作認領(不是分配)。同時，確定每日站立會議的時間和地點，確定好演示會議和回顧會議的日期。

站會是敏捷中的一個顯著特點，每次10-15分鐘，遲到將接受懲罰，每個成員自問自答三個問題：昨天做了什么，今天要做什么和遇到了什么問題，會后再溝通問題的解決方案，最重要的是更新燃盡圖。

在開發過程中，要使用好任務看板，關注產品的整個生命周期：需求，設計，開發，測試和維護。注意燃盡圖，對于小團隊而言，建議不要使用軟件取代看板，可以選擇性的和XP或其它敏捷的某些方式相結合。

演示會議是至關重要的。演示是跨團隊的，會產生不同團隊之間的交流。不要關注太多的細節，以主要的功能為主，一定要讓老板或者客戶看到。演示會議

非常的重要，絕對不可以被忽略。

回顧會議的時間一般在1-3個小時，要找最舒適的地方(最好有回顧看板)。開始的時候輪流發言，而不是主動發言。記錄問題并總結，并討論改進的方法，放在回顧看板上。每人將最重要的2-3個改進點，成為下一輪產品需求的一部分。

還是那就話，“沒有銀彈”，敏捷也不是萬能的。Scrum的主要缺陷有，團隊壓力大，不方便跨時區和跨語言的協同團隊，而且一旦啟動無法被中斷，更重要的是程序維護的成本偏高，對工程師的要求較高，尤其是應用的架構和可擴展性。

但是，敏捷開發的12個準則還是應該理解的，個人總結成一句話，按花生醬，贊不絕口。

Clic 按

Concise：簡潔開發

要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。

Lean：精益求精

對技術的精益求精以及對設計的不斷完善將提升敏捷性

Iteration：高速迭代

要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好

Change：擁抱需求變更

歡迎對需求提出變更——即使是在項目開發后期。要善于利用需求變更，幫助客戶獲得競爭優勢。

Jif 花生醬

Join：全員參與

項目過程中，業務人員與開發人員必須在一起工作

Incentive：員工激勵

要善于激勵項目人員，給他們以所需要的環境和支持，并相信他們能夠完成任務。

Face2Face：當面溝通

無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。

Raves 贊不絕口

Rethink：反思

團隊要定期反省如何能夠做到更有效，并相應地調整團隊的行為

Availabiltiy：可用第一

可用的軟件是衡量進度的主要指標。

Value：盡快給用戶帶來價值

最高目標是，通過盡早和持續地交付有價值的軟件來滿足客戶。

Evenly：勻速前進

敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恒久穩定的進展速度。

Self-orgnazation：自組織團隊

最佳的架構、需求和設計出自于自組織的團隊。


敏捷開發乃至一般的開發過程都會涉及到一件事，任務估點，就如何見招拆招。個人覺得，一個task 最好以2個小時為單位，半小時設計，半小時編碼，半小時測試，半小時文檔、注釋以及重構。原因可能是這樣的，互聯網上流傳著一句名言——3個月就是一年，也就是1周相當于1個月。那么，2個小時就相當于1天了，也就是說，我們的團隊要將每兩個小時當成一天來計算。眾所周知，所有的估算都是不準確的，以2小時為單位是為了降低誤差。就像我們度量的時候，以米為單位度量，誤差就是米，以毫米來量，誤差就是毫米。2個小時一個task，就相當于開發中的“毫米”。

敏捷開發中最重要的還是代碼，優秀的代碼質量決定著產品或者服務的質量。個人以為，有四種手段可以提升一下代碼質量：

1)意圖導向編程，簡單地說，就是把注釋變成代碼，讓代碼擁有自解釋性

2)測試驅動開發，尤其是對后端而言更為重要，可以結合日志系統可以更快捷定位問題

3)創建和使用分離，這就是大家常說的“高內聚 低耦合”了

4)單點修改原則，單點修改可能只是一種理想狀態，但應該銘記在心

至于敏捷團隊，就是我提倡的ABC了：

具體的，我在舊文《和 <創時代>》中有描述，這里不在重復。對于團隊敏捷，我只想澄清項目和產品開發(project developement vs product developement)的區別，這兩者在目標上還是又著區別的，例如持續演進，架構的可擴展性等等。

老曹眼中的敏捷開發，還是以我喜歡的一行python 代碼作為共勉：

$ python -c "import this"

The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

【本文來自51CTO專欄作者老曹的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】