敏捷需求與用戶體驗工作坊（已額滿XD）

Jan. 23 21:45~20:52

Erica畫的「漫畫」XD。

 

農曆年後的2月15日泰迪軟體會舉辦一場「深入探索需求：敏捷體驗設計工作坊」，這個工作坊名額有限，Teddy還沒來得及在部落格上打廣告就已經被「住在巷子內的鄉民」給預定額滿了，搶先報名者大多是參加C. C. Agile的朋友以及上過Teddy「Scrum敏捷方法實作班」的老客戶。工作坊的內容如下：

• 什麼是敏捷體驗設計？
• 敏捷體驗設計中的團隊合作方式介紹
• 如何共同分析問題產生概念
• 產生設計方案
• 建立故事版、原型與敏捷體驗地圖
• 產出使用者故事
• 建立敏捷釋出計畫（Release Plan）
• 分組實做練習

***

最近這一年多Teddy花了不少時間和Erica討論敏捷需求與用戶體驗設計的議題，希望能夠發展出一套方法，這個方法需要具備以下特點：

• 具備抽象定義，以便解決不同領域的設計問題。也就是說，需要提供一個「設計框架」，讓人可以在此框架之下處理與檢視設計問題。
• 提供具體操作步驟，不嘴炮、不打高空，讓人在學習之後可以有能力自己實施這個用戶體驗設計流程。
• 要夠簡單，UX designer、software developer、PO、PM、行銷、老闆、以及公司其他路人甲都有能力參與。
• 要符合敏捷與精實開發精神。
  

這個方法的內容最近整理得差不多了，而且Erica和Teddy都發現不少鄉民對這個議題有著很大的興趣。Teddy預備將今年度的課程規劃做一些調整，目前預計的方向是，原本計畫今年新開的「軟體重構入門實作班」往後延到下半年或是明年第一季，今年確定會增開一門兩天的「敏捷需求與體驗設計實作班」，時間預計在4月19~20。

此外，Teddy也正著手準備跟Erica合寫一本《敏捷需求與體驗設計的逆襲》的書，書中從Alexander的模式（pattern）理論談起，在Alexander的設計框架之下，如何逐步地把「老闆或客戶的一句話，加入用戶體驗的觀點，透過團隊合作的方式，發展與梳理出需求」。Teddy終於可以藉此在Design Pattern課程以外發揚Alexander的設計精神了，哈哈哈（忍很久了）。

希望今年六月之前可以把這本書寫好，今天先預告一下。

***

友藏內心獨白：今年是寫書年。

影響Retrospective Meeting成效的四個問題

Jan. 22 20:30~22:00

 

幾天前有一位朋友寫了一篇〈如何讓人在 retrospective meeting 說真話？〉的文章，內容很有意思，有興趣的鄉民們可以參考一下。讀完之後，Teddy想到有一次某個Scrum團隊的員工要離職，主管請Teddy以「外人的身分」跟這位員工聊一下。見面之後的第一句話，這位準備離職的員工就問Teddy：「我可以說實話嗎？」

Teddy不是該公司的員工，看起來也還算是「老實人」，對方就敞開心胸地說了許多內心話。經過將近兩個小時的長談，Teddy發現對方的鼻子並沒有變長，顯然應該是說出了真話。Teddy從對方的口中得知他對於團隊運作的看法，其中包含著許多不滿意之處，想必是「心受委屈了」。

等一下，這不是一個Scrum團隊嗎？不是每個sprint結束都要開retrospective meeting嗎？有這麼多不滿，為何沒有在retrospective meeting提出來？很顯然是retrospective meeting出了問題。以Teddy的經驗，retrospective meeting進行不順利，大致上可以分成幾個原因：

• 公司文化大環境不鼓勵：不少Scrum團隊是在傳統command-and-control（一個口令一個動作）的企業文化之下，苟且偷生、苟延殘喘地運作著Scrum。團隊成員也許曾經努力地提出改善方案，但礙於公司規定使得改善的推行變得遙不可及。人都不是笨蛋，每次凝聚的改善共識都沒有落實，久而久之大家就不想動腦筋。retrospective meeting就算沒被廢掉，也變成沒有生命的行屍走肉，只是一個流程上不得不開的會議罷了。舉一個最簡單的例子，團隊成員都在還用3~4年前慢到不行的筆電在開發Android APP，嚴重影響開發進度。但「公司規定」電腦要5年以上，且有特殊原因才可以申請更換。在這種情況之下，公司層面想的是「預算控制」、「省錢」，哪管你開發效率好不好。反正效率不好都是人的能力不足，自己還不乖乖留下來加班，換什麼新電腦。

