Ruddy Lee 分享空間

Emergent Design 演化設計

需求要作到哪裡為止?

leave a comment »

.

敏捷開發需求要不要全部做完?

.

Sprint可以消化需求,但展示會議又會在尋求回饋時增加需求,因此便產生了更多的需求,每個迭代下來需求只會不斷的增加,試問需求什麼時候才能做得完呢?

 「梳理會議 Refinement meeting 是需求進行調整、刪除的時機,但PO經常只做需求修整,很少會去刪除需求」

 .

敏捷開發的一大特色,需求持續的增長

需求的增長可能是來自展示會議的回饋,也可能是開發團隊越來越清楚應該給客戶些什麼(團隊自我回饋)或是為了強化程式架構性的需求(來自工程師的回饋)。總之;需求增加了,但專案的開發時程卻隨著時間的過去一再地減少著,而人力與資源也持續的消耗著。請問;需求要作到哪裡為止呢? 這裡提出一個新的措施,設定需求停止開發線

需求無限上綱.png

左側: 解決之道,右側: 持續增加的需求

.

停止開發線  Stop Development Line

一條屬於PO與團隊共同協議下的需求停止開發線(SDL)。它可能是因為要作發布作業所以必須停止開發的工作日,也可能是專案預定開發時程的結束日,當然也可能是專案的資源用完了、專案預算被終結了都有可能(需要多考慮到使用者測試及發布作業所需時間)。總之;專案的需求開發工作在這裡停止了,接著來的是使用者的測試作業或是測試後的缺陷修補,在敏捷開發的作業下,需求很少是被完全做完的,這要歸因於敏捷開發採用迭代的開發方式,因此需求只有在要進入開發之前(一般是梳理會議 Refinement meeting) 時才會被拿出來仔細討論,因此也就產生了較大顆粒與較小顆粒不同的大小差異的需求存在 backlog 裡頭。一旦較大的需求被開始Breakdown 時,需求的數量就可能會再增長,這是需求不斷增加的另一個來源點。

.

需求的無限上綱

每個Sprint開發團隊都會努力的去消化需求,這是需求主要減少的來源,另外就是梳理會議,它可以就不需要的需求進行討論後決定是否刪除,這時需求也會減少。但每個迭代後的展示會議又會向客戶尋求回饋,繼續新增需求,因此就產生了需求數量的持續增長,試問需求什麼時候才能做得完呢? 答案:

實施敏捷開發時,一切以滿足使用者為主,需求是不需要全部做完的

.

如上圖右側的區間,為了克服持續增加的需求量,所以我們在需求的累積堆疊裡新增一條停止開發線(SDL),這一條時間線限制了開發作業的停止開發日,換句話說;需求只做到這裡,線以下的需求預計將不會被做到,也就是成為了需求的候選名單,之所以稱為候選名單,原因是這些需求可能透過梳理會議時因為其他需求的刪除與修改,而向上提升到停止線的上方,進入到可以被開發到的範圍。這是敏捷開發的動態化需求的一種特色,它是隨著客戶的要求做增減的(唯一的例外是: 只有當Sprint在進行時,該次Sprint所要完成的需求是不容許被變動的)。此外,PO擁有梳理需求的絕對權限,但停止開發線卻是PO與開發團隊共通的協議(是被討論出來的)。

.

線的上方有一個區域稱之為需求的競爭區。這是一個在停止開發之前最後被做到的需求區,這塊資源是由所有客戶所共享的,使用者可以決定在發布作業之前產品將擁有的功能範圍。之所以稱為需求的競爭區的原因是,每一個提出需求的使用者,都希望自己所提出的功能被做到產品裡頭(我們應該以滿足所有提出者的希望為圭臬),但受到停止開發線的限制時,就有可能被規畫到不會被做到的需求,因此就會產生競爭;一種希望自己的需求能被放入開發功能區裡頭的競爭(PO與其他的利益相關者 Stackholder 持續進行角力與溝通),這是難以避免的現象,至於採用甚麼標準來做取捨,就由組織自行決定了。這是一種良性的需求取捨行為,對敏捷開發有著正面的效應。需求在透過不同的 Stackholder 討論之後將更為精煉。

