Sep. 24 14:21~14:50
▼遊船結束後先到明天準備搭車的Florence巴士站探路，以免明天搭巴士到維也納的時候手忙腳亂。沿著伏爾塔瓦河旁的道路走，還蠻舒服的。
▼Florence巴士站就在Florence地鐵站出口不遠處，還蠻好找的。
▼Florence車站有很多售票口，不過我們已經先在網路上買好票，所以只是進來參觀一下，不用煩惱要在哪個售票口買票。
***
▼明天就要離開捷克了，利用剩下的時間去買點紀念品。搭地鐵回到布拉格廣場，到附近的小廣場的刺蝟筆專賣店買刺蝟筆回台灣當作紀念。
▼買完先回旅館休息，途經布拉格廣場，似乎每天都有不同的活動。
***
友藏內心獨白：不知道為什麼台灣人好像特別愛買刺蝟筆。
Oct. 23 12:30~14:00
▲【圖1】節錄自〈The Star Model〉文章
上一集介紹Star Model的五個分類，接下來幾篇文章參考《Scaling Lean & Agile Development，簡稱［SLAD］》把Scrum放到Star Model來討論，看看在組織中拓展Scrum（以及敏捷開發）需要考量哪些因素。
依據戴明（Deming）的看法：「公司需要建立朝向產品與服務改善的一致性目標，其目的在於讓公司具備競爭力並可持續留在業界。」這句話剛好和《Management 3.0》書中對於敏捷的定義有異曲同工之妙：
敏捷就是關於如何在不斷變化的環境中保持成功。
因為討論敏捷拓展，所以直接把企業的strategy指定為：敏捷力（agility）也是很自然的一件事XD。在讓企業具備敏捷力的這個策略之下，企業組織要如何跟隨著調整？
***
Scrum本來就建議組成「跨職能」、「自組織」、「持續產品開發模式」的5~9人小團隊，將這個基本架構拓展到整個組織：［SLAD］建議組織產品群組結構（product group structure），如圖2所示。
▲【圖2】節錄自［SLAD］
以產品作為組織結構的分群單位，在同一個產品之下，再區分為：
舉個例子，一個超大型電子商務系統可能有產品管理、客戶關係管理、購物、物流等RA，每個RA有若干個Scrum Team來同時開發不同的end-to-end需求。
這樣的單位很顯然就是component team，也是Scrum想要避免的團隊模式。在組織SS單位需要小心專業過度集中與形成瓶頸的問題。
***
看到這裡對於Scrum拓展應該有個基本的認識，最後還有兩個問題：
***
友藏內心獨白：面向客戶的組織型態。
Oct. 28 22:28~23:24
▲看板桌遊
泰迪軟體今年度表定公開課程原本已經都結束了，這兩天剛好有一位客戶在年底要上兩門企業內訓課程，客戶也很好心允許Teddy對外招生，所以就來打個廣告。今天先介紹【看板方法與精實開發實作班】。
鄉民們可能知道現在最流行的敏捷開發方法是Scrum，那為什麼沒事還要學看板（Kanban）？
幾年前剛開始接觸看板的時候Teddy也有類似的疑問。剛開始以為因為有些專案屬於「事件驅動」類型，例如系統維護、IT營運、客戶服務，這種專案無法或是說不容易套用Scrum這種迭代式的開發方法，所以可以套用看板。後來才慢慢理解，了解看板與精實開發精神之後，對於原本敏捷開發與Scrum的用運，可以開啟另一個維度的思考與持續改善契機。
也就是說，就算只是為了讓Scrum更上層樓，也很值得來了解看板方法。
***
具體來上說，看板可以應用在：
▲用看板方法來解決工作上的問題。
本課程將透過玩遊戲的方式介紹實施看板方法的重要步驟：
▲課程實況照片。
***
報名網址在此：【看板方法與精實開發實作班】，2015年11月20、21日（五、六）。
***
友藏內心獨白：拓展你的敏捷視野與規模。
Oct. 21 20:58~22:38
▲【圖1】節錄自《Scaling Lean & Agile Development》
昨天介紹《Scaling Lean & Agile Development》書中提到的組織轉型十大阻礙，接下來幾集介紹書中引用的一個組織設計模型：Star Model。這個模型是由Jay Galbraith在1960年代所發展的，可以作為組織設計的參考。如【圖1】所示，書中介紹的Star Model由Strategy開始，接著影響Task、Structure、Processes、Rewards、People這五個類別。這是比較早期的Star Model，後來的模型拿掉了Task，直接由Strategy開始。【圖2】為最新的Star Model，詳細介紹可參考這裡。
▲【圖2】節錄自〈The Star Model〉文章
***
Star Model的五個類別：
***
先了解Star Model的內涵，之後再討論當組織進行敏捷轉型之後，如何依據這五個分類來設計與調整組織。
***
友藏內心獨白：作軟體的人本質上和作賊好像很類似。
Oct. 21 15:52~16:59
▲寫作的阻礙（友藏內心獨白：好歹留一個鍵盤給我用吧！）
從今年初開始，慢慢接觸到幾間導入Scrum的公司，想要拓展Scrum的運用範圍，因此面臨到組織轉型的問題。例如，組織部門調整、招募、用人策略、績效考核方法、多個Scrum團隊如何共同開發一個大型產品等。以前談的內容比較侷限在單一團隊的Scrum運作，接下來的一些文章將把焦點轉移到敏捷轉型與拓展Scrum的議題。
在《Scaling Lean & Agile Development》這本書中談到了很多這方面的內容，今天先介紹書中提到造成組織轉型的十大阻礙。
***
這10個阻礙，相信鄉民們應該有很深的認同感。顯然公司不分國內外，遇到的問題還是很類似。先了解問題出在哪裡，接下來再想辦法慢慢打怪。
***
友藏內心獨白：打怪前要先去補充裝備，增強戰力。
Oct. 23 09:05~10:17
▲不想說可以用畫的
有朋友問Teddy一個問題…
朋友：「我們Scrum團隊裡面有人平常私底下有許多意見，但是在retrospective的時候卻悶不吭聲，不願意公開提出他的意見。該怎麼辦？」
Teddy：這個問題可以從幾個角度來看。首先，你的同事有很多意見卻又不願意公開表達，有可能是：
Teddy：退一萬步想，如果有人已經發掘問題卻不願意表達，那很抱歉他自己就要承擔這樣的後果。Scrum團隊是自組織的團隊，但也許大家還是習慣於command-and-control（一個口令，一個動作）的工作模式，期待有一位英明神武的主管出來拯救他們。
***
和朋友繼續深聊才發現，原來他們目前只是「擷取」Scrum若干元素，並不是真正的Scrum。例如，他們的團隊只是把原本「一個人負責一個元件（component）的單人component team」集合到同一個團隊中，這些團隊成員雖然一起開sprint planning meeting，每天都會Daily Scrum，sprint結束也都有舉辦review與retrospective，但是他們的工作模式還是各做各的。他們的出發點是，因為目前組織上的限制無法組成真正的Scrum團隊，因此先把原本單人component team湊在一起，希望藉由Scrum框架所設計的活動，有一天讓這些人可以變成一個真正的Scrum團隊。團隊成員的工作，還是在sprint planning meeting的時候透過某人指派下來，並不是由團隊成員自行決定如何合作完成。
後來因故被中斷，就沒有繼續跟朋友談下去。Teddy認識不少人都想要「創造屬於自己公司特色的Scrum」，雖說Scrum是一種流程框架（請參考〈流程與流程框架〉），每個組織可以產生屬於自己的流程，但你不能一開始就把「流程框架本身」給改變了啊。Scrum的開發團隊有三個特性：
Teddy的朋友組成了跨職能團隊，但這是一個command-and-control的跨職能團隊，並非自組織的跨職能團隊。組成團隊的基本要求都沒有做到，怎麼可能期望Scrum設計的活動可以發揮原本宣傳的藥效呢。
***
有時候遇到一些客戶，不管公司大小，都有老闆想要「創造屬於自己公司的Scrum框架（注意，是框架不是流程）。」守、破、離這三個階段，在「要守什麼都還搞不太清楚」的情況之下，就準備離了。只能說，這些公司真的非常有實驗精神。
***
友藏內心獨白：為什麼要說出來？
Sep. 23 22:50~23:28
▼吃完早餐回旅館休息，接著出發去搭船遊伏爾塔瓦河。走了好一會終於到了買票的地點，今天的第一班船，中午12點開船。
▼11點半左右買到票，本來以為還很早，沒想到船上甲板已經快沒位置了。
▼點了杯飲料和冰淇淋。
▼開船了，從河中看兩岸風景還是有種不一樣的感受。
▼別艘船上可愛的小朋友。
▼從船上看查理大橋。
▼穿越查理大橋時，橋上的遊客。
***
友藏內心獨白：搭船要早點去卡位啊。
