why scrum (敏捷式專案管理)
DESCRIPTION
TRANSCRIPT
2
先做名詞解釋
3
敏捷 (Agile)是一種框架 (可以解釋成一種概念 ),在這個概念下,由不同的專案管理大師發展出不同門派。目前常見的有Scrum、 XP、 Lean…。在溝通上我們會用 Scrum或敏捷(Agile)來稱呼,其實指的都是同一個東西。
4
START
5
這是一個真實故事
6
自從 2010拿到PMP
7
Requirements
Analysis& Design
Development
Testing& Validation
Deployment & Maintenance
PMP說:我們要時時刻刻修正管理計畫
WaterfallModel
8
事實上
9
自從寫完需求分析跟功能報價後文件更新頻率越來越低
10
不是偷懶
11
而是每增加一個需求User往往不太看更新後的文件客戶會覺得口頭上的討論就已經是確認需求更新後的需求文件對客戶的價值,往往不高
12
更何況同時兼任PM、 SA、 SD 、 P
G
13
學習敏捷式專案管理後
14
看到一些解決問題的方法
15
稍微解釋SCRUM
16
本投影片只會粗略介紹敏捷式專案管理必須深入學習,才能了解更細節的部分
(本投影片較適合想對 SCRUM有點概念的人 )
17
它是基於 Iteration Model的管理模式
假設一個為期 3個月的專案,以每 14天為一個基期(Sprint),總共區分成 12期,把全部功能分散在 12期內完成,每一期的結束必須跟使用者進行Demo&Review,確保功能正確產出。(Waterfall的做法是當功能完成到一定的進度才會跟User Demo)
18
好處是使用者不必等很久就能看到系統功能若是有問題,系統方可以提早修正。
傳統上,客戶必須在測試期才能做意見回饋
19
在Demo&Review之後接著召開 Sprint Meeting,讓User決定本期 (Sprint)要開發那些功能。(這些功能就是下次Demo&Review的內容 )
讓客戶檢視專案執行概況,例如,增加了多少需求,還需要多少時間系統才能完成。
20
就這樣重覆到專案結束
21
SCRUM怎麼解決問題
22
需求管理使用者不斷增加、變更需求
23
在敏捷的世界裡,客戶必須把需求寫在便利貼上,假設有 10個需求就寫10張,然後在Demo&Review裡驗證功能是否符合該需求。
24
好處是需求不會遺漏,不會要求客戶Review整份需求文件,只需專注在未完成的便利貼上。
25
時程管理
26
每個寫在便利貼上的需求,系統方會對這個需求進行複雜度評估,然後給予一個數字。假設本 (期 )Sprint能處理的複雜度總量為 100,客戶可以任意挑選不同需求的便利貼,只要複雜度總量不超過 100即可。
27
好處是需求予以量化後,假設客戶提出 20個新需求,系統方可以很容易估算出需要增加多少時間進行開發。此外,需求的執行先後順序是由客戶排定,而非系統方 (讓客戶挑選重要的先做 )
28
用簡單的方式就能做好需求、時程管理
29
上圖,有些不符合Scrum的做法,參考就好
30
專案管理不是 SOP ,可以用局部導入的方式,轉變成你自己的方法 (流程 )。
31
團隊改善
32
在敏捷的世界裡,有兩個時間點可以作團隊改善,第一個叫Daily Scrum,第二個是在每期 (Sprint)結束後招開的改善 (Retrospective)會議團隊改善其實是落在整個敏捷流程裡
33
Daily Scrum也叫Daily Standup Meeting(每天大家站著開會 ),此時每個人需要回答 3個問題1.昨天做了什麼2.今天要做什麼3.有沒有遭遇困難
34
1.昨天做了什麼2.今天要做什麼可以讓團隊成員跟 PM了解進度,有沒有人打混,一看就很明顯…
身為一個 PM,你是怎麼關心組員的進度 ?
35
3.有沒有遭遇困難藉由將問題拋出,讓團隊可以去想辦法解決,而不是孤軍奮戰。
36
Retrospective 會議目地在改善工作流程,檢討每期(Sprint)的執行狀況,好的地方就保留,不好的地方就改善。
傳統的管理手法,沒有讓成員發聲的管道
37
另一個常見的問題
38
我們公司有CMMI
ISO9000ISO2000
…..現在還多一個 Scrum?
39
Scrum與 CMMI對照表http://ebookbrowse.com/cmmi-iso-vs-agile-dev-doc-d191228954
40
某種程度上符合公司規範流程
41
好處是
42
減少Paper Work
43
專注產品 (功能 )開發
44
Scrum文件基本上只有便利貼(這是把便利貼做成投影片的版本 )
45
回頭看一下
SCRUM流程圖
46還記得便條紙嗎,全部集合起來,專有名詞就叫 Product Backlog
每一期要做的便條紙需求,集合起來就叫 Sprint Backlog
還記得 Daily Stand-Up Meeting嗎,每天都要不斷召開
每一期 (Sprint)的執行時間長度,長度是固定的
每期 (Sprint)的做完都有東西產出
Sprint Meeting,決定要產出哪些功能 Demo&Review Meeting,獲得意見回饋
Retrospective Meeting,改善工作流程
Demo&Review之後討論下個 Sprint的產出
48
關於敏捷還有很多沒講
49
1.需求怎麼編寫、如何切割2.複雜度如何估算3.如何計算團隊執行速率(團隊能處理的複雜度總量 )4.Sprint Meeting的意義… .
50
敏捷式管理的概念很簡單但執行上會有相當的難度至於細節…嗯…再說吧
The End