敏捷規劃與組合管理 - Agile Planning and Portfolio Management

  • Article

 作者 – 李智樺 (Ruddy)

TFS 2012 的TFS Web存取讓團隊透過網頁分解需求與工作，並以面板呈現進度與狀態。TFS 2013 新增「特殊功能(Feature)」工作項目，可以階層式的方式建立多個「特殊功能」工作項目間的父子關係，並透過網頁的編輯環境增修與呈現，讓大型團隊內的多個小團隊可以清楚彼此的狀態與進程。

分解使用者劇本

運用「使用者劇本(user story)」來描述使用者需求，不但廣為大家所採用，也成為Scrum建立產品待處理項目(product backlog)的基本工具。雖然人們接受這種用故事的方式來描述需求，但工程師要真正將使用者劇本分解成可以執行的工作項目時，仍然會因各種需求不同，而經常碰到分解上的困擾，以下是可以協助你分解(break down)的規範。

  • 依據標準範本撰寫使用者劇本：

As a <user>, I want <business functionality>So that <business value>

身為 ，我希望 從此以後

  • 依據標準範本撰寫這個故事的驗收準則(Acceptance Criteria)：

Given <starting conditions> ，When <event> Then <result>

假如 ， 當 那麼

一個使用者劇本對照至少一個驗收準則

這樣做是盡量確保你能夠了解提出需求的用戶，其背後的動機是什麼，以及他們試圖實現的故事，同時還要確保這些需求可以被驗證。一般而言，當我們第一次試圖將使用者劇本轉換成工作項目時，第一個會碰到的問題是，這個故事似乎太大了一點，好像無法在一至二周的衝刺周期內完成。

此時該深入了解，試著問自己：這個故事可以分解成工作項目了嗎？如果不行，為何不行呢？因為故事太大了嗎？這些問題通常是以下的幾種原因所造成的：

  • 複合式故事：故事中含有多重目的，採用了“和(and)”及”或(or)”的語法，多重目的用法會模糊了目標，應該盡量的簡化，最好每個目標都能單獨寫成個別的故事。
  • 複雜的故事：通常描述不確定性較高的需求時，就會感覺較模擬兩可，不容易抓到重點，此時的故事可能寫得複雜了些。

怎麼辦呢？我們可以嘗試下面的幾種方法分解：

  • CRUD ( Create/ Read/ Update/ Delete)

當可以區分是 CRUD的功能時，就應該把它們分開來寫成個別的故事。特色是；通常這類的使用者劇本你會覺得只寫一條驗收準則(Acceptance Criteria)是不夠的，這時候大可為CRUD個別寫驗收準則，再反過來相對地拆解出個別的使用者劇本。

  • 決策樹

遇到故事有顯著的複雜性時，能夠運用決策樹來確定什麼樣的業務邏輯或行動需要發生。這時候可以將那些對應的節點(那些老是產生相同數值的節點)寫成個別的使用者劇本。

  • 工作流程步驟

遇到故事有顯著的工作流程存在時，可以將每個細分出來的工作步驟，都寫成一個使用者劇本，就能達到簡化的效果了。

  • 對外部品質的妥協

「內部品質(Internal Quality)」指得是在設計軟體時就可能埋入的缺陷。如果內部品質下降，該系統在未來就較難改變。因此，務必要透過不斷地重構，明確的編碼，及嚴苛的測試(unit test)…等保證程式碼品質的方法，來避免內部品質不良，這部分是不能妥協的。

相對於「內部品質」的是「外部品質」，它是相對的輔助功能，例如：與使用者操作正確性無關的動畫或背景圖，雖然它是外觀上的重點，可以吸引客戶而有其必要。但對於功能測試而言，明顯在初期開發階段不是重點。所以在運用使用者劇本做分解時，可以考慮調低其重要性，待事後再來補救。

  • 運用None、One、Many 模式

用假設法來破題，針對None假設根本沒有這種現象，便能產出第一個使用者劇本。接著假設這種現象只發生一次，這是針對 One，再產出第二個使用者劇本。最後假設會經常發生(Many)，要有何種內容的使用者劇本。運用這種模式來將較大的故事進行拆解。

  • 切蛋糕法則(slicing the cake)

當工程師必須分割較大的故事時，通常第一個想到的；是沿著技術的方向去切割，做法雖合理，但很容易就把故事寫得只能滿足部分需求，成了缺乏完整描述的使用者劇本。此時，合理的作法是沿著需求的邊緣切割，就好像切蛋糕一樣，讓每塊都有它的完整性。

使用者劇本是開發人員提問的依據

有經驗的產品擁有者(Product Owner)經常會在召開衝刺會議(Sprint planning meeting)之前，反覆閱讀自己寫來描述需求的使用者劇本，透過「閱讀及重寫」的反覆方式讓故事的範圍盡量縮小，以便達到工程師們可以依據它，成功地分解成可以開始的工作項目。

