Scrum筆記


感謝Teddy精彩的演講,順便幫他打一下廣告好了~ (明明就應該是我的網誌沒人看吧 XD)

http://teddy-chen-tw.blogspot.tw/

重點筆記一下:

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

  1. Team:一般的專案成員,負責進行開發,在開發初期對所有開發項目─Scrum稱為User Story─會用一種投票的方式表決該Story的相對難度,感覺這是個蠻不錯的設計。而每個Team的組成都是Full Functional Team,意即這個Team是可以獨立完成所有功能的開法,免得進度會因為其它單位的無法配合而delay。
  2. Product Owner:以下簡稱PO。一開始以為這是類似一般Project Mananger的角色,後來才發覺這其實是客戶的一員,會去驗證每個User Story的成果是否符合客戶需求,但並不實際involve專案開發過程,但負責整個專案的成敗。不過在一般專案實際運作上,可能必須理解為PO與後面提及的Scrum Master互為對口,PO由客戶端實際確認專案開發狀況是否符合需求,並適時提出feedback。
  3. 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的估計應該也是有所侷限─當每一次的軟體專案都是新類型的研究專案,以前留下的歷史資料也不見得能派上用場。

這也讓我想到幾年前曾經流行過的紙上RPG,「遊戲主持人 (Game Master) 」的角色似乎跟Scrum Master有所雷同之處:為了讓Game / Project能持續往前走,Game Master / Scrum Master終究還是得協調處理人與環境的問題,畢竟不是生產線上的機器,人的心思雖然充滿無限可能的創造力,卻也更顯複雜而難以單一角度去看待─如果台灣還是以硬體製造的觀點來看軟體發展,這個產業終究很難獲得長足進步…

About David Yang

David Yang, like sports, nature, reading, music and...traveling. I am not good at sports, but like watching basketball, baseball and tennis games. I am not very strong, but like hiking, bushwalking and riding bicycle into the nature...Although I am a software engineer. Not only continue to read and gain knowledge, I also want to walk around every corner of the world. Here are some stories about my itineraries: https://dflucifer.wordpress.com/ I come from Taiwan...no matter where you meet me, either I am traveling, or just preparing for next trip :-)
This entry was posted in 產業現況及社會觀察, 軟體工程 and tagged , , , , , . Bookmark the permalink.

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s