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

Why Scrum (敏捷式專案管理)

Why Scrum (敏捷式專案管理)

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

×