從零開始—SCRUM在軟體產品研發過程中的成功實踐歷程

摘要簡介：

本文取自真實的敏捷SCRUM應用實踐。筆者認為，敏捷方法的推行實施在企業中是一個系統的工程。本文從敏捷SCRUM的背景分析，推行準備，推行實施，推行總結幾個方面來總結。

筆者在一家軟體企業，承擔某軟體系統產品開發項目的項目管理。通過半年多的加班加點，帶領團隊完成了軟體demo版的開發，CCBN展會上，很受客戶歡迎。接下來，商務洽談如火如荼，系統產品化開發迫在眉睫，可是，筆者深深清楚團隊一路掙扎走來的現狀，怎麼做才能在3個月左右的時間裡完成從DEMO版到產品化版本的開發？

1t背景分析

1.1t公司背景

公司是一家60人左右的軟體公司，以研發、銷售軟體系統為主營業務。作為一家民營企業，講究人盡其才，可喜的是公司組織結構分明，部門職責比較明確。

負責主管研發的領導有著多年的研發經驗，對推行敏捷持支持態度。

1.2t團隊背景

項目團隊總計10餘人。其中包括開發9人，測試4人，管理3人。根據所開發的軟體系統特點，將全員分成6個小組，分別是管理組，開發組A, 開發組B，開發組C，測試組，產品組。

團隊之前一直實行迭代開發，通過半年來的加班加點，終於完成系統DEMO版的開發。但是，已經是談加班而色變，團隊士氣漂移不定。

團隊對敏捷知之甚少。我作為項目經理，在項目中統一協調研發部、測試部、產品部。

1.3t項目背景

本項目主要目的是完成公司主營軟體系統的產品化開發。依據IPD流程的定義，目前只是完成了基本的技術開發，下一階段需要完成技術開發及產品化開發。

因為是產品化開發，產品開發面對的是行業內的某一類整體客戶群體。所以項目需求寬泛，需求篩選、分析的難度較大。沒有固定、明確的客戶可以來針對性的溝通交流。雖然已經完成了DEMO版的開發，但是相關業務的具體實現和系統的功能性能指標確定實現等，還需要很長的路要走。

公司要求在3個月左右的時間裡完成軟體系統的技術開發及產品化開發，時間壓力很大。如果持續的加班加點，恐怕引起團隊震蕩，要知道，當時可是剛過完春節的3月份，作為管理者，3月份是一個難捱的月份，也許突然什麼時候，就會有團隊成員找你溝通，然後從團隊內消失離去，那你就能深切體會什麼是鐵打的營盤流水的兵了@@。

2t推行準備

2.1t自我準備

首先，自己買書，從網上讀了大量敏捷方面的內容。在這裡，向大家推薦兩本書： 硝煙中的Scrum和XP和敏捷項目管理，都是老外寫的。前一本深入淺出的介紹了SCRUM實踐方法，而後一本從產品開發及項目管理的角度闡述了敏捷。

同時，與直接領導也做了大量的交流，最後，把要推廣的目標鎖定在SCRUM上。為什麼？因為SCRUM是當下流行的敏捷開發方式，流行的必然有它流行的理由，SCRUM框架清晰，容易上手，充分體現了敏捷開發的特點；其次，SCRUM開發與項目團隊之前的迭代開發有某些相似之處，便於成員接受執行。

然後，經過對比後，聯繫了一家敏捷培訓的專業公司，在經過幾次的溝通後，確定了讓全體團隊成員（包括相關領導）正式參加敏捷集訓的日期。

好了，萬事俱備，只欠東風。

2.2t培訓內容準備

經過與敏捷培訓公司的溝通，決定培訓的內容包括如下：

重要內容：敏捷開發的講解，向大家講明敏捷開發的優勢。

簡單介紹：敏捷項目管理簡介，向大家介紹敏捷項目管理的特點。

關鍵內容：SCRUM詳細培訓，向大家詳細培訓SCRUM的具體執行方法。

3t推行實施

3.1t集體培訓

整個項目團隊加上相關領導，在公司聘請專業的培訓公司進行了為期2天的集體培訓。（我也想時間長點，可是需要Money呀）

通過集體培訓，整個團隊感受了敏捷的氣氛，了解了敏捷的含義，並初步了解了SCRUM的框架。

下一步，是騾子是馬，該出來遛遛了。

3.2tSCRUM執行

培訓結束後，團隊按照自己項目的實際情況，開始嚴格按照SCRUM框架執行。

我們項目團隊SCRUM執行如下。

首先，我們定義了SCRUM團隊角色：

我由原來的項目經理，轉換成Scrum master。

產品經理轉換成Product Owner。

團隊原來的職能分組仍然保留，但是大家達成一致，要按照敏捷團隊高度自主的特性來進行自我管理和要求。

其次，我們確定了我們的SCRUM會議規則：

我們的sprint周期為2周（後來改為3周）；

Sprint 計劃會議1、2，sprint評審，回顧會議每次2小時；

每日立會，每天早晨9:15準時開始，每次15分鐘。

再次，我們確定了我們要使用的SCRUM工件：

Product backlog; Sprint backlog；看板；燃盡圖。

最後我們定義了我們軟體系統產品的產品願景及我們在SCRUM執行中各種「完成」的檢驗標準，包括：

Product backlog中User story完成的標準；

Sprint backlog中Task完成的標準；

看板任務條移動的標準；

Sprint 評審完成的標準；

產品發布完成的標準。

接下來呢，別看廣告看療效，真是誰用誰知道呀！

3.3t執行小結

項目團隊從推行SCRUM開始，經過3個月左右的戰鬥，終於完成了第一個產品化版本的開發，推向市場後，獲得了客戶的好評。

