l

2019年1月15日 星期二

Product Owner 的存在

Jan. 15 12:48~14:33

螢幕截圖 2019-01-15 14.20.44

▲擁有就要負責,不要製造流浪產品。


作為解決方案

Product Owner(產品擁有者、產品負責人)這個角色接近傳統專案的產品經理或專案經理,雖然傳統專案沒有這個角色,但Product Owner目的與責任並不難理解。畢竟不管瀑布式專案或敏捷專案,總是要有人來管理需求與規劃產品藍圖,

依據中文版Scrum Guide對於Product Owner的說明:

螢幕截圖 2019-01-15 12.53.12

由此可看出Product Owner藉由管理Product Backlog將產品價值最大化,其他文字敘述則是進一步解釋Product Owner這個角色如何達到此目的常見做法,也就是對Product Owner這個解決方案的詳細說明。

***

解決什麼問題

如果Product Owner是一種解決方案(Solution),請問他要解決的問題是什麼?

從Scrum Guide的敘述,Product Owner要解決的問題有三種可能的表達方式:

Problem 1:如何最大化產品價值?

Problem 2:如何管理Product Backlog?

Problem 3:如何管理Product Backlog以最大化產品價值?

Solution:指派一位Product Owner來負責。

***

Product Owner Pattern對於Product Owner的描敘則是:

One person needs to be responsible for the Product Backlog. This person needs deep domain knowledge, business insight, understanding of product technology, technical dependencies, and the authority to force rank the backlog to maximize business value.

(一個人需要負責產品Backlog。 此人需要深入的領域知識、商業洞察力、對產品技術的理解、技術相依性,以及排序代辦事項以最大化商業價值的權限。)

依據Product Owner Pattern的描述,可以將Product Owner要解決的問題寫成:

Problem:如何管理Product Backlog?

Solution:指派一位Product Owner來負責。

***

Product Owner的難題

指派一個人當任Product Owner,透過排序product backlog item (產品待辦事項)來最大化產品的商業價值,即時且持續的交付高價值的產品給客戶,聽起來是多麼理想與合理的一件事。但實務上,好的Product Owner也是很難找。

Product Owner經常遇到以下難題:

  • 未被授權:既然Product Owner「擁有產品」,就應該被公司充分授權,才能夠對產品的成敗負責。但實務上,Teddy遇到不少「有名無實」的Product Owner,只是老闆的代理人,大部分團隊提出的問題都無法當場回覆而必須回頭問老闆。遺憾的是,老闆又很忙,無法及時與Product Owner討論,導致整個團隊溝通非常不順,也很容易造成大量的重工(等產品做好之後老闆看到才說這不是他要的)。
  • 沒有主見,不願承擔:也有不少Product Owner雖然獲得公司充分授權,但他卻不敢也不想承擔「做決策」的風險。這種Product Owner的口頭禪就是:「由團隊決定、都可以、這個需要再研究。」甚至把做決定的工作「外包」給其他單位,以便到時候萬一產品失敗,可以有人一起承擔「歷史共業」。

 沒有主見或不願承擔,也有可能代表Product Owner 對於產品領域知識不足,也缺乏產品的熱忱。

  • 進度壓力無處發洩:依據Scrum框架,Product Owner決定What(做什麼),開發團隊決定How(怎麼做、做多久)。換句話說,完成每一個功能所需的時間是由開發團隊所決定,Product Owner必須尊重。

在傳統的專案開發中,如果產品經理或主管對於開發團隊的進度不滿意,大體脫不了痛罵一頓與祭出激勵手段(棍子與胡蘿蔔策略),最後再要求員工 強迫 自願加班。但採行Scrum之後,Product Owner突然失去「自願加班」這個萬用工具,當他覺得進度落後時,自然會產生焦慮感,然後將此種壓力用明示或暗示的方法轉嫁到開發團隊身上。久而久之Product Owner與開發團隊彼此看不順眼,互相抱怨。

***

熱情與看法

Teddy始終相信,如果你對於產品沒有熱情,就不要擔任該產品的Product Owner。就好像如果你不喜歡貓,就不要貿然的學人家養貓。你可以養狗、養鳥、養烏龜、養兔子、養小孩,甚至什麼都不養。

有熱情,才會想方設法把產品做好。熱情可能來自先天對於產品的喜愛,例如有些人天生就熱愛玩Game。熱情也可能來自後天的訓練,例如你原本不喜歡玩Game,但為了生活從事遊戲開發若干年後,慢慢地愛上玩Game。

對事情有熱情,就會慢慢培養出「職業達人」的堅持。自己對於產品有看法,才不會人云亦云,做出有特色的產品。

