實例化需求，軟體外包質量管理的神器

作者簡介：

Ruddy Lee（李智樺）老師

DevOpsDays北京站金牌講師，台灣著名精益佈道師，敏捷專家，著有《精益開發與看板方法 》。

一個經常被問到的問題：「實行敏捷，遇到大量委外開發（外包）時，怎麼辦？」

實際上，你唯一能作的就是持續的做驗收測試，用來保證廠商所交付的功能是否仍然符合你的需求？

但是，當你運用「實例化需求」的解決方法時，你將會變成努力的在維護文件系統與程序的同步性，並依靠一個由文件觸發的自動化測試系統，來持續的驗證並維護這個活文件的系統（一般而言，我會建議採用FitNesse來維護你的活文件系統）。

註：明確描述的文檔與程序同步，即活文件 living document

採用「實例化需求」的最大好處，就是能夠持續做到自動化測試，並明確的運用文件上可自動化驗收的測試用例數據，做到測試與文件同步的效果。

守住「活文件」 - Living Document

運用活文件來守住委外廠商所交付的功能程序還是不是好的？ 是否還能夠正常工作請參考「 實例化需求」（注1）一書第三章一開始的說明：

「一般認為實例化需求說明的過程和工具有二種流行的模型。以驗收測試為中心的模型及以系統行為規範為主導的模型。

以驗收測試為中心的模型，就是A-TDD也就是驗收測試驅動開發 ，側重於自動化測試。並把它作為實例化需要說明的一部分。他的主要優點是使開發目標更為明確，並且可以防止功能退化。

以系統行為規範為主導的模型，通常稱為行為驅動開發 ，也就是BDD。其側重於制定系統行為的場景。它的主要工作是透過協作與需求澄清，在項目干係人和交付團隊之間建立共識「。

我每隔幾年就會與它相遇一次，同樣是採用SBE（Specification By Examples，實例化需求），但我總是會採用驗收測試的FIT架構，而沒有使用更適合內部開發採用的BDD（Behavior Driven Development行為驅動開發），這一點並非我有所偏好。實質上是我碰巧都遇到處理委外的問題所致。實質上，該採用那一種解題法呢？ 就要依照要解決的問題種類來作判斷了。這二種方法要用對場合了，才容易有功效。因為它們都有相對需要付出的維護作業負荷。

指的是我們持續維護的活文件系統 （ 一個Wiki Pages系統 ） 。

指的是委外廠商所開發的系統。

是讓我們可以定製化用來詮釋實例化表格的方式，以及要調用到的功能名稱的界面程序，稱為Fixture。

中間核心的部分，分成上半段的 FIT（ 舊有的整合測試功能引擎 ） 及下半段的 SLIM（Simple List Invocation Method新開發的引擎 ） ，網站上有描述舊有的整合測試功能引擎 FIT 因為複雜性較高，維護的負荷逐漸變大，才有新引擎的出現。

圖的上半部是一個填滿測試用來數據的表格，最後抬頭名稱有問號標註的是用來驗證的回傳值。

圖的下半部是一個Fixture的範例。

所謂「簡化」意味著團隊一開始就應該採用一種剛好足夠（勉強足夠）的方法。

實例化之前一定要制定「簡單化 」的守則

採用實例化需求之前的共識，團隊需要擁有「簡單化」的共識。因為文件這個東西，往往會因為撰寫人的追求完備性而慢慢的走向于越來越複雜的不歸路上。

我推廣「實例化需求」時最常聽到的一句話， 就是「我們的文件系統要比你所展示的文件複雜太多了，如果再把測試的案例，還有那些表格加進來，那還得了...」。

是的，如果要實行實例化需求的活文件系統的話，首先要訂的策略就是盡量的維持簡單化。

這一點，就好比維護單元測試的程序一樣，如果測試程序多到需要相當的維護負荷時，就有可能會產生喧賓奪主的情形，也就是維護測試程序的負荷要重於維護主程序的現象，這時候當然就應該要丟棄測試程序的時候了。

為了要避免這種情形，簡單化就是最需要遵行的法則，才不會白忙一場。

結語

雖然大家都知道，要建立與委外廠商之間的共識才是重點。是的，建立互信是合作關係的基礎，但有趣的是，信任往往是由不信任開始的。

第一次合作的廠商一定是建立在不信任之上，慢慢的由於越來越多的接觸，彼此開始產生了解而逐漸建立互信的立場，實例化需求可以成為互信的一個開始。

過往的經驗里，廠商往往在獲知你即將採用FitNesse的驗收測試系統時，會主動的在自己的開發環境里也建立這樣一個系統，並要求經常跟你的文件系統進行同步，這是一個負責的廠商往往會透過實例化需求的過程來建立與客戶之間的互信立場。

因此實例化需求往往不只換來可靠的測試系統，更容易的是可以看出協作廠商的可信任度。

注1。 實例化需求Specification by Example:How Successful Teams Deliver the Right Software為2012年JLOT震撼獎的得獎作品，作者是Gojko Adzic，為塞爾維亞人。

《實例化需求：團隊如何交付正確的軟體》是在世界各地調查了多個團隊軟體交付過程後的經驗總結。

它介紹了這些團隊如何在很短的周期內說明需求、開發軟體、並交付正確的、無缺陷的產品；為團隊在實施產生實體需求說明時使用的模式，想法和工件創建了一致的語言;展示了案例中的團隊用來實現產生實體需求說明原則的關鍵性實踐;並在案例分析部分展示了一些團隊實施產生實體需求說明的歷程。

適合與項目管理、開發、測試、交付有關的人員閱讀。

注2。 ATDD所指的是驗收測試驅動開發，一般所謂的TDD實際上可以加註為UTDD。 U是UNIT的意思，它明確的指向進行單元測試驅動開發，但很少人這麼用。

您在外包（委外）管理中遇到過什麼問題？歡迎留言，大神和你一起來解決。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！