團隊如何交付正確的軟體

這個功能需求可能不是最佳的解決辦法

Product manager:對於產品沒有不了解的項目

產品經理的工作內容包含許多項目,此篇討論的重點在於「正確的軟體」。

許多軟體開發團隊致力於功能的開發,導致產品一直在創造新的功能,或許這會讓整個產品充滿新鮮感,但背後的真實訴求是否已經解決了呢?


Requirement:需求是無盡的而時間卻是有限的

我最喜歡開的玩笑是:需求就像個許願池,你知道許願池一年的收入可達一億台幣嗎?

舉個例子:在20世紀中的F-16 戰機,最初需求方提到飛行速度必須於2 ~ 2.5馬赫;但在最後設計上其實沒有超過2馬赫,原因是真實的問題被解決了。

因為飛行速度並不是主要訴求,而是「飛機必須能從戰鬥中逃脫」,而需求方認為這樣的速度才足以讓飛機逃脫,但要解決這核心訴求並不依定是從飛行速度下手。

再回到軟體上,開發團隊往往接獲「我們需要OOOO」的需求內容,但或許這樣的需求不一定能解決當前的問題,正確理解欲解決的問題,或許在眾人討論可以得到更好的答案!


Specification:精簡、提煉、活的文件

在設計Spec.的階段,讓開發人員及測試人員一起參與,不僅能加速理解,更能減少單獨溝通的資訊遺;結果能更精確減少開發重工的狀況。

成功的團隊會透過商務使用一起協作制定解決方案,不同的背景憑藉自己的專業,更能在早期發現問題,或找到更加的解決方案,也能讓整體文件事更完善的。


雖然共同協作可帶來好處,但並不適用於多人的會議,且參與人員在事前須對該項目清楚了解,才能帶來更有效的溝通,而非變成腦力激盪的會議內容。

為了效率地進行協作,最好在籌備階段準備:

足夠且詳細的進行分析 — — 開發數週前
搜集並解答關鍵的開放性問題 — — 開發數天前
重新商討嚴重問題的工作項目 —開發初始階段
流程中斷的重大風險 — — 開發週期內

小型的開發團隊經常是較敏捷的,而帶來的問題是可能更多的細節在當下未提及討論,尤其須頻繁釐清問題時,小型的Workshop將更有效率;這將會包含開發人員、測試人員、功能需求人。

雖然和大型的WorkShop相比,不能確保整個團隊有相同的共識,但在整體專案的組織會較為順暢,因為三方擁有不同領域的專長,在第一時間可獲得良好的回饋及共識,並且可更為靈活不需要有特別的排程。但與會的人必須達到相似的理解,不然還是在會前做好准備而不是隨時進行會議。


一個好的Spce.需附帶實例,並且滿足下列內容:

精準、可測試
真正的Spec.,而非執行腳本
是關於需求功能的,而不是關於實作設計

且Spec.需要長期保存,為了避免時間推演遺忘細節,因此須為:

不須說明
聚焦

舉例一個好的Spec.範例:

功能:免費送貨服務
當VIP用戶購買一定數量書本時,將提供免費送貨服務。
免費送貨服務不提供給一般用戶或購買非書籍的VIP用戶
要獲得免費送貨服務,假設最少購買5本

這個範例著重於『具體的服務規則』,並且包含實例、可測試以及邊界狀況,並沒有提到程式工作和階段作業,讓整份文件簡潔清楚。


Fumction test automation:自動化的價值不僅是人力的減少

測試就是Spec.、Spec.就是測試,具體的實例描述Spec.它也可以用來測試系統,而將這些自動化後就變成驗收測試。

功能測試自動化是個容易實現的目標,更能為團隊帶來良好的效益。使用敏捷開發的團隊,在版本釋出的頻率相較高出很多,這種情況容易帶給測試人員極大的壓力,短週期的Sprint要進行大量的功能測試是無法的,並且可能遺漏掉項目。

但自動化的價值遠大於你的想像,它將包含:

減少測試階段的時間,遺漏的項目也隨著減少
將讓開發人員與測試人員有良好溝通的合作渠道,減少隔閡
更能著重於交互性測試、參加Spec.的WorkShop
自動化可完成更多項目測試,頻率更高且讓測試價值能見度提升

Conclusion:應用於團隊

此篇參考『Specification by Exmple』的內容,部份內容為該書中我覺得的重點,軟體開發中有很多問題需要一一解決,如:需求的制定、開發的過程、測試的反饋;但其實還有很多項目是在書中未提及的地方,如需求的精煉、如何導入至團隊、頻繁驗證等…

但每個團隊皆有不同的開發流程以及團隊默契,並不是依照別的團隊開發就是好的,而是如何將好的概念導入而應用在自身團隊才是更高的學問。