***

友藏內心獨白:不要製造流浪產品。

2019年1月14日 星期一

Scrum Master 的存在

Jan. 14 10:52~12:48

螢幕截圖 2019-01-14 12.46.52

▲泰國清萊的白廟,過橋後到達天堂不可走回頭路


作為解決方案

對於初次接觸Scrum的朋友,Scrum Master這個角色是一個不容易理解的存在。依據中文版Scrum Guide對於Scrum Master的說明:

螢幕截圖 2019-01-14 10.53.19

由此可看出Scrum Master負責推廣與支持Scrum。其他部分的文字敘述都是在進一步解釋Scrum Master這個角色如何達到「推廣與支持Scrum」的細部做法,包含Scrum Guide文件後續提到Scrum Master分別對於Product Owner、開發團隊與組織所提供的各種服務都是針對Scrum Master這個解決方案的描述。

作為一種解決方案,接觸過Scrum的鄉民多多少少可以講出Scrum Master是:

  • 牧羊犬,保護開發團隊不受大野狼(外部因素)干擾
  • 流程專家
  • 敏捷教練
  • 敏捷轉型引導者
  • 僕人式領導

***

解決什麼問題

如果Scrum Master是一種解決方案(Solution),請問他要解決的問題是什麼?

從Scrum Guide的敘述,可以將Scrum Master要解決的問題寫成:

Problem:如何推廣與支持Scrum?

Solution:指派一位Scrum Master來負責。

***


ScrumMaster Pattern中針對Scrum Master的解決的問題有一個較精確地描述:
Development Teams, Product Owners, and organizations cannot get the benefits of Scrum without deep understanding and application of its principles and values.

(如果沒有深入理解和應用其原則和價值觀,開發團隊、產品擁有者和組織就無法獲得Scrum的好處。)

依據ScrumMaster Pattern的描述,可以將Scrum Master要解決的問題寫成:

Problem:如何讓開發團隊、產品擁有者和組織獲得Scrum的好處

Solution:指派一位Scrum Master來負責。

***

是否需要專職的Scrum Master

在台灣,Teddy遇到不少剛導入Scrum的團隊面臨到沒有專職Scrum Master的困境。其原因不外乎人手不夠、老闆不同意有一個專職的人每天無所事事不用寫程式,只負責「流程改善」這種虛無飄渺的工作

依據Scrum框架,每個Scrum團隊都需要一位專職的Scrum Master。理由之前已經說明過了,就是「要讓開發團隊、產品擁有者、組織獲得Scrum的好處」。

如果你的團隊不需要Scrum Master也可以「獲得Scrum的好處」,那當然可以不需要這個專職的角色,畢竟Scrum Master只是「如何讓要讓開發團隊、產品擁有者、組織獲得Scrum好處?」這個問題的一種解決方案,團隊可以自行探索其他可能的解決方案。

《金剛經》中講過:「汝等比丘,知我說法,如筏喻者,法尚應舍,何況非法。」Scrum Master只是幫助團隊到達敏捷彼岸的一種媒介,正所謂「過河拆橋」,到達彼岸之後橋就用不到了,可以把Scrum Master丟掉XD。

但是,就是因為產品擁有者、開發團隊與組織都不懂Scrum,尚未獲得Scrum的好處,才需要「導入Scrum」。既然決定要導入Scrum,安排合適的專職Scrum Master,減少敏捷轉型過程的碰撞並提高成功機會,這一點點的投資也是很合理的。

***

友藏內心獨白:不要落入「省小錢、花大錢」的陷阱。

2019年1月11日 星期五

我想用Scala

Jan. 11 8:34~9:21

螢幕截圖 2019-01-11 09.14.04


數年前Teddy帶幾個學弟開發一個系統,討論完需求後,學弟A建議採用Scala語言。

雖然Scala同時具備物件導向語言與函數導向語言的優點,但在當時Scala還是一個相當新的語言,採用的專案不多,會的人更少。Teddy擔心除了學弟A以外,Teddy自己與其他團隊成員還需要時間學習Scala,可能會模糊專案目標並且影響開發時程。另外,萬一學弟們畢業後,日後系統維護找不到懂Scala的人也是一個問題。再加上使用新語言雖然很酷,但新語言通常有很多「雷」等著不怕死的人去清除。為了 怕麻煩 降低專案風險,於是Teddy建議學弟還是保守一點,用實驗室最熟悉的Java語言來開發這個系統。

