我降價，你背書？！

July 30 14:45~15:46

 

昨天在Facebook上看到朋友分享這則新聞〈當1千塊成了決定藝人去留的電視圈…〉，讓Teddy想起一件往事。話說許久、許久以前，有一間公司的HR打電話給Teddy，詢問企業內訓的事宜。該公司不虧為年營業額數千億的大公司，對於挑選講師有一套標準的制式流程。對方跟Teddy要了課程介紹、報價單、講師簡歷、服務過的客戶列表、以及學員的滿意度調查等資料。

在上課時間敲定之後的幾天，HR打電話給Teddy…

HR：關於課程費用的問題，想跟你商量一下。

Teddy：請說。

HR：我們主管對於上課費用有意見，因為我們公司以往內訓的費用沒有依據上課人數計費的方式，只能付給講師一個小時N元，再乘以上課的總時數來計費。我們預算有限，不知道老師你能不能配合一下。

Teddy：很抱歉，恐怕不行。

HR：我告訴你，就算是很有名的講師我們也都是這樣配合的。上次就有一個很有名的講師，來我們公司上課之後，靠著這樣的經歷在外面接到很多生意。

Teddy：對不起，我公司也要生存下去，上課必須用人數計費。

***

其實Teddy內心真正要說的話是 ：「我不需要貴公司來背書，客戶會找我，是因為我是泰迪軟體的Teddy，不是因為我曾經幫某某大公司做過企業內訓。」如果這一點都做不到，而需要靠著「因為我幫某某公司上過課，所以你們找我絕對可以放心」來做生意，那還不如把公司收起來，找一間大公司了此殘生罷了。

如果沒記錯的話，Teddy在泰迪軟體公司的網站上，從來沒有寫過「曾經幫某某公司上過課」這樣的廣告台詞，唯一一次例外是列出幫「台中家扶基金會」上過Scrum課程。因為家扶是非營利組織，Teddy收取的費用也是友情價，而且是由非IT部門來上Scrum課程，算是一次特別的經驗，所以把這段經歷列出來。

雖然是小公司，但基本的骨氣還是要有。

***

友藏內心獨白：公司大不是拿來這樣用的。

課題分離

July 29 21:25~22:25

▲Eiffel內心獨白：每天睡16個小時是我的課題

 

在Teddy念國中的那個年代，學校每個禮拜都有周會。開周會的時候全校的學生到大操場集合，聽著司令台上的長官發表告誡學生的老生常談。通常校長或是訓導主任的話最多，也最沒人想聽。當時校長說了什麼老早就忘記，唯一記得的一句話是：「自己要為自己的行為負責」。

最近讀了《被討厭的勇氣》，書中提到「課題分離」這個觀念—因為某個決定所帶來的後果需要由誰來承受，就是那個人的課題。如果我們干涉別人的課題，或是自己的課題受到他人干涉，都會引起人際關係的紛擾。

***

在〈邯鄲學Scrum〉提到，有一位擔任ScrumMaster的朋友告訴Teddy，公司希望他「看到團隊有問題不能干涉，要讓他們自己發現。開會的時候也要跟隱形人一樣退居幕後，不要主導會議的進行。」這應該是希望團隊成員可以做到自我管理（自組織），自己處理自己的課題。如果ScrumMaster介入過深，會讓團隊成員以為「這是ScrumMaster的課題，不是他們的課題」，如此一來，如同《被討厭的勇氣》所說，因為不當干涉別人的課題，造成人際關係（工作）的紛擾。

但是，任何規則都有例外。在實踐Scrum的過程中，要把「時間」這個因素放進去考量：此時此刻，團隊的能力屬於什麼樣的程度？團隊改善目標是什麼？團隊目前遭遇哪些問題阻礙他們到達目標？在這些問題中，最棘手的是什麼？要如何優先改善它？

在做到課題分離之前，是否須先建立團隊對於Scrum的信心？

***

雖然Scrum規範Product Owner、ScrumMaster、Team這三種角色的責任，但從「因為某個決定所帶來的後果需要由誰來承受，就是那個人的課題」的角度來解讀三種角色的責任，這個界線有時候存在模糊與矛盾。例如，請問story沒做完是誰的課題？理論上是Team的課題，因為團隊決定如何做、要做多久。但從公司的角度來看，Product Owner或是ScrumMaster卻可能因為「Team的課題」而被責怪。

鄉民甲：這麼說應該直接把團隊叫出來罵？

Teddy：如果你同意這是團隊的課題，請問在Scrum裡面如何面對這個課題？

鄉民甲：不知道…知道我就去當顧問了XD。

Teddy：Retrospective會議應該是一個好的場合。但是，如果這個問題持續發生，也沒有在retrospective被提出來，那應該是誰的課題？

鄉民甲：嗯，看起來團隊會被影響，但有可能是團隊根本沒有持續改善的能力，所以應該不能算在他們頭上。既然ScrumMaster的責任之一是要確保Scrum被正確落實執行，所以對於「團隊沒有持續改善的作為」這件事沒有反應，應該由ScrumMaster來承受，所以算是他的課題。

Teddy：從這個角度來看，Product Owner是否需要介入？

鄉民甲：我覺得Product Owner可以提醒，但應該交由ScrumMaster來處理，因為這是他的課題，而不是Product Owner。

***

Teddy認為課題分離和當責也有關係，該自己負的責任，絕不逃避。不是自己的課題，可以鼓勵當事者採取行動，但不要越俎代庖。

要做到課題分離真的不容易，有些人可能從小到大都習慣依賴別人幫他處理他的課題—「我要問一下我爸媽的意見、這件事要先請示主管、這隻程式不是我寫的。」又或者身為家長、主管的人，放不下心讓子女、部屬負責，因而干涉了別人的課題。

《被討厭的勇氣》是一本好書，還有許多有用的觀念，日後再逐一介紹。

***

友藏內心獨白：只有自己可以改變自己。

邯鄲學Scrum

July 28 11:30~12:50

 

有個朋友參加Scrum團隊幾個月的時間，擔任ScrumMaster的角色。有一次和他聊天…

Teddy：你們Scrum團隊最近狀況如何？

朋友：老實說，我做得很累。

Teddy：為什麼？

朋友：我覺得參加Scrum團隊之後，我好像反而不知道怎麼開發軟體了。看到團隊有問題不能干涉，要讓他們自己發現。開會的時候也要跟隱形人一樣退居幕後，不要主導會議的進行。

Teddy：這樣有什麼問題嗎？

朋友：但這樣一來公司又責怪我，說Scrum團隊的「績效」不好，開發的速度太慢。當然會慢啊，團隊成員都還在經歷「嘗試錯誤」的學習過程，公司又不希望我這個ScrumMaster「幫」團隊解決問題，要讓他們自己成長，但又不給他們成長的時間。所以我說，我都不知道要怎麼做到公司希望我扮演的角色，有點動輒得咎的感覺。這樣做也不對，那樣做又不好。

***

此時Teddy腦中浮出「邯鄲學步」這個成語，用來比喻模仿新的事物尚未成功，反倒把自己原本會的東西給忘記了。鄉民們是否也曾經有過「邯鄲學步」的經驗？

怎麼辦？其實很簡單，不要想著一步到位。朋友的公司心中有著一份理想中ScrumMaster的範本，期待朋友變身為這個理想中的範本。但「變身為理想情人」是一個努力的過程，並非像電影或電視劇中所演的那樣，揮一揮魔法棒一蹴即成。每個人「變身」的過程都不一樣，「生命自然會找到出路」。在找到出路的過程中如果過度限制或是干涉，反倒會失去自我演化（學習）的能力，變成「扮演別人眼中的理想情人」。一但干涉的外力消失，馬上就會現出原形，徒然浪費時間。

***

友藏內心獨白：邯鄲是戰國時期趙國的都城，聽說那裡的人走路特別好看。

自己的生命自己浪費

July 24 10:53~:12:15

▲自己的生命自己浪費

 

YA先生是Teddy的好朋友，三不五時會跟Teddy分享一些資訊。許久以前，有一天收到YA先生的來信，大意是說他發現「友台」有一個活動邀請了X先生，他也想在C. C. Agile聚會聽到X先生的分享。

沒想到Teddy的回信潑了YA先生一盆冷水：「你想聽X先生的分享，應該是去參加友台的活動。」後來YA先生問Teddy：「如果有客戶跟商家說他覺得某項商品很好，你們要不要也賣這樣商品？結果商家卻把客戶往外推，叫客戶去其他商店購買。有人這樣做生意的嗎？」

Teddy能力範圍之外的生意，還真的是不能做。Teddy請YA先生去參加友台的活動，不是負氣或是把「生意」往外推，而是每家店都自己專注的地方，也有自己能力不足之處。為了有效使用有限的資源，實在無法滿足所有朋友的要求。很感謝YA先生提供這樣的資訊，但要如何回應應由Teddy自己判斷，不是客戶說什麼，Teddy就照做。關於這一點，尚請見諒。

