自省非自省

August 26 16:38~17:35

 

Scrum跑了一陣子許多團隊都會面臨「自省會議成果不彰」的問題。為了怕得罪人，有些人在自省會議變成「自我批判會議」，只提自己在這個sprint所犯的錯誤並且不斷道歉。有些人「有話直說」，不怕得罪「權貴」，例如在會議中直接挑明：「Product Owner所準備的user story太過模糊，害我們不斷修改程式浪費開發人員的時間。」

***

自省什麼？

Retrospective可以翻譯成自省也可以翻譯成回顧。自省並不是「個人行為的自我反省」，而是整個團隊針對「流程（做事情的方法）」的反省與改進。回顧這個sprint哪些做事的方法很好，鼓勵團隊持續維持。哪些做事的方式卡卡，找出最迫切的項目討論如何調整、改善。

鄉民甲：你們搞敏捷的人常說「自省會議是對事不對人」，但是事情就是人所搞出來的，討論到最後還會指涉到特定人士啊。

舉個例子，有團隊成員可能會覺得「Product Owner所準備的user story太過模糊，害我們不斷修改程式浪費開發人員的時間。」當腦袋想起這個念頭，其實已經對某個觀察到的現像作出結論了。換個角度思考，「不斷修改程式」是一個現象，但這個現象未必是因為「Product Owner所準備的user story太過模糊」所造成，也可能是因為開發人員遇到問題都不主動詢問Product Owner，導致程式寫好後才被要求修改。所以如果先描述現象，除了不斷修改程式以外，可能還有：

• 這個sprint開發人員認為已經完成（Done）的story卻不斷被移回到Doing狀態，或。
• 這個sprint原本預計完成五個story但最後完成3個。

這些都是開發過程中的「現象」，先溝通這些現象，接著再討論造成這些現象的可能原因，最後才擬訂改善計畫。

***

請ORID幫忙

有些敏捷團隊覺得在retrospective活動中使用「焦點討論法（Focused Conversation，又稱為ORID）」（請參考〈學問—100種提問力創造200倍企業力〉）可以避開「對人不對事」的問題。

• 客觀（O）：這個sprint發生什麼事件。
• 反映（R）：對這些事件的感覺如何，開心、喜悅、興奮、悲傷、生氣、暴怒、無奈。
• 意義（I）：這些事件背後代表什麼涵義？溝通不足、Product Owner太忙、團隊成員身兼多份工作、團隊成員遇到問題沒有立刻反應、不知道該如何反應、找不到人反應、不敢或不好意思反應、技術能力不足、團隊對於敏捷開發精神沒有共識、沒有定義Definition of Done（DoD）或沒有遵循它。 
• 決議（D）：把DoD印出來貼在taskboard旁邊，請每位團隊成員簽名；user story一完成立刻找Product Owner來驗收；sprint planning的時候讓團隊成員針對每一個user story撰寫驗收測試，拉近Product Owner與團隊成員對於user story內容的認知。

***

友藏內心獨白：Retrospective是持續改善的重要活動。

2016年11月【看板方法與精實開發實作班】

August 29 16:55~17:21

 

你有以下問題嗎需要解決嗎？

• 一個團隊同時開發多個專案，工作分配與時程管理一團亂，該怎麼辦？
• 最近DevOps很熱門想導入但卻不知如何著手落實？
• Scrum跑了一陣子但團隊的持續改善能力並沒有顯著提升？
• 不知如何將敏捷開發應用在大型專案上？
• 如何管理IT維護與營運專案的事件驅動型工作？
• 行政人員、HR也可以導入敏捷嗎？

歡迎報名參加「看板方法與精實開發實作班」。

▲課程實況照片。

***

報名網址在此：【看板方法與精實開發實作班】，上課日期2016年10月2、3日（日、一）。

***

友藏內心獨白：本年度最後一次公開班。

實無眾生得滅度者

August 26 13:37~14:28

 

昨晚〈C.C. Agile#48 - 組織導入敏捷的困境、機會、挑戰與疑惑〉繼續嘗試「開放空間技術」（Open Space）的形式。Teddy發現上個月也有參加的兩位朋友，在上次討論中提問很多Scrum團隊的問題，怎麼這次沒有發起討論議題？一問之下原來在上次活動中這兩位朋友獲得許多建議，而他們回去之後也努力嘗試，短短一個月之內解決了原本非常困擾他們的主要問題，所以這次就沒發起新的討論議題，改派他們另一位同事提問。

