Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 三月 2017

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

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 日 at 11:33:31

需求分布圖

leave a comment »

.

為什麼要看需求的分布呢?

因為要了解專案開發的人力、時間都用到那裡去了,是否把開發的主力都放對地方了呢?若要加快專案開發的速度,那些地方(需求)是最可以取捨的、影響又較少的地方。不只開發人員想知道,使用者更應該知道。

.

由需求的數量、開發時間及它在示意圖上的服務節點,可以看出專案開發的負荷及重點所在,以及它完成後將對使用者的影響。

.

1.jpg.

示意圖提供了使用者的種種行為場景,接著在針對示意圖,把各個需求放在它所服務的節點上,這樣就可以看出相對於使用者行為上開發團隊將要付出的努力所在了。當然也能拿來看出此次專案的開發重點(通常就是需求最多,最花時間的地方)。下面們就用範例來做說明,讓大家比較容易了解。

.

用一場演講來作範例

首先講師把演講的過程畫成示意圖,下面的範例是我在參加Agile Tour 2017所演講的題目: 讓英雄先救貓咪。 演講過程的示意圖如下,左邊是「涉及人」也就是來聽演講的學員,最右邊是「標的物」也就是做完演講之後,所產出的圖像紀錄。

.

2.jpg

讓英雄先救貓咪的演講場景圖示

.

這裡我們把演講的Slides當成需求,演講的過程當成描述使用者行為的場景,圖上打勾的符號表示會講到的 Slide, 打叉的是不會講到的 Slide(這是自己講課時的一種習慣,通常我們會先針對演講主題準備演講資料,最後才是針對演講的時間長短進行刪刪減減,也就是那一堆打叉的slide囉,我的習慣是把它留給學員自己參考用而不做刪除,目的是針對演講主題的完整性而不是演講時間的限制)

花較多時間講的正是講師所想闡述的重點 

我們把slide數當成需求,由需求在示意圖上各個節點的分布數量,便可以一眼望穿每個節點個別需要多少使用者故事才足以完成這項服務(功能)。也能藉著視覺化看出專案服務客戶在進行各種操作行為上的負荷(完成此項需求,工程師所需要投入的開發時間),我們也可以依據它來進行價值判斷,考慮是不是值得做這麼大或是應該再加重投資開發某項功能的比例。因此,需求分布圖足以讓我們看見專案在開發上各個需求所占的比重大小。

.

3.jpg看見專案負荷的比重

.

專案開始之初  — 看見全貌

專案開始之初首要在先看見全貌,而「需求分布圖」則是可以在需求示意圖完成後用來分析專案開發的重點所在。我們可以拿來作為投資報酬率的評估用,依據開發功能、數量在某一個服務節點上是否做了過度的投資的統計依據。它可以讓我們再一次客觀的審視各個使用者故事在某一個情境上的負荷及相對的價值。

.

結語

需求分布圖的依據是使用者的場景示意圖,一切以使用者為主軸。它的效用就好必影響地圖一般,可以看見工程師開發某一個功能相對於它對使用者的影響路徑所在,可以用來分析用。而需求分布圖看的則是全貌,展示專案開發在需求負荷下的分布狀態,我們可以拿來評估專案的目標跟預期的計畫重點是否一致,有沒有做錯重點、把時間及開發功能投資錯了地方。

它也是我上課時的依據,我會把課程先做成情境的描述示意圖(它就是整個演講的過程),然後把如何協助講課的 Slide當成需求(凡需求就要區分重要性,也就是Must have/ Should have/ Could have/ Won’t have的區分),它是我拿來對演講時間有限的清況下,這時候;我只要斟酌這張投影片的重要性,再決定要不要放棄不講(也就是在右上角標示 W: won’t have 符號)。

 

參考: 「讓英雄先救貓咪」的演講投影片

https://1drv.ms/f/s!AtlpfGB0RrJoh7sK0CvFHArPKK95qA

 

Written by ruddyllee

2017 年 03 月 24 日 at 11:46:42