Ruddy Lee 分享空間

Emergent Design 演化設計

如何增加、減少DoR — 運用看板方法

leave a comment »

 提要

1. 什麼時機點需要增加DoR? (過濾需求是否備妥)
2. 什麼時機點需要減少DoR的動作?(避免浪費)
3. 在看板上要怎麼作?(看板如何控制流程)

.

前二篇文章一直圍繞著如何來檢查需求的資料是否備妥,也就是 DoR(Definition of Ready)的作法。現在則要來談一下,什麼時候應該要作DoR?及什麼時候則可以省略它。

.

需求很難拿捏是否Ready了?
DoR的出現是因為 Refinement meeting 的被高度關注。你可能會有一點疑惑,為什麼從前不去談它呢?難道從前它就不重要,一直到現在才開始變得重要了嗎? 當然不是的;「視覺化」抬頭是其中一個因素。另一個原因是因為敏捷開發在開始之初,擔心大家容易在這裡又會像傳統開發一樣把時間都花在作文件上了,會重犯了CMMI的老問題,因此刻意不作深入的描述。但近幾年尤其是對需求的控管變得越來越重要,而開發流程又受到新創團隊的MVP策略ㄙㄨㄛ影響,使得refinement meeting就越來越受到重視了。

.

宜減少DoR的時間
當專案的技術複雜度遠高於需求變化度的時候。工程師能盡快開始問題挖掘作業,則對專案的進展越是有幫助。反過來換個角度來看它;一個較大的組織,往往在運作的時候會有層層負責的現象,這種每個人各盡其職的結構是造成專案開發之所以「快不起來」的最基本原因(因為界面變多了,人們往往會認為自己已經作的夠多了,忘了要全面性的來看問題,因此就容易造成許多工作掉落一地,沒人去作。出問題時,大家都忙著在弄清楚是你該做還是我該做。對很需要快速回饋市場運作的專案,讓「運作扁平化」是一道管理者的功課。

宜增加DoR的時間
當專案的需求變化遠大於技術的挑戰性的時候。此時不宜讓工程師太快拿到問題,也就是增加用抽象解題的時間,讓問題的可能性更容易分晰的時候,也就是更明確的知道「需求」要些什麼的時候,再把工程人員請進來,這個時候對團隊戰力快速推進,才會有大幫助。

.

適度的運用看板來控制它
在product backlogs的欄位後面多加上【DoR】的欄位。當應該減少浪費在DoR的時間的時候,給它較大的WIP值(Work In Process)。相反的,當需要嚴格過濾需求的時候,把WIP訂小一點。

.

》什麼時候可以不用有 DoR的欄位呢?

 

即便是完全在同一個單位裡運作DoR還是很難省略,維護的工作也是如此,不作DoR就好似瞎子摸象一般,對問題大部份都用猜的來作探討。(這一點大家都很習慣了XD)。但在團隊運作良好,專案開始漸上軌道的時候,哈哈!一種可有可無的現象便會應運而生,正是可以省去DoR的時機來了。

 

小結

我的團隊需要DoR嗎?

》正確的問法應該是:這個專案的DoR需要重視到什麼程度?

 

 

 

 

 

Written by ruddyllee

2016 年 06 月 22 日 於 23:21:44

張貼於未分類

Tagged with ,

發表迴響

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

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: