※ 本文為 dinos.bbs. 轉寄自 ptt.cc 更新時間: 2012-09-01 10:15:28
看板 Soft_Job
作者 標題 [心得] Scrum演講的筆記
時間 Fri Aug 31 07:12:29 2012
這是上次聽Teddy簡報的Scrum筆記，雖然我現在沒有應用空間，不過我覺得有些
做法似乎可以解決我這陣子帶專案的實務面問題，所以那次聽完就大略記錄了一
下，並記錄了一些自己的感想，請不吝指教，謝謝。
做法似乎可以解決我這陣子帶專案的實務面問題，所以那次聽完就大略記錄了一
下，並記錄了一些自己的感想，請不吝指教，謝謝。
[網誌連結] (原文略做刪減)
http://dflucifer.wordpress.com/2012/07/20/scrum-notes/
![[圖]](http://0.gravatar.com/blavatar/0b03901c967c3bca1ff8d3e1dc444f29?s=300)
======================================================================
Scrum是敏捷 (Agile) 方法之一。運作Scrum的專案會有三種角色：
Team：
一般的專案成員，負責進行開發，在開發初期對所有開發項目─Scrum稱為User
Story─會用一種投票的方式表決該Story的相對難度，感覺這是個蠻不錯的設計
。而每個Team的組成都是Full Functional Team，意即這個Team是可以獨立完成
所有功能的開法，免得進度會因為其它單位的無法配合而delay。
Story─會用一種投票的方式表決該Story的相對難度，感覺這是個蠻不錯的設計
。而每個Team的組成都是Full Functional Team，意即這個Team是可以獨立完成
所有功能的開法，免得進度會因為其它單位的無法配合而delay。
Product Owner：
以下簡稱PO。一開始以為這是類似一般Project Mananger的角色，後來才發覺這
其實是客戶的一員，會去驗證每個User Story的成果是否符合客戶需求，但並不
實際involve專案開發過程，但負責整個專案的成敗。不過在一般專案實際運作
上，可能必須理解為PO與後面提及的Scrum Master互為對口，PO由客戶端實際確
認專案開發狀況是否符合需求，並適時提出feedback。
其實是客戶的一員，會去驗證每個User Story的成果是否符合客戶需求，但並不
實際involve專案開發過程，但負責整個專案的成敗。不過在一般專案實際運作
上，可能必須理解為PO與後面提及的Scrum Master互為對口，PO由客戶端實際確
認專案開發狀況是否符合需求，並適時提出feedback。
Scrum Master：
負責整個專案運作，並依據Scrum的流程進行，調配資源解決專案進行中的各項
問題─感覺Scrum Master反而還比較接近一般專案中的PM。
[名詞解釋]
User Story
可以當作是傳統開發流程的需求項目，但User Story描述的其實是scenario，也
就是一個完整的feature，所以在實際開發過程中，每個User Story還可以細分
為不同的task，例如UI、DB或控制邏輯，可以由不同的Team member負責或協同
開發。
就是一個完整的feature，所以在實際開發過程中，每個User Story還可以細分
為不同的task，例如UI、DB或控制邏輯，可以由不同的Team member負責或協同
開發。
個人以為每一個User Story都是一個可執行的Feature這點很棒，這樣是有實際
成果可以展示的，但缺點就在於這算是Feature-based view，如果底層比較複雜
，需要以Component-based去看並成立專責的Component Development Team，會
需要更複雜的協調─因為Feature-based相當於垂直各項的觀點，Component-
成果可以展示的，但缺點就在於這算是Feature-based view，如果底層比較複雜
，需要以Component-based去看並成立專責的Component Development Team，會
需要更複雜的協調─因為Feature-based相當於垂直各項的觀點，Component-
based則是水平分層觀點。
Backlog
收集所有的User Story，並記錄其相對難度及優先順序的表格，只有PO可以產出
這個表格的最終版。而在開發過程中另外可能產生Technical Story，是伴隨
User Story必須處理的技術問題。
Sprint
跟一般的專案比較不一樣的是，Scrum會把整個專案開發時程切為幾個比較小的
時間單位─Sprint，每個Sprint會進行部分User Story的開發，啟動時需由Team
估計各User Story的task的實際開發時數，然後每個Team member各自選擇開發
的task進行，最後在Sprint結束時要demo完成的User Story給PO確認─感覺這樣
的設計可以避免長期開發後一次demo給客戶的不如預期，進而在每個Sprint結束
時修正專案方向。
時間單位─Sprint，每個Sprint會進行部分User Story的開發，啟動時需由Team
估計各User Story的task的實際開發時數，然後每個Team member各自選擇開發
的task進行，最後在Sprint結束時要demo完成的User Story給PO確認─感覺這樣
的設計可以避免長期開發後一次demo給客戶的不如預期，進而在每個Sprint結束
時修正專案方向。
Retrospective Meeting
這是在每個Sprint結束時會進行的Scrum Master與Team的反省會議，讓Team
member暢所欲言，感謝其他人的幫助及自己認為還要再加強的地方─但不是批鬥
大會。有些項目可能需要Scrum Master去協調，但我認為這是一個非常好的溝通
管道，免得像大部分的專案，RD都知道一堆開發過程中的問題，然後PM只是負責
把問題壓下來…
大會。有些項目可能需要Scrum Master去協調，但我認為這是一個非常好的溝通
管道，免得像大部分的專案，RD都知道一堆開發過程中的問題，然後PM只是負責
把問題壓下來…
只是現實層面上來說，Scrum Master其實會是個很辛苦的保母…
Daily Scrum
每天Team都要跟Scrum Master報告手中task的情形─完成、進行新的task或delay
，可據之更新進度或處理問題。
其它什麼burndown chart我還沒很懂就不介紹了，其實每次看這些軟工的方法論
之類的，老是會看到新名詞，也有點想抱怨一下~
[個人心得]
很多像PO、Feature-based的User Story、討論得出的User Story相對難度及
Retrospective meeting對我而言都是蠻符合人性、蠻正面的設計，很棒!!但
Retrospective meeting對我而言都是蠻符合人性、蠻正面的設計，很棒!!但
Schedule的估計應該也是有所侷限─當每一次的軟體專案都是新類型的研究專案
，以前留下的歷史資料也不見得能派上用場。
--
現在的自己 - http://www.facebook.com/David.CY.Yang
照片的日記 - http://picasaweb.google.com/dflucifer
從過去到未來，世界與我的對話..
http://dflucifer.wordpress.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.110.229.165
推 :推 :)1F 08/31 07:44
推 :感謝分享2F 08/31 14:08
推 :感謝分享3F 08/31 16:34
推 :推4F 08/31 21:48
推 :感謝分享~5F 08/31 22:17
--
※ 看板: dinos 文章推薦值: 0 目前人氣: 0 累積人氣: 370
回列表(←)
分享