多年後函數語言已融入主流的物件導向語言之中,物件與函數的「混搭風」成為主流的開發模式。不知怎麼的幾天前突然想起多年前的這個故事,驚覺到隨著年齡增長,年輕時的冒險犯難精神不知道消失到哪裡了

年輕時剛出社會寫程式,剛好趕上第一波網際網路大爆發時代,Java、Java Applet、JavaScript、HTTP、HTML,這些當年的「新技術」在學校完全沒學過(學校教的是Pascal、C/C++、Fortran、組合語言),但工作上就是要用到,怎麼辦?沒怎麼辦,做中學就是了,專案需要用到什麼技術,就去學什麼技術。當時雖然開發軟體的經驗不足,但企圖心與衝勁十足

***

N年後,多做了一些專案、多讀了一點書,也多了一層鮪魚肚,漸漸補足了當年缺少的軟體開發與軟體生命週期管理的經驗。但隨著手中抓住的東西越多,很多時候反倒捨不得打破現況,去追求那些最新的、風險最高的新東西。

高風險通常伴隨著高失敗率與高收益。人在年輕時應該找機會多冒險、多累積失敗經驗,從失敗中學習。公司也是,特別是新創公司。

那年紀大了怎麼辦!?只能不斷提醒自己:「取捨風險與利益,不要事事都打安全牌,也不要變成自己年輕時所討厭的老屁股XD」。或者,變成支持年輕人去冒險犯難的老人,也是一種不錯的選擇。

***

友藏內心獨白:快速失敗,不斷學習。

2018年11月21日 星期三

泰迪軟體2019年上半年開課時間表

November 21 12:00~14:23

螢幕截圖 2018-11-21 09.56.20

▲Scrum敏捷方法實作班課程照片


時間過得好快轉眼就要跟2018說Bye Bye,又到了年底排課表的時間。以下是泰迪軟體2019年上半年課表,提供給鄉民們參考。2018年的新課程「敏捷開發懶人包:Clean Architecture嘴砲班」在明年將改版為兩天的「Clean Architecture實作班」,打嘴砲之餘也要不忘動手寫程式。


Scrum敏捷方法實作班

  • 假日班:1月26、27號(六、日)。
  • 假日班:4月28、29號(六、日)。

看板方法與精實開發實作班

  • 假日班:1月19、20號(六、日)

Design Patterns這樣學就會了--入門實作班

  • 假日班:3月9、10、16號(六、日、六)。

    Design Patterns這樣學就會了--進階實作班

    • 假日班:5月3、4、5號(五、六、日)。

    敏捷開發懶人包:物件導向技能

    • 假日班:1月12(六)。
    • 假日班:5月18(六)。

    Clean Architecture實作班

    • 平假日班:4月19、20號(五、六)。

    單元測試實作班

    • 假日班:2月23、24號(六、日)。
    • 假日班:5月25、26號(六、日)。

    例外處理設計與重構實作班

    • 假日班:6月1、2號(六、日)。

      軟體重構入門實作班

      • 假日班:3月22、23、24號(五、六、日)


      ▼看板方法與精實開發實作班課程照片

      螢幕截圖 2017-12-12 10.08.45


      ▼「單元測試實作班」課程照片。

      螢幕截圖 2017-12-12 10.14.10螢幕截圖 2017-12-12 10.15.07

      螢幕截圖 2017-12-12 10.15.26螢幕截圖 2017-12-12 10.15.51螢幕截圖 2017-12-12 10.16.10

      ▼「敏捷開發懶人包:物件導向技能」課程照片。

      螢幕截圖 2017-12-12 10.11.38

      ***

      友藏內心獨白:2019年也要繼續努力。

      2018年10月24日 星期三

      此流程非彼流程

      Oct. 24 22:14~23:07

      螢幕截圖 2018-10-24 23.07.10

      ▲工作中的阻礙


      幾年前有一次機會參加一個行政團隊的sprint review與retrospective會議。這個團隊剛開始接觸Scrum,他們對於Scrum的理解是由公司內上過Scrum課程的同仁所傳授。在review會議中,同仁甲展示他的工作成果—召募新人流程。他將這個流程視覺化,並比較舊有招募流程與新流程的差異。

      Product Owner對於這個展示沒說什麼,倒是Scrum Master問了很多問題。Scrum Master以前是行政部門主管,跑Scrum之後轉為Scrum Master。

      ***

      Review結束之後,在retrospective會議Scrum Master請團隊成員各說出三個好的與三個有待改善的項目。

      同仁甲:我覺得Scrum Master要求我們將自己工作流程視覺化這一點很好,讓我比較容易看出現有流程有問題的地方。有待改善的地方就是關於校園招募這部分,我覺得吸引學生來填寫資料的誘因還不夠,這部分的流程以後還可以加強。

      就在每位同仁都發表意見之後,Scrum Master請Teddy提供一些建議。

      Teddy:我想請問你們知道retrospective會議的目的是什麼嗎?

      Scrum Master:知道啊,就是流程改善啊,讓我們可以越做越好。

      Teddy:你說的沒錯。請問各位同仁,你們剛剛所提出Good與Improvement的項目,是屬於需求面的改善,還是流程面的改善?

      此時安靜了幾秒,大家你看我,我看你,對於Teddy所提出的疑問,大家一臉黑人問號的感覺。

      Scrum Master:我不懂你的問題,我們剛剛提出來的的確是流程的改善。像是同仁甲就很明確提出他在校園招募流程方面的改善建議。

      Teddy:同仁甲,請問您的主要工作是什麼?

      同仁甲:我負責招募與其他人事方面的工作。

      Teddy:所以新人招募是你提供的服務,對嗎?

      同仁甲:這是我的工作,要說是我提供的服務也可以。

      Teddy:你們是行政團隊,不像開發團隊需要寫程式,做出可動的軟體。你們所提供的「服務」就是你們的user story

      Scrum Master:所以你是說,我們剛剛都在討論「需求的改善」?

      Teddy:沒錯。

      同仁甲:可是我們討論的明明是「流程改善」啊,以我來說,我談的是招募流程改善。

      Scrum Master:啊,我知道了。我們實作的「需求」,是對公司提供某種服務。我們討論的都是這些服務的流程,就好像軟體功能怎麼被使用的流程一樣,這是屬於需求的範疇。

      Teddy:沒錯。

      Scrum Master:我還是有一點不明白,retrospective所謂的流程改善,是什麼流程?

      Teddy:是團隊合作的流程,有什麼阻礙存在,讓團隊無法更快、更好的交付價值給客戶。

      Scrum Master:可以舉個例子嗎?

      Teddy:例如,我觀察到你們每個人所負責的工作彼此獨立,無法互相幫忙。這對你們來說會是一個問題嗎?如果有同仁請長假,他所負責的工作會不會無法進行?你們在提供服務的時候有沒有遇到什麼阻礙?是否很清楚用人單位的需求?會不會經常發生找到人被RD打搶等等問題。

      Scrum Master:如果撇開Scrum不談,難道我們不能找時間討論我們提供服務的流程嗎?為什麼要侷限在retrospective所規範的活動範圍?

      Teddy:團隊當然需要時間來討論供服務的流程,也就是你們團隊的需求。在Scrum框架中,你們可以在product backlog refinement workshop討論,也可以在sprint planning討論,但不適合在retrospective討論。

      Scrum Master:可是我就是不想被框架限制住啊。

      Teddy:你會在告別式的時候包紅包嗎?

      Scrum Master:啊?當然不會啊,我沒那麼白目。

      Teddy:那你為什麼要在retrospective討論需求改善呢?如果你在這個活動討論需求,請問你要在什麼活動討論「工作流程改善」?Sprint planning嗎?不會吧。

      Scrum Master:是不會啦…

      ***

      友藏內心獨白:先學會走再看看要怎麼飛。

      2018年10月22日 星期一

      Scrum Master的兩個魔咒

      Oct. 22 13:21~14:20

      螢幕截圖 2018-10-22 14.18.00

      ▲兩個搗蛋鬼


      Scrum「大濕」

      對於Scrum而言,Scrum Master是一個很神奇的存在。正所謂「好的Scrum Master讓你上天堂,不好的Scrum Master讓你住套房」。這個角色似乎成為Scrum成敗的關鍵因素,理論上你的Product Owner和開發團隊甚至整個公司一開始很爛都沒關係,在Scrum Master的輔助之下,透過持續改善的過程,Product Owner和開發團隊的不足之處都可以慢慢地變好。

      理論上…

      ***

      自組織魔咒

      Scrum的開發團隊是自組織團隊(請參考〈自組織〉),因此有些Scrum Master會採取所謂的「主動不做任何事」的模式,從旁觀察團隊。當團隊遭遇問題時讓團隊成員自行解決,既使解決的過程產生各種大大小小的失敗也視為學習所需付出的必要成本,Scrum Master儘量不要跳出來幫團隊解決問題。

      這一招對於已經具備「自我餵食」能力的團隊成員可能會很有效,但如果團隊成員尚未具備「自我覓食」能力之前就貿然將其放生,最後結果可能不是放生而是放死。從生物的角度來難,當個體還屬於幼年時期,需要的是更多父母親的照顧,然後在個體成長的過程中慢慢培養自組織的能力。

      曾經有朋友告訴Teddy,他離開Scrum團隊的原因居然是因為看不慣Scrum Master主動不做任何事的行事風格。團隊也想要自組織、靠自己的力量排除阻礙,但問題是團隊目前就是無能(尚未具備此能力),都跟你發出求救訊號你還置之不理,身為Scrum Master總不能只靠主動不做任何事這一招打通關吧?!

      ***

      寶媽魔咒

      為了讓團隊運作順暢,impediment removal(阻礙排除)佔了Scrum Master最多時間,這種情況在初導入Scrum的團隊中特別明顯。

      屏幕截图 2017-05-11 01.46.58

      ▲節錄自《Essential Scrum》,


      雖說Scrum Master需要幫助排除阻礙,但幫助不等於自己動手做,而是讓團隊具備自己排除阻礙的能力。有些過於積極與熱心的Scrum Master可能會認為處在「幼年期」的團隊尚未具備「自我覓食」的能力,如果放任他們自生自滅,將會落入自組織魔咒而無法自拔。因此Scrum Master開始扮演一位認真的新手媽媽,對孩子照顧的無微不至。

      在不知不覺中,團隊只要遇到無法解決的問題全部丟給Scrum Master幫忙處理,久而久之Scrum Master變成寶媽,而團隊成員則變成了媽寶。

      Teddy認識一位技術很強的Scrum Master,在團隊剛導入Scrum時扮演寶媽的角色,自己動手幫助團隊解決幾個關鍵的技術問題,讓團隊在導入Scrum初期,在兵荒馬亂的過程中增加關鍵穩定軍心的助力。而在團隊熟悉敏捷開發精神與Scrum框架之後,慢慢淡出舞台,切換到主動不做任何事的模式。

      ***

      沒有一定的形狀

      好的Scrum Master,沒有一定的樣子。不要看到別人主動不做任何事,以為回家後照做就會成功。別人的Context與你的Context不一樣,無腦照抄解決方案,到時候失敗再來哭哭討拍,抱怨Scrum不適合台灣人乃至整個亞洲人的特殊體質。

      套句PPT上鄉民常說的一句話:「正妹不是不給約,而是不給你約」。反思一下,這是正妹(方法)的問題呢,還是自己(團隊)的問題。

      ***

      友藏內心獨白:要先確定是不是正妹。

      2018年10月17日 星期三

      增進學習力的三個練習

      Oct. 17 22:13~22:47

      螢幕截圖 2018-10-17 22.09.28


      Teddy在北科上課時經常指定學生回家閱讀教科書或技術文章當作家庭作業,隔週上課再討論閱讀內容。大部分的學生並不擅長抓住內容的重點,閱讀經常只停留在字面上的涵義。

      Teddy不是什麼閱讀專家,但多年來發覺把握以下三個重點,可以幫助自己在閱讀技術文章時看到不同層次的問題,也可以提升自己的「教學力」。

      • 1. 定義:對於重要的名詞或概念,能否用簡潔的字句說出它的定義?例如,試著說出以下名詞的定義:多型(polymorphism)、迭代與增量(IID)、敏捷、Scrum、軟體架構、設計模式。
      • 2. 比喻:能否用一般人聽得懂的方式說明重要的名詞或概念?例如,用下圖的磨豆漿來解釋迭代與增量就比較容易讓鄉民們理解。

      螢幕截圖 2018-10-17 22.29.34

      ▲圖片節錄自 https://goo.gl/YgiMyr


      • 3. 找問題:名詞或概念通常代表某種產品或解決方案,也就是建築師Alexander所說的Form。學了一堆名詞與解決方案,如果不知道它們用來解決什麼問題,很容易發生吃錯藥的情況。就好像學了一堆design patterns但卻不知道每一個pattern要解決什麼問題,所以就很容易誤用pattern。

      有一個很簡單的自問自答練習,可以幫助自己發覺名詞與解決方案背後所要解決的問題是什麼。只要問自己:

      If X is the solution, what is the problem?

      例如:

      • If polymorphism is the solution, what is the problem?
      • If IID is the solution, what is the problem?
      • If Agile is the solution, what is the problem?
      • If Scrum is the solution, what is the problem?
      • If software architecture is the solution, what is the problem?
      • If the design pattern is the solution, what is the problem?

      ***

      只要把握住這三個簡單的重點,相信可以把技術文章看得比別人更透徹。

      ***

      友藏內心獨白:桌子要解決什麼問題?