***

後來沒過多久又收到YA先生的來信，他看到某人寫了一篇談論敏捷開發的文章，文中有多處他覺得有問題的論點，想問問Teddy的看法。以下是Teddy的回信（為保護當事人，內容略加改寫XD）：

Hi YA先生，

我認為該文章的作者也許看起來懂很多，但有沒有可能這些「很多」有很大一部分是薄薄一層的理解？如你在信中提到的一個問題：「Product Owner在sprint planning meeting的時候沒有傳達為什麼要做這些需求的原因，而是從技術的角度來解釋需求。」Product Owner不應該以技術角度來思考問題，這是對Scrum錯誤的理解或實踐，而非Scrum的問題。

其他的內容我就懶得去評論了，我的生命要浪費在更有意義的地方。

謝謝。

Teddy

***

透過email聊八卦太累了，「黑特談軟工」還是面對面進行比較有感覺。Teddy的生命要浪費在更有意義的地方，陪Eiffel玩，發呆都好。對於頻率不對的人所發表的言論，點到為止即可，就不用太在意了。

***

友藏內心獨白：這一篇是因為沒料所以只好拿出來講…Orz。

尊敬與鄙視的循環

July 25 19:52~21:03

▲鄙視的姿勢 XD

 

昨天晚上失眠，到了凌晨兩點多還睡不著。在床上翻來覆去的過程中，腦中突然想到一件關於學習的事情。記得2008年剛開始參與Scrum團隊，當時覺得Scrum的設計實在是太棒了，簡單又有效，解決了傳統計畫驅動（plan-driven）專案管理的問題。藉由快速回饋，頻繁交付，持續修正團隊目標與改善作事的方法。

過了約一年後，團隊運作慢慢上軌道。這時候有點志得意滿，對Scrum的看法慢慢變成：「它也只不過是一個空的框架，很多實質的開發工作還是要依靠XP的實務作法。」對Scrum的「尊敬之心」慢慢轉變成「鄙視之情」（迷之音：沒什麼了不起、沒什麼了不起…）。

後來上了Certified ScrumMaster課程，對Scrum的看法又不太一樣，重捨當初對它的尊敬之心。「哇，原來Scrum團隊三種角設的安排有這個層面的道理，開發團隊的組成也不是隨便瞎湊合。」

又過了幾年，成立泰迪軟體之後，開始從事敏捷開發培訓與顧問服務的工作，接觸的人與團隊也不少，對Scrum又興起了「輕視之心」。「厚，這個東西都講了幾十遍了，難不成還能生出朵花來！」

在同時間，因為開設「看板方法與精實開發實作班」，花了點時間比較這兩者的異同之處。沒想到一比之下，又發現一些Scrum以前沒注意到的優點。

激情過後，歸於平淡。敏捷開發搞了10幾年，Scrum搞了8年，還有甚麼新鮮事？耶，做人就是不能鐵齒，還真的有。最近讀了《群的智慧》與《被討厭的勇氣》這兩本書，對於Scrum團隊的「自我管理」（自組織）以及ScrumMaster所扮演的角色，又有一些新的領悟。尊敬之心又油然而生。

***

鄉民甲：你有完沒完啊？！

Teddy：

do {

尊敬（）；

鄙視（）；

} while (!悟道())

***

今年六月的時候寫了〈守破離與技能模式〉，以前以為守、破、離這三個階段好像waterfall流程一樣（需求訪談、分析、設計、實作、測試、上線、維護），一個流程接著下一個流程。先是守，然後到了破，最後是離。後來覺得，整個過程應該比較像是IID（iterative and incremental development），經過多次的「尊敬」與「鄙視」的迭代（iteration），慢慢從守到破到離的過程。有時候，你以為已經到了離，但一不小心因為某種新的領悟，又被打回到守的階段。

也許，「層次」就是透過一連串的「尊敬」與「鄙視」所層層積累而成。

***

友藏內心獨白：所以要開始練習用鼻子看人？！

2015捷克、奧地利考察之旅Day7-B買木偶劇門票與The Stone Bell House

July 21 12:47~13:14

▼離開市政廳剛好接近上午11點，順便看一下天文鐘。

 

接著繞去買木偶劇的門票，有魔笛與唐喬凡尼兩齣劇。根據Kay表示Teddy的程度大概比較適合聽魔笛，但魔笛的場次很少，因為時間的關係只好選擇唐喬凡尼。

▼購票處入口。

 

▼演出時間表。

 

▼門票590克朗，約新台幣735元。沒有劃位，先來先坐。

***

