[心得] Scrum演講的筆記

[yangyr (山頭斜照卻相迎)]

這是上次聽Teddy簡報的Scrum筆記，雖然我現在沒有應用空間，不過我覺得有些
做法似乎可以解決我這陣子帶專案的實務面問題，所以那次聽完就大略記錄了一
下，並記錄了一些自己的感想，請不吝指教，謝謝。

[網誌連結] (原文略做刪減)
http://dflucifer.wordpress.com/2012/07/20/scrum-notes/

======================================================================
Scrum是敏捷 (Agile) 方法之一。運作Scrum的專案會有三種角色：

Team：
一般的專案成員，負責進行開發，在開發初期對所有開發項目─Scrum稱為User
Story─會用一種投票的方式表決該Story的相對難度，感覺這是個蠻不錯的設計
。而每個Team的組成都是Full Functional Team，意即這個Team是可以獨立完成
所有功能的開法，免得進度會因為其它單位的無法配合而delay。

Product Owner：
以下簡稱PO。一開始以為這是類似一般Project Mananger的角色，後來才發覺這
其實是客戶的一員，會去驗證每個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負責或協同
開發。

個人以為每一個User Story都是一個可執行的Feature這點很棒，這樣是有實際
成果可以展示的，但缺點就在於這算是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結束
時修正專案方向。

Retrospective Meeting

這是在每個Sprint結束時會進行的Scrum Master與Team的反省會議，讓Team
member暢所欲言，感謝其他人的幫助及自己認為還要再加強的地方─但不是批鬥
大會。有些項目可能需要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對我而言都是蠻符合人性、蠻正面的設計，很棒!!但
Schedule的估計應該也是有所侷限─當每一次的軟體專案都是新類型的研究專案
，以前留下的歷史資料也不見得能派上用場。

--
現在的自己 - http://www.facebook.com/David.CY.Yang
照片的日記 - http://picasaweb.google.com/dflucifer
從過去到未來，世界與我的對話..
             http://dflucifer.wordpress.com/

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 123.110.229.165
推 olctw:推 :)
推 landlord:感謝分享
推 pizzahut:感謝分享
推 silveriii:推
推 tsaomimo:感謝分享~
推 iceonly:burndown chart是用來控管專案速度用的，他的單位是所謂的
→ iceonly:難度點(team自己估的)。假設一開始有400點，一個sprint解
→ iceonly:決了80個難度點，那麼你就可以假設你們可以在5個sprint解
→ iceonly:決這專案。不過實際上每個sprint都會一直發現新需求，所以
→ iceonly:bd chart可能不會有到底的一天，這時就要看能不能縮小範圍
→ iceonly:另外scrum沒有PM的概念，不過這當然和現實環境不合，所以
→ iceonly:大多是PM去當scrum master
→ iceonly:(以上同是上課心得的嘴砲文)
推 iceonly:scrum之所以沒有PM的概念是因為scrum非常強調team的獨立性
→ iceonly:整個專案要怎麼開發是team自己決定的事，SM的工作在於"讓
→ iceonly:流程遵守scrum"
→ iceonly:雖然說這就包山包海了(同樣是無實際經驗的心得文)
推 liu721003:謝謝分享!
推 CuteAmi:我有Scrum中文版PDF耶~想要的可以寫信給我~XDDD