如何處理固定上線日期的專案

敏捷團隊如何處理固定上線日期的專案(Fixed-Date Release Project)，正名一下；我們面對的是如何進行Fixed-Date Release Planning 的交付計畫，有關Release Planning在敏捷開發裡頭是一個比較敏感的字眼，因為乍聽起來它給人很Waterfall的感覺，但不可否認的還是有存在的價值(有興趣的人可以參考Mike Chon的說法) 。這裡我們先依據 Kenny Rubin (《Essential Scrum》作者)的建議，分成6個步驟來處理:

第一步、首先確定版本開發會Run多少個sprint。假設所有衝刺長度是相等的，就變成簡單的數學計算了，因為您知道第一個sprint何時開始，並且您知道交付日期。

第二步、通過創建細項需求，估算產品待辦事項(Product Backlog Items)的大小和優先級來確定產品一直到足夠完成發布的深度。也就是你需要有足夠的PBI來計劃到固定的發布日期 (在Essential Scrum的第6章中有關產品待辦事項的更多說明)。

第三步、測量或估計團隊的開發速度作為範圍的依據(見Essential Scrum第7章估算和計劃：)。

第四步、通過將團隊的開發速度中最慢的數值乘以衝刺的數量來畫出一條開發產能的低標線(Slowest, 橘色線條)。 並將該數量的點數畫入產品需求累積圖中。

第五步、是通過將團隊的開發速度中的最快的數值乘以衝刺的數量來畫出一條開發產能的高標線(Largest, 紅色線條)。將該數量的點數畫入產品需求累積圖中。

第六步、是比較產品需求累積圖中的最小可發布功能(MRF；Minimum Releasable Features) 的可能性。如果所有必須完成的需求(Must Have)都落在橘色線內，那麼你的狀態很好，表示可安全過關(Good, 最左邊圖形)。 若是落在中間區域: 則表是有可能完成。如果是落在紅線下面的區域外，則表示團隊即使是用最大產能的速率來進行開發作業也不可能把必須完成的需求(Must Have)全數做完，也就是說你必需另外做打算了。

註: Ken寫道；如果你的專案範圍比完成日期更重要的話，則建議採用“固定範圍發布計劃”Fixed-Scope Release Planning。

.

參考自Innolution網站

.

真實世界的固定上線日期專案

在真實世界裡總有著各式各樣的理由，讓你非得在時間內(Fixed-Date)完成專案的交付。有可能是時節的緣故；例如月餅的銷售就得在中秋節前完成才有意義或是雙11的改善作業，哪就得在11月 11日以前完成才有意義。當然也有可能是多家公司上下游的聯合開發模式，你就是硬生生的被卡在中間的位置，而上下游的開發作業都沒有採用敏捷迭代的方式進行開發作業。在這些情況下如果參考上面所談到的敏捷式的解題方式，給人的感覺就不是很真實了，這6個簡單的步驟雖然很容易理解也好像很合理，但總覺得好像少了什麼? 是不是有什麼重要的因素漏掉考慮進來了呢?

專案開發總是有很多我們不會知道的事

這是敏捷開發的一種典型解題模式「小增量迭代」的觀念在作祟，它的目的是為了避開Big Design Up Front (BDUF)也就是在專案還沒開始時就過度設計的問題(這是一種一直以為可以透過完善的設計來達成任務，如果失敗了就是因為我的考慮不夠周詳，是典型Waterfall式的思維方式)，而敏捷開發就不會花太多時間去把所有的需求都做估算然後再做成統計上頭，而會尋求從重要的需求先確認後便快速開工的方式。相較之下，上面的估算方式就會給人一種好像過度簡單的感覺，但我們就稱之謂敏捷化。

>>>

》老闆與工程師的對話:

「你專注起來做事還滿可怕的，六親不認、生產力奇高無比，而且連測試的部分也沒有偷懶，做出來的品質也都還不賴！要是能每天都能像這樣就好了！」老闆調侃的說著…。

「吼！我也知道啊！可是像這樣每天閉關工作十幾個小時，很累人的！怎麼可能每天這樣啦！會死人的好嗎？」

「接下來的連續假期我一定要出去走走，好好放鬆一下，實在是受不了！」

– 固定上線日期的專案

