l

2015年9月30日 星期三

管理者在Scrum中扮演的角色(4):管理價值創造流

Sep. 24 16:30~17:34

螢幕截圖 2015-09-24 23.32.56

▲要觀看全局。

 

《Essential Scrum》提到管理者的第四個也是最後一個責任是管理價值創造流(managing value-creation flow),其中包含了:

  • 採取系統觀點:要有效管理創造價值的工作流,管理者必須要綜觀全局,採用系統性(全面性)的觀點,以避免做出「局部最佳化」的錯誤決定,反倒傷害了整體的價值流。這一點對於部門主管來說,有時並不容易做到,因為人總是習慣以自己的立場來看待問題。例如,開發部門主管的觀點,肯定與測試部門主管有很大的差異。敏捷組織的管理者,要學習與適應從系統性的觀點來看待問題,如果改變對整個系統是好的,就算有時候會看起來犧牲自己部門的利益,但從公司的角度來看,這樣的改變應該要給予支持。
  • 管理經濟狀況:跟「錢」有關的議題,不只是〈Product Owner的責任〉,也是〈XP的原則〉之一,和管理者當然也有關係。軟體開發本質上就是一種經濟活動,在Scrum組織內的高階管理者,要留意他們所負責領域之內的獲利狀況。在討論是否支持或終止一個產品或專案的開發活動時,管理者也需要從經濟的角度出發,提供建言。
  • 監控度量與報表:訂定度量指標與觀看報表是許多傳統組織管理者的責任,在敏捷組織中一樣存在,只是度量指標有所不同。管理者應注意閒置工作而非閒置人員、以真正完成的工作來測量進度(所以DoD很重要)、管理工作流以便快速獲得回饋。

***

看完這一系列四集的文章,可以發現敏捷組織的管理者與傳統組織一樣,還是肩負著許多「管理」的責任,只是這些責任的內容與實踐方式有所不同。另外,管理者是應該是ScrumMaster的好朋友外加背後支持的力量,缺少管理者的協助,ScrumMaster恐怕很難獨自排除組織層面的阻礙。最後,敏捷組織的管理者也是引導敏捷變革的重要一份子,必須對敏捷精神有深入的理解,協助組織克服變革過程所遭遇的問題。

***

友藏內心獨白:這算隱藏版的ScrumMaster嗎XD。

2015年9月29日 星期二

管理者在Scrum中扮演的角色(3):調整與適應環境

Sep. 23 14:40~16:15

螢幕截圖 2015-09-23 16.28.45

敏捷宣言

 

《Essential Scrum》提到管理者的第三個責任是調整與適應環境(aligning and adapting the environment),其中包含了:

  • 提倡敏捷價值:在單獨小團隊中導入Scrum是一個好的開始,但如果可以把Scrum推廣到整個產品開發價值流的每個階段,才可以發揮Scrum的全部好處。要做的這一點,管理者就必須扮演主動推廣的角色。管理者自己要清楚敏捷開發與Scrum的精神,首先不要讓自己成為「絆腳石」(OK,你說的我都了解,但是我們公司狀況特殊,所以…)。更進一步,協助敏捷開發與Scrum在公司內部的推廣與發散。
  • 排除組織層面的阻礙:這個責任雖然是ScrumMaster的工作,但沒有管理者的協助,ScrumMaster很難獨自做好這個工作。畢竟很多組織的溝通管道,多多少少還是會依循著「組織表」的階層關係。 例如,團隊遭遇到持續整合速度太慢的問題,需要組建一個持續整合農場(CI Farm),要花一筆錢去購買機器。這個時候會計部門告訴你今年沒有編列這筆預算,明年請早,就算ScrumMaster每天跑去會計部門 丟雞蛋 溝通可能也沒什麼效果。這時候如果請部門主管出來協調與爭取,效果通常會比較好一些。
  • 調整內部團體:英文是align internal groups,align這個字不知道怎麼翻譯比較好。簡單的說,就是要打通Scrum團隊價值鏈「上下游」之間的關係,使得價值的交付更加快速。大部分公司都是從開發團隊開始導入Scrum,假設開發團隊的Scrum已經運作順暢,但是每次產品上線卻需要營運團隊花兩周的時間配合。這種狀況會影響交付價值的速度,也就是Scrum團隊的下游卡住了,需要往價值鏈的下游拓展(DevOps就是一個敏捷開發往下游拓展的例子)。
  • 調整外部合作夥伴:很多公司的產品開發不只牽涉到內部的團隊,也經常需要外部合作夥伴或協力廠商的配合。除了要打通內部價值流的上下游以外,如果合作夥伴的速度或步調無法配合,也會影響價值交付的速度。

***

如果稍微了解TPS(Toyota Production System)的鄉民應該看的出來,《Essential Scrum》書中提到關於管理者的這些責任,感覺很多是從TPS借用過來的。這些觀念在早期的Scrum文獻談的比較少,可能是隨著Scrum在公司內部的拓展,很自然地光是談Product Owner、ScrumMaster、開發團隊這種以產品開發為主的範圍就顯得不足夠,因此當敏捷開發的應用範圍從開發團隊拓展到整個公司之後,自然會有比較多的角色與責任冒出來。

***

友藏內心獨白:要學的東西也變多了。

2015年9月28日 星期一

不要用憶測的方式來除錯

Sep. 22 12:47~13:34

螢幕截圖 2015-09-22 13.31.24

 

《The Pragmatic Programmer》是10幾年前讀過的一本舊書,書中的兩個觀念「Rather than construction, programming is more like gardening」與「All programming is maintenance programming」在當時改變了Teddy對於軟體開發的看法。今天談書中提到的一個小技巧:「Don’t Assume It—Prove It」。

***

以前還在當工程師的時候,經常有機會和同事一起除錯。由於待除錯的程式碼當初主要是由同事主寫,Teddy並不清楚程式的運作細節,因此在合作除錯的過程中,會一直問一些「蠢問題」。

Teddy:這個method是做什麼用的?

同事:它是用來設定某個排程工作。

Teddy:你怎麼知道這個設定有正確執行?

同事:(不耐煩的語氣)程式都跑起來了,排程工作的檢查結果也顯示在畫面上,這樣還不算正確執行嗎?

Teddy:我知道整個流程串起來「看起來」是可以動的,但如果我們無法確定這個流程裡面的每個單元都是正確的,就很難找出bug。

同事:這樣太花時間了啦,這個method我確定它是對的,問題應該是出在別的地方。

Teddy:你怎麼確定它是對的,你有幫這個method寫單元測試嗎?

同事:這個method相依的物件太多,很難寫單元測試。但我有手動測試確定它是OK的。

Teddy:我們要不要利用除錯的機會,順便幫它補寫單元測試,來確定這個method真的沒有問題?

同事:我就跟你說問題不在這裡,不需要浪費時間做這種無意義的事情啦,先把bug找出來再說。

***

有時候Teddy會說服同事,由下而上用補寫單元測試的方式來除錯。有時候會先依據同事的直覺,從最有嫌疑的物件或method開始著手除錯。但無論如何,最後都儘量用撰寫自動化測試來證明「嫌疑犯」是清白或是有罪。

只要是人都有盲點,用憶測的方式來決定程式的正確性,是很不可靠的方法。當你說出:「這個地方應該不會有問題」的時候,請想想看有沒有相對應的各種測試案例(單元測試、整合測試、或是end-to-end測試)來證明你的憶測。這種心態剛開始會讓別人覺得你是一個「很龜毛」的人,但Teddy認為這是成為專業開發人員的一種訓練。龜毛就龜毛吧 XD。

***

友藏內心獨白:假設常常並不可靠。

2015年9月27日 星期日

2015捷克、奧地利考察之旅Day9-D佩特辛觀景塔

Sep. 07 15:32~16:12

佩特辛觀景塔(Petřín Observation Tower)建於1891年,是一座仿巴黎鐵塔的建築物,但高度只有60公尺,和巴黎鐵塔的320公尺差了5倍。
螢幕截圖 2015-09-07 15.43.51螢幕截圖 2015-09-07 15.53.12

 

▼售票處在塔內一樓。

螢幕截圖 2015-09-07 15.54.42

 

▼使用布拉格pass可以免費換票。

螢幕截圖 2015-09-07 16.01.56

 

▼登塔方式可以選擇搭電梯或是用走的,電梯有點小,用走的上去好了,可以順便看風景。

螢幕截圖 2015-09-07 15.54.52螢幕截圖 2015-09-07 15.55.15螢幕截圖 2015-09-07 15.59.10

 

▼電梯是進近年增建的,當初蓋好的時候並沒有。

螢幕截圖 2015-09-07 16.05.19

 

▼來布拉格看過這麼多次風景,這裡是高點中的高點。

螢幕截圖 2015-09-07 15.55.35螢幕截圖 2015-09-07 15.55.48螢幕截圖 2015-09-07 15.56.08螢幕截圖 2015-09-07 15.56.48螢幕截圖 2015-09-07 15.56.56螢幕截圖 2015-09-07 15.57.55螢幕截圖 2015-09-07 15.58.04螢幕截圖 2015-09-07 15.58.14螢幕截圖 2015-09-07 15.58.26螢幕截圖 2015-09-07 15.58.39螢幕截圖 2015-09-07 15.58.50螢幕截圖 2015-09-07 15.59.01

 

▼從最高點看城堡區果然視野大不相同。

螢幕截圖 2015-09-07 15.57.13


***

友藏內心獨白:該爬的塔應該都爬完了吧。

2015年9月26日 星期六

2015捷克、奧地利考察之旅Day9-C登佩特辛山

Sep. 07 14:50~15:23

▼原本計畫從佩特辛公園搭纜車上佩特辛山,然後再從山上輕鬆走下來。怎知人算不如天算,今天覽車居然停駛。都已經到了,只好改變計畫,徒步登山。

螢幕截圖 2015-09-07 14.54.22

螢幕截圖 2015-09-07 14.53.59螢幕截圖 2015-09-07 14.54.09螢幕截圖 2015-09-07 14.55.59

 

▼纜車軌道。

螢幕截圖 2015-09-07 14.58.51

 

▼停駛的纜車。

螢幕截圖 2015-09-07 14.58.34

 

▼天氣不錯,小朋友也出門踏青。

螢幕截圖 2015-09-07 14.59.05

 

▼一路上風景優美,越往上走漸漸可以看到布拉格舊城區以及對面的城堡區建築物。

螢幕截圖 2015-09-07 14.58.15螢幕截圖 2015-09-07 14.58.45螢幕截圖 2015-09-07 14.59.20螢幕截圖 2015-09-07 14.59.37螢幕截圖 2015-09-07 15.00.16螢幕截圖 2015-09-07 15.00.45螢幕截圖 2015-09-07 15.07.57螢幕截圖 2015-09-07 15.08.19螢幕截圖 2015-09-07 15.08.35

 

▼走到半山腰,有一間餐廳,發現一貓。

螢幕截圖 2015-09-07 15.01.14

 

▼在這裡稍微休息一下,順便欣賞市區的景色。

螢幕截圖 2015-09-07 15.10.31螢幕截圖 2015-09-07 15.11.13螢幕截圖 2015-09-07 15.11.26

***

▼看到這堵「飢餓之牆」,就到目的地了。此牆由神聖羅馬帝國皇帝查理四世下令修建,據說建造城牆的目的是為了雇用當時的窮人,讓他們有有飯可以吃,故稱為「飢餓之牆」。

螢幕截圖 2015-09-07 15.13.20螢幕截圖 2015-09-07 15.13.31螢幕截圖 2015-09-07 15.13.55螢幕截圖 2015-09-07 15.14.05

***

友藏內心獨白:運動一下也不錯,還好不趕時間。

2015年9月25日 星期五

管理者在Scrum中扮演的角色(2):培育團隊

Sep. 22 10:38~11:53

螢幕截圖 2015-09-22 11.49.25

▲發展捕鼠能力

 

《Essential Scrum》提到管理者的第二個責任是培育團隊(fashioning team),其中包含了:

  • 激勵員工:營造一個有利於員工打拼、有樂趣、追求卓越的工作環境。提供團隊正面思考的力量,鼓勵員工勇於嘗試。
  • 發展員工能力:在傳統的組織中,管理者負有協助員工發展能力的責任,這一點在Scrum團隊同時成立。看到這邊鄉民們可能會有疑問:「管理者又不在Scrum團隊裡面,怎麼協助員工發展能力?」再者,協助員工發展能力好像應該是員工自己,不然也是透過ScrumMaster來協助,和管理者有何關係?這裡談到的重點是:「管理者需要讓員工清楚知道,持續學習是個人、團隊與組織的重要文化與競爭優勢」,因此要提供時間與資源讓員工可以參加培訓活動與各式研討會。
  • 提供功能區域的領導力:管理者(functional manager)在Scrum組織中與傳統組織一樣,針對他所屬的功能領域(functional-area)扮演者領導者的角色。通常管理者會是某個領域的專家,在Scrum組織中,管理者可以針對多個Scrum團隊所使用的技術提供建議,從公司的角度建議不同團隊維持使用技術的一致性,以避免日後維護的困難。
  • 維持團隊的完整性在Scrum組織中,團隊取代個人成為衡量產能的基本單位。要維持一個團隊的完整性並不容易,在傳統組織中很容易因為各種原因把人從團隊中臨時抽離,並樂觀地認為這種任意的改組團隊不會影響專案進度。管理者要避免Scrum團隊經常性的改組,或是人員頻繁異動,以保持團隊的穩定,這一點非常重要。

***

看到這裡有經驗的鄉民不知道有沒有看出什麼門道出來。上述責任有些和ScrumMaster所負擔的責任是重疊的。例如,「維持團隊的完整性」,假設在sprint進行的過程中有人要把團隊成員拉走,ScrumMaster應該要出面處理以保護團隊不受干擾。講是這樣講,但實務上,ScrumMaster可能無能為力,因為要把人拉走的正是管理者本人挑眉質疑。另外一種情況是,別的部門的人利用「高高層」的名義要把團隊成員拉走,ScrumMaster尋求管理者(部門主管)的協助,而管理者卻裝死不想處理。這些狀況,都會造成Scrum團隊的混亂。

***

友藏內心獨白:主管不是那麼好當的。