l

2015年10月31日 星期六

2015捷克、奧地利考察之旅Day10-C到Florence巴士站探路 & 採買刺蝟筆

Sep. 24 14:21~14:50

▼遊船結束後先到明天準備搭車的Florence巴士站探路,以免明天搭巴士到維也納的時候手忙腳亂。沿著伏爾塔瓦河旁的道路走,還蠻舒服的。

螢幕截圖 2015-09-24 14.28.40螢幕截圖 2015-09-24 14.29.02螢幕截圖 2015-09-24 14.29.31螢幕截圖 2015-09-24 14.29.41螢幕截圖 2015-09-24 14.29.25螢幕截圖 2015-09-24 14.28.54螢幕截圖 2015-09-24 14.29.14螢幕截圖 2015-09-24 14.29.49螢幕截圖 2015-09-24 14.30.03

 

▼Florence巴士站就在Florence地鐵站出口不遠處,還蠻好找的。

螢幕截圖 2015-09-24 14.35.32

螢幕截圖 2015-09-24 14.35.23螢幕截圖 2015-09-24 14.35.58螢幕截圖 2015-09-24 14.36.07螢幕截圖 2015-09-24 14.36.21螢幕截圖 2015-09-24 14.36.49螢幕截圖 2015-09-24 14.36.59螢幕截圖 2015-09-24 14.36.33

 

▼Florence車站有很多售票口,不過我們已經先在網路上買好票,所以只是進來參觀一下,不用煩惱要在哪個售票口買票。

螢幕截圖 2015-09-24 14.37.19

***

▼明天就要離開捷克了,利用剩下的時間去買點紀念品。搭地鐵回到布拉格廣場,到附近的小廣場的刺蝟筆專賣店買刺蝟筆回台灣當作紀念。

螢幕截圖 2015-09-24 14.45.24

螢幕截圖 2015-09-24 14.45.01螢幕截圖 2015-09-24 14.45.08螢幕截圖 2015-09-24 14.45.17

 

▼買完先回旅館休息,途經布拉格廣場,似乎每天都有不同的活動。

螢幕截圖 2015-09-24 14.47.39

***

友藏內心獨白:不知道為什麼台灣人好像特別愛買刺蝟筆。

2015年10月30日 星期五

組織設計的Star Model(2):Strategy與Structure

Oct. 23 12:30~14:00

螢幕截圖 2015-10-21 21.24.51

▲【圖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所示。

螢幕截圖 2015-10-23 13.09.42

▲【圖2】節錄自[SLAD]

 

以產品作為組織結構的分群單位,在同一個產品之下,再區分為:

  • Requirement Area:如果產品規模很大,需要數十、數百甚至千人以上一起共同開發,第一步拓展Scrum的方式就是將開發人員切分為若干個Scrum Team(圖2中的Scrum Feature Team)。接下來會面臨一個問題:「這麼多團隊怎麼同時開發一個產品?而且Product Owner有辦法一個人應付這麼多團隊嗎?」[SLAD]建議先將產品依據requirement area(需求領域,簡稱RA)切割,然後把Scrum Team分派到各個RA裡面。針對每一個RA,指派一位Area Product Owner(APO)。一個RA最大不要超過10個Scrum Team,也就是90人左右。

舉個例子,一個超大型電子商務系統可能有產品管理、客戶關係管理、購物、物流等RA,每個RA有若干個Scrum Team來同時開發不同的end-to-end需求。

  • Undone Organization:理想上,每個sprint結束Scrum團隊需要產生一個「潛在可交付產品增量(potentially shippable product increment)」,但實際上依據產品規模不同,要做到這種程度可能需要數年到十數年以上的持續改善努力。因此很多團隊在sprint結束之後還有許多undone work(未完成的工作)—產品釋出或是佈署到production環境所需要做的事情。例如處理不屬於單一Scrum團隊的測試工作、客戶要求的文件、軟體架構文件等。這些工作可以暫時交給Undone Organization(UO)來處理,但是Scrum拓展的目標是希望藉由增強團隊的Definition of Done,有一天可以達到每個sprint都可以產出「潛在可交付產品增量」的能力,減少UO的工作,甚至消除UO。
  • Service & Support:一個跨職能的Scrum團隊自己要負責產生「潛在可交付產品增量」,但有時候組織會想要把支援工做獨立成一個Service & Support(SS)單位,讓它來服務多個團隊。例如,維護共享資源(昂貴、稀有、或數量龐大的測試設備),工具與基礎設施、協調與教練(facilitation and coaching)。

