Home > Tags > 敏捷

敏捷

協作,敏捷,繼續做引擎

距離上一篇 Blog 已經是兩個半月了。光陰似箭,兒子也出生了,引擎的開發進度還是很慢。

希望引擎不用等到兒子接手才能完成,回來上海後,最近有了一些新進展。

首先,決定不再獨自閉門做車,找了同事 xlyao 一齊在工餘時間開發。很多獨自煩惱想不到解決科案 (通常是太多科案選不來),兩個人經過討論後就較容易得出結論。

第二,採用所謂敏捷軟件開發方法 (Agile Software Development)。我對 Agile 也許還是一知半解,希望逐步能掌握箇中真諦。

現時的開發過程包括以下數項。

User Story

一個 user story 是一個由 user 提出的明確要求。這些 user story 是要很細小及可以簡單驗証的,例如「使用者可以在地圖編輯器點選一個物件,把它複製。」

我們利用 Google Docs 的 Spreadsheet 輸入 user stories。這些 stories 沒有指明由誰來做,誰喜歡做那個就拿來做,記下開始及完成日期。

User story 的好處是軟件的功能按實際所需而增加,而不是在項目開始時花很多時間寫一份軟件需求規格。因為每個 User story 都比較小,軟件能不停有新的產出 (deliverable),也能讓使用者驗証是否合乎他的要求。傳統的做法有時可能花幾個月時間在一個需求上,但後來又發現和實際所需有所分別。另一個好處是,程序員可能用幾小時或幾天時間便可以完成一個 story,不用預先考慮太多將來未知的需求,心理上也能得到點成就感。不過也要有打算,未來會因為新的 story 而要把舊的代碼重構 (Refactor)。

審核

每個 User Story 完成後,現時是直接 commit 進 SVN 伺服器。我設置了 svnnotify 程序,當有 commit 時會發電郵給所有人,內容包括 log 和 diff。我們需要審核代碼,並應該測試是否符合 story 的要求。

溝通

敏捷很重視溝通。撰寫 Story 可能是一個人提出的,但應該要和其他人解釋。Story 不會寫的很深入 (和傳統的軟件規格有分別),要討論來得知詳細的需求,和如何把它實作。

未來

敏捷方法還包括很多 practice,我們暫時未正式採用,或許將來會慢慢加入吧,例如:

  1. Poker Planning: 透過各自估計 story size point (規模點數),和別人比較和討論後,決定 story 的 size point。
  2. Sprint planning: 每個 sprint (時間單位,例如一週) ,按 story 的優先次序、依賴性及 point 預算 (以之前的 Sprint 能做多少 point 和這個 sprint 的人手時間等決定),去決定做那些 stories。
  3. Stand up meeting: 每天工作開始時,所有隊員站立開會,討論上一天的工作情況及今天的計劃。這個應該沒可能了……
  4. Sprint review: 每個 sprint 結束後討論 sprint 做得好與壞的地方。

雖然開始協作和敏捷方法只有數天,但感覺上項目有了新的動力,希望能在很短的未來能不斷有產出,和大家分享。

P.S. 我把兒子起了英文名字── Lua,真的寫了在出身證名文件裡……

Home > Tags > 敏捷

Search
Feeds
Meta

Return to page top