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