敏捷開發(fā):從理論到團(tuán)隊(duì)落地

敏捷開發(fā)很早就已經(jīng)流行過了，之前也零碎地了解了一些相關(guān)知識(shí)，并在團(tuán)隊(duì)中進(jìn)行了部分實(shí)踐，但效果都不怎么好。最近又重新梳理了一遍，并結(jié)合現(xiàn)狀，準(zhǔn)備在團(tuán)隊(duì)中重新實(shí)踐敏捷。

什么是敏捷？

首先，敏捷是一種觀點(diǎn)和價(jià)值觀，不是具體的指導(dǎo)性方法，其核心思想是：

• 響應(yīng)變化、擁抱變化；
• 注重溝通；
  
• 能夠持續(xù)交付，注意這里的持續(xù)非常重要，這也是我們團(tuán)隊(duì)之前存在的問題；
• 交付的成果是以客戶的角度，對(duì)客戶來說是有價(jià)值的。

2001 年，17 位軟件開發(fā)者齊聚在美國的猶他州的雪鳥( snowbird )，討論輕量級(jí)的軟件開發(fā)方法，并寫下了敏捷軟件開發(fā)宣言，其中包括四條核心價(jià)值觀和十二條原則，這里就不具體貼出了。想表達(dá)的還是上面總結(jié)的核心思想。

既然敏捷是一種思想，終究還是要落地的，針對(duì)敏捷的落地有很多的實(shí)踐方法，比如：精益軟件開發(fā)、特性驅(qū)動(dòng)開發(fā)、極限編程（XP）、Scrum，其中 Scrum 是比較流行也是資料最多的，我們團(tuán)隊(duì)也將采用 Scrum 進(jìn)行實(shí)踐。

什么是 Scrum？

Scrum 是一種實(shí)踐敏捷的框架和方法論。其中包含：

• 三種角色；
• 五大會(huì)議；
• 兩個(gè)關(guān)鍵產(chǎn)物。

三種角色

Product Owner：產(chǎn)品負(fù)責(zé)人，主要把控產(chǎn)品的方向，構(gòu)建正確的產(chǎn)品，解決做什么的問題；

Scrum Master：

• 確保團(tuán)隊(duì)能夠使用正確的流程；
• 確保團(tuán)隊(duì)能夠正常召開各種會(huì)議；
• 幫助團(tuán)隊(duì)成員理解 Scrum 理論、實(shí)踐、規(guī)則和價(jià)值；
• 不設(shè)置固定的人員，可以是團(tuán)隊(duì)中的任何人以輪流的方式擔(dān)任。

Development Team：

• 包含架構(gòu)、開發(fā)、設(shè)計(jì)、測試、運(yùn)維等；
• 在產(chǎn)品方向確定的前提下，確保能以正確的方式來構(gòu)建產(chǎn)品，解決怎么做的問題。

五大會(huì)議

待辦事項(xiàng)梳理會(huì)（梳理 Product Backlog）

• 建議每周都和相關(guān)人員進(jìn)行溝通，確保 Product Backlog 中不會(huì)斷貨，不然就持續(xù)不起來；
• 在該會(huì)議中，進(jìn)行待辦事項(xiàng)的補(bǔ)充、優(yōu)先級(jí)的調(diào)整和一些具體實(shí)現(xiàn)思路的討論。

迭代計(jì)劃會(huì) （確定 Sprint Backlog）

• 在每個(gè)迭代開始時(shí)進(jìn)行；
• 從 Product Backlog 中挑選一個(gè)迭代能完成的事項(xiàng)放入到當(dāng)前的迭代列表中；
• 一個(gè)迭代周期一到四周不等，我們現(xiàn)在團(tuán)隊(duì)在實(shí)踐初期，準(zhǔn)備 3 周一個(gè)迭代，等到流程運(yùn)轉(zhuǎn)順暢了，可以再調(diào)整為 2 周；
• 在會(huì)上還需要將用戶故事拆解成任務(wù)，指定責(zé)任人和工時(shí)。

每日站會(huì)

• 由 Scrum Master 主持，團(tuán)隊(duì)成員每人輪流發(fā)言，控制好時(shí)間，一般不超過 15 分鐘；
• 發(fā)言內(nèi)容為：做過什么？將要做什么？遇到什么問題？
  

迭代評(píng)審會(huì)