但在數十條的使用者劇本中，總會有一些個偏大的故事出現，這種現象通常是它們包含了太多的資訊，因此產生了複合式及複雜性較高的使用者劇本，前文提供一些解法。但不要忘了，使用者劇本的真正目的是讓工程師能依據這些故事，向產品擁有者提出問題，並透過一問一答的方式，對要開發的產品進一步了解。所以故事過大，或透過上述的切割法之後，勢必會產生一些想依性(dependency)，這是必然現象，大家真正的目的是盡快釐清工作，正確地開始幹活，開工後能夠再持續的溝通，才是真正解決問題的妙方。

而當團隊在討論及規劃使用者劇本時，可以透過TFS 2013所提供的「Backlogs」功能，依照上述的法則來建立可行的工作項目，如圖1所示：

 

圖1：團隊成員透過TFS Web存取提供的Backlogs功能來規劃與檢視使用者劇本

Agile Portfolio管理

在運用Scrum進行開發時，常會被質疑規模的大小，如圖2所示：

 

圖2：管理者對多團隊專案開發的困擾

  • 大企業擁有數以千計或上萬名的開發工程師，同時擁有數以百計的專案在進行，請問Scrum可以適用於這樣的規模嗎？
  • Scrum強調小組開發的方式，可以適用在大型專案嗎？
  • 主管如何來管理控制專案排程呢？

這是Scrum在多團隊開發下經常遭遇到的困擾，我們習慣的解法是「Scrum of Scrum」；也就是多層次的Scrum運作。但始終缺乏好的工具來結構化管理。

微軟針對這個問題提供了解法，引進產品組合管理(Portfolio Management)的觀念，在TFS2013內提供「Agile Portfolio管理」，以階層分析方式處理多團隊的Scrum of Scrum模式，管理多個開發團隊，統一運用資源。至於實作上，就是在原有產品待處理項目上再加入了Portfolio backlog的管理項目。如圖3所示(左右二個圖是在顯示Portfolio Backlogs與產品backlogs的相互對照)：

  圖3：擁有多層次的 portfolio backlogs與產品待處理項目(Product Backlog)

由於加入了多層次的 portfolio backlogs，管理者在專案規劃上，可以全盤掌握到個別團隊在某一專案上的產品待處理項目，也讓測試團隊可以進行全盤性的測試規劃。圖2右側開發團隊及產品代處理項目對照到左側的多層級圖示，可以看出針對使用者產出的使用者劇本為左圖灰色線下方的底層部分，它包含了產品待處理項目及工作項目(task)。這是呈現開發團隊進行開發作業所依據的部分。

灰色線上方則屬於管理階層，依據最佳化團隊開發資源的前提，協調多個團隊。至於這種多層次的 portfolio backlogs，到底需要幾層才足夠呢？則完全視專案團隊的多寡，及針對需求內容進行的分析為依據，來決定是否需要這個項目。

工作項目的追蹤連結

多層次的portfolio backlogs，看起來似乎會增加使用者的負擔，但它是運用在開發大型專案時，追蹤多個團隊的好用工具，如圖4所示：

 

圖4：工作項目的追蹤連結

我們可以將工作項目關連起來，好處是：讓你在進行工作規劃時更有效率，更準確地追踪工作項目之間的關係，讓跨團隊的整體開發作業之層次更清楚，更快速地找到相關的資訊。

圖4中，顯示在左右二個工作項目中，分享了第一層的測試案例和共同工作步驟，讓使用者可以據此來管理或設定測試計畫。同時，這些追蹤結果也能夠傳到 Excel 或其它Office產品，方便地分析運用。

透過新增的「特殊功能(Feature，在不同的團隊專案範本會以不同的工作項目名稱呈現)」工作項目，搭配TFS「Backlogs」的Web編輯與呈現環境，企業將可以更容易地管理、協調與整合多個開發團隊，其編輯畫面如圖5所示：

 

圖5：透過工作項目與Web環境管理Agile Portfolio

也可以透過「面板」的方式呈現較高層次、不同團隊進行中的項目，如圖6所示：

 

圖6：透過面板呈現進程與狀態

TFS 2013現今可以擴大工作規模，以完成更廣泛而高層次的目標。讓每位團隊成員都可以藉由相同的工具程式與平台共享資訊與溝通協調，套用相同的開發流程範本，訴說共通的語言。不僅讓個別的小團隊可以追蹤進度與分析問題，更可讓管理階層瞭解目標與細節。相信這將讓大型團隊更有彈性地面對問題，並有效地解決問題。

附註：

  1. 使用者劇本的分解法參考自 Mike Cohn 的經典名著 User Stories Applied： For Agile Software Development。
  2. GWT，Given-When-Then的驗收準則，取材自行為驅動開發法(BDD) 中成熟的一個框架： Cucumber。

 

延伸閱讀