如何製作需求的場景圖 Scenario diagram

.

使用者故事不是文件，它是用來溝通及確認用的需求說明。真正的文件必須視描述時的需要程度而適當的加上畫面、場景或是較複雜的流程說明來加以補充。而其中場景可能是跟使用者故事最為速配的一種情境的描述方式（當然前題是要能夠支援持續改善的更新形式，也就是活文件）。

.

示意圖，由Google 所提供的一種只有方塊、文字、箭頭及線條的圖示工具。

.

帶有問題陳列的示意圖(上半部是問題，下半部是示意圖)。

.

上圖為一種帶有問題陳述的示意圖，它更容易引發團隊的討論（因為問題就列在上面）。它十分適合拿來協助使用者故事成為場景討論的文件。Google 把它拿來運用在5天衝刺計畫Sprint的第一天，用來描述衝刺計畫的目標結構。由於它的簡單好用，幾乎不需要任何的專業素養也能快速的融入問題的討論，因此我把它拿來用作場景的描述，真是事半而功倍。尤其在配合上HMW的隨處黏貼與即興討論，可以讓整個開發團隊迅速的融入場景的設計中，同時能補足先前規劃時的遺漏，非常適合團隊ㄧ起討論用。

.

 

敏捷缺乏制式的文件規範

敏捷開發團隊缺乏標準文件的規範(由於沒有規範或許會更好，所以始終沒有一種標準誕生)，因此許多敏捷團隊就凌亂的各自使用自己的標準來進行文件描述。這一點讓剛入門或剛剛轉換跑道(由傳統開發方式轉換到使用敏捷開發)的工程師們比較難以遵循，往往必須經過多年的經驗累積後才能有所頓悟。因此，這裡我打算提供幾種繪製場景Scenario的方法，供大家視需要作選擇。首先來談談《Google創投認證！SPRINT衝刺計畫》這本書裏頭所介紹的「示意圖」方法(Map，原文只用 map圖示來做說明，並未採用Schematic diagram或是 Scenario diagram 的專門詞彙，至於翻譯成「示意圖」則是中文翻譯本的佳作?!)。

 

示意圖

我把它拿來作為場景描述的場景圖scenario diagram，原因是因爲它簡單好用。如果只是用來描述應用程式的操作或是邏輯情境，採用一般的工程用流程圖示應該就能夠勝任了。但如果考慮到可以讓一般非工程人員也能輕易地看懂我們在說什麼的話，還是以採用看起來更簡潔，而且完全不用學習就看得懂的圖形來作說明會更好些(以簡單為上策)。這一點從電影星際效應(原片名：Interstellar)裡的星際穿越作例子說明就可以看出來(如果想要深入探討星際穿越的話，你得先了解黑洞學說、宇宙的次元說等艱深的理論，而前提是；你要先懂得相對論才行XD)。因此物理學裡在討論越是複雜的理論時越會採用較簡潔的方式去做表達（請参考下面的圖示），才不容易產生誤解，或是讓人聽了一頭霧水完全無法理解(然後就只能點頭示意了，千萬不要這麼作溝通)。

.

電影星際效應的星際穿越理論圖示

.

示意圖的目的是讓大家都能一目了然，一看就知道要解決什麼樣的問題以及團隊該怎麼作才能完成任務。這一點跟物理原理的說明一樣，總是採用最少最簡潔的話語(例如海森堡的測不準原理: 海森堡主張，只有在可以設定的實驗環境下對於粒子的位置做測量，則位置才具有物理意義，否則位置不具有任何物理意義)，所以在邏輯的細節越複雜時，我們越應該以簡單的方式來進行溝通，而越簡單它就會越顯得出它的效果來(可以減少誤解)。

.

在示意圖前面，進行團隊協作

當運用示意圖時，是給予團隊協作的機會。我們可以讓團隊在示意圖前做即時性的共同討論，然後在需要它的地方一起補上如何作(HMW: How Might We )的卡片，這是非常有價值的一種互動方式，能讓大家都進入狀況，比交給情境設計師一個人把它畫完後再做討論的效果要好得多了，或是事後再做任務分配要有效得多。

.

繪製「示意圖」的步驟:

1. 列出重要的角色(最左側)。

2. 寫下最後結果(最右側)。

3. 中間就是文字和箭頭 (必要時加上一些判斷符號)。

4.  以簡單為上策。

5. 尋求團隊協作 – 持續詢問團隊成員「這個圖看起來正確嗎?」還要補上些什麼?

.

一個網站Sign In的示意圖，只有方塊、文字、箭頭及線條的圖示(註1)

.

小結

敏捷文件；讓我們在實施敏捷開發後仍能擁有足夠作為維護，或後續開發的規格文件。其中使用者故事幾乎是所有的ALM工具都拿來作為依據的基本需求描述資料，但它不是規格文件，它是拿來觸發需求討論的小卡片而已。所以談到務實的維護作業時，我們最想弄清楚的是程式會怎麼去應對使用者的操作方式呢？這便是場景所負責描述的情境了，請務必留下當初在進行開發時的情境分析資料，它可以讓後續開發或維護的作業順暢許多。

 

.

註:

1. Google創投認證！SPRINT衝刺計畫 (試讀本在此)

為Google內部實用工作手冊，作者： 傑克．納普, 約翰．澤拉斯基, 布雷登．柯維茲 共同著作。示意圖在第二章、星期一 Monday 畫出問題時所採用的方法。

2. 附上書裡頭所談到的場景圖部分及重要問題的部分(取材自網路)

3. GML(銀河建模語言Galactic Modeling Language) by Kent Beck，正是在描述這種極其簡單的描述方式。

.

》場景圖對需求的明確化有著極大的幫助，上面介紹的Google Sprint的示意圖方式，有著容易繪製易於討論的優點，但製作場景Scenario還可以採用傳統的電影劇本「情境圖」的方式，那就會讓場景圖示再加上了「啟、承、轉、合」的能力，我們下回再談。

.

敏捷專案開發精神

.

《這是一場在竹科的演講，PPTX檔在這裡》

（底圖是會場的照片）

.

》問題(先回答主管的疑問)

維持足夠的抽象度，假設就是假設

.

有關假設的謬誤

我們經常犯的錯誤就是把「假設」當真，明明就知道這只是個猜測，它或許會這樣、也可能那樣，但是我們老是把自己希望的樣子當作第一優先，忘了那只是在事情剛開始時所作的猜測，所以失敗就來得ㄧ點不突然了！例如專案一開始時所作的估算，誰都知道那是工程師的猜測，但就是要信以為真，認為時間到的時候程式自然會完成，忘了假設是需要持續的觀察與修正才可能接近事實的嗎！

.

敏捷經常就是務實，少作假設多實事求是。

.

》敏捷開發的10大指導原則

(From Gartner公司，Nathan Wilson, 2015-7-24)

.

》敏捷為何比傳統方法快

.

》Scrum 之前、後的階段

不可忽視的需求與發佈階段

.

》多變的 Scrum Process Chart

教學專用的 Scrum Process Chart

.

》看板六條規則

看板方法: 前三條是步驟，後三條則是策略

.

》案例一、如何處理團隊開發品質不佳的問題?

如何運用看板方法來解題

.

》案例二、如何加快團隊開發速度?

 

 

4

.

》案例三、需求模糊怎麼辦?

善用工具來協助你分析、看見需求的全貌

 

.

參考:

1. Google 創投認證! Sprint 衝刺計畫 :  我曾經做過許多次的衝刺計畫，效果很不錯，但後遺症也很大，我發現開發團隊中沒有被選上來參加衝刺計畫的成員，很容易出現漸行漸遠的現象，團隊會有明顯的分離的跡象，應該小心處理。也就是說作「衝刺計劃」前務必先考慮到團隊士氣，避免得不償失。
2.  Predicting the Unpredictable 是 Johanna Rotheman女士的小品。
3. 敏捷10大指導原則。
4. 演講會場留念：

.

 

 

建製看板時的需求描述

.

建製看板跟設計軟體一樣，首先；把需求弄清楚。

.

 》考慮物理因素:

環境如何?要放在哪裡?白板的大小?工作項目卡片的大小?如何製作?

 》考慮建製的目的：

這張看板要展示給那些人看？應該要包含那些內容、如何表達？他們看了以後能得到什麼？或，我們希望他們得到什麼？

.

透過建製一個 Q&A的看板，來介紹一個「故事outline」的作法給大家参考：

以下是Q&A看板的使用者故事:

》我特別重視第一個使用者故事，因為它往往是構想的前提，也是最大的假設（如果它不能成立的話，整個想法可能就要推翻了）。

