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

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

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

相對于軟件開發(fā)流程，有一門專門的學(xué)科——軟件工程。最早接觸軟件工程，是20年前在北電貝爾北方實(shí)驗(yàn)室工作的時(shí)候，當(dāng)時(shí)的開發(fā)流程是這樣的：

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

以Scrum為例，典型的開發(fā)模型如下：

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

難點(diǎn)在于一個(gè)sprint周期有多長，個(gè)人覺得Sprint周期的長度要依賴于你能在多長時(shí)間內(nèi)保證在Sprint期間的需求不發(fā)生變更。

敏捷是一種方式，不是單純的方法，通過各種的行為方式來實(shí)現(xiàn)目標(biāo)。

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

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

在開發(fā)過程中，要使用好任務(wù)看板，關(guān)注產(chǎn)品的整個(gè)生命周期：需求，設(shè)計(jì)，開發(fā)，測試和維護(hù)。注意燃盡圖，對于小團(tuán)隊(duì)而言，建議不要使用軟件取代看板，可以選擇性的和XP或其它敏捷的某些方式相結(jié)合。

演示會(huì)議是至關(guān)重要的。演示是跨團(tuán)隊(duì)的，會(huì)產(chǎn)生不同團(tuán)隊(duì)之間的交流。不要關(guān)注太多的細(xì)節(jié)，以主要的功能為主，一定要讓老板或者客戶看到。演示會(huì)議

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

回顧會(huì)議的時(shí)間一般在1-3個(gè)小時(shí)，要找最舒適的地方(最好有回顧看板)。開始的時(shí)候輪流發(fā)言，而不是主動(dòng)發(fā)言。記錄問題并總結(jié)，并討論改進(jìn)的方法，放在回顧看板上。每人將最重要的2-3個(gè)改進(jìn)點(diǎn)，成為下一輪產(chǎn)品需求的一部分。

還是那就話，“沒有銀彈”，敏捷也不是萬能的。Scrum的主要缺陷有，團(tuán)隊(duì)壓力大，不方便跨時(shí)區(qū)和跨語言的協(xié)同團(tuán)隊(duì)，而且一旦啟動(dòng)無法被中斷，更重要的是程序維護(hù)的成本偏高，對工程師的要求較高，尤其是應(yīng)用的架構(gòu)和可擴(kuò)展性。

但是，敏捷開發(fā)的12個(gè)準(zhǔn)則還是應(yīng)該理解的，個(gè)人總結(jié)成一句話，按花生醬，贊不絕口。

Clic 按

Concise：簡潔開發(fā)

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

Lean：精益求精

對技術(shù)的精益求精以及對設(shè)計(jì)的不斷完善將提升敏捷性

Iteration：高速迭代

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

Change：擁抱需求變更

歡迎對需求提出變更——即使是在項(xiàng)目開發(fā)后期。要善于利用需求變更，幫助客戶獲得競爭優(yōu)勢。

Jif 花生醬

Join：全員參與

項(xiàng)目過程中，業(yè)務(wù)人員與開發(fā)人員必須在一起工作

Incentive：員工激勵(lì)

要善于激勵(lì)項(xiàng)目人員，給他們以所需要的環(huán)境和支持，并相信他們能夠完成任務(wù)。

Face2Face：當(dāng)面溝通

無論是團(tuán)隊(duì)內(nèi)還是團(tuán)隊(duì)間，最有效的溝通方法是面對面的交談。

Raves 贊不絕口

Rethink：反思

團(tuán)隊(duì)要定期反省如何能夠做到更有效，并相應(yīng)地調(diào)整團(tuán)隊(duì)的行為

Availabiltiy：可用第一

可用的軟件是衡量進(jìn)度的主要指標(biāo)。

Value：盡快給用戶帶來價(jià)值

最高目標(biāo)是，通過盡早和持續(xù)地交付有價(jià)值的軟件來滿足客戶。

Evenly：勻速前進(jìn)

敏捷過程提倡可持續(xù)的開發(fā)。項(xiàng)目方、開發(fā)人員和用戶應(yīng)該能夠保持恒久穩(wěn)定的進(jìn)展速度。

Self-orgnazation：自組織團(tuán)隊(duì)

最佳的架構(gòu)、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。


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

敏捷開發(fā)中最重要的還是代碼，優(yōu)秀的代碼質(zhì)量決定著產(chǎn)品或者服務(wù)的質(zhì)量。個(gè)人以為，有四種手段可以提升一下代碼質(zhì)量：

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

2)測試驅(qū)動(dòng)開發(fā)，尤其是對后端而言更為重要，可以結(jié)合日志系統(tǒng)可以更快捷定位問題

3)創(chuàng)建和使用分離，這就是大家常說的“高內(nèi)聚 低耦合”了

4)單點(diǎn)修改原則，單點(diǎn)修改可能只是一種理想狀態(tài)，但應(yīng)該銘記在心

至于敏捷團(tuán)隊(duì)，就是我提倡的ABC了：

具體的，我在舊文《和 <創(chuàng)時(shí)代>》中有描述，這里不在重復(fù)。對于團(tuán)隊(duì)敏捷，我只想澄清項(xiàng)目和產(chǎn)品開發(fā)(project developement vs product developement)的區(qū)別，這兩者在目標(biāo)上還是又著區(qū)別的，例如持續(xù)演進(jìn)，架構(gòu)的可擴(kuò)展性等等。

老曹眼中的敏捷開發(fā)，還是以我喜歡的一行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專欄作者老曹的原創(chuàng)文章，作者微信公眾號(hào)：喔家ArchiSelf,id:wrieless-com】