》PM與工程師的對話(開發團隊坐進戰情室後，PM坐在門口)

工程師:「我要去上個廁所，手機可以還我了嗎！」

PM:「好的，五分鐘夠不夠?」

– 戰情室情節

>>>

所謂的「戰情室工作法」；就是把負責開發的團隊成員，全部關進同一個房間裡，目的是盡量減少他們受到外部的打擾(所以請在進入房間以前交出手機)，讓它們專注的去完成任務。這是IT部門遇到固定日期專案超過他們的產能時所常用的手法，正可以拿來呼應上面的二句對話。它實質上雖是可行的，但不能長期如此，原因是會造成團隊與其他團隊之間的脫勾無法進行協作，而且工程師在長期承受過大壓力下，離職率會上升，身心也會較不健全，是一種開發作業的短期解。

.

以大家能形成共識為前提

.

前提是讓業務、PO及Tech Lead形成共識

工程師不喜歡固定上線日期的專案，這是一種先入為主的感覺，即便分析結果上線功能落在產能的低標線內，工程師還是普遍覺得壓力太大，即便只是聽到自己即將參加一個固定上線日期的專案時心理頭就會自然浮現出一種無形的壓力，會自動想像加入這樣的專案，就好像要被關進戰情室一般(也就是所謂的戰情室工作法)，開發工作像是在跑百米衝刺一樣，企圖在很短的時間內透過高度聚焦來完成預期不可能的任務一般(敏捷式工作法則比較像是採用均速跑法的長距離馬拉松)。這是一種普遍的錯覺，但一旦形成這種先入為主的觀念，就很難去改變它了。因此針對這種非固定上線日期的專案，團隊對專案的共識才是重點。也就是要形成業務端、需求規劃者PO及負責開發團隊的Tech Lead能形成共識才是關鍵，大家能齊心處理專案。要能夠回歸到一種正常化的工作心態才是重點。而秘訣就是要能統一目標、統一行動及統一價值觀。要讓這三位負責不同面向的人士擁有一致的觀點才好導正大家對固定上線日期的專案的偏見。這是一種文化層面的問題，因此解題方式也必須從根源來著手，也正是所謂的長期解。

.

.

建構企業文化來面對這個棘手的問題:

※ 目的: 讓業務端、PO需求規劃者及Tech Lead開發團隊技術領導者能形成共識。

※ 作法: 讓三者都能正視到一線的需求，沒有透過轉述，並經過意見的交換溝通。

※ 執行規則: 建議是透過制定簡單的規範，讓企業形成一種處理這類事務的文化理念，並能堅持以恆。三位執行者的處理準則則是解題於 (1) 專注於主要功能。(2) 階段式的達成目標。(3) 關注於實務的細節，並取得認同。

.

要奉勸正準備拍胸脯與客戶達成上線日期協議的老闆，

先打個電話回去問問你的開發部門主管再作決定吧，

你這麼作不會有任何損失的，反而會換來對方的尊重!

.結論

為什麼需要三位一體，讓他們（業務、PO及 Tech Lead)有一致面對客戶的機會呢？這不是很花時間嗎？但這能夠所代表的是企業的文化，當我們需要團隊的工程師犧牲自己的精力為組織效命時，這是我們最起碼可以作到的，也就是讓業務部門確認了客戶真的有這個需求嗎？而身為產品負責人的PO也有機會向客戶陳述並有機會詢問所有待開發的需求確確實實都是有必要的嗎？最後再由與工程師站在同一陣線的Tech Lead把所有功能鉅細彌遺的攤開來讓使用者確認那些是他一定要使用到的功能。以及向客戶解說那些功能團隊能夠輕鬆完成或是必須花費一番功夫才能作到的地方，讓客戶也能意會到我們的苦勞及願意付出的誠意。

公司承接任何專案，絕對不僅僅是開發單位的事，其實向外包括業務人員，向內則包括專案規劃人員及負責開發的團隊成員大家都是必然的共同責任承擔者，都必需為成敗負責，所以任何人都有必要弄清楚這麼趕的專案真正的需求邊界是什麼，一定要作到的範圍，也才知道到底自己是在為何而戰，也才足以齊心協力一起來克服困難。

.

 

廣告

敏捷開發學習前移

用.

