iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 25
3
Software Development

軟體開發隨筆談系列 第 25

分離需求與實作的討論空間

在討論軟體開發時,有一種尷尬的情況是「在聚焦需求時開始討論實作細節」、「該討論如何實作時卻發現需求還沒釐清完」。前者會讓非技術背景的夥伴被晾在一邊不知如何是好,後者會導致討論中斷、或是可能就會有自認為需求是什麼擅自決定的情況。

身為程式設計師的職業病就在於討論需求時,很容易不小心和其他程式設計師一起討論起如何實作以及實作細節,然後導致某項需求花了太多時間,拖長整個釐清需求的時程。而在討論需求時,通常會有其他非技術背景的夥伴參與,若是他們遇到這類情境,通常會導致他們覺得參與這項討論或會議是浪費自己的時間,因為裡面有很大比例時間中展開的對話是他們聽不懂的。

在討論需求時,應該著重在釐清需求、可行性與準確但不用太精準的成本估算。這部分可以把標準放在當有夥伴聽不懂當前對話時,就是討論太過細節的情況,這時候身為技術人員就要有意識的切回正題。需求的討論應該著重在之前所講的〈暸解目的去實作,而不是暸解要去實作什麼〉〈確認好要驗收的項目與規格的滿足條件〉

如果專案管理工具是可以在項目中設置子項目的,例如 Asana 的 Subtask,也會建議在原本的項目裡專注在需求的討論,並把要做的事情或是技術相關的細節討論另外開子項目去討論,方便聚焦;或是透過項目之間的相依關係去管理,讓需求項目相依於實作項目。例如我們可以在原本的項目裡專注討論、確認驗收需求,以及目前這個需求進度如何,然後是否可以驗收了。然後在子項目裡建立要做的事情,或是希望討論的實作細節等等。形式上可能還有其他做法,但是把兩者的討論空間分離出來是有助於聚焦的。


上一篇
軟體價值的層次與平衡
下一篇
程式碼從什麼時候開始發臭
系列文
軟體開發隨筆談31

尚未有邦友留言

立即登入留言