另外一個例子，Teddy以前有一個Scrum導入案的客戶，團隊苦於沒有足夠的測試設備可以使用，因此嚴重影響到團隊開發速度。添購這些設備其實花不了公司幾萬塊的經費，但是部門主管就是打死不想提出申請（可能是怕被老闆責怪，沒什麼績效卻一直在花錢），ScrumMaster與團隊成員也很無奈。

• ScrumMaster不給力：Scrum推行成敗與否，除了公司高層是否支持，還有一個很大的因素，就是能不能找到一位好的ScrumMaster。很多人會受到現況的制約，以至於畫地自限，不敢邁開大步協助團隊實踐改善方案。例如，以剛剛提到開發電腦太慢的問題。好的ScrumMaster就算知道公司規定5年才可以提出電腦升級，但只要電腦的速度影響了團隊開發進度，他會主動與公司溝通，對老闆「曉以大義」，讓他乖乖掏錢出來幫團隊換上最新、最快的「武器」。
• 團隊成員不長進：對，就是不長進。有些團隊成員已經習慣於command-and-control的管理模式，每天混吃等死，得過且過。要求他們動腦提出團隊做事方法的改善方案，簡直比登天還難。
• 以為自己在實施Scrum：有些團隊以為他們在導入Scrum，但其實只是新瓶裝舊酒，骨子裡還是用原本的做事方法與思維來進行開發活動。例如，retrospective meeting進行方式是由「偽裝成ScrumMaster的主管」詢問團隊：「這個sprint大家有沒有什麼問題？」而不是讓團隊成員將好的、有待改善的項目寫下來公開討論。

***

以上是Teddy觀察到影響retrospective meeting成效的四點常見問題，每一點都非常「致命」。要改善retrospective meeting的運作，Teddy覺得首先要從「培養給力的ScrumMaster」著手。雖然有人建議ScrumMaster不應該參加retrospective meeting，因為團隊成員想「公審」的對象有可能就是ScrumMaster。但Teddy覺得ScrumMaster還是應該參加retrospective meeting，直接觀察團隊成員的反應。

如果連ScrumMaster在場會造成團隊成員有所顧忌而「不敢講真話」，那這個Scrum團隊就真的是病的不輕。怎麼辦？快來報名Teddy的「Scrum敏捷方法實作班」吧。

***

友藏內心獨白：這一篇真的不是廣告文。

有紀律的例外處理原則

Jan. 21 22:18~ Jan. 22 00:13

好的運動員必須要有紀律的練習

 

Teddy今天正式把《笑談軟體工程：例外處理設計的逆襲》的初稿寫完了，約10萬6千字。自己校正了一次，現在請「小幫手」幫忙二校，過完農曆年就準備交給出版社。快的話應該可以在三月底左右出版。

寫了這麼多有關例外處理的文章，鄉民們可能以為Teddy變不出什麼新把戲了。今天拿出「壓箱寶」，介紹一個對Teddy影響很大的例外處理設計原則，叫做：Disciplined Exception Handling Principle（以下簡稱DEHP），中文姑且翻譯成「有紀律的例外處理原則」。這個原則由Bertrand Meyer所提出，最早投稿至ECOOP（European Conference on Object-Oriented Programming，歐洲物件導向研討會，論文可在此下載），但是被reject（拒收）了。根據Bertrand Meyer表示，早年他的論文「有系統性的」被學術研討會拒絕（暗示有人在背後搞他），直到後來他寫了一本得獎名著《Object-Oriented Software Construction》，之後大紅大紫，這個情況才改善。哇，原來大師也有被「打壓」的過往。

***

言歸正傳，DEHP好就好在它只有兩條規則，簡單、好記、好學。好聽又不會跳針：

• Retrying（重試）：嘗試改變造成例外的狀況然後重頭開始重新執行一次函數（attempt to change the conditions that led to the exception and to execute the routine again from the start）。
• Failure（失效）：清理環境，中止函數執行然後回報失效給呼叫者（clean up the environment, terminate the call and report failure to the caller）。這條規則又叫做organized panic，對岸有人翻做「忙而不亂」。

如果鄉民們一直有在注意Teddy所寫的例外處理文章，Retrying這一條規則，其實就等於「強健度等級三：行為回復」（請參考〈敏捷式例外處理設計的第一步：決定例外處理等級〉）。翻成白話文就是說，就算是遭遇到例外狀況，函數不可以失效，要想辦法達成原本規格中所賦予該函數的任務，接近於C++所稱的「不丟擲保證（no-throw guarantee）」（請參考〈你的汽車有多耐撞？談談例外安全性〉）。

