Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 四月 2017

團隊如何解讀看板 – 1分鐘統計報告

leave a comment »

.

許多敏捷團隊都已經運用看板進行站立會議,但卻仍然採用傳統Scrum站立會議的三件事來進行會議:

  • 昨天做了什麼?

  • 今天準備做什麼?

  • 有沒有遇到障礙?

 

對看板而言;其實這三件事都已經記錄在看板上了。雖然這種做法基本上沒有什麼問題(我也一直是這麼做的,但總是會覺得好像有些不足的地方,好像可以作得更好才是,因為這是團隊共同的事,所以應該是團隊一起運作才是,一問一答的輪詢方式似乎太個人化了?!)。這麼做會忽略了看板上已有的資訊,而無形間浪費了看板上的基本資訊,也就是團隊在「視覺化」上的認知機會。團隊也會因此把焦點放在了個別成員的身上,而忽略了看板所具有的團體性。那要怎麼做才能充分運用這些特性呢? 一種看板式的站立會議,它是以團體為主的方式,它專注於回饋(一分鐘統計報告):

.

解讀看板

適合團隊共同運作的看板式站立會議

.

一分鐘統計報告

首先;運用值星生的方式,讓團隊成員輪流擔任這個職務,輪到的人,就要負責看板的維護工作,然後必須在站立會議時做先期解讀的工作,先幫大家做一次統計式的解讀,目的是協助團隊迅速進入狀態。然後才是由SM負責一對一的輪詢,問的內容當然就不止於那三件事了。進行的步驟如下:

  • 設定「值星生」的制度,以一個星期為一輪,讓他負責日常看板的整理工作還有看板的維護。並於站立會議時首先發言,用一分鐘來向大家解譯目前的看板狀態,讓團隊能迅速進入狀態,而無須重新做個別解讀。提供團隊一起能夠同步看板的視覺認知。這是一種單向的報告方式,團隊無須立即回饋。「值星生」必須以統計分析的方式進行報告看板現狀。

  • 然後由SM 接手以 提問 的方式輪詢團隊成員個別的工作狀態,並要求成員對值星生的報告進行必要的解釋或回饋

  • 最後,SM針對個別事件進行 重點討論,詢問團隊是否變更流程以解決障礙、等待Waiting狀態說明及討論是否需要進行變更(WIP值)來改善流程速度,作總結或重申重要事項。

.

統計式解讀.png

參考自一日看板遊

.

統計式的看板解讀

解讀上圖: ( 由右往左)

》團隊還沒有成功的發佈任何東西,因此發佈欄位是空的。

》有一個嚴重障礙,就是測試區Task-A 無法被正常布署,沒能夠通過測試,測試人員正在努力中,但因為測試欄位的 WIP值設成1(因此只要有任何一項測試失敗看板就會被卡住)。

》這時候當初做Task-A的成員正在做 Task-C(是否請他們協助偵錯? 畢竟解鈴還須繫鈴人),而另外一組成員已經做完Task-B了,但受限於看板測試欄位的上限WIP值因此無法移進來做測試,因此沒有進度。

》預備欄位目前只有一個 Task-D 可以再移入一項工作。

》此時產品負責人PO仍在審視所有的工作項目。

看板解讀由右往左的目的是希望能盡快看到障礙,尤其是上圖中將測試欄位的WIP上限設定成1,表示這個團隊非常重視品質,只要有任何一個測試失敗的工作項目,團隊就要停下來解決,一直到解決之後才能繼續開發的流程。當然我們可以考慮把WIP上限調高,但這樣做了就會延遲解決問題的速度,但仍然能夠持續有產能輸出,好處就是生產線不會完全停下來。

 .

善用值日生

看板需要整理,又必須與工具(ALM: Application Life Cycle Management)同步,SM常常為此抱怨連連。採用值星生的方式能夠適當的降低SM的負荷,又能多一個人出來管理、解讀看板。是團隊落實自我管理的一種實踐。

因為以星期為範圍所以稱為值星生好像比較準確。看板值星這件事,勢必會造成「值星生」不得不在站立會議之前先行整理過看板,然後再運用統計的方式先行解讀過看板,然後才能在站立會議時運用足夠簡潔的語句描述給團隊聆聽,而團隊也會因為有人代為解讀了看板,便可以省下各自解讀的時間花費,一起聆聽看板解讀也能造成大家對看板上的動態有更一致的認知。同時這也是一種回饋的方式(只要團隊成員聽完後覺得跟自己的解讀有所差異時,此時成員之間任何的交談與討論都是極具價值的)。

.

小結

團隊共同解讀看板的方式:  (站立會議開始)由「值星生」先為大家以統計的方式做1分鐘看板解讀,然後才是由 SM 接著進行輪詢團隊成員,成員一一更新看板上的工作項目,同時就剛剛值星生的解讀進行解釋或更正。完成一輪後SM 做成重大事項的總結或重申重要任務。站立會議於 15 分鐘內結束。

.

廣告

Written by ruddyllee

2017 年 04 月 25 日 at 17:27:26

需求要作到哪裡為止?

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) ,當然就可以忽略這一條線了,因為廠商會自動把資源控管住,你想多做一點都很難!

 

.