.

圖的左側提供解決原則:

  需求的優先順序

我們以完成此需求對客戶所產生的價值為依據,依序排列下來便可以得到需求的優先順序。即便是到了最後需求沒有完全作完,但基於有限的開發時間裡至少我們把較重要的部分都開發完成了(請參考註解,談到需求開發與功能真正被使用者使用到的百分比)。

  需求的梳理

產品負責人Po擁有對所有需求進行新增、刪除、修改的權利。這屬於PO對產品進行開發的權利與義務的一環,梳理會議refinement meeting是它的執行時間,一般以不定期的每周召開一次為主,時間為固定的一個小時之內完成,梳理原則如下:

  將較大的使用者故事調整(Break down)到適合開發的大小。

  改善那些寫得不好的使用者故事。

  開發團隊對使用者故事進行相對估算,以符合 Sprint 足以開發完成為主。

  對使用者故事加入驗收標準。

  深入規劃產品待辦事項,做較長期性的技術規畫。

  刪除沒有必要開發的需求(對於開發作業,少就是多的哲學,參考註解)。

善用停止開發線

這是一條以時間為依據的動態限制線,它明確的規範了需求開發的終止日。停止開發線的產出方式:

.

PO與開發團隊一起討論出來的共同協議。

  開發團隊評估自己的開發能力並與PO預期想要獲得的商業功能,在二者之間進行協調後取得的停止開發線。

初期估算的日期較不準確,應該隨著專案進行到後期,相關訊息越完整時持續進行調整。

需要多考慮到使用者、整合測試及發布作業所需的時間。

.

它可以用來應對需求很少被刪除的情形進行改善(一般PO的通病,偏好需求的修改很少有刪除的動作,造成需求的數量出現容易增加但卻不容易減少的現象)。PO通常可以運用使用故事地圖作為劃分出產品最後完工時的功能雛形,而停止開發線能讓此雛形得以具體化。

停止開發線的好處:

  可以拿來解決需求只增不減的問題。

   讓發布作業變得明確。

  便於掌握資源與預算。

  便於具體化產品的功能雛形

.

小結

敏捷開發不願重導傳統開發對需求過度計畫的問題,因此只有在 Sprint 開始前才會花時間去做需求個別的細部 break down。因此對需求的堆疊(本體)而言會始終保持一種足夠抽象的形式,直到他被選擇進入開發週期才會被細化,也就是只有在開發團隊真正要開發的時候(進入Sprint的週期)才會花時間去做估算。在這種作法之下,實在很難進行整體專案的時程預估,所以;如何決定停止開發線 DSL的時間呢?確實很難估算,有一種好的做法是: 運用資源的多寡來決定停止開發的時間線,這是一種務實的作法。也符合敏捷開發做到客戶滿意為止的精神。範例: 在精煉(將專案資源考慮進去)之後產出的使用者故事地圖,團隊就可以依據此地圖的總需求量來決定第一次停止開發時間線。你可能會擔心它的準確度,但因為它是動態的一條線(隨時都可以來調整它,一般會在每次的梳理會議refinement meeting時進行調整)因此不需要太在意第一次的設定日期,真正該重視的反而是它上面的需求競爭區間的大小。

.

.

  Standish Group 總裁 Jim Johnson 2002年的調查,針對軟體被使用的開發功能應用統計。一般僅有( 一直會被使用到 7% + 經常使用 13%=) 20% 的功能經常被使用者用到,其他有 45%的功能,幾乎重來沒有人去使用,這張圖可以提醒我們應用程式的少數功能,其實就能滿足真正使用者的需求了(這個統計結果是用來粉碎需求必須全數完成的謬誤觀念,為 Jim 在 2004 extreme programming 年會所發表)。

pie-chart-copy

.

:  如果你的開發作業是委外開發的形式(outsourcing) ,當然就可以忽略這一條線了,因為廠商會自動把資源控管住,你想多做一點都很難!

 

.

廣告

發表迴響

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

WordPress.com Logo

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

Twitter picture

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

Facebook照片

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

Google+ photo

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

連結到 %s

%d 位部落客按了讚: