管理者在Scrum中扮演的角色（4）：管理價值創造流

Sep. 24 16:30~17:34

▲要觀看全局。

 

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

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

***

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

***

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

管理者在Scrum中扮演的角色（3）：調整與適應環境

Sep. 23 14:40~16:15

▲敏捷宣言

 

《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、開發團隊這種以產品開發為主的範圍就顯得不足夠，因此當敏捷開發的應用範圍從開發團隊拓展到整個公司之後，自然會有比較多的角色與責任冒出來。

***

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

不要用憶測的方式來除錯

Sep. 22 12:47~13:34

 

《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捷克、奧地利考察之旅Day9-D佩特辛觀景塔

Sep. 07 15:32~16:12

▼佩特辛觀景塔（Petřín Observation Tower）建於1891年，是一座仿巴黎鐵塔的建築物，但高度只有60公尺，和巴黎鐵塔的320公尺差了5倍。

 

▼售票處在塔內一樓。

 

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

 

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

 

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

 

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

 

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

***

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

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

Sep. 07 14:50~15:23

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

 

▼纜車軌道。

 

▼停駛的纜車。

 

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

 

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

 

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

 

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

***

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

***

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

管理者在Scrum中扮演的角色（2）：培育團隊

Sep. 22 10:38~11:53

▲發展捕鼠能力

 

《Essential Scrum》提到管理者的第二個責任是培育團隊（fashioning team），其中包含了：

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

***

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

***

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