在上次聚會中，原本這兩位朋友很擔心團隊合作與開發進度這個兩互相影響的問題。在一般專案中，當「有人」認為開發進度不如預期的時候，很多負面情緒就會跑出來。例如懷疑員工偷懶、不認真、沒有企圖心、能力不足等，然後就會想要怎麼「控管」這種現象。

在上次討論中小組成員提供的建議其實很簡單，主要有兩點：

• 縮短sprint長度。不少Scrum團隊原本的sprint長度可能是兩週，但發現許多功能在兩週內無法完成，於是就自然覺得如果把sprint長度延長成三週或四週應該可以解決這個問題。殊不知sprint長度延長之後更多的需求會被放入sprint中，所以事情還是做不完。更糟糕的是，原本兩週可以發現這個現象而有機會加以調整，sprint長度拉長之後回饋週期變長，問題變得更加複雜。
• 採取pair programming。「開發進度是否正常」這件事是很難加以預估，因為軟體開發是複雜性很高的工作，一路上遭遇到的風險、不確定性太高，所以很難準確預估。有些人採用Scrum之後發現原本sprint planning會議中團隊成員預計要完成5個user story，但實際上只完成了3個。於是主管可能開始討論怎麼樣才能「預估準確」，或是私底下懷疑團隊成員某某人（或全部）都在打混摸魚，要想辦法來「盯進度」。所謂「疑人不用，用人不疑。」比較正面的方式可以鼓勵團隊成員採取pair programming的方式來完成每一件工作。兩兩一組一起工作，往「壞的方面想」可以互相監督，往好的方面想可以互相學習，技術交流，而且開發出來的程式碼品質通常會比較好。

***

以上兩個建議，這兩位朋友回去之後全面落實。而且出乎預料之外，pair programming居然大受團隊成員歡迎。他們現在的困擾反而是當人數是奇數的時候有一個團隊成員會落單找不到人pair programming。

***

友藏內心獨白：很少遇到一個月之內改變這麼大的團隊。

2016大阪姬路神戶考察之旅Day3-D淡路夢舞台之百段苑

August 21 21:29~22:11

離開海之教會準備前往淡路夢舞台另一個著名景點百段苑。這裡是一個緩坡，佈滿了數十個（沒仔細數過，叫做百段苑不知道會不會有一百個）方形花壇。直排的花壇中間有水景階梯隔開，邊看花邊聽水聲，很舒服。

 

▼途中不小心看到海之教會的屋頂。

 

▼由下往上看百段苑。

 

▼水景階梯，水聲潺潺很好聽。

 

▼終於看到百段苑的真面目了。

 

▼不只種花，還種了許多青菜、草莓。

 

▼遠眺海上的小船。

 

▼遠方的花園，沒時間走過去只能用望遠鏡頭欣賞XD。

***

友藏內心獨白：當成菜園也不錯。

2016大阪姬路神戶考察之旅Day3-C淡路夢舞台之海之教會

August 21 20:42~21:22

▼從本福寺水御堂快馬加鞭騎自行車回到港口服務中心，還車之後稍作休息等待中午發車前往淡路夢舞台的巴士。

 

▼搭上巴士之後沒多久來到淡路夢舞台，巴士就停在安藤忠雄設計的Westin Hotel前面。

 

▼回程可以從這裡搭車前往高速舞子換火車，或是直接搭到終點站新神戶驛轉搭新幹線。

 

▼先記好回車發車時間。

***

▼淡路夢舞台有好幾個景點，先到位於Westin Hotel二樓的海之教會參觀。入口處很低調，要注意看指標不然很容易錯過。

 

▼看到這一片清水混凝土就知道找對地方了。

 

▼前方的十字架是用燈光打出來的。

 

▼屋頂有簍空（鑲嵌玻璃）的十字缺口，原本以為前方的十字架是從屋頂射入的光線，後來仔細一看才發現前方的十字架是人造燈光打出來的。

 

▼十字架光線製造機。

 

▼教堂屋頂，感覺套用安藤忠雄另一個著名作品，位於大阪的「光之教堂」的設計模式。

 

▼海之教會是飯店的結婚會場，是一個非常迷你的小教堂。

 

▼教堂外掛了兩幅畫。

 

▼離開海之教會，有種要上天堂的錯覺XD。

***

友藏內心獨白：免費參觀。

自問自答的練習

August 25 09:38~10:27

▲你在產生instance的時候都有確保class invariant成立嗎？

 

昨天上完第一梯次「敏捷開發懶人包：物件導向技能」一共四小時的課程，在課前規劃內容的時候想了很久，怎麼在短短四小時內講完重要的物件導向觀念？物件導向技術包山包海，光是語言、設計、分析、流程、架構、測試，每一個項目單獨來討論一天都講不完，更何況是全部合在一起要在四個小時內介紹完畢。

建築師Alexander說：「設計就是決定形式（form）和背景（context）的界線」，要找到合適的邊界真的頗傷腦筋。後來想到一個很簡單的方法，把這個短課程定位為：「上完課之後，如果要找工作在面試時面試官問到物件導向的問題，有能力作答及格，甚至回答的深度連面試官都聽不懂你在講什麼。」

大方向（整體的感覺）決定之後，接下來的事情就比較簡單了。四個小時的內容規劃四個主題：

• 物件導向基礎觀念
• 依合約設計（Design by Contract；DBC）
• 物件導向設計原則（SOLID五大原則）
• 物件導向分析與設計

***

上禮拜三晚上第一次上課，講完前兩個部分出了兩個作業，其中一個作業請學員找工作上使用的類別或介面，用DBC的方式幫它定義前置條件（preconditon）、後置條件（postcondition）、類別不變量（class invariant）。昨晚第二次上課有學員拿作業跟Teddy討論，討論結束後學員說：「奇怪，怎麼聽你上課講定義合約那麼簡單，我自己回去要定義合約才發現寫不太出來」。

另一個學員拿了一個函數和Teddy討論合約，討論完前置條件和後置條件之後，他說：「我不知道這個類別不變量要怎麼定義？」對啊，Teddy也不知道要怎麼定義這個函數的類別不變量，因為顧名思義類別不變量（class invariant）必須要針對類別（class）來定義，而這位學員所練習的對像是一個獨立的函數，所以根本不能也沒得定義類別不變量（本來無類別，何存不變量？）。

上課講得很間單並不表示這件事本身很簡單，只是用淺顯易懂的方式讓學員在短時間快速接觸一個新的方法或概念。理解方法並不表示有能力可以應用、活用這個方法，還必須仰賴練習，不斷地練習，才可以把這個東西變成自己的。練習的過程非常辛苦，但這是能力增長的必經歷程。

***

昨天上課時Teddy提供學員一個很簡單的自我練習方法，就是把投影片拿出來，試著「自問自答」，看看每張投影片你自己可以問出幾個問題。如果可以問到18個問題，那就恭喜你可以從18層地獄解脫，早登西方極樂世界XD。

***

友藏內心獨白：先自問自答，別人問才不會不能答。

【工商服務】2016年9月Scrum敏捷方法實作班

August 24 15:30~16:32

 

開始第一個Scrum專案到目前已經過了八個年頭，當初以為自己會一直當工程師直到退休，沒想到因緣際會現在以敏捷開發培訓與顧問維生。這些年來認識了不少對敏捷開發有興趣的朋友，有些組織已經把敏捷拓展到全公司範圍，並思考如何透過各種工具，例如顧問、教練、引導、溝通，朝向學習性組織的目標邁進。有些人在團隊範圍內獲得不錯的成績，正朝向將敏捷拓展到其他團隊與部門。有些團隊正在努力獲得第一次的敏捷成功經驗。有些人因為公司文化與專案特性限制，只能在個人範圍內嘗試敏捷，從自動化測試、持續整合、簡單設計、重構、TDD等技術面著手。也有不少人停留在「知道」敏捷而尚未有機會親自參與敏捷。

敏捷開發到底有沒有用？說到底還是取決於「人」的因素。因為產品是人做出來的，如果做事的人心態與方法不改，敏捷開發的效用可能有限。反之，對於軟體開發而言敏捷方法的確是一個相當有效的做事方法。

***

前幾天晚上在電視上看到王貞治電影的廣告，有一幕演著鄉民批評王貞治的稻草人打法，說這種打法風一吹就倒了，根本不行。下一幕演到王貞治連續幾年靠著稻草人打法坐上日本全壘打王寶座，最後還打破日本全壘打數的記錄。最後鏡頭轉到訪問年老的王貞治，他說他根本不再乎別人怎麼說，因為只有他自己知道能不能打到球。

能不能打到球只有自己知道，敏捷開發好不好，Scrum有沒有用，自己試過才知道。如何建立正確的敏捷思維與流程觀念？與其自己花時間慢慢看書、嘗試錯誤，還不如直接報名「Scrum敏捷方法實作班」，省時又方便。以下為課程實錄照片。

***

友藏內心獨白：時間才是專業人士最寶貴的資源。