這是我如何執行敏捷開發的經驗，整理出來供大家参考。
至於為什麼要 Run2 回呢？因為Scrum沒有它表面上看起來的簡單。
.
【 實 施 過 程 】
.
給自己一個月的時間，設定二個星期為一個衝刺Sprint，也就是說任何Scrum 的演示你都有二次演練的機會。為什麼要二次呢? 因為第二次一定會做得更好。
.
.
持續改善
第二次一定會比第一次做得更好，這叫做「持續改善」。它是敏捷開發的終極目標，原由是因為變化來的太快。所以最好的因應方法便是針對眼前的問題來思考如何解題，然後放棄那種想法，也就是「事情會一層不變的想法」，盡量減少預設立場的思維，也就是要客觀，先做一遍然後看著結果依靠得到的數據再來持續改善它。
.
敏捷不只是一種開發方法，更是一種觀念。
要做好敏捷開發就應該先從建立團隊的觀念開始。
.
實施顧問模式的四個步驟:
.
實施顧問模式的四個步驟，運用精實觀念來充實敏捷開發的實施過程。
.
{ 這四個步驟其實是針對敏捷顧問們一直以來常面對的問題，所提出來的對策。
以下是來自一位敏捷顧問的感概:
- 一開始，發現都是一些技術知識的問題，
- 然後，馬上進入到系统架構方面的問題，
- 當再解决架構問題的时候，我發現，已經是軟體工程的問題，
- 而軟體工程問題的後面，又是公司管理上的問題，
- 而公司管理的問題，结果又到了人的問題上，
- 而人的問題，又到了公司文化的問題……
哈哈！用說的總是比較容易XD。
}
.
由「增強學習」開始
Hatching 孵化，我喜歡用孵化來比喻顧問開發團隊學習敏捷開發的過程。一開始總是由增加知識及專業技能開始，讓工程師們盡量地看見學習的路徑(光有目標還不夠，要看到如何學習才是重點)，讓他們自己去選擇學習的途徑，由充實專業技能的慾望帶領著他們去成長，我發現這是最好的開始，人們在學習、吸取新知識的過程裡，總是擁有最佳的穩定性(沒人喊著要離職或加薪)。這是我習慣的開始方式，也就是步驟一、「增強學習」Amplify learning它是精實開發的原則 (註1. 精實開發原則)。
品質與紀律
關注品質是為了改善程式的質量，而程式在質量上的提升意味著缺陷bug的減少，缺陷減少了自然就省下不少修復缺陷時所需要的時間，工程師少了返工修復缺陷時所花的時間，自然也就作到了消除浪費的目的。因為花太多時間在修復缺陷是軟體開發上最大的浪費。我這麼做的目的是用消除浪費來替工程師們賺取更多可以運用的時間，我們稱之為「盈餘時間」。有了時間之後工程師才可能放開心胸去接受新的知識、新的技能然後做到持續成長。同時，提升軟體品質真是好處多多，好的品質能帶來團隊的相互信任與合作，會讓人帶著愉快的心情去上班。無形間建立了團隊的紀律，當然同時也會換來外界的好名聲，真是最值得的投資。而且好的品質能夠換來紀律，它們是一體的二面。
衍生設計
敏捷最有趣的地方就是不能一口氣設計太多東西，你必須懂得「適可而止」這句話，做到恰恰好的設計，尤其是在架構設計上。在前幾個步驟裡，我們努力的讓團隊增強專業能力，但很快地你就會發現真正約束團隊開發能力的是架構層面上的問題，我們必須運用軟體工程上許多的模式 Pattern來解題。這要感謝一些軟體前輩在物件開發或設計模式上的貢獻，我們今天才有這項工具來時實施所謂的「衍生式設計」 Emergent design (註 2. 參考《浮現式設計》一書，作者: Scott L. Bain)。
敏捷價值觀
很多人都以為開發團隊是否優秀是決定實施敏捷開發是否成功的最大因素。確實，擁有一個極為優秀開發團隊是獲取成功的重要的環節。但我做顧問這麼多年以來，我一直以為，工程師最重要的不一定是優秀，尤其是你的團隊實在很難都是由極端優秀的工程師所組成。反之，只要有幾個優秀的工程師在團隊中便能讓團隊變得更優秀。原因就在工程師是否擁有正確的價值觀。(註 3. Scrum 價值觀)
.
敏捷顧問模式採用 Alignment Diagram繪製
談完實施顧問模式的四個步驟之後，該來說明最上面的那張圖示了。它是依據 Alignment Diagram 的觀念製作成的。中間是價值的部分，他是上下兩層的銜接部分，Alignment 的意義就是指在上下二層的對等價值所在。
.
Alignment Diagram 排列圖(註4 Mapping Experiences)
.
適合表達經驗的 Alignment Diagram
區分成三部分，上半部: 流程與角色，下半部: 是執行的時間表，中間則是價值的部分我用「時期」來作區分，每個時期都有它的目標及所希望達到的成果，也就是價值。說明如下:
【 時 期 】
敏捷化的基礎就由「前置時期」開始，它發生在二個 Sprint 循環之前的時間，是一段建立觀念的時期。在這段時間裡我會努力地進行同步的動作。同步什麼呢? 例如: 團隊對Scrum、Kanban的觀念做法上的同步，及與主管、Scrum Master之間默契的建立。並藉由好的教科書及實際案例等(正確運用)工具讓大家可以在觀念上有一致的看法。
- DOR: Definition Of Ready 需求是否備妥的定義。
- DOD: Definition Of Done 完成的定義.
.
【流程與角色】
教會PO與團隊運用「使用者故事地圖」的產出物來討論每一個Sprint的目標是一個巨大的挑戰，也是隨後團隊開發速度的關鍵，因此一開始就把重點放在這裡。由於它的影響也十分深遠，它是整個開發時期的是否順利的重要因素。而隨之而來的 DOR 與 DOD時期也都是朝向需求的優化而來。目的就是為了正確的開發方向及飛快的開發速度而努力。
團隊開發的流程與角色
.
【時間表】
這是維期一個月的敏捷顧問模式時間表。後面的二個衝刺sprint循環是標準的Scrum式的迭代開發模式。比較特殊的是運用看板方法來調整開發流程的速度及加入必要的重點項目(就是以加入欄位來強制改變開發流程的方式。例如: 第一個 Sprint 將強調單元測試，第二個 Sprint則強調自動化及維護文件)。
實施顧問模式的時間表
.
結語: 目的是降低改革所造成的團隊恐慌
為了減少恐慌，讓顧問的團隊能夠清楚整個的顧問過程，讓大家能因為了解整個的實施過程，就是這樣了無需大驚小怪。用「看得見」來磨滅疑慮跟猜測，盡量讓團隊不要因為即將來臨的改革而感覺得恐慌產生莫名的抗拒。要知道所謂的顧問! 其實就是老闆請來幫你的那個人罷了，是來幫你忙的，有問題就盡量找他不用擔心什麼。上面這張圖是我習慣運行的顧問模式，採用一個月二次迭代的方式，目的是讓團隊能夠有一次反覆練習的機會，所以會設計成二次的輪迴完全是擔心自己顧問的時間一到便必須離開，而學員會因為不夠熟悉而有半途而廢的事情發生(第二次機會，就是要讓他們多做一次時能體會出持續改善的意義)。這個模式實際執行起來，最有趣的是很少有團隊可以在一個月內做完所有動作的 (當然是因為我害怕遺漏而放太多進來了，這些個功能要求理當視團隊的現狀來作取捨），而實際上最長的實施紀錄是一整年。
.
採用一個月的顧問模式還有一個優點，就是它好報價。
.
附註.
註1. 精實開發原則
七大原則: 消除浪費 Eliminate waste、增強學習 Amplify learning、盡量延遲決策 Decide as late as possible、盡快交付 Deliver as fast as possible、授權團隊 Empower the team、崁入完整性 Build integrity、著眼整體See the whole。
參考: 《精實開發與看板方法》第一章精實軟體開發。
註 2. 《浮現式設計》作者: Scott L. Bain。
作者把當今最重要的開發原則彙集成了一個統一的、流線化的、實用的軟體發展方法，他汲取了模式、重構和測試驅動開發的精華，闡述了如何在整個軟體生命週期中高效地開發、管理變更以及持續交付健壯、可靠且經濟高效的系統。
註 3. Scrum 價值觀
專注 Focus、勇氣 Courage、公開 Openness、承諾 Commitment、尊重 Respect。
我習慣由 “專注" 開始，因此幾乎每個專案的第一個 Sprint，都設定為 “專注週" 做開始。團隊在進行站立會議時，大家必須說出今天自己將投入到這個專案的百分比。
註4. Mapping Experiences， 作者: Jim Kalback 的名著
很棒的圖示法，原意是用在UX的設計表達上頭，用來作為個人與組織互動的影響說明。但運用在經驗模式的說明上也很適用。，
Ruddy Lee 分享空間 
讚！