經過分析，筆者認為敏捷SCRUM給團隊帶來好的改善如下：

1. 團隊項目流程方法清晰明確。較之之前的工作流程，SCRUM框架清晰，簡潔，能夠比較大的程度上減少流程制度給研發團隊帶來的遲滯。

2. 團隊目標感增強。每一個sprint迭代，通過計劃會議，都會使團隊對sprint時間盒內要完成的工作目標異常清晰。

3. 團隊溝通意識加強。SCRUM要求團隊是高度自主，自組織管理的。大家在這個組織原則下可以進行更大可能的積極溝通，尤其是研發和測試人員，積極的溝通交流極大地提高了工作效率。

4. 團隊成就感增強。每一次sprint評審會議，團隊成員都會自豪的展示自己的工作成果，從而提升了成員的自信心和工作熱情。

5. 產品質量加強，實現了快速增量交付。周期一致，有節奏感的sprint迭代，嚴格透明的評審，使團隊中的每一個人都能夠時刻關注工作質量，從而加強了產品質量。

整體來說，通過SCRUM框架的推行，可以說敏捷的工作理念已經滲入到整個項目團隊，整個團隊的工作績效也得到了大幅度提升。而且從始至終，大家基本都保持了積极參与，熱情高漲的工作狀態（因為不怎麼加班的緣故吧-_-！），這對於以創造性為主要特徵的研發項目團隊來說，無疑是最重要的。

4t推行總結

4.1t沒有規矩，不成方圓

任何一個團隊，想要做什麼事情，必須有自己的工作規則。大企業有完善的流程制度，游擊隊有自己的戰鬥方針，可以根據自己的組織規模及實際情況來決定工作方法、規則的繁簡，但是必須要有。

因為團隊中的成員來自四面八方，不同的教育背景，工作經驗、專業技能決定了大家對同一件事的看法必然存在著差異，這是正常現象。但是作為管理者，必須讓大家心往一處想，勁往一處使，怎麼辦？要統一大家的思想，需要制定統一的規則並且去嚴格執行。所謂「洗腦」，就是這個道理。否則，就會公說公有理，婆說婆有理，最後誰都不服誰，更別說完成既定的工作目標了。

所以，我們的團隊選擇了統一的敏捷方法論作為我們工作規則制定的依據。

4.2t殫心竭慮，謹慎決策

做事之前，先想想。決策如果失誤的話，後面再怎麼做，只不過使錯誤得更離譜。

首先，要分析自己團隊的實際情況，分析一下有哪些需要改進的地方。比如在推行敏捷之前，我們的團隊是迭代開發、士氣低迷；我們的軟體開發是開發產品，需求不確定因素很多，但是時間壓力還很大，要求成品儘快出來，銷售正巴巴等著米下鍋呢。

其次，要分析你所選擇的新方法是否適合？敏捷SCRUM是很流行，可是，它是否適合我們團隊？作為管理者，需要把這個問號想清楚。這就需要管理者自己先要把敏捷、SCRUM等有個較詳細的了解，看它們的特點優勢是否能夠真正應對我們團隊的現狀。

再次，我們自己分析出來了敏捷可能適合我們的團隊，那麼下一步，我們需要獲取高層領導的支持。任何改進，沒有領導的支持，往往會適得其反，事倍功半。

4.3t外來的和尚會念經

這裡有兩個關鍵詞，第一個是和尚。大家想到念經，大多數第一印象腦海中都會想到和尚，為什麼？因為對於念經來說，和尚往往是最專業的。所以，我們要培訓、要改進，一定要找個在這方面大家覺得專業的組織或者個人來做。因為專業，所以大家才容易信服。

第二個關鍵詞是外來的。這裡的外來可以是職能部門之外的，也可以是公司之外的，但是，一定要是團隊之外的。為什麼呢？大家對不熟悉的事物，都會存在神秘感，存在神秘感，大家對這個事物的特徵、言行舉止往往更好奇。陌生的專業人士，會降低大家的心理抵制度，能夠大幅提升培訓效果。

4.4t虛懷若谷，團隊保持空杯心態

能否保持空杯心態，是衡量一個組織、個人學習能力健康度的重要依據。一個人，一個組織要想做出改變，必須先勇於接受外來的變化，只有先接受變化，然後在實踐中去檢驗它的對錯，吸取對的東西，揚棄錯誤的，才能螺旋式的上升，才能從優秀走向卓越。海納百川，有容乃大。

切記的是，我們不要動不動就憑藉自己以往的經驗去輕易地下結論、下判斷、去否定他人，我們可以在可控的預期內先試試看。

4.5t步步為營，循序漸進

對未來懷有願景，但是要保持適度的期望值。在具體的方法改進中，要步步為營，不要期望一口就能吃成胖子，欲速則不達。

所以，敏捷的實施也要一步一步慢慢來，因為，敏捷工作方法不單純是一種具體的工作方法，它還是一種方法論，價值觀。對於人來說，改變對事物的看法很容易，改變認識事物的方法則不那麼容易。敏捷方法追求自組織的管理，對於大多數團隊來說，還是需要有一個漸進的認識、接受的時間過程的。

5t後記

本文描述的經歷在6年前，那時候筆者還只是項目經理的角色，很多事情的推行也是從項目管理的角度出發來考慮的。從敏捷實施的成熟度來看，當時，也只是「守、破、離」的守的階段，只是踐行了基本的SCRUM框架，但是現在看起來，當時的成效也達成了公司的業務要求。

不積跬步無以成千里。隨著時間的流逝，對於敏捷方法的系統認識，敏捷方法論對軟體開發，對項目管理，對組織業務的影響仍然在探索中。

在路上，願與大家共勉。

2017年2月

推薦閱讀：