Failure這一條規則，就是告訴函數「你可以放棄了」。雖說是放棄也不是胡亂放棄，至少要把環境打掃乾淨，不要導致資源洩漏。最後，要透過丟出例外的方式，回報函數失效給它的呼叫者。只所以又稱為organized panic，因為函數無法達成任務是一件很痛苦的事（panic），但是雖然痛苦，也要讓這個痛苦是在「受控制」、「有組織」（organized）的情況下發生。

Failure相當於「強健度等級二：狀態回復」，對應到C++的例外安全性，應該涵蓋基本保證（basic guarantee）與強烈保證（strong guarantee）。

***

看到這邊鄉民們不知道有沒有發現，很多事情道理其實是一樣的，但是不同的人會用不同的方式、不同的用語和名詞來解釋，搞得大家暈頭轉向。

DEHP的好處在於簡單，但缺點則是過於簡單。但對於如何設計例外處理完全沒有任何觀念或想法的團隊而言，由DEHP入門，也不失為一個不錯的途徑。

***

友藏內心獨白：DEHP原本設計給Eiffel用的，應該很適用於Ruby吧。

為什麼要採用Scrum？

Jan. 20 21:36~22:58

想過著跟派大星一樣的生活嗎？

 

不少《笑談軟體工程：敏捷開發法的逆襲》這本書的讀者告訴Teddy，他們是因為封面上面印著「從此每天準時下班享受幸福人生！」的這句話而買這本書。這句話很顯然是出版社的行銷口號，但的確也反應出廣大勞工「軟工」朋友的心聲。

時間過得好快，出版《笑談軟體工程：敏捷開發法的逆襲》至今也已經超過一年半的時間。幾天前在寫〈你如何評價成功〉這一篇文章的時候，想起了一個基本問題：「為什麼要採用Scrum（敏捷開發方法）」？

為什麼要採用Scrum（敏捷開發方法）」？

是為了幫公司賺錢、為了提升軟體品質、為了實現自我理想、為了準時下班過家庭生活、還是單純為了護肝？

***

如果只是為了「賺錢」，其實和有沒有採用Scrum並沒有絕對的關係。生意模式錯誤、Product Owner（很可能是公司的大老闆）亂作夢，需求搞錯方向。總總因素，都可能讓一個良好的Scrum團隊做到公司倒閉。相反地，老闆有辦法去包工程、搶案子，就算是只找一堆22K的便宜人力，公司還是很可能賺大錢。

當然上面提到的兩種狀況算是兩個極端，大部分的團隊，大致上處在「缺少一個有效做事方法」的位置，如果可以找到一個持續改善的做事方法，就可以儘量平衡業務面（賺錢）、個人發展、與生活面等因素。

雖然Teddy讀了很多敏捷開發、精實開發、XP、Scrum、Kanban方面的書，不過很多關於軟體開發應該如何進行的原則，是受到了Alexander很大的影響。在思考「為什麼要採用Scrum（敏捷開發方法）」這個問題的時候，又回去翻了Alexander的〈The Oregon Experiment〉，他在說中提到：

We … propose a process which can allow people … to take care of the environment for themselves, and have some measure of control over their own lives.

（我們提出一個流程，允許人們為了自身而去關心環境，並且對於自己的生活有些控制措施）

想來想去，這一句話剛好可以解釋為什麼要採用Scrum、其他敏捷開發方法、或精實方法。身為人，在自由社會裡面，為什麼不能掌控自己的生活？為什麼還要把「掌控自己生活」列為追求的目標？雖然說是「自己的生活」，但其實很多時候自己的生活卻是由別人幫你決定要怎麼過。光是一個「責任制」、「加班文化」，就打死一堆人。

老闆：想不想賺錢？想的話就不要妄想過自己的生活。

***

Teddy在《笑談軟體工程：敏捷開發法的逆襲》書中曾經提到：「我希望改變人們在台灣開發軟體的方法」，其實也就是Alexander所說的希望鄉民們可以「have some measure of control over their own lives」。至於這個方法，一年半前寫書的時候認為是「Scrum + Lean + XP（Agile Practice）」，現在這個想法還是沒變，但是可以在Agile Practice的大帽子裡面塞入一個Agile UX來彌補Scrum在需求發展上的不足。

***

為什麼要採用Scrum（敏捷開發方法）」？因為想要過人的生活啊。

***

友藏內心獨白：難道現在過的就不是人的生活？

推理就好

