[還少一本書] Executable Specifications with Scrum

April 01 09:20~10:38

 

這幾天利用一些時間把《Executable Specifications with Scrum: A Practical Guide to Agile Requirements Discovery 》這本只有160多頁的「小書」很用力的重讀一次。一年多前第一次讀這本書，覺得這本書根本是掛羊頭賣狗肉，名不符實，書中提到「Executable Specifications」的地方好少，都在講一些對於熟悉Scrum的人早已知道的事情，例如story的寫法、用planning poker做估算、與stakeholder合作一起產生需求、product backlog管理與梳理、用taskboard追蹤進度等。從73頁開始才提到直接與「executable specifications」相關的內容，而且這些內容很淺顯，感覺沒有搔到癢處。

這次重讀卻有另外一種全然不同的感受，覺得這本書寫的很好，把敏捷開發（Scrum）與需求有關的主題描述的很清楚，有一種打通任督二脈的感覺。怎麼會有這麼大的反差勒？

當初會買這本書是因為這幾年對於「specification by example」與「BDD/ATDD」這個主題一直有興趣，一看到書名「Executable Specifications with Scrum」就被吸引了。但Teddy覺得這本書的副標題「A Practical Guide to Agile Requirements Discovery」當做書名會比較好，因為書中的重點並非著重在「executable specifications」的技術面（程式與工具），而是告訴讀者在Scrum的框架之下，如何落實「executable specifications」這個實務做法。否則讀書的時候一直在找「executable specifications」的程式範例與工具介紹，會有一點小失望啊。看了這本書在Amazon上的讀者評分，只有區區的2.5顆星，這可能是原因之一。

***

這本書的重點可以用書中的這兩張圖來介紹，首先看到Figure 6.10，整個Scrum的需求管理流程，從梳理product backlog開始，將大的需求透過rank（區分等級、排優先順序）、illustrate（詳細說明）、size（估算規模）、split（切割）這四個步驟逐步拆分成小而明確的用戶故事。在Scrum框架中，grooming又稱為product backlog refinement，佔用每個sprint的5%~10%的時間。

 

接著參考Figure 6.9，在grooming活動中，Scrum團隊與stakeholder針對每一個user story共同訂出幾個用來表達重要需求的「key scenario」，從這裡開始就慢慢浮出「executable specifications」的味道。每一個「key scenario」在specification workshop（參考Figure 6.10）會被展開成更詳細與具體的scenario，然後透過工具寫成自動化驗收測試案例。

***

回到Figure 6.10，在sprint planning開始之前的specification workshop並沒有出現在標準的Scrum框架之中。作者建議在這個活動中將「key scenario」展開，以便做為sprint planning中，每一個story的驗收條件。

接下來的事情就很簡單，選擇一個團隊喜歡的工具，像是Fit/Fitness或是Cucumber/JBehave/SpecFlow，將這些scenario翻譯成可執行的自動化驗收測試。

***

Teddy自己的經驗，有些團隊嘗試在grooming就列出story的所有scenario，導致團隊成員經常有grooming的時間不夠用與整個流程太繁瑣的抱怨。針對這個問題，這本書的建議就是Figure 6.9與6.10提到的方法，用兩階段的方式將scenario逐步列出來。書中並且建議每一個story指派一位開發人員當做這個story的「分析師」，負責完成詳細scenario的撰寫。

聽起來不錯，但是仔細一想整個流程變的越來越複雜，而且書中建議specification workshop不要超過2小時，如果無法完成所有的scenario，被指派為「分析師」的開發人員要找時間把工作做完。因為完成每一個story的scenario成為「Definition of Ready（DoR）」的一部分，所以sprint planning相對來說就可以進行的比較順利（因為story的驗收條件已經先定義好了）。

耶，聽起來有點up-front design的味道，是嗎？是啊。隨著團隊落實的敏捷實務做法越多（Definition of Done越來越完整），的確會有一些之前沒被強調的工作慢慢冒出來。但大體精神還是秉持著iterative與incremental的做法，一次做一點、成長一點。雖然看起來好像多花了時間在up-front design，但得到的好處卻是讓團隊每個sprint結束之後的產出物更接近「可以立即交付給使用者」的這個目標。因為需求的正確性在開發流程的早期已經被提出探討，而且可以被重複地自動驗證，所以「理論上」開發完成的軟體功能應該和使用者的期待不會落差太大。

***

「Executable specifications」串起了軟體開發的價值鏈上下游，要真正落實需要花費一番功夫，不是用自動化測試工具寫寫驗收測試就好了。一路上雖然艱苦，但最後的果實卻很甜美，值得投資。

***

友藏內心獨白：光會使用工具無法發揮全部的戰鬥力啊。