這樣的單位很顯然就是component team,也是Scrum想要避免的團隊模式。在組織SS單位需要小心專業過度集中與形成瓶頸的問題。

  • Product Owner Team:PO團隊包含一位PO、若干位APO,以及其它可以協助釐清需求的成員。

***

看到這裡對於Scrum拓展應該有個基本的認識,最後還有兩個問題:

  • 分散在不同團隊的專業人員要如何技術成長?答案是可以組成Communities of Practice(CoP),請參考〈單一職能團隊比較容易促進學習嗎?〉。
  • 會計、人資、行銷、業務等部門跑去哪裡?關於這一點[SLAD]沒提到,暫時列入待釐清問題清單之中 XD。

***

友藏內心獨白:面向客戶的組織型態。

2015年10月29日 星期四

11月【看板方法與精實開發實作班】招生中(確定開課)

Oct. 28 22:28~23:24

螢幕截圖 2015-10-28 23.20.03

▲看板桌遊

 

泰迪軟體今年度表定公開課程原本已經都結束了,這兩天剛好有一位客戶在年底要上兩門企業內訓課程,客戶也很好心允許Teddy對外招生,所以就來打個廣告。今天先介紹【看板方法與精實開發實作班】。

鄉民們可能知道現在最流行的敏捷開發方法是Scrum,那為什麼沒事還要學看板(Kanban)?

幾年前剛開始接觸看板的時候Teddy也有類似的疑問。剛開始以為因為有些專案屬於「事件驅動」類型,例如系統維護、IT營運、客戶服務,這種專案無法或是說不容易套用Scrum這種迭代式的開發方法,所以可以套用看板。後來才慢慢理解,了解看板與精實開發精神之後,對於原本敏捷開發與Scrum的用運,可以開啟另一個維度的思考與持續改善契機

也就是說,就算只是為了讓Scrum更上層樓,也很值得來了解看板方法。

***

具體來上說,看板可以應用在:

  • 幫助新創公司要管理開發流程以便快速找到市場定位
  • 協助開發團隊有效管理手上同時進行的多個專案
  • 增進Scrum團隊的敏捷性與觀察問題的能力
  • 協助擴展大型敏捷開發團隊(例如Scaled Agile Framework, SAFe)
  • 管理IT維護與營運專案的事件驅動型工作
  • 以漸進且比較無痛的方式實施敏捷開發方法
  • 透過視覺化管理工作流程以便觀察與突破工作瓶頸

 

DSC00068

▲用看板方法來解決工作上的問題。

 

本課程將透過玩遊戲的方式介紹實施看板方法的重要步驟:

  • 可視化現有工作流程為起點,先不要求團隊做出巨大的改變,以減少採用新方法的抗拒。
  • 限制在製品(Work In Progress;WIP)以協助團隊成員聚焦於「把工作完成」,而非不斷地把資源浪費在製造「賣不出去的半成品」上面。
  • 藉由管理工作流而達到持續改善的目的。

螢幕截圖 2015-04-26 21.36.24

▲課程實況照片。

***

報名網址在此:【看板方法與精實開發實作班】,2015年11月20、21日(五、六)

***

友藏內心獨白:拓展你的敏捷視野與規模。

2015年10月28日 星期三

組織設計的Star Model(1):簡介

Oct. 21 20:58~22:38

螢幕截圖 2015-10-21 21.19.33

▲【圖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,詳細介紹可參考這裡

螢幕截圖 2015-10-21 21.24.51

