2015捷克、奧地利考察之旅Day10-A帝國咖啡館早餐

Sep. 23 18:10~18:34

▼今天是待在布拉格的最後一天，明天就要啟程前往維也納。今天早上到帝國咖啡館吃早餐，這裡其實是飯店附設的咖啡館，早上有很多住宿飯店的旅客在這裡用餐。

 

▼裝潢還蠻氣派的。

 

▼單價也比之前去的餐廳要略高一點點。這裡的早餐有提供吃到飽的自助餐，其實比單點貴不了多少。因為吃不了那麼多所以就用單點的。

 

▼在捷克吃早餐預設都會給一盤麵包，如果不要麵包要特別告訴服務生。光是吃這些麵包就有夠給他飽的了。不知道是不是因為單點的關係，沒點到這裡的招牌，覺得這裡的食物也算不上特別讓人驚艷，不過來開開眼界看看人家的用餐環境倒是還不錯。

***

▼回程經過布拉格廣場，剛好遇到有人舉辦婚禮。

 

▼布拉格的早晨。

***

友藏內心獨白：每天都到不同餐廳吃早餐也挺不錯的。

Subtle Control

Oct. 19 15:11~16:45

 

昨天提到〈The New New Product Development Game〉文章提出「新的新產品開發方法」—Rugby approach（橄欖球方法），其中第五個特色是subtle control（含蓄控制）。今天詳細介紹一下這個特點。一個自組織團隊並非不需要管理，若是採用subtle control策略，有下列七個步驟可參考：

1. 謹慎挑選團隊成員，觀察團隊合作氣氛，並且視需要增減團隊成員。有些人就是天生不對頭，把兩個死對頭的人故意放在同一個團隊裡面，就算最後他們可以勉強一起合作，長時間的摩合期加上脆弱的合作關係，對團隊可能是有害的。有些人很適合在command-and-control（一個口令一個動作）的模式下工作，但自主管理的能力非常薄弱，這樣的人也不合適直接放在自組織團隊中。
2. 建立一個開放工作環境。
3. 鼓勵開發人員到第一線聆聽客戶的心聲。
4. 建立基於團隊表現而非個人表現的績效考核系統。
5. 管理開發步調，避免專案一開始轟轟烈烈，到了結尾的時候大家都沒力了。換句敏捷開發（XP）的術語，就是要讓團隊維持Sustainable Pace（可持續開發步調）。
6. 容忍與預期犯錯。Handa的工程師說：「1%的成功率來自於99%的失敗」。犯錯是正常現象，關鍵在於儘早發現錯誤，從錯誤中學習，採取步驟立即改正。
7. 鼓勵供應商也採行自我組織。在設計的初期就邀請供應商參與，但不需直接告訴供應商要怎麼做，讓它們發揮自己的創意，找出自己的解決方案。

***

看完這七個步驟，鄉民們有沒有聞到濃濃的敏捷開發味道？除了第7點敏捷開發比較少直接討論以外（精實開發有類似的作法），其他1~6點根本和敏捷開發所談的沒什麼不同。

組織一個有戰鬥力的團隊並非易事，但卻很有價值。《SCRUM：用一半的時間做兩倍的事》書中提到，好的工程師和差的工程師生產力可相差十倍。好的團隊和差的團隊，生產力則可相差一萬倍（信不信由你 XD）。看一下上面七點，回想一下自己的敏捷團隊，有沒有什麼可以改進的地方呢？

***

友藏內心獨白：考古的工作還是有其必要。

The New New Product Development Game

Oct. 19 13:26~14:53

畫面節錄自此

 

學過Scrum的鄉民可能知道，Scrum受到〈The New New Product Development Game〉文章所啟發。這篇發表於1986年Harvard Business Review的文章，作者是兩位日本教授：Hirotaka Takeuchi與Ikujiro Nonaka。文章提出一個新的「新產品開發」方法—Rugby approach（橄欖球方法），用以增進產品開發速度與靈活性。這個方法具備以下六個特色：

• Build-in instability：高層主管只給團隊一個具有挑戰性的開發目標或開發策略方向，讓團隊自己決定要怎麼做。看到第一點就覺得好奇怪，不穩定（instability）不是大家避之唯恐不及的性質嗎，怎麼還內建在這種方法之中？因為新產品開發原本就充滿著不確定性，如果高層想要用各種方式來控制或是避免這些不確定性，很有可能反倒妨礙了新產品開發的進行。因此高層主管只需給團隊一個具有挑戰性的題目，至於團隊要用何種方式來完成這個挑戰，由團隊自行決定。在尋找解答的過程，很可能會來來回回，不斷地打掉重練，或是反覆修正。這是一種聯合次要敵人（不穩定性），打擊主要敵人（未知、不確地性或改變）的策略。
• Self-organizing project team：因為是新產品開發，所以團隊剛開始所知甚少。團隊運作有如新創公司（start-up company），成員主動性高、願意承擔風險，最後找出一套適合團隊的運作模式。自組織有三個條件：
  • autonomous：自治。公司高層只限於提供建議、資金、精神上的支援，不介入團隊實際的運作。換句話說，老闆「打開錢包，閉上嘴巴。」
  • cross-functional：組織跨職能團隊，將這些人放在一個大房間內一起工作。別人的知識在無形中變成你的知識，將有助於你做出系統性的最佳決策，而非單點最佳化。
  • challenged：持續改善產品與流程，不斷挑戰極限。
• Overlapping development phases：，傳統開發方法好像接力賽跑一樣，開發階段一棒接著一棒，例如需求分析、系統分析、系統設計、實作、測試等。在新的開發模式中，不同開發階段會重疊在一起，以加速開發或尋求各種不同的可行性。例如，設計、實作、測試可以同時（重疊）進行。
• Multilearning：學習發生在multilevel learning與multifunctional learning，詳細說明請參考昨天的〈單一職能團隊比較容易處進學習嗎？〉。
• Subtle control：雖然團隊享有高度自治，但並不表示它們完全不受控制。控制的方式有三個重點：self-control、control through peer pressure、control by love。文章提到subtle control可以細分為七個步驟，內容蠻重要的但有點長，另外再寫一篇介紹。
• Organizational transfer of learning：當學習發生在multilevel與multifunctional之後，團隊成員也會將這些知識帶其它團隊，形成整個組織的知識交流。

***

對敏捷開發，特別是Scrum有興趣的鄉民，不妨花點時間好好把這篇文章讀幾遍。Scrum發明者吸收了這篇文章的日月精華，加上自己的經驗創造了Scrum。直接閱讀這篇文章，可以品味Scrum框架背後的原理，甚至可以重新發現原本直接學習Scrum無法體會的精神。

***

友藏內心獨白：所以到發源地朝聖是一種必要的體驗。

單一職能團隊比較容易促進學習嗎？

Oct. 19 12:01~12:50

▲跨職能團隊。圖片來源在此

 

企業在推行敏捷轉型時，經常會遇到一個問題：「組成跨職能團隊之後（cross-functional team），團隊中的專業人員要怎麼深化他的專業能力？」例如，以UX設計師為例，在component team（由相同專長組成的團隊）中，可以直接從組員身上學習技術。Component team的團隊主管專長與你相同，所以也有能力幫你規劃學習路徑。但在cross-functional tem裡面，假設只有一位UX設計師，他要如何學習成長？此外，cross-function team可能採取自組織（self-organizing）的方式，沒有團隊主管。就算有，這位團隊主管的專長未必與你相同。在這種情況下，團隊主管如何幫你規劃學習路徑？

傳統上許多人認為專業人員最主要的能力提升來自於專精自己最擅長的事情（不然怎麼叫做「專長」哩），所以component team的組成把一堆專長相同或相近的人擺在一起，最可以促進學習、增強能力。實際上，人的成長不能只倚靠單一路徑。在組織內，多層次、多職能的學習，也是十分重要。在〈The New New Product Development Game〉提到兩種不同層次的學習：

• 多層次學習（multilevel learning）：學習發生在個人、團隊、企業層次。在個人方面，組織應該保留一定比例的時間讓個人可以學習成長。例如，有些公司允許員工有15%~20%比例的工作時間可以拿來做自己想做的任何事。在團隊層次，有時整個團隊需要集體抽離專案，看看其他團隊或公司以外的人怎麼做事情。在公司層面，如果公司定義清楚整個公司所要達成的目標或是能力，便可以做為團隊與個人的學習目標。
• 多職能學習（multifunctional learning）：以UX設計師為例，有時候問題無法解決，設計出來的產品客戶不喜歡，通常不是單純UX設計的問題。可能牽扯到需求從頭開始就搞錯方向，或是實作與原本規劃有落差，亦或是產品本身沒問題，但是上市時間太慢。透過組成cross-functional team，團隊成員可以更理解整個產品開發不同專長的人所顧慮的面向。有了全面性的觀點，更能幫助自己做出比較好的區域決策，以避免區域最佳化而傷害整體價值流的傳遞。

***

就算cross-functional team可以幫助多層次、多職能的學習，但原本單一職能的技術提升的問題還是沒有解決啊？其實答案也很簡單，試想鄉民們在念大學的時候，如果你很喜歡彈吉他，但班上沒有其他人可以互相切磋，那怎麼辦？就參加吉他社啊。

公司可以組織專業社團，讓隸屬於不同cross-functional team的單一專長人員參加。社長可以是原本component team的主管，或是大家公認該專長最強的員工（當然也可以用票選產生）。如此一來，不但解決了單一專長成長的問題，還可以將不同團隊內的文化、做事方法，透過社團交流帶回到原本的團隊中，達到公司內部跨團隊的知識交流。

***

友藏內心獨白：近親繁殖容易產生有缺陷的後代，維持生物多樣性是很重要的。

Advanced ScrumMaster課程推薦

Oct. 20 17:45~18:10

今年九月Erica到上海參加由odd-e公司的講師呂毅所舉辦的Advanced ScrumMaster課程，收穫良多。這個課程明年2月將會到台灣舉辦，由鈦坦科技協辦。剛剛應朋友之請，今天特別加碼介紹一下這個課程。

問題是Teddy自己沒上過odd-e的這門課，要如何推薦？還好Erica上完課回台灣之後花了點時間跟Teddy分享她上課的經驗與課程內容，讓Teddy做一下簡短的「三手傳播」。

這門兩天的課適合已經有Scrum導入經驗的人參加，第一天從組織管理領域的Star model介紹起，以strategy、structure、processes、rewards、people這5個面向來詮釋敏捷轉型所需關注的議題。在討論structure與processes時會介紹LeSS與SAFe這兩個拓展Scrum的方法。第二天介紹ScrumMaster的四個角色：引導者、教練、團隊建設、變革大師。

這裡有講者分享在網路上的Agile organization design投影片，課程的部分內容在《Scaling Lean & Agile Development》這本書裡面也可以找到相關資料，有興趣的鄉民可以先參考看看。

課程報名網址在此，所剩名額不多，有需要的鄉民請把握機會。

***

友藏內心獨白：第一次收到需求馬上動手寫。

敏捷開發都不寫文件？

Oct. 19 09:50~11:12

 

「敏捷開發都不寫文件」這個錯誤的刻版印象，Teddy以為在N年前就已經結案無需再提了，沒想到時至今日還是有不少人抱持這樣的看法。今天就來舊事重提，談談敏捷開發與文件的話題。

▼雖然敏捷宣言第二條提到「可用的軟體重於詳盡的文件（working software over comprehensive documentation）」，但這並不表示採用敏捷開發就不需要撰寫文件。

 

首先思考一個問題：「軟體開發為什麼需要寫文件？」Teddy認為有最主要的目的有兩個：

• 記錄知識：將人腦袋裡面的知識以書面形式記錄下來，以便於後續重複使用。例如，用use case記錄使用者需求。
• 輔助溝通：將知識書面化之後，多個人可以同時閱讀這些文件，作為溝通的輔助工具。例如，開會前先閱讀會議通知文件。

