這是一系列文章的開始，由於經常被新的客戶問道，您作顧問這麼多年一定有一些模式可以讓我們參考的。我的回答是：「當然了！」但心裡却總覺得有些虛虛的。案例是累積了許多，但把它們變成Pattern！這確實是從來沒有想過的念頭。原因；因為沒有一個顧問案例會一模一樣的，更何況大家的組織大小與文化更是有著很大的差異(新創公司跟一般的IT資訊部門實施起來就有大不同)，要想歸納成一個放諸四海皆准的模式，不太可能吧! 回顧自己的職業生涯，在進入職場後曾經換過20幾個工作，從事顧問後也顧問了十多家廠商。為什麼就不能勇敢一點，嚐試看看呢! OK，或許能協助那些自己很想協助但卻始終顧問不到的公司也說不定(哈哈! 報價是一種技巧)，所以就從先把他們寫出來開始。
{此時自己正和老婆在美西旅遊，這是三個星期的假期，難得輕鬆。這個roadmap我稱它為「Scrum 顧問 Pattern」，接下來的說明就是圍繞著下面這個 roadmap，它交叉了我對Scrum及Kanban 方法的理解及運用(每看一次這張roadmap就會有好多回憶湧上心頭，它看起來平淡無奇，但有多少經歷跟陷阱隱藏在其中，偷偷跟你說，雖然看起來我是在實行 Scrum 但其實我一直是採用看板的Column 來調整開發團隊的工作流程的。 哈哈! 這些招式有多少功用我都太熟悉了，而人老了就是容易多愁善感)，我盡量長話短說，畢竟這不是在寫書。但必須聲明一下，放在 Blog上的東西完全歡迎大家拿去用，它是屬於大家的。即使你冠上自己的姓名也會得到我的祝福的。}
想要施行「敏捷開發」要從那裡開始？
敏捷開發不只是一種開發方法，更是一種觀念的改變。如果只是學習一種技能，只要多下功夫就一定能有回報，但觀念要作改變就比較難了。改變觀念，其實就是一種「變革」，試想要從接受變革開始到去適應變革，然後能夠發揮它的效益，這就需要一定的時間才能作到。那該從那裡開始呢？
第一篇、從看見既有的工作流程開始
二個目的:
- 減少推行Scrum的阻力，並協助工程師取得盈餘時間。
- 提前面對需求。
.
看見 (Visualize) 的力量非常之大(這一點從iPad/iPhone誕生以來，各種媒體就在不斷的教導我們視覺化的力量，尤其是在使用手冊與UI介面的變化上，紙張版的使用手冊真是越來越少見了)。透過網路的力量，造成使用者界面的突飛猛進可能是這個時代最大的改變來源，許多的前端工程師因此應運而生，而這股熱潮將不會隨著時間的推演而逐漸平息，它反而更突顯了客戶視覺體驗的重要性，而他也是產品本身價值重要的一環。我個人一直視「看得見」是一種務實的行為。你可以試著把一些平常總認為稀鬆平常的習慣，試著務實的分析一下這些動作，把他們記錄下來之後讓自己看見這些活動是否有足夠的效能表現，讓紀錄下來的時間花費告訴我們它們是不是一種浪費，然後依此來做改善，增進自己的工作效率。這是看得見與務實能給我們的建議(一種自我的回饋)，千萬不要忽略了。
我們總是在看見了浪費的真正原由，才知道要思考如何來改善它。因此要先從看見現在的流程開始。(註: 我之所以挑「浪費」來作說明，除了浪費是精實開發最重要的一條原則之外，再來便是他是團隊提升效能的最佳開始之處，其實我是在替工程師找出他工作上的「盈餘時間」)。
熟悉看板方法的人(或是看過我所寫的看板方法書的人)大概都知道我為什麼從這裡開始，因為這樣作阻力最小，讓工程師由他們既有的流程開始，可以將既將產生的變革先置之腦後，先把自己習慣的工作流程畫出來，用價值流程圖的模式畫出來，然後再把每個步驟及步驟跟步驟之間所需要消耗的時間標上去。這個時候，便可以一目瞭然浪費的所在了(就是那些對我們的工作沒有產生價值的行為或等待，當然是浪費了)。
我選擇「看見」作為起手勢，還有另外一層意義就是想要提前來面對「需求」。
Scrum 缺少處理需求的前置方法
大部份的開發團隊輕估了需求是否備妥的重要性，也就是所謂的 Definition of Ready(DOR)。執行敏捷開發時，如果你覺得團隊的開發速度始終沒有起色的話，第一個值得懷疑的便是DoR 了。Scrum 沒有強調DoR的重要性，但在實作時却強烈的依靠後續的會議來對需求作檢驗, 這一點可以由最近的refinement meeting 越來越受重視，就可以看出它的重要性。
.
讓開發工作少作白工
敏捷開發採用使用者故事(User Story)來描述需求。目的是它夠抽象(抽象的目的是減少細節，減少我們對未來、還不確定的東西作預設性的假設，說白了就是胡亂作猜測)，它的目標是夠抽象又簡單到可以直接寫在小小的卡片上、便利作交談討論及確定如何驗證它。
而這裡我想追求的是提前在開發作業之前的解題動作。我長期把它稱為是在抽象與明確之間解題。你會問我是嚐試在開發作業之前就把事情都想清楚了嗎?這不正是傳統開發法所想作的嗎！不,當然不是。我的意圖在把需求說清楚，也就是用說故事的方式把故事講的圓滿。要知道，如果是一個好的創意，則大概在說故事的途中我們已經能夠體會到了(就是有驚歎聲跟賀彩聲)。當然，如果故事實在不怎麼樣的話，說完了的時候，大家也應該曉得沒太大作為了(不相信! 請在下一次有好 idea 出來的時候，大聲講給大家聽，看反應的好壞就是他該得的分數了)，其實idea如果不講出來就會變成是空想了，空想是很傷的，作多了會分不出來是空想還是幻想，還是多多講出來吧，如果連需求都講不好的工程師，你相信他能把需求作好，才奇怪了。
有很多方法可以幫我們來看清楚一點「需求」的真貌，例如:最小可行性產品MVP(Minimal Viable Product)就是其中一種。它的基本觀念跟測試開發的理念很類似: 試著作出一個最基本功能的產品，然後在取得客戶回饋的數據後進行修正。這種作法對新創公司很合理值得去作，但對大部份的IT資訊部門就不見得合適了(敏捷就是這麼回事，永遠沒有放諸四海皆準的事兒，一定需要調整的)。
下一篇、Definition of Ready: 工程師要學會如何講好故事。
接下來要來面對需求了。來談 DoR: Definition of Ready 需求的描述資料是否備妥? (它可以說是影響開發速度最大的關鍵，千萬別小看它了，這是我最近一年以來，花掉最多時間在處理的事情之一了)。
(上面的文章中有很多專有名詞都沒有多作解釋，在《看板方法》的書裡頭都有。如果還有問題的話，就請問吧!)
Ruddy Lee 分享空間 