從零開始—Scrum團隊敏捷轉型實戰案例

摘要簡介：

摘要簡介：

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

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

1 背景分析

1.1 公司背景

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

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

1.2 團隊背景

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

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

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

1.3 項目背景

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

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

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

2 推行準備

2.1 自我準備

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

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

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

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

2.2 培訓內容準備

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

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

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

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

3 推行實施

3.1 集體培訓

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

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

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

3.2 SCRUM執行

培訓結束后，團隊按照自己項目的實際情況，開始嚴格按照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.3 執行小結

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

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

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

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

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

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

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

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

4 推行總結

4.1 沒有規矩，不成方圓

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

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

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

4.2 殫心竭慮，謹慎決策

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

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

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

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

4.3 外來的和尚會念經

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

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

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

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

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

4.5 步步為營，循序漸進

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

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

5 后記

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

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

在路上，愿與大家共勉。

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。