※ 身為講師，我希望把學員所提出來的問題能用看板的方式來回答，以便讓學員們能更熟悉看板的運作方式。

.

首先；進行需求的收集。

※ 身為講師，我希望學員們對自己所提出來的問題能夠作進一步的說明，以便讓大家都能知道老師的回答是針對哪個問題。

※ 身為講師，我希望對類似的問題能夠做進一步的整理，以便能夠一起回答。

※ 身為講師，我希望回答問題時能夠把握時間，以便能夠多回答一些問題。

※ 身為講師，我希望提問題的學員都能得到滿意的答覆，以便能解除他們心中的疑惑。

※ 身為講師，我希望在會後還能有機會再看一下剛剛回答了哪問題，以便在未來能回答的更好。

 …

上面這些需求；都是用使用者故事來描述的，但是你會不會經常覺得有了使用者故事後好像還是少了點什麼? 也就是仍然覺得抽象了一點，更有一些凌亂不能容易一眼望穿它的感覺，這個時候我的解決方式是，幫使用者故事找家，也就是做歸納，做法是:

.

試著用更簡潔的一句話來描述這個使用者故事，也就是故事outline。

.

{這個做法是參考了費曼的快速理解方法及設計思考Design thinking (註 1)而來}

.

Q&A看板牆的故事 Outline

.

運用OUTLINE

故事的Outline(輪廓；就是用一句簡潔的話來代表後面的故事)，由於撰寫使用者故事的時候常常會發生重疊的現象，又因為故事越寫越多，於是亂的現象就不請自來了，嘗試過許多方法來篩選剔除，最後，因為輪廓Outline可以包含許多類似的故事，可以讓我們看得更清楚，因此就開始喜歡上幫故事加外框了。這是運用Empathy(同理心)做持續綜合所得的結果。上面的圖示中，前面有顏色的區塊就是後面使用者故事的outline。當你在寫outline這一句話的時候，無形中已經在思考怎麼樣更簡潔的去表達後面的故事了(費曼快速理解的第一步)，如果你覺得這句話始終是詞不達意的話，就是告訴你是時候了，你應該再去斟酌一下這些使用者故事了。最後總結出以下的規則。(Outline是我習慣這麼稱呼它的，或許還有更好的叫法)

.

Q&A看板

.

》產出的規則說明:

欄位一、「問題」欄位WIP=10,

《規則》，預計回答一個問題需要2分鐘，希望能夠回答盡量多的問題。

欄位二、「分析」欄位WIP=3,

《規則》，允許同時回答類似問題的數目設為3,大於3的時候會害怕太凌亂無序。

欄位三、「回答」欄位WIP=1，

《規則》，為了控制整個Q&A的時間，所以希望教師在回答問題時內有時間的限制。

欄位四、「確認」欄位WIP=3,

《規則》，確認欄位必須與分析欄位相對襯，綜合了三個問題一起回答，當然確認的問題數也要設為三了。

欄位五、「完成」

《規則》，供講師回顧使用。

.

小結

剛開始使用Outline的時候，很驚訝的發現這些區塊竟然就是看板的欄位說明，這一點很有趣。後來發現因為你不斷的在作綜合的動作，自然會歸納出流程的各個步驟，這是很正常的。而好處是使用者故事竟然就越變越能意會到了。Outline的作法有別於使用者故事地圖，他只是針對使用者故事本身在加工罷了，但你一旦開始使用之後就會發現它的魔力了。

故事Outline其實還有一個很重要的目的，就是增強學習。閱讀與撰寫使用者故事其實都是一種學習的過程，我們學得越好對需求了解的越深入，自然對開發而言就會越快。

.

 

註1.

》設計思考Design Thinking的流程

設計思考的簡單流程可分於下述數個單元所組成。

◾Empathy(同理心): 同理心的意思，在中文之中近似於體驗、體諒、體察三者的綜合體。即以使用者為中心的設計，透過多元的方式了解使用者（包含訪問、田野調查、體驗、問卷…等等），協助設計思考家能以使用者的角度出發，找尋使用者真正的問題、需求。

◾Define(需求定義):需求定義是將「同理心」步驟中蒐集到的眾多資訊，經過「架構」、「刪去」、「挖深」、「組合」後（可交互使用），對問題重新的作更深入的定義，就像探索水平面下的冰山，更進一步找出使用者真正的需求，並用簡短的一句話定義使用者的需求。

◾Ideate(創意動腦):創意動腦的過程中，是要發顯出眾多的解決方案來解決「需求定義」的步驟中所找出的問題。發想的過程透過三不五要的原則，激發出腦內無限的創意點子，並透過不同的投票標準找出真正適合的解決方案。三不五要：不要打斷、不要批評、不要離題。要延續他人想法、要畫圖、要瘋狂、數量要多、要下標題。

◾Prototype(製作原型):在設計流程之中，採用製作一個原型（Prototype）之意，透過一個具體的呈現方法，可以作為團隊內部或是與使用者溝通的工具，並可透過做的過程讓思考更加明確，是一個動手思考的過程。此外，可以由簡略的草圖呈現，進一步不斷修整進而達到更完美的效果。在本階段的產出結果，會作為測試之用。

◾Test(實際測試):實際測試是利用前一個階段製作出的原型與使用者進行溝通，透過情境模擬，使使用者可以測試是否適用，並從中觀察使用者的使用狀況、回應等，透過使用者的反應，重新定義需求或是改進我們的解決辦法，並更加深入的了解我們的使用者。

 

》費曼的快速學習 Feynman technique

.

 

{Q&A 看板一直是我最喜歡採用的課後問答方式，不知是來自哪位前輩的創意，由衷的感謝他!}

.

如何讓專案透明化?

Scrum 理論的三個支柱，它們分別是：透明化，檢驗，與調適性。

透明化:

工作流程內的重大要件對於那些對產出負責的人必須是顯而易見的。透明化要求這些方面被一套共同標準所定義，所以觀測者能夠對所看見的事物有一個共同的認知。

 – Scrum 指南

.

最好的方法 – 運用看板方法讓開發工作被看得見。

最好的時機 – 在站立會議時作更新，讓開發團隊能更忠於自己的工作。

.

敏捷開發最大的成本 – 溝通

這幾年很流行的一種辦公室裝潢，就是打掉辦公室裡所有的隔間，只擺上幾張大大的，像極了蘋果專賣店的黃色木紋Apple展示桌，然後四周牆壁都是白板或是可以塗寫的玻璃，至於那些無法移除的柱子，也是貼上了白板或玻璃，讓整個辦公室完全沒有隔間空空蕩蕩的，在這樣的辦公室裡只要抬頭就能看到所有的人，目的正是為了透明化，為它所能帶來「溝通」上的便利。很多公司都依樣畫葫蘆的這麼作了，但是很少有管理人員懂得去教導員工要如何去運用它，去善用這些設備來進行溝通進而提升效能（白板/玻璃(要選擇可以吸磁鐵的那種）都能在上面畫看板、能夠黏貼工作單、能寫下Memo、能用吸鐵，又能輕易擦拭乾淨，重新再來過）。其實它的一個重要目的，便是給予團隊一種良好的討論空間，讓團隊養成隨時隨地進行溝通討論的習慣，並久而久之自然形成為團隊的一種文化，一種沒有溝通障礙的文化。

.

Apple Store的標準外觀

.

如果你也有這麼一個辦公室，記得善用每一個角落、每一塊白板、每一個可以黏貼注意事項的地方，善用它；並「制定簡單的辦公室運用守則」，讓所有的員工都知道怎麼正確地去運用它。讓辦公室的種種器材成為溝通上的最好工具。它能讓團隊開發的效能達到無形的提升作用，也能間接的讓專案更透明。

.

{敏捷辦公室的運用

• 最顯明的區塊適合放置看板牆、會持續改正的最新架構圖及最新的會議結論(能貼一些會議結論所拍下來的討論照片更好!)，要設法讓它成為「戰情室」而不是公布欄。

• 轉角適合放置使用者故事地圖(待辦工作事項product backlogs)、績效表現或回顧時決議的待改善事項。

• 團隊成員之間的樑柱則宜標上團隊名稱(代表某某團隊的工作區，這麼做可以增加團隊的歸屬感)，適合二、三人的小組進行討論用，或貼上最近正在忙著做的工作事項或是下回準備展示的 Demo會議目標都會很具有宣示性，可以讓大家都清楚的知道這一塊區域都在做些什麼(可以增加團隊的責任心)。

• 然後各個地方都要隨時可以拿到白板筆、板擦、3M黏貼紙、尺、多種顏色的磁鐵… 等等必須的器材。}

.

{制定辦公室的簡單規範:

範例: 當運用樑柱型的白板進行討論時，人數大於三人以上就必須進入會議室才能繼續討論，以維護辦公室的安靜。（它也是團隊自我管理的簡單規範之一）}

.

如何讓專案更透明呢?

找個最明顯的地方當做看板牆，在上面建立一張(或多張)的看板，上面記載著專案的進度，明白的顯示出每個工程師此時此刻正在開發的工作或是維護的工作，這些工作的狀態，是否有緊急事件或是特殊狀況出現…等等，然後每天在這裡召開站立會議。目的是讓大家都能看見，看見風險及看見之後觸發它隨時都可以進行溝通討論的地方。更重要的是能顯示出來，能顯示因為看見之後所採取的改善措施及改善之後的結果。

.

面對面站在白板前面是最佳的溝通方式。

.

最好的溝通管道?

如上圖所示，最好的溝通管道是二個人能夠「面對面運用白板來作溝通」的溝通方式（最糟的是文件，再來是email，然後是即時性的軟體，如 line或 slack)。而不是遠端透過電子裝置來顯示的方式。因為對話一定要凝視對方的眼睛，才能看出真偽，也好提供參考及判斷。在白板前面容易激發較深入的討論，尤其是可以將結論用手機拍下來作成紀錄，便於事後回憶檢討，相當有價值。

 

辦公室太吵怎麼辦?

空曠的辦公室最怕吵雜。記得破窗理論嗎? 當環境中有不良現象出現時，如果被放任存在，就會誘使人們仿傚，甚至變本加厲。所以當辦公室太吵時怎麼辦? 應當做的是嚴格要求團隊自治（製訂簡單的規範），對同一個區間的吵雜現象必須立刻制止，並要求他們到會議裡進行討論。然後在辦公室的角落裡設定站立的coding區，專門給需要安靜的人士一些空間。

.

辦公室的吵雜度正好可以作為團隊自我管理的指標之一。

.

維護作業，適合用「人」作橫向欄位來建構看板，可以增加責任感。

.

看板如何提供透明化 – 讓主管寫使用者故事

透明化的目的，就是要讓我們看得更清晰。但我們都知道，資訊的多寡絕對不等於透明化的高低，要展示出一些對觀看的人有意義的資訊才對。這個意思是要適度的隱藏不重要的資訊，反而可以讓透明度增加。也就是說能夠維持足夠的抽象化，對透明化才有真正的幫助。這也正是我們設計看板時，要決定應該放多少屬性上去的依據。顯示多了不一定好，而且還要浪費不少時間在做勞作。顯示少了，就很容易被挑毛病，接著還要花時間做解釋。而真實世界的看板運作就是在它應該提供資訊的多寡之間持續做調整，主要的依據是它想說明些什麼? 我習慣讓有此需要的人士（就是主管了）採用講故事的方式告訴我它想要什麼? (哈哈!這招好用極了，可以讓主管們也學習運用使用者故事來描述他們的需求。請注意：很少看板會像下面的範例只服務一個人的。所以一般在製作看板時，要由團隊一起來撰寫使用者故事。這是一舉數得的動作，Scrum Master務必要貫徹執行它）。

《 範例 》

身為一位一級主管，我想要看到各科組目前專案的進度，以便於可以調整部內的資源。

解譯:

• 這個看板的主要使用者是一級主管，所以這個看板可能就放在他的辦公室裡。

• 他最想要知道的事是專案的進度。

• 目的是想要調整部內的資源去協助他們。

.

小結

看板不只是用來靜態的做顯示用，它也可以拿來動態的調整團隊的開發流程。我們可以視團隊目前最迫切的需要來進行調整。例如，明確性高的維護作業，可以以人為單位，採用職責分明的方式來設計看板牆(如上圖)。至於創意性較高的開發工作，則可以適當的增加一些抽象度，例如:讓看板的重點轉向功能層面的顯示，也就是已經完成哪些功能，正在進行、測試哪些功能及有哪些功能即將進入開發階段。規則是適度的指向開發完成那些功能為重點，並設法凸顯它，而不是密密麻麻的補滿整個看板，讓細節都展示在看板牆上，反而看不出重點來了。

 

看板擁有一項最大的任務便是顯示流程進度。善用看板的欄位加入或刪除則可以改變團隊的工作流程（最常見的是為了提升品質，而加入code review的欄位），或是改善開發的速度(調整半成品數)。但最重要的是它可讓專案透明化，讓風險提前被看到，讓原本一直被忽略的屬性凸顯出來(例如多工所造成的忙碌、效率或是隱藏的缺陷技術債)。然後再試著改改流程、增減限制看看改變之後的結果，嘗試著去改善它。

.

提供持續改善的依據，才是透明化真正的價值所在。

.

為什麼我沒有採用電子化的工具呢？原因是團隊的運作能採用實體的看板牆是再好不過的選擇了，這跟開會時與會人員是否在現場有著類似的效果。

.

了解你的開發團隊

.

「估算是在浪費時間！別再做了！」

「採用故事點或理想工作日來做估算才是王道，不要再用小時了！」

 

.

要了解你的開發團隊，從他們的表現去了解他們，無疑是最好的一種方式，但要避免以偏概全，所以要從頭開始，從專案的估算開始。

.

敏捷開發的團隊應不應該做估算呢?

基本上，我認為只要需要做計劃時就應該要估算。計劃，是一種考慮未來該怎麼做事的行為準則，而估算則是它的依據。尤其是團隊的行為，一個人的時候，我們可以不用經過精確的計畫就搭上火車到處去旅行，因為鐵道是固定的，哪一站下哪一站上我們始終不難掌握它。但如果給你帶領一個團隊的時候，則計畫就免不了了，我們開始要考慮何時該吃飯或放他們自由行動。因此；我們真的需要估算嗎？答案當然是肯定的。因為估算是計劃的基本條件，而你不可能在沒用做任何估算之前就開始做計劃的。只是估算到底該做到多準確呢?

一個準則是；如果進一步的估算能讓計劃變得更合理，能讓我們更容易做出決策，能讓團隊對交付日期更有信心，或者能夠讓我們看清楚需求的優先順序的話，那麼就應該做進一步的估算及計劃。(如果沒法弄清楚呢? 就試一次看看，因為敏捷式的迭代開發，機會很多的，不嘗試看看又怎麼會知道 — 這種做法是敏捷的價值觀:勇氣，可以培養出勇於創新跟承擔失敗的開發團隊)。

.

讓適當的人，在適當的情境下，完成適當的事。便是；合理的計畫(估算)。

前提是，了解你的開發團隊。

 

.

故事點是針對工作量，而不是複雜度

太多人都誤解了。Mike Cohn認為，使用故事點來描述特性的開發複雜度是不對的，應該使用工作量。他發現太多的團隊認為，故事點應該基於用戶故事或特性的複雜度，而不是開發所需的工作量。這些團隊通常將"故事點"定義為"複雜度點"，這看起來不錯，可能還更精確，但卻是錯誤的。故事點與特性的複雜度無關，而與開發特性所花費的工作量有關。例如：你可以花三個小時抄寫10份三字經，而同樣的時間外科醫師正好可以作完縫合的手術，他們的複雜程度絕然不同，但卻有著同樣的工作時間。

當你需要維持抽象度的時候，請採用故事點/理想工作日，但一旦將使用者故事Breakdown成任務 tasks以後，抽象度就應該逐漸消失了，工程師開始運用各自的技能去完成任務，這個時候的估算能夠縮減到一日以內，是再好不過的事情了，此時用小時做估算都不為過(最大的好處是可以配合番茄工做法，更高效的進行開發的工作)。

.

前提是了解你的團隊

作家長的都愛護自己的孩子，也都知道愛護不是放縱。因此培養她(他)擁有正確的觀念，讓他(她)懂得自治才是王道。一樣的道理，也可以用在團隊管理上。讓團隊懂得自我管理，可以讓團隊擁有最好的效能。所以前提是培養團隊擁有正確的觀念，作法呢?就是給她約束。制定一些基本的規範給她去遵循，但只要她表現得優秀(符合或超越預期)，就逐漸把約束放掉。一旦可以預知她對事情的看法了，便是開始了解她的行為模式了，當然就可以放心地讓她自己做決策了。

.

從估算的過程中可以看出一個團隊的成熟度及他們個別的價值觀。

.

 

你可能更想知道有關估算:

引用 Magne Jorgensen 的一篇短文《關於工作量估算，你知道的和你不知道的一切》，歸納一下重點:

1. 不存在“最佳”的工作量估算模型或方法。

2. 客戶著眼於降低價格，是工作量氾濫的主要原因。

3. 最大工作量和最小工作量區間過於接近。

4. 工作量估算易於走偏，一旦走偏，難以恢復。

5. 相關歷史資料和檢查清單可以改善估算準確度。

6. 結合多個獨立估算可以提升估算準確度。

7. 估算有其害處。

估算不僅預測未來，而且會頻繁影響未來。過低的估算會導致過低的品質，以後可能要返工；過高的估算可能降低工作效率，遵從“帕金森定律”——工作會自動占滿所有可用的時間。

 

『因此，必須考慮是否的確需要工作量估算。如果可有可無，或是以後才有必要，可能不做更好，或是延遲估算，直到可以得到更多的資訊。敏捷軟體發展——只估算下一個 sprint 或者發佈版本的工作量，而且必須使用此前 sprint 或者版本發佈的回饋資訊——可能是避免過早估算帶來的潛在危害的良好方法。』

.

註: 如何正確的估算，請參考: Joey Chen的一系列文章。

.

如何實施敏捷開發?

這是我如何執行敏捷開發的經驗，整理出來供大家参考。

至於為什麼要Run2回呢？因為Scrum沒有它表面上看起來的簡單。

.

【 實 施 過 程 】

.

給自己一個月的時間，設定二個星期為一個衝刺Sprint，也就是說任何Scrum的演示你都有二次演練的機會。為什麼要二次呢?因為第二次一定會做得更好。

.

.

持續改善

第二次一定會比第一次做得更好，這叫做「持續改善」。它是敏捷開發的終極目標，原由是因為變化來的太快。所以最好的因應方法便是針對眼前的問題來思考如何解題，然後放棄那種想法，也就是「事情會一層不變的想法」，盡量減少預設立場的思維，也就是要客觀，先做一遍然後看著結果依靠得到的數據再來持續改善它。

.

敏捷不只是一種開發方法，更是一種觀念。

要做好敏捷開發就應該先從建立團隊的觀念開始。

 

.

實施顧問模式的四個步驟:

.

實施顧問模式的四個步驟，運用精實觀念來充實敏捷開發的實施過程。

.

{ 這四個步驟其實是針對敏捷顧問們一直以來常面對的問題，所提出來的對策。

以下是來自一位敏捷顧問的感概:

• 一開始，發現都是一些技術知識的問題，
• 然後，馬上進入到系统架構方面的問題，
• 當再解决架構問題的时候，我發現，已經是軟體工程的問題，
• 而軟體工程問題的後面，又是公司管理上的問題，
• 而公司管理的問題，结果又到了人的問題上，
• 而人的問題，又到了公司文化的問題……

解決之道：

用(1) 增強學習來補足工程師或團隊專業能力的不足。將求知慾帶入團隊，激發鼓舞團隊上進心。(這麼做之前，還是得先運用看板方法幫工程師找出盈餘時間來，有了多餘的時間就更容易激發他們的求知慾望)。讓工程師處在用功學習的狀態時，這是他穩定性最高的時候，也是最值得珍惜的時刻。

(2) 品質與紀律: 接著，讓團隊開始自我管理，怎麼做呢? 就從紀律開始，也就是開始嚴格要求品質。

(3) 衍生式設計 Emergency design: 讓團隊學習敏捷開發在進行設計時的精隨- 衍生式設計(註2.)。這一關很抽象很難明確，要適度就好。由需求（也就是使用者故事）開始最洽當了，容易掌握又可以看到成果（使用者故事地圖）。至於運用在架構或系統的設計上，那就要依靠工程師的素質了。

然後再把正確的(4)敏捷價值觀推廣到管理階層。讓上下之間有著一致的認知。

最後才是，讓管理及規劃部門清楚自己的任務其實是在「朔造團隊的敏捷文化」。

哈哈！用說的總是比較容易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。

 

註4.  Mapping Experiences， 作者: Jim Kalback 的名著

很棒的圖示法，原意是用在UX的設計表達上頭，用來作為個人與組織互動的影響說明。但運用在經驗模式的說明上也很適用。，

工程師如何自我管理?

.

工程師的本質 – 愛好自由自在的工作，不喜歡被管理。

寫程式辛苦嗎?當然辛苦但我們樂在其中。《人月神話》的作者Fred Brooks總結了身為程式設計師辛苦之下的樂趣:

第一、是純粹的創造所帶來的愉悅…。

第二、因為作出對其他人有用的東西而帶來的快樂…。

第三、是設計複雜邏輯元件並看著他們像魔術般的運作所產生的吸引力…。

第四、是持續學習的樂趣，原因是每次的任務總是不相同，沒有重複的特性…。

第五、因為工作的對象是可以自由駕馭的程式碼，這一點令人開心。

.

你很難讓團隊的每個成員都變成傑出優秀的工程師，

但可以確定的是幾個優秀的工程師就能讓團隊變得更優秀。

.

合群會讓人更優秀

程式設計人員大都很能自我享受工作，無形中把寫程式變成了一種樂趣(如果你還是覺得很辛苦，或許是因為頭髮多了些，那就再多寫個幾年吧XD)，我們喜好自由自在的工作，也樂於接受它的挑戰，這便是程式設計師與他（她）的工作。我們不喜歡被管，因為管理會無形中降低了這種樂趣，因此造成我們寧可關在房間裡寫程式也不喜歡去與人開會，這正是工程師總是不喜歡被管理的原因。但老實跟你說，如果你想要更快速成長的話，試著接受別人的管理其實是一件好事，它會讓你容易融入團隊，會讓你不會孤獨無援，而且事事有人照應，最起碼在出問題時還有人在上面撐著。

.

程式設計人員天生的主觀意識太強

我們容易為主觀意識所作祟，經常忽視自己的壞習慣，只看到別人的缺點而忽略自己也有著一樣的問題。這是因為「客觀」一直都不是我們所擅長的意識，往往需要借助一些外部的刺激或是設法消除主觀的偏見才可能讓自己客觀起來。至於如何借助外力呢?其中「看得見」可能是消除主觀意識的最簡單的解法。至於如何才能看得見呢? 我要推薦給你的工具就是個人看板 – 一種讓你足以客觀的看見事情真相的看板，我稱之為「客觀的個人看板」。

.

個人看板就是要你表現的更優秀

要習慣於表現優秀。但要如何表現得優秀呢? 《告別失控》的作者Mickey Mantle告訴我們把自己培養成為一位做事有條不紊、遵守紀律的工程師，也就是所謂的匠師Craftsmen，才能成為傑出的工程師。很不幸的是傑出的工程師實在太少了，那些習慣把動力的來源歸於時間計劃表、管理層給予的壓力或是金錢的誘因所造成的程式設計人員，他們通常都不會是一名傑出的程式設計師的。因為要變得優秀得要有真正的動機，那種追求卓越的動力應該來自於更高的要求: 也就是對世界做出貢獻並且做出人們實際上樂於使用的程式或產品( Mickey W. Mantle)。

.

重複一下，要如何表現得優秀呢? 就是對自己要求更高，並立志對世界做出貢獻，然後開發出對人們有著實際作用的程式或產品(如果你成功地作到了，財富自然會隨之而來的)。

.

Mickey在《告別失控》書中強調自我管理的六件事:

1. 個人風格

2. 時間與優先級管理

3. 溝通管理

4. 管理實踐

5. 跟蹤管理

6. 尋找導師

 .

在這裡我想用個人看板來描述第一項、個人風格。至於其它項目，就交給想上進的工程師自己來吧！

.

可以讓你變得更客觀的個人看板

.

個人看板只要有異動最適合的作法是隨時隨地更新，只有一項原則最好不要異動，那就是睡前一定要靠在枕頭上回顧一下（這個行為我已經作好幾年了，效益驚人）。

 .

個人風格

Mickey書裡頭的「個人風格」所指的是工程師的穿著。所以不論你是要創立個人風格或是試著想要改變別人對你的觀感，請用個人看板來作紀錄，用功的紀錄它一周，每日嘗試改變、改善不同的穿著並勤作回顧，常常問周遭的人士給一點comment，一周之後一定大有斬獲的。如果沒有就去請教服裝專家囉!

.

 

{我参考了 Mickey W. Mantle 與 Ron Lichty 這二個老學究所合寫的《告別失控》一書，他們雖然展現了古板的思維模式，但對於團隊及工程師如何自我管理的描述，還真是給出了很多優秀的論點，相當值得参考。}

{也參考了Fred Brooks 的《人月神話》第一章第二小節:

程式設計行業“滿足我們內心深處的創造渴望和愉悅所有人的共有情感”，提供了五種樂趣：}

{繪製個人看板我經常是採用 Kanbanflow， 但開發團隊的看板則採用 Trello居多}

.