Ruddy Lee 分享空間

Emergent Design 演化設計

敏捷委外開發時的守護策略 –實例化需求

leave a comment »

.

一個經常被問到的問題:「實行敏捷,遇到大量委外開發時,怎麼辦?」

.

※ 實務上,你唯一能作的就是持續的作驗收測試,用來保證廠商所交付的功能是否仍然符合你的需求?但,當你運用「實例化需求」的解決方法時,你將會變成努力的在維護文件系統與程式的同步性,並依靠一個由文件喚起的自動化測試的系統,來持續的驗證並維護這個活文件的系統(一般而言,我會建議採用 FitNesse來維護你的活文件系統)。

.

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

.

守住「活文件」- Living Document

運用活文件來守住委外廠商所交付的功能程式還是不是好的? 是否還能夠正常工作。請參考《實例化需求》(註1)一書第三章一開始的說明:

.

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

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

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

.

因此如果企業擁有大量的委外開發廠商的話,一個好的持續進行驗收測試的方法,就是實行 A-TDD(註2)就是驗收測試開發,讓公司內部的人員守住文件的正確性,並讓它能夠與廠商開發的程式持續同步,你能夠運用的方法正是由 ward Cunningham 所創始的 FitNesse (它在: http://www.fitnesse.org/),目前的維護者是著名的 Robert C. Martin, Micah D. Martin, Patrick Wilson-Welsh & other.

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

.

12.pngFitNesse 架構(參考自www.fitnesse.org)

.

  1. 指的是我們持續維護的活文件系統(一個 Wiki Pages系統)

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

  3. 是讓我們可以客製化用來詮釋實例化表格的方式,以及要呼叫到的功能名稱的介面程式,稱為 Fixture.

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

而你要做的工作,便是把文件寫在 Wiki Pages 上,然後把測試案例加進來,並運用指定 Fixture的方式來指定要測試的程式它的功能名稱,並預先把呼叫此功能的參數及預設回傳值設定在測試案例的表格裡。接著;就可以持續進行自動化驗收測試了(請參考http://www.fitnesse.org/ 的範例)。

.

IMG_1754

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

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

.

所謂「簡化」意味著團隊一開始就應該採用一種剛好夠用(barely sufficient)的方法。

.

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

採用實例化需求之前的共識,團隊需要擁有「簡單化」的共識。因為文件這個東西,往往會因為撰寫人的追求完備性而慢慢的走向於越來越複雜的不歸路上。這是我推廣「實例化需求」時最常聽到的一句話,就是「我們的文件系統比你所展示的文件複雜太多了,如果再把測試的案例,還有那些表格加進來,那還得了 …」。是的,如果要實行實例化需求的活文件系統的話,首先要訂的策略就是盡量的維持簡單化。這一點,就好比維護單元測試的程式一樣,如果測試程式多到需要相當的維護負荷時,就有可能會產生喧賓奪主的情形,也就是維護測試程式的負荷要重於維護主程式的現象。這時候當然就應該要丟棄測試程式的時候了。為了要避免這種情形,簡單化就是最需要遵行的法則,才不會白忙一場。

.

結語

雖然大家都知道,要建立與委外廠商之間的共識才是重點。是的,建立互信是合作關係的基礎,但有趣的是,信任往往是由不信任開始的。第一次合作的廠商一定是建立在不信任之上,慢慢的由於越來越多的接觸,彼此開始產生了解而逐漸建立互信的立場,實例化需求可以成為互信的一個開始,過往的經驗裡,廠商往往在獲知你即將採用FitNesse驗收測試系統時,會主動的在自己的開發環境裡也建立這樣一個系統,並要求經常跟你的文件系統進行同步,這是一個負責的廠商往往會透過實例化需求的過程來建立與客戶之間的互信立場。因此實例化需求往往不只換來可靠的測試系統,更容易的是可以看出協力廠商的可信任度。

.

註1. 實例化需求 Specification by Example:How Successful Teams Deliver the Right Software

為 2012 年 JLOT 震撼獎的得獎作品,作者是 Gojko Adzic,為塞爾維亞人。

《實例化需求:團隊如何交付正確的軟體》是在世界各地調查了多個團隊軟體交付過程後的經驗總結。 它介紹了這些團隊如何在很短的週期內說明需求、開發軟體,並交付正確的、無缺陷的產品;為團隊在實施產生實體需求說明時使用的模式、想法和工件創建了一致的語言;展示了案例中的團隊用來實現產生實體需求說明原則的關鍵性實踐;並在案例分析部分展示了一些團隊實施產生實體需求說明的歷程。適合與專案管理、開發、測試、交付有關的人員閱讀。

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

廣告

Written by ruddyllee

2017 年 03 月 31 日 於 11:33:31

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: