很多企業(yè)、團(tuán)隊都在提倡敏捷開發(fā)、DevOps運(yùn)動，我最近在了解DevOps的相關(guān)知識。結(jié)合自己的實踐，把對敏捷開發(fā)的一些理解，分享予大家。

敏捷開發(fā)強(qiáng)調(diào)的首先是人的變化，其次才是工具應(yīng)用的層面。

一，人的變化（團(tuán)隊），主要思想模式上的變化，比如：

沒必要等到全部確定才可以開始。只要大的框架需求、關(guān)鍵點(diǎn)確定之后就可以開始，沒必要等到弄清楚所有細(xì)節(jié)才開始，如果要弄清一切才開始，就是傳統(tǒng)的瀑布式開發(fā)了，那樣產(chǎn)品見面周期長，無法適應(yīng)需求的快速變化。

不是一次性交付后就結(jié)束。敏捷開發(fā)，就是要分多個迭代交付，小步快走。

允許有不完美。不要一開始就想著很完美，而且也很難一開始就想得很完美，要清楚這是一個逐步優(yōu)化的過程。

要擁抱變化。敏捷的目的就是能快速響應(yīng)變化，以真正滿足業(yè)務(wù)的需求。當(dāng)然變化是以真正體現(xiàn)業(yè)務(wù)價值為基礎(chǔ)的，不是以某個人的盲目意見為理由。

真誠溝通。與客戶建立親密性，真誠地進(jìn)行溝通，客戶不是“談判對手”，也不是“上帝”，而是與團(tuán)隊一起共進(jìn)退的伙伴、合作人。

二，工具應(yīng)用的層面

以故事場景的形式把需求描述出來，敏捷強(qiáng)調(diào)的是從客戶的業(yè)務(wù)場景角度，把需求講出來，不太強(qiáng)調(diào)具體的系統(tǒng)功能需求設(shè)計。目的就是為了能真實表達(dá)業(yè)務(wù)的需求和價值。

大目標(biāo)需要拆分小目標(biāo)，需要懂得把大目標(biāo)拆分成各個小目標(biāo)，縮短成品交付的周期，讓系統(tǒng)盡快出來驗證業(yè)務(wù)價值。

迭代交付，每個迭代是一個完整的閉環(huán)“計劃-開發(fā)-測試-體驗-發(fā)布”。

每日站會，每日站會是為了讓團(tuán)隊了解整個項目的情況，知道成員彼此的工作和困難，可以互相幫助。

任務(wù)看板，用來跟蹤項目進(jìn)度的，特別是在沖刺階段特別有效。

定期回顧，回顧是團(tuán)隊一起回顧，是規(guī)避，也是學(xué)習(xí)交流的機(jī)會。

具體實踐的一些感悟

1，與客戶親密溝通，站在同一陣線，很重要。

能與客戶保持親密溝通，站在一起探討需求，設(shè)計功能，討論解決方案，是項目走敏捷路線的良好基礎(chǔ)。很幸運(yùn)地，本人負(fù)責(zé)過很多項目，基本都能做到這一點(diǎn)。我覺得主要有兩個原因：

1）接到任何一個項目，我都會專心投入去思考：應(yīng)該怎樣設(shè)計才是對業(yè)務(wù)最有價值的（那怕一開始不清楚業(yè)務(wù)，也會想辦法溝通弄清楚，然后思考）；

2）客戶的需求，不會拒絕。而是會去思考，這個需求的價值是什么，如果是有價值的，我們就如實商量實施計劃；如果是沒有價值的，則會提出我的見解。做到這兩點(diǎn)，除非很惡劣的情況，否則一般客戶都是會講道理的。

2，拆解目標(biāo)需要清晰，可靠。

項目的目標(biāo)一定要清晰，然后拆解的子目標(biāo)也要清晰、合理。一般情況下，我會從兩個方面考慮：

1）把故事轉(zhuǎn)成全功能目標(biāo)圖；

2）明確業(yè)務(wù)意愿的時間目標(biāo)。

以上兩點(diǎn)，結(jié)合團(tuán)隊資源的情況，按照系統(tǒng)本身特有的特征和客戶的意愿拆分目標(biāo)。確保每個小目標(biāo)可達(dá)。

3，定期回顧總結(jié)，反思。

迭代交付，一定要定期回顧，并反思，確保項目方向正確，目標(biāo)可達(dá)，特別是要考慮總體目標(biāo)也是在計劃中可達(dá)，如有偏離、或者出現(xiàn)風(fēng)險，需要及時糾正。定期反思，一般我會考慮：離目標(biāo)還差多少，交付的需求是否都是有價值的，目前有沒有出現(xiàn)隱含的風(fēng)險等。