• 迭代結(jié)束前進(jìn)行；
• 迭代負(fù)責(zé)人給相關(guān)人員（產(chǎn)品負(fù)責(zé)人、其他的利益方）做功能的驗(yàn)收演示；
• 在會(huì)上提出的意見或建議記錄到 Product Backlog ，可能會(huì)規(guī)劃到下一個(gè)迭代中進(jìn)行處理。

迭代回顧會(huì)

• 迭代結(jié)束后進(jìn)行；
• 因?yàn)橐粋€(gè)迭代的周期不會(huì)很長，所以在迭代結(jié)束后進(jìn)行回顧，能夠比較真實(shí)，不會(huì)有遺忘的情況；
• 在會(huì)上可以討論當(dāng)前迭代中做的好的和做的不好的地方，團(tuán)隊(duì)的每個(gè)成員都要積極發(fā)言，這也是考驗(yàn) ?Scrum Master 的時(shí)候。

兩個(gè)關(guān)鍵產(chǎn)物

Product Backlog

• 產(chǎn)品的待辦事項(xiàng)列表，作為每個(gè)迭代的來源；
• 需要相關(guān)人員持續(xù)地進(jìn)行碰撞，確保待辦列表中的事項(xiàng)的優(yōu)先級(jí)是正確的。

Sprint Backlog

• 迭代列表，每個(gè)迭代周期的范圍；
• 迭代結(jié)束后的交付內(nèi)容。

通過上面的描述，應(yīng)該大致清楚了敏捷和 Scrum 是怎么回事了。接下來介紹在我們團(tuán)隊(duì)怎么去使用。

敏捷對(duì)組織是有一定要求的，希望是跨職能組織，在一個(gè)組織中包含架構(gòu)、開發(fā)、測試、運(yùn)維、UI 設(shè)計(jì)等角色。如果不是，組織結(jié)構(gòu)需要進(jìn)行調(diào)整。要求跨職能組織的一個(gè)重要原因就是希望不同角色的人在工作時(shí)能隨時(shí)面對(duì)面交流。目前我們產(chǎn)品團(tuán)隊(duì)是符合跨職能組織的要求，這也為實(shí)踐敏捷提供了先決條件。

整個(gè)過程就是按照 Scrum 的五大會(huì)議進(jìn)行，其中有一些小的調(diào)整，如下圖：

1、最開始的待辦事項(xiàng)梳理會(huì)，建議是每周都能進(jìn)行，因?yàn)榇k事項(xiàng)的優(yōu)先級(jí)會(huì)受到很多因素的干擾，每周進(jìn)行能夠及時(shí)調(diào)整；

2、站會(huì)的時(shí)間調(diào)整到上午的 11 點(diǎn)半，目的就是為了控制時(shí)間，畢竟誰也不想到了 12 點(diǎn)還吃不上午飯；

3、在迭代周期中添加了「用戶故事評(píng)審會(huì)」，在會(huì)上用戶故事的責(zé)任人對(duì)該用戶故事的成果進(jìn)行演示，這樣可以讓用戶故事的責(zé)任人更有責(zé)任感，想要在一個(gè)相對(duì)比較正式的場合進(jìn)行演示，那么事前肯定要做些演練，除此之外也能鍛煉到每個(gè)人的演講和溝通能力；還有一個(gè)好處就是演示過程中，集思廣益，容易找出之前考慮不足的一些地方。

組織調(diào)整為了跨職能組織，每個(gè)成員也都對(duì)敏捷的思想達(dá)成了共識(shí)，并且制定了相關(guān)的工作流程，剩下的就是選擇一個(gè)合適的工具來輔助了，這類的工具有很多，比如 PingCode、Tower 等。選擇一個(gè)自己用著順手的就行。

網(wǎng)上很多的文章都說敏捷執(zhí)行到最后會(huì)變形，最終只留下了一個(gè)站會(huì)，或者變成小瀑布的模式，我認(rèn)為在還沒執(zhí)行前就各種擔(dān)心是大可不必的，出來混最重要的是出來，我們先得執(zhí)行起來，過程中發(fā)現(xiàn)問題即使改進(jìn)、調(diào)整，其實(shí)不光開發(fā)模式可以采用敏捷的方式、團(tuán)隊(duì)和個(gè)人也可以是敏捷的。

在寫這篇文章的時(shí)候，史蒂夫·邁克康奈爾的新書《卓有成效的敏捷》到貨了，如果你還不知道史蒂夫·邁克康奈爾是誰，那么他的著作《代碼大全》，你一定聽過。等這本書看完后，肯定會(huì)有更多的思考，到時(shí)再繼續(xù)分享給大家。

希望本文對(duì)您有所幫助！