Scrum敏捷開發方法實踐

前言

作者所在的公司在專案開發的過程中採用著當下網際網路公司中流行的小步快跑開發策略，特別借鑑了敏捷開發中的迭代遞增思想來指導專案的開發。我們經過對相關敏捷開發方法的調查研究，最終採用了Scrum敏捷開發方法來管理專案。敏捷開發思想和相關方法的應用降低了專案的風險，極大地提升了專案團隊對需求變更的響應速度和處理能力，每個迭代週期的版本釋出都是對團隊成員對激勵，讓整個團隊對專案的信心越來越強。今天作者和大家聊聊Scrum敏捷開發方法以及它的實踐。

敏捷開發原則

《敏捷宣言》中釋出了12條敏捷原則和相關的敏捷開發價值觀，用來指導軟體開發過程。其中我們在專案中主要遵循的兩條關鍵原則是：可工作的軟體優於面面俱到的檔案；對需求變化的響應優於對計劃的遵循。

其中，可工作的軟體系統優於面面俱到的檔案這一原則是強調通過頻繁持續地提供可供使用者使用的軟體系統來提升使用者和開發團隊對軟體系統的信心，能夠更及時地獲取到使用者和市場的反饋，調整後續的開發計劃和需求的優先順序。使用者最終需要的是一個滿足需求的可工作的軟體系統而不是面面俱到的檔案，過多過複雜的檔案會成為開發團隊的負擔，而且也沒有人願意去讀。根據作者多年的軟體專案開發和管理經驗來看，這個觀點是在當前的網際網路環境下是十分適用的。當前的網際網路應用迭代更新很快，市場的需求也在瞬息萬變，在半年前還十分重要的需求，在半年後可能也已經不是一個優先順序很高的需求了。而且，及早地釋出可以使用的軟體版本確實可以儘早地收集到使用者的反饋，從而及時調整後續專案的開發方向。舉例來講，Instgram在最初的版本只是一個簡單的根據地理位置進行打卡的工具。市場的反響不是很理想，同時發現使用者對地理位置不是很在乎，反而對上傳照片很感興趣，後來就調整了開發的方向轉做圖片上傳的軟體。

對需求變化的響應優於對計劃的遵循。敏捷開發承認開發過程中的不確定性，在開發的過程中需要通過不斷規劃，執行和調整來消除不確定性。如果一味地遵循一個龐大而複雜的計劃，會使團隊變得很被動，無力抵抗需求的變化，最終開發出的軟體系統並不滿足市場和使用者的需求。作者對這一點深有體會，作者之前所在的公司是一家傳統的商業智慧分析公司，其BI產品在市場中佔有很高的佔有率。2013年，公司的高階管理層做出一個決定，要做一款軟體，幫助人們享受智慧生活，只要有一部智慧機在手就可以滿足人們所有的日常生活需要，其願景有點兒類似今天的支付寶和微信。為此，公司做了一個長達一年的開發計劃，投入了很多優秀的開發人員和軟硬體資源，但是因為沒能夠及時獲取到市場的反饋，投入市場的APP並沒有得到市場的認可。

Scrum開發方法

通過對當前各種型別敏捷開發方法的分析和比較，以及結合我們公司的實際情況。我們最終選擇了Scrum敏捷開發方法，Scrum敏捷開發方法流程如下圖所示。

Scrum開發方法包含5種不同型別的會議，每一種會議都有它明確的目標。

1.Sprint計劃會議

在每個迭代開發週期的開始階段，Sprint計劃會議被召開。通常來講，整個團隊成員最好都參加計劃會議。計劃會議的目的是制定出一份切實可行的待辦需求列表，同時選擇出一個最高優先順序的需求，每個需求的開發週期最好在2周以內。產品經理可以給開發團隊解釋待辦需求列表中的每一個需求。

2.每日站會

當一個迭代開發週期被啟動之後，每天舉行站會是十分必要的，該會議的持續時間要嚴格控制在15分鐘之內。該會議上面每個人都要回答三個問題：

你昨天完成了哪些任務？
今天你的工作安排是什麼？
是否有任何障礙影響了你的工作進度？

3.Sprint評審會議【可選】

每個迭代開發週期結束的時候，最好舉行一個評審會議，這個會議的主要目標是向大家演示產品的功能，讓大家瞭解到我們完成的產品是符合預期的。隨著網際網路應用的更新迭代速度越來越快，實際上現在每個迭代開發週期結束後都舉行一次評審會議，已經變得不是十分必要了。

4.Sprint回顧會議

Sprint回顧會議，顧名思義，主要是幫助團隊來總結每次迭代開發週期中有哪些地方做得好，哪些地方做得不好，未來有哪些需要改進的地方。

5.Backlog Refinement會議【需求細化會議】

在Sprint計劃會議之前，實際上還有一個需求細化會議，其主要目標是對待辦需求列表中的需求進行細化，讓團隊能夠更好地理解需求細節以及需求的目標是什麼。需求細化會議可以減少Sprint計劃會議的持續時間，同時也給團隊成員一些時間去思考需求的問題、意義和優先順序。

實踐與問題

在實踐中，我們不能去生搬硬套Scrum開發方法的流程，而是要從自身的開發環境和需要出發制定適合自己團隊的開發流程。

1.取得團隊成員的認同

很多時候，你的團隊成員可能並不會認同Scrum開發方法，他們可能會認為依照Scrum開發流程沒什麼好處，只是單純地在浪費時間而已。因此，我們必須儘可能讓團隊成員理解這個開發流程和專案的目標。這樣有助於將團隊所有成員凝聚成一個整體，消除團隊成員在方向和認知上面的衝突。

2.會議目標要明確

在每次會議之前我們都要有明確的會議目標，否則的話我們的會議很容易就變成漫無目的的閒聊。

3.面對陌生領域

有些待開發的需求會涉及到技術上的未知領域，開發團隊不好對相關需求所需的時間和資源進行評估。我們會根據實際情況採用如下的解決方案。如果相關技術領域團隊的人員比較充足，我們會拆分部分開發成員去調研相關技術領域的解決方案；如果相關技術領域團隊人員不足，我們會首先調整待開發需求的選擇，不再採用「高價值」優先的選擇策略，而且採用避重就輕的策略選擇技術難度較低的需求，從而給相關的技術團隊留出相應的技術調研時間。如果，沒有這樣的需求可供選擇，我們會單獨安排一個小的週期專門用於相關技術調研。

4.團隊成員缺席

在開發的過程中，難免會遇到團隊成員請假的情況，從而影響整體的開發進度。這個時候，我們採用的做法是留出相應的冗餘時間，我們給出15%的冗餘時間用來應對部分團隊成員因為不可預知的情況而缺席迭代開發任務的情況。

總結

Scrum開發的迭代增量思想非常適合當前的網際網路專案開發，但是必須根據自身的情況進行相應修改。沒有放之四海而皆準的開發流程，在任何的開發管理流程中都會需要突發情況，對於相應的突發情況，我們要做好相應的預案儘可能降低專案的風險。