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

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

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

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

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

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

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

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

敏捷是一種方式，不是單純的方法，通過(guò)各種的行為方式來(lái)實(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è)成員自問(wèn)自答三個(gè)問(wèn)題：昨天做了什么，今天要做什么和遇到了什么問(wèn)題，會(huì)后再溝通問(wèn)題的解決方案，最重要的是更新燃盡圖。

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

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

非常的重要，絕對(duì)不可以被忽略。

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

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

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

Clic 按

Concise：簡(jiǎn)潔開(kāi)發(fā)

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

Lean：精益求精

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

Iteration：高速迭代

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

Change：擁抱需求變更

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

Jif 花生醬

Join：全員參與

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

Incentive：?jiǎn)T工激勵(lì)

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

Face2Face：當(dāng)面溝通

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

Raves 贊不絕口

Rethink：反思

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

Availabiltiy：可用第一

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

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

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

Evenly：勻速前進(jìn)

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

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

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


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

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

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

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

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

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

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

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

老曹眼中的敏捷開(kāi)發(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!

【本文來(lái)自51CTO專欄作者老曹的原創(chuàng)文章，作者微信公眾號(hào)：喔家ArchiSelf,id:wrieless-com】