所以文件是一種紀錄知識以及溝通知識的媒介。

***

現在思考第二個問題：「記錄知識的方法，難到只有「文件」一途嗎？」Teddy在〈BDD（1）：詳盡的文件就是可用的軟體〉介紹過，世界上有五種儲存知識的媒介：

• DNA
• Brain
• Hardware
• Book
• Software

文件（book）只是其中一種。對軟體開發而言，產品的知識最終儲存於軟體（software）本身。如果鄉民們對於軟體開發的看法是把傳統所謂的「分析設計知識」先用文件儲存，之後再找人將這些知識「轉譯」成軟體，勢必就會遇到「知識同步」的問題—當文件與軟體不一致的時候，你要相信誰？

敏捷開發的想法很簡單：「既然可用的軟體重於詳盡的文件，而文件本身也有其價值。何不把詳盡的文件也變成可用的軟體？」如此一來，「詳盡的文件（通常以各種形式的測試案例存在）」與「最終產品（production code）」這兩種知識都是用「軟體」這個媒介來記錄。因為軟體是可以執行的，可自動驗正傳統分析設計的知識與軟體是否同步。而開發人員可以藉由閱讀測試案例與production code來理解系統。為了讓非技術人員也可以理解系統的商業邏輯，進一步可將記錄於軟體（測案案例或production code）中的知識轉成傳統一般人可以理解與閱讀的文件形式。

***

最後一個問題：「難道所有的知識都可以用軟體來記錄？」以現在的技術而言答案很顯然是否定的。例如，使用手冊、抽象的軟體架構圖，就無法或非常不容易直接由軟體產生。那怎麼辦？很簡單，就…寫文件啊。

Teddy認為敏捷開發對於文件的看法很簡單：「你覺得文件有價值，就寫。覺得沒有價值，就不用寫。」儲存知識的媒介有五種，對軟體開發而言，DNA、brain、hardware、book、software都是可利用的途徑，不必單戀一支花。

***

友藏內心獨白：我超會寫文件的。

平行關係

Oct. 18 20:35~21:40

 

這裡拜四（10月15日）在北科上「敏捷與精實軟體開發」課程，進度剛好是講解完Scrum。下課前Teddy問了學生一個問題：「Teddy（老師）和學生之間的關係，應該是上圖中的哪一種關係？」

有3位學生回答A，13位學生回答B。

Teddy自己覺得應該是B，平行關係，也就是夥伴關係。以前書的時候，指導教授就是這樣對待學生，前一陣子讀了《被討厭的勇氣》，書中也提到同樣的觀念。

***

接著Teddy告訴學生：「我講的每一句話都有可能是錯的，你們要抱持著懷疑的態度去挑戰它。」學生聽了之後有點傻眼，心裡面或許在想：「老師你講的每句話都可能是錯的，那我們還上什麼課？」。

Teddy的意思當然不是說自己上課都在胡說八道，只是希望學生能自行思考過後，再決定相信或不相信Teddy所說的觀點。如果有任何疑問，歡迎提出來討論。

可以應用在軟體開發的方法多如牛毛，很多事情沒有絕對的對或是錯，經常需要依據不同的情境（context）、遇到的問題（problem）、圍繞著問題的限制因素（force）來選取合適的解決方法。最後再觀察套用解法之後的結果（resulting context），來評估套用解決方案的成果。

在資訊發達的現代，知道各種方法並不算困難，難的地方在於知道方法之後，如何把方法吸納為己用，變成自己不可分割的一部分、如何用這些方法來解決手邊所遭遇到的問題—這就需要深入思考與自我批判的能力。

***

Teddy：例如我告訴你們我很喜歡吃大便，你們不要傻傻的也跑去吃大便。

學生甲：嗯，老師，你喜歡吃大便這句話我相信。

Teddy：那我會覺得你的判斷力非常有問題。

***

友藏內心獨白：這是嘴砲實作班嗎XD。