▼接著來到The Stone Bell House，如下圖所示有一個鐘卡在建築物牆角。

 

▼目前是博物館，既然來了就進去參觀一下。

 

▼門票。

 

▼建築物內部也很漂亮，展出現代藝術。

***

友藏內心獨白：怎麼這麼多特別的建築物可看啊。

2015捷克、奧地利考察之旅Day7-A在Cafe EBEL吃早餐與爬舊市政廳

July 10 23:00~23:43
▼早上八點到住宿地點附近的Cafe EBEL吃早餐。雖然這是一家連鎖咖啡廳，不過咖啡和食物都滿好吃的。

 

▼面街的那面有一大片落地窗。

 

▼咖啡好喝，蛋糕也好好吃。

 

▼老店員在教新店員使用收銀機。

***

▼10點去爬舊市政廳塔樓，就在布拉格廣場旁邊，塔樓下方就是天文鐘。

 

▼舊市政廳塔樓是也很好，布拉格舊城區一覽無遺。

 

▼繞一圈塔樓，可以360看到布拉格舊城區。風有點大，所以戴上帽子。

 

▼某個房子的屋頂看起來改建成餐廳，遠眺感覺還不錯。

 

▼天氣不是很好，不過遠處城堡區還是看的見。

 

▼用垂直全景圖拍一張布拉格廣場。

***

友藏內心獨白：好美的舊城區。

朋友的部落格

July 21 20:43~11:33

▲Yves的部落格截圖

 

幾個禮拜前偶然看到Yves的一篇文章，才知道他從今年五月開始寫部落格〈敏捷進化趣 Agile FunEvo〉。不看不知道，看了嚇一跳，實在寫的太好了，Teddy都擔心自己那一天會被「幹掉」，也督促自己要好好努力，不可以偷懶XD。

Yves原本是Teddy的客戶，慢慢成為朋友。到底Yves的部落格好在哪裡？

• 有料：Yves的公司有多個Scrum團隊，對於員工的教育訓練非常重視，經常舉辦培訓課程，還找顧問來協助導入敏捷開發，有很多一手的經驗。不是看看書，打打嘴砲，紙上談兵的那種論調。
• 有趣：如果只是要找敏捷開發與Scrum的資料，在網路上與市面上的書籍很多，多到讓你想哭。但對於大部分鄉民而言，過於正規的文字敘述讀起來比較沒有感覺。Yves的文章非常在地化，用鄉民都懂的語言和巧妙的比喻，來解釋敏捷開發的觀念。例如〈別被酒店經紀打臉 – Scrum與敏捷開發的部門主管定位〉和〈快推別說風涼話啦：如何量化個別開發人員和工程師的產能〉，都很有趣（迷之音：這不是搞笑談軟工的任務嗎，怎麼最近都不好笑了…Orz）。
• 原創：Teddy每天都發表一篇文章，也看了網路上許多人寫的文章，知道寫一篇好的原創性文章是需要花很多的時間。如果部落格的內容大部分都是翻譯或是摘錄國外文章的重點，精彩度與自己將各種知識吸收後重新用自己的話敘述一遍是完全無法比擬的。

***

希望台灣有多一點這種品質的文章，不用為了看中文資料，只能引用對岸的簡體字文章。

***

友藏內心獨白：把餅做大。

【工商服務】2015年9月單元測試與持續整合實作班

July 21 09:00~10:06

 

Teddy今年遇到兩個Scrum團隊，導入Scrum半年後，在開發流程上有著很大幅度的改善。這兩個團隊有一個共同點，就是單元測試與持續整合做得很徹底。

其實不管是否導入Scrum，只要不是太小的軟體開發專案，都應該要做單元測試與持續整合。但如果導入Scrum卻沒有做好單元測試與持續整合，在缺乏測試與持續整合這道安全網的情況下，很難支撐團隊持續保有穩定的開發步驟。

***

有朋友問Teddy…

朋友：我們團隊成員不會寫單元測試也不知道如何做持續整合，怎麼辦？是不是要從測試部門找一些人來團隊內部幫忙做測試？

Teddy：恐怕找測試部門的人也沒用，因為他們大部分都做人工測試，不一定具備自動化測試的技能。

朋友：哪怎麼辦？

Teddy：很簡單啊，找我過去就可以了。

朋友：你太貴了啦。

Teddy：那就來上9月4、5日（五、六）的「單元測試與持續整合實作班」。

***

課程簡介與報名網址在此，以下為課程實錄照片。

 

***

友藏內心獨白：今年度最後一梯次課程喔。