[心得] Scrum簡報的筆記

看板Soft_Job作者yangyr (山頭斜照卻相迎)時間13年前 (2012/08/31 07:12)推噓9(9推 0噓 10→)

留言19則, 8人參與討論串1/1

這是上次聽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

08/31 07:44, , 1^F

08/31 07:44, 1^F

推

landlord

08/31 14:08, , 2^F

08/31 14:08, 2^F

推

pizzahut

08/31 16:34, , 3^F

08/31 16:34, 3^F