Jan. 19 18:40~19:20

 

一位朋友告訴Teddy…

朋友：我們公司的顧問告訴我們，Scrum做得好很難，他們曾經連續開了五天的sprint planning meeting。因此顧問建議我們，還是採用Kanban比較簡單。

上面這句話，鄉民們覺得有沒有道理？

今天又要在「公堂之上假設一下」，先推理一下為什麼sprint planning meeting開了五天的可能原因：

1. 對方以為他們在實施Scrum，其實只是用以前waterfall的方式換個名稱而已。把以前的需求分析/系統分析會議改個名字叫做sprint planning meeting，一連開五天也是很平常的現象。
2. 對方真的在實施Scrum，但是他們的sprint長度太長。假設為期兩周的sprint需要花一天來開sprint planning meeting，連開五天代表對方的sprint可能長達10周（2.5個月）。
3. 對方真的在實施Scrum，sprint長度也在2~4周之內，但是尚未掌握sprint planning meeting的要領，因此導致會議時間太長。簡單的說，還是沒有脫離waterfall或是plan-driven（計畫驅動）的舊習，想在sprint開始之前就把所有的設計細節弄清楚。
4. 對方想在sprint planning meeting就把全部product backlog的內容全部討論完畢。同樣地，還是中了waterfall或是plan-driven的遺毒。

無論是哪個原因，都是對於團隊對於Scrum與敏捷開發不夠理解或是程度不夠的徵兆。

***

接著來推論第二點，sprint planning meeting連開五天這個問題，無論上述1~4點的哪一個原因，是不是只要換成Kanban就解決了？

鄉民甲：當然是解決了啊，Kanban根本沒有sprint（iteration），更沒有要求要舉辦sprint planning meeting，本來無一物，何處惹塵埃。連sprint planning meeting都不需要開了，當然就不可能連開五天啊。

沒錯，Kanban沒有sprint也沒有要求要開sprint planning meeting，那請問原本團隊在sprint planning meeting所做的「事情（討論需求、切割工作）」跑到那去了？總不可能憑空消失吧？

因為Kanban沒有sprint，團隊以一種「事件驅動」或是「非同步」的方式來消耗（實作）需求。能量不滅，原本需要五天來討論的需求，並不會因為改用Kanban之後而變成一天。運氣好的話團隊還是花了五天的「總時間」來做原本「錯誤版」sprint planning meeting所做的事情，只是這五天被分配到不同的需求項目上面。運氣不好，因為沒有sprint以及sprint review，團隊一下子沒了「time-boxing」的壓力或是節奏感，可能花費更長的時間在up-front design之上，最後的結果就是很長的平均lead time（交期）。

***

不管是採用Scrum，最後導致sprint planning meeting花了五天，或是改用Kanban，乍看之下避免了sprint planning meeting花五天的問題（因為根本沒這個會議），但卻形成很長的平均lead time，這些都是一種「病徵」，並不是Scrum或是Kanban的問題。改善的契機就來自於有一套機制將這些病徵凸顯出來，然後團隊去正視它，謀求解決方案。而不是閉上眼睛就以為看不見，人云亦云的認為Kanban比Scrum好，或是Scrum比Kanban好。

Scrum和Kanban這些方法，有它們的長處，也有各自的限制。知道這些長處與限制，人才可以駕馭方法，而不是被方法給駕馭。

有人說，軟體開發最難的事情就是讓大家「動腦筋」，年紀越長越覺得這句話很有道理。

***

友藏內心獨白：有空多看點柯南或偵探小說。

2012緬甸考察之旅Day9-A仰光早安

Jan. 17 20:33~21:08

28美元旅館的早餐算不錯了，三合一咖啡、兩片烤過的吐司、奶油、一顆荷包蛋、水果，已經可以吃飽了。

 

吃完早餐之後在仰光街頭漫步，Kay說要散步到仰光車站，反正也不趕時間，就慢慢走。仰光的馬路很寬，人行道也很寬，雖然有些人行道有點破損沒有維修，但是大體上走起路來還蠻舒服的。

 

走到仰光車站，原來Kay打算去搭火車繞仰光一圈，到了車站看不太懂火車要怎麼搭，未免不小心跑到遙遠的不知名地點，還是逛一下車站就好了。仰光車站沒什麼人，和想像中那種大城市的車站人潮洶湧的印象相比，這裡算是很悠閒的車站。

到仰光的第一日上午就在尋找仰光車站的過程中畫下句點，準備找地方吃午餐了。

***

友藏內心獨白：仰光應該可以找到咖啡廳。