在影響地圖中運用行動學習的技能，讓敏捷開發產生學習前移的效果。也就是在需求仍在分析的階段時就有機會在ㄧ邊擬定工作需求下(運用影響地圖功能進行需求分析）一邊進行針對完成專案所需要的相關知識進行學習，或可稱之為在行動中進行學習，也就是 Action Learning.

.

看板的站立會議

.

運行看板方法在站立會議時，雖然看板上已經含概了Scrum 站立會議的所有資訊，也就是大家熟悉的Scrum 站立會議三件事:

1. 我昨天做了什麼?
2. 今天準備做什麼?
3. 遇到什麼障礙?

但是執行人員親自描述工作狀態的行為，往往可以透露出許多有意義的資訊，也能夠在無形之間增進團隊之間的默契。因此我仍然會要求團隊成員進行三件事的工作描述。(有時候你還能聽出需多弦外之音，例如: 隱藏的工作項、真正的做法…)

.

看板站立會議的順序圖示

.

看板的站立會議

站立會議的進行方式: 首先由「看板值日生」對團隊就現在的看板狀態進行陳述性的說明，這是很棒的一步，也就是至少會有一位人士去關注全貌，他用比較客觀的角度來負責提醒大家整個看板的運行狀態。透過別人朗讀我們的工作，可以觸發自已進行有效的反省，是提升學習效果的動作。在實施時；一開始就要取得團隊共識，然後堅持實施下去，是持續改善的好檢核點。

 

接著團隊進入輪流做三件事的報告流程。它反映了在這個過程中工作單的更新(上圖中的「更新欄」位，欄位線最下面的數字 (7) 則是做完的更新工作單數目。在下面的圖形則是顯示著即時更新的燃盡圖) 顯示出完成故事點的數目。

.

對燃盡圖的偏好

我喜歡在站立會議時即時更新完成的故事點數，並把它紀錄在燃盡圖旁，這一點是為了增加站立會議的檢核效果，也能反映出個人的努力成果與團隊能否達成衝刺目標的一種關聯，它能激發工程師想做得更好的慾望。所以我常常會把即時做加法的運算式繼續留在白板上一整天，或許有時會再增加一點點綴，做些簡單的區分來擴大運作效果。

.

 

接著是今天沒有更新到的工作單，可能是工時未到或是有延誤，當然不會做任何跟催的動作，只是用來提醒團隊，或許這個現象代表團隊成員有人需要協助了。

 

再來是「障礙」，有出現阻礙團隊達成Sprint目標的事件出現了嗎? 障礙欄線條下所顯示的是紅色到三角的警告標示，目的是提供團隊貼在需要額外關注的地方。也無形中向團隊展示了出現輻射現象(註1)的地方，希望團隊持續關注。(團隊應該善用看板的輻射訊息，它代表了團隊的現狀，也展現了我們團隊跟其他團隊的不同之處)。

 

接著是對「協助欄」的關注，協助欄有助於團隊產生良好的互動，是相當正向的事件，它有助於團隊的自組織，欄位線下面是發生互助的次數(團隊在不同時期，協助欄位還可以拿來做Pair Programming或 Unit test 的時數使用)。

 

然後是「其他欄」，它記錄的是團隊所遭遇到的其他事件。

 

團隊全部輪流說完後，若PO或來參加站立會議的非coding或Testing 成員有事要說的機會時間，讓他們有機會做表述，講完後，最後的總結陳述又會交回給值日生做跟剛剛團隊所做報告的總結陳述。當然不一定要對剛剛才發生過的事情做一一的陳述，這個動作更多的是對團隊成員做提醒與進行校正協調。

.

上面那張圖示並不真正存在，它只是用來展示看板站立會議的順序罷了。

.

 

註1. 輻射現象

所指的是這張看板上，讓路過的人第一眼會注意到的事物。又可稱為看板的輻射訊息。

.

 

 

程式開發要怎麼樣變快呢?

.

有人說 DevOps 是一場速度的競賽，這種狹隘的說法不是很正確，但某方面它確實反映了DevOps 在工程上的需求。

.

第一、就是交付速度夠快(那就是有好的 CD 能夠做到「持續交付」了)
> 要交付快，先決條件便是團隊產出程式的速度要夠快(那就是能夠做到 CI 「持續整合」了)

> 而團隊產出程式要怎樣才能快起來呢?
> 當然程式員要夠厲害才可能寫得快。

> 希望所有的程式員都很厲害是不務實的，因為團隊總是會持續有新人進來的，
> 而如果團隊成員所有的動作都能 Follow SOP標準作業程序來，用簡單的規範來讓一切取得協調，動作便自然能快起來了。
> SOP讓一切變快了! 但要如何變得更快呢?
> 那就是要打破 SOP 了，自然就會更快了。

所以到底要不要 SOP呢? 「限制理論」可以回答這個問題。

> 是的，正是"高德拉特" 先生所創的 TOC 限制理論可以回答這個問題。

.

.

也就是，

> 首先、找出現在系統上最大的瓶頸所在
> 然後思考如何來運用這個瓶頸
> 設法讓整個系統去配合來極大化這個瓶頸
> 接著便是全力來解決瓶頸了
> 確認真的搞定了，那就回到第一步，朝下一個瓶頸出發了..

這個和程式員做偵錯(debug)時的動作與思維方式完全相同，試試看吧!

.

敏捷從來就不是單一的方法

.

我的顧問生涯裡，最常發生的事，便是被要請去企業裡作導入Scrum的工作，也就是作Agile coach了。而我作導入的起手式則總是由單元測試或 TDD測試開發法開始推廣起,雖然它們都不屬於Scrum，然而因爲它們是工程師的基礎，是一種本質學能，是只要作工程師就需要不停的追求的技能。而我對單位主管的說詞則是勤練測試能帶來紀律，又能夠提升品質，百利而無一害，當然就要從這裡開始。但實質上是為了持續整合也就是continue integrated來預作鋪路。其實CI才是加快工程師產能的基本技能，可說成是當工程師能夠越精練於CI的技能時，開發速度便會越順暢。

.

.

Scrum裡頭完全沒有開發技術

Scrum需要技術的支援，極限編程eXtreme Programming 便成了最佳選擇了，這一點無須多作解釋，它讓測試前移的觀念融入了開發程序中，而要一直等到DevOps的出現大家才正視到，開發與運維不合一有多大的危險時，運維也前移了， 然而任何實施過敏捷轉型的團隊都知道，那產品規劃跟業務部門呢？應該也一起敏捷起來嗎？這便是能看見全貌的可貴之處。推廣DevOps的人士也很清楚這一點，因此Business-DevOps 才是正解。只是一個名詞要被時代與潮流所接受還是得花一些時間的，不如就在內函的詮釋裡把這些包含進來吧！所以DevOps在一開始便強調端到端的範圍，由商業端一直到客戶端的交付流程，就是在正視這個概念。

 

是不是該把用得到的技術都加一加陳列出來呢，所以就有了下面這張圖了。

.

為了擔心上課時遺漏了的技術就畫了這張敏捷的Process chart

.

.

.

.

.

.

.

.

.

 

.

.

 

2018 Scrum Process Chart

.

2018 Scrum Process Chart

.

新增 

1. PM 的相互依賴聲明.
2. OKR 目標關鍵結果 (約束=2).
3. AL 行動學習 (約束=1).

註

敏捷各個方法或框架的約束與自適應圖示

 

敏捷走向精益的思维过程

.

.

當你在運行 Scrum 的時候，眼睛裡只會看到專案，
當你往前一步開始思考DevOps時，則眼前又多出現了產品的生命週期，
這時候你才體會到，你是在做產品全面性的規劃，其實是進入「系統思維」的領域了，
然後在看見全貌之後，往前、往後看自己在哪裡，接著你會開始思考該從哪裡下手?
想到「三步工作法」；想到「限制理論」裡所說的:

※ TOC 的思考程序裡的五大核心步驟：

• 　第一步，找出系統中存在哪些約束。
• 　第二步，尋找突破這些約束的辦法。
• 　第三步，使企業的所有其他活動服從於第二步中提出的各種措施。
• 　第四步，具體實施第二步中提出的措施，使第一步中找出的約束環節不再是企業的約束。
• 　第五步，回到步驟1，別讓惰性成為約束，持續不斷地改善

然後；就從眼前最大的 限制 開始著手吧!

.

 

.