▲【圖2】節錄自〈The Star Model〉文章

***

Star Model的五個類別:

  • Strategy(策略):組織設計的第一個考量因素就是Strategy—公司要以何種策略贏過別人。Strategy明確指出公司的目標、價值觀與使命。Strategy會影響其他四個類別的設計方向,以協助公司達到它所設定的目標。
  • Structure(結構):組織結構決定權利與授權要分配於何處。以往看到Structure這個字總是以為它是用來決定組織的「Form(形狀)」(例如階層式、矩陣式、扁平式、分散式等組織結構),在Star Model裡面,Structure包含了:
    • Specialization:專業領域的種類與數量。
    • Shape:每一個結構階層中,組成部門的人數(也就是水平的控制範圍,能夠管多少人)。
    • Distribution of power:垂直的權利範圍,中央集權式或者是去中心化的地方分權方式。
    • Departmentalization:在每個結構層級如何產生部門。
  • Processes(流程):貫穿組織結構的資訊(information)與決策(decision)流程,包含:
    • Vertical processes:垂直流程通常含蓋業務規劃與預算流程。
    • Horizontal processes:水平流程或稱為橫向流程,則依據工作流程(workflow)而設計。例如產品開發流程、客戶服務流程、訂單管理流程、退貨流程等。
  • Rewards(獎勵):獎勵系統的目的是要將員工的目標與組織的目標結合在一起。獎勵系統包含薪資、升遷、獎金、分紅、股票選擇權等。
  • People(人):Star Model講的People是傳統的人力資源(human resource),包含招聘、選才、輪調、訓練與發展等。人員政策有助於培養組織能力,用以達成組織的策略目標。

***

先了解Star Model的內涵,之後再討論當組織進行敏捷轉型之後,如何依據這五個分類來設計與調整組織。

***

友藏內心獨白:作軟體的人本質上和作賊好像很類似。

2015年10月27日 星期二

敏捷轉型的十大組織層級阻礙

Oct. 21 15:52~16:59

擷取

▲寫作的阻礙(友藏內心獨白:好歹留一個鍵盤給我用吧!)

 

從今年初開始,慢慢接觸到幾間導入Scrum的公司,想要拓展Scrum的運用範圍,因此面臨到組織轉型的問題。例如,組織部門調整、招募、用人策略、績效考核方法、多個Scrum團隊如何共同開發一個大型產品等。以前談的內容比較侷限在單一團隊的Scrum運作,接下來的一些文章將把焦點轉移到敏捷轉型與拓展Scrum的議題。

在《Scaling Lean & Agile Development》這本書中談到了很多這方面的內容,今天先介紹書中提到造成組織轉型的十大阻礙。

  • 無法移除組織阻礙:公司有公司自己的文化,我們以前就是這樣子挺過來的啊,不需要、不可能、也不可以改變。
  • 集中式部門為了省錢與省事,導致區域最佳化:例如,工具部門規定全公司只能使用同一種工具,而不管不同開發部門、不同專案的差異性與實際需要。
  • 把學習視為一種時間與金錢的浪費:比較嚴重的公司根本沒有安排教育訓練的經費與時間,公司同仁要自費到外面上課還不能請公假。稍微好一點的,只願意把訓練課程安排在晚上或假日,然後用少少少的預算希望請到最優良的師資
  • 功能性組織(component team):阻礙溝通與學習,增加工作交接的浪費。
  • 鼓勵區域最佳化而非全域最佳化的制度:例如QA找到的bug越多績效越好(這樣一來QA還能不用顯微鏡去找麻煩嗎?)、開發人員個人的單元測試statement coverage越高越好、開發人員每天寫的程式碼行數越多越好(使出copy & paste大絕招)、員工待在公司的時間越長越好。
  • 未能從外部專家身上學習:咱大清國地大物博,什麼東西沒有?!把這些洋人送來的貢品全部退回。
  • 個人績效評估與獎勵:妨礙團隊自我組織與合作、傷害士氣(只要幹掉你我的績效就比較好)、鼓勵command-and-control管理。
  • 假裝取得共識以及不切實際的承諾:鼓勵員工走短線、累積技術債,最後導致時間都花在滅火上面。
  • 認為敏捷轉型只和開發人員有關,與我無關:不關我的事啊,我只是一個小小的品管、人資、財務、業務、行銷部門的員工而已啊。敏捷轉型與我何干?
  • 「銀子彈思維」以及膚淺的採行敏捷:Scrum/Agile這一帖藥吃下去就妥當了,只要照著做(doing agile),所有問題都可以迎刃而解。

