【第165期 June 7, 2011】
 

CMMI與軟體工程

SCRUM與 CMMI v1.3 的敏捷式專案管理

作者/林靜蘭

[發表日期:2011/6/1]



前言

SEI在 CMMI V1.3 版加入敏捷式專案管理( Agile Project Management)。主要是順應市場瞬息萬變潮流。由於速度就決定了成敗與盈虧,在如此快速改變的外在環境下,唯有反應靈敏者才能生存,因此敏捷式專案管理( Agile Project Management) 就是在這樣的背景下應運而生,現在正以驚人的速度在球擴散。 SEI 也順應潮流在 2010 發行 CMMI V1.3 加入 Agile 專案管理,包括的10 個流程領域如CM,PP,PMC, REQM,PPQA,RD,TS,PI,VER及 VAL。其中包括5 個 ML2 PA及 5 個 ML3 的 PA。 但CMMI對 Agile的實作解讀並不夠直覺,因此要從CMMI的角度來看,而不是Agile的角度來看。因此在導入 CMMI 的流程中如果選擇 Agile 如何用CMMI的角度來解讀則是一種挑戰。本文想先用 SCRUM 來說明 Agile 敏捷式專案管理,再來探討如何以用CMMI的角度來解讀。

What is SCRUM?

SCRUM是一種 『Iterative and incremental 』軟體開發過程,通常用於敏捷軟體開發。SCRUM一詞源自英式橄欖球,在兩隊前鋒對峙下互相爭球,也可以解釋做「a usually brief and disorderly struggle or fight」 SCRUM把專案開發過程化整為零,可快速反應需求改變,及開發時間緊迫的專案。 因此SCRUM是非常適合快速變化的專案,或非常緊急要求的專案。每一次 Sprint,通常2-4週。

因此 SCRUM是一種靈活的軟體開發方法。而不是一個完整的過程或方法,它是一個框架,而不是提供完整及詳細描述一切如何做的流程或規定。這就是如好的球隊將知道如何解決它的問題。所以『Sprint計劃會議』上討論期望的結果,而不是一套(ETVX)標準。ETVX 包括了任務定義,驗證標準,並允出標準提供大部分的方法。

SCRUM團隊是自我組織的,該小組是跨不同功能,每個人負責一個功能,包括設計到實施參與。SCRUM小組有兩個角色:一SCRUMMaster和 產品須需求者。SCRUMMaster可以被看作是一個教練團隊,幫助團隊成員進行SCRUM的框架,確保發揮其最高效率。產品負責人代表了業務,客戶或用戶,負責確認正確的產品。

SCRUM專案進展,是一系列的Sprint。通常一個Sprint是不超過一個月的。一開始,一個Sprint,團隊的成員承諾的客戶功能,被列入該專案的產品Product Backlog。在最後的Sprint,這些功能完成程式撰寫,測試,並集成到不斷發展的產品或系統。在最後的一次Sprint是進行 Sprint Review,會依據客戶或其他人提供的意見,展示產品,本次的結論可能會影響下次的Sprint。

SCRUM的主要活動

Sprint 主要活動如下:

1.Sprint (1~4 週)(視專案大小會有 n 個 1~4週),一個Sprint不建議超過一個月,超過一個月最好想辦法再細分。
2.Brief Daily Meeting (Daily SCRUM Meeting),Daily 主要要報告以下三件事:
 ‧昨天做了什麼事?(或今天做了什麼事,依開會時間而定)
 ‧今天要做什麼事?(或明天要做什麼事,依開會時間而定)
 ‧工作上是否遇到任何阻礙或問題?(主持者(SCRUM Master)必須快速解決成員所遇到的困難。)
3.Sprint Review Meeting(檢討會)
4.繼續重覆上述步驟到專案完成

因此SCRUM專案的主要活動就是Sprint。 SCRUM是一個” Iterative and incremental 過程,因此該專案被分成一系列連續的Sprint。每個 Time-boxed,通常一個星期之間和一個月。最常見的Sprint為兩個星期。在此期間成員會完成小部分功能,包括設計到程式撰寫和測試功能。

每次Sprint的第一個活動是「Sprint planning meeting」。在會議上,使用者和團隊討論的需求優先次序- 也就是專案的Product Backlog。小組成員承諾可以完成的需求,然後創建一個Sprint Product Backlog,也可以解釋為任務執行列表(To do list)。

每天的SCRUM會議是由所有團隊成員參加,包括SCRUMMaster和使用者。 每次會議Time-Boxed不超過十五分鐘。 在此期間團隊成員分享他們目前的工作進度,今天的工作及工作困難。

最後一次的Sprint是審查活動。在Sprint評審,團隊展示功能,過程中可能會因審查而增加功能。審查會議的目的是借由審查獲得產品的回饋。這種回饋可能會導致更改為剛交付的功能。但它可能同樣有可能導致修改或添加功能因此修正Product Backlog。

每次Sprint活動結束時會進行的每一次Sprint回顧展。團隊參加包括SCRUMMaster和產品所有者。這次會議是一個回顧機會,除表示短期即結束,透過經驗學習並找出下次Sprint可以改善的部份。

SCRUM專案主要產出

‧產品本身。也是每個Spring最後的產出。
‧Product backlog 是一個完整的功能表列,包括功能的優先次序, 團隊可以依優先次序進行以提高效率。 Product backlog通常在第一次sprint planning meeting 中產出。 Product backlog 也可以視為 To do list。
‧Release burndown chart。主要是可以一目了然所有工作進行的進度及完成的工作。

結論

SEI在 CMMI V1.3 版加入敏捷式專案管理( Agile Project Management),專案可選定 SCRUM 的開發方式,也就是敏捷式專案管理。但如何執行 CM,PP,PMC, REQM,PPQA,RD,TS,PI,VER, VAL 等各流程領域, 評鑑過程又如何認定證據這是一個挑戰,也將是所有或未來將導入 CMMI 的公司將進一步了解, 這也是筆者想待續在下次的文章中繼續探討的部份。

參考文件

http://www.cmmi-taiwan.org.tw/content/project.aspx

‧CMMIR for Development, Version 1.3

‧Agile software development - Wikipedia, the free encyclopedia