iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 17
0
Software Development

軟體開發隨筆談系列 第 17

為軟體訂定狀態階段

前幾天在《為團隊與組織導入敏捷的經驗分享》 系列文講到了有關產品生命週期的題目,包含〈產品從無到有〉〈從驗證完成到開始的準備〉,而開發到發布因為與本主題更具相關性,所以就改到這裡發佈了。

在開始之前,先聊聊一種對於軟體專案管理的方式——看板(KanBan),想先破除關於看板的迷思。當我們想到看板,大概很容易就是想到 Trello、或是 GitLab 的 Issue Board,而對於使用這類工具的最大印象,大概就是將要做的事情,分成了 To Do、Doing、Done 吧!而我們也因此認為看板不外乎這三個狀態,頂多大不了多了一個 Done Done、Checked、Validated 之類的,去表示驗收完成。

很多時候我們想在軟體專案管理上,導入這樣的看板。有時候會很有效,而有時候卻覺得好像有點綁手綁腳,或是覺得這樣的管理只能侷限在簡單的把功能完成,但對後續追蹤卻略顯不夠。

事實上, To Do、Doing、Done 這其實只是看板的最最最基本的形式,而看板對於各狀態的訂定,是極具彈性,沒有制式規定的。或許在一開始嘗試透過這樣的方式去管理是個不錯的入門方式,但是當大家習慣後,我們或許就可以來做點變化,讓團隊針對軟體會有哪些狀態進行定義。

讓我們將狀態向前、向後延伸,比如說將 To Do 拆成整個軟體的待辦清單,以及最多只能放置 7 個項目的 To Do 清單,這 7 個是最優先要去認領實作的,而待辦清單可能又可以分為分析過、尚未分析過的兩種狀態,要先分析過成本、和需求,才可以進到 To Do 清單。又比如說,我們可以將 Doing 和 Done 分為實作中、等待 Code Reveiw、等待驗收、等待部署、部署到了 Staging、部署到了 Production 等等。這些都只舉例,但這樣講之後,或許就激發了我們的認知,並且突破對看板原有的既定印象。

透過這樣訂定,我們就可以知道目前這個軟體的更詳盡的狀態,以及暸解哪部分佇列了特別多項目,是不是遇到了瓶頸、阻礙,從而去改善。

也因為每個團隊的人員組成不一樣、軟體研發方式不一樣、佈署策略不一樣,所以很難有一個標準答案,每個人對於狀態的認知可能也不太相同,所以在訂定這樣屬於團隊的開發流程時,更要整個團隊、所有成員一同進行討論、訂定。這樣不但能交流彼此對於個狀態的想法、更能凝聚對於各階段的共識,減少了溝通成本,也讓未來在軟體開發的管理上,更加透明與容易。


上一篇
Pair Programming 帶來的好處
下一篇
留下思路
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言