***

這10個阻礙,相信鄉民們應該有很深的認同感。顯然公司不分國內外,遇到的問題還是很類似。先了解問題出在哪裡,接下來再想辦法慢慢打怪。

***

友藏內心獨白:打怪前要先去補充裝備,增強戰力。

2015年10月26日 星期一

為什麼不說出來?

Oct. 23 09:05~10:17

螢幕截圖 2015-10-23 10.12.53

▲不想說可以用畫的

 

有朋友問Teddy一個問題…

朋友:「我們Scrum團隊裡面有人平常私底下有許多意見,但是在retrospective的時候卻悶不吭聲,不願意公開提出他的意見。該怎麼辦?

Teddy:這個問題可以從幾個角度來看。首先,你的同事有很多意見卻又不願意公開表達,有可能是:

    • 團隊或組織缺乏透明性,成員無法公開坦率溝通。
    • 他只是發發牢騷而已,並不真的認為這是迫切需要解決的問題。
    • 根據以前的經驗,在公司的體制之下(跑Scrum之前),很多事情講了也沒用,不如不說。
    • 雖然改善之後團隊可以變得更好,但他不想公開當「壞人」。私底下講給你聽就是希望你去當這個「壞人」。

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框架(注意,是框架不是流程)。」守、破、離這三個階段,在「要守什麼都還搞不太清楚」的情況之下,就準備離了。只能說,這些公司真的非常有實驗精神。

***

友藏內心獨白:為什麼要說出來?

2015年10月25日 星期日

2015捷克、奧地利考察之旅Day10-B遊船

Sep. 23 22:50~23:28

▼吃完早餐回旅館休息,接著出發去搭船遊伏爾塔瓦河。走了好一會終於到了買票的地點,今天的第一班船,中午12點開船。

螢幕截圖 2015-09-23 22.58.31螢幕截圖 2015-09-23 23.06.18

 

▼11點半左右買到票,本來以為還很早,沒想到船上甲板已經快沒位置了。

螢幕截圖 2015-09-23 23.06.26螢幕截圖 2015-09-23 23.08.35

 

▼點了杯飲料和冰淇淋。

螢幕截圖 2015-09-23 23.06.43

 

▼開船了,從河中看兩岸風景還是有種不一樣的感受。

螢幕截圖 2015-09-23 23.11.34螢幕截圖 2015-09-23 23.12.14螢幕截圖 2015-09-23 23.11.48螢幕截圖 2015-09-23 23.12.26螢幕截圖 2015-09-23 23.12.39螢幕截圖 2015-09-23 23.12.54螢幕截圖 2015-09-23 23.13.02螢幕截圖 2015-09-23 23.13.11螢幕截圖 2015-09-23 23.13.33螢幕截圖 2015-09-23 23.13.40螢幕截圖 2015-09-23 23.14.55螢幕截圖 2015-09-23 23.15.05螢幕截圖 2015-09-23 23.15.24螢幕截圖 2015-09-23 23.17.11螢幕截圖 2015-09-23 23.17.38

 

▼別艘船上可愛的小朋友。

螢幕截圖 2015-09-23 23.16.08

 

▼從船上看查理大橋。

螢幕截圖 2015-09-23 23.14.17螢幕截圖 2015-09-23 23.14.27

 

▼穿越查理大橋時,橋上的遊客。

螢幕截圖 2015-09-23 23.16.56


***

友藏內心獨白:搭船要早點去卡位啊。