“Scrum 敏捷軟件開發”讀書心得分享

Stanley Huangwenlien1001(at)gmail.com

   

有天中午 ...強者我同事： Scrum 就像是一台 4WD 的車子，可以駕馭各種環境。

於是，我開始看一堆 Scrum 的書，試圖擺脫苦難工程師的地獄輪迴～

   

大綱

● 誰是我● 你是誰● 緣起● 分享● Q&A

   

誰是我是誰 ?

● Stanley Huang– wenlien1001@gmail.com

● 現任：美商無線網路公司– Functional Spec Engineer (a.k.a. Feature Owner)– Post­it Engineer (a.k.a. Scrum Master)

● 社群：– Taipei.py– PyCon APAC 2015 Program Chair

   

你是誰？

● Programmer● Architect● Scrum Master● Product Owner● Project Manager● CEO● Co­Founder ­­>  （我的部落格在這裡）

   

緣起

從這個故事告訴我們 – 推坑激勵組員，是 Scrum Master 的基本能力！( 作筆記中 ...)

   

前言

● 這本書為實用主義者而生，寫給哪些已經開始嘗試 Scrum 且可能已經遇到問題的人。

● 整理出一些共通的問題及給與的建議。– 「反對」– 「試一試」

   

書本結構

● 啟航● 個體● 團體● 組織● 下一站

   

一、啟航

● 關於如何開始執行 Scrum 。

   

為什麼要轉型？

● 為什麼轉型困難？● 為什麼值得投入？

   

ADAPT 模型

● 意識● 渴望● 能力● 推廣● 傳遞

   

不要詆毀過去

● 許多管理者對未來的熱情源於「將來比過去好」。嘲笑或談論原來的做事方式，這樣加大了轉型的阻力。

   

推廣

http://www.mountaingoatsoftware.com/scrum­a­presentation

https://www.mountaingoatsoftware.com/agile/scrum/a­reusable­scrum­presentation

   

試一試

● 在你的團隊找出和你的情況最接近的一些ADAPT 活動。找出三件你可以做的事情，將其中的某一個活動推進到 ADAPT 下一個階段。

   

Scrum 實施模式

● 小團體前導，還是全面轉型？● 公開敏捷，還是悄悄行動？

   

推展模式

● 先拆分 , 後播種 ?● 先成長 , 後拆分 ?● 內部教練（ internal coaching ） ?

   

ETC

● Enterprise Transition Community

– 來自 Scrum 轉型的最高級別人員

– 企業底層的人所發起

● ETC 職責– 清楚表達背景

– 鼓勵對話

– 提供資源

– 設置合適的目標

– 人人參與

– 處理人的問題

– 消除障礙

– 鼓勵同時關注”實踐”與”原則”

   

IC

● Improvement Community– 自動化測試– 持續整合– 測試驅動開發– 產品負責人– ScrumMaster

   

理想前導專案的四個屬性

   

前導專案團隊選擇

● Scrum說客● 積極的樂觀者● 公正的懷疑論者

   

二、個體

● 關注於個體及其在導入 Scrum 過程中需要做出的改變。

   

克服抵觸

● 員工與管理人員抵觸變革的主要因素

排名 員工 管理人員1 缺乏意識 害怕失去控制與權力2 對未知的恐懼 缺少時間3 缺乏職業安全感 安於現狀4 缺少支持 不清楚”對我有什麼好處 ?”

5 沒有參與解決方案的設計

   

面對變革，個體不同的反應● 保守主義者 (25%)

– 喜歡在保持現有結構的情況下變化

– 熱衷於預見性

– 遵守傳統和公認的實踐

● 實用主義者 (50%)– 喜歡實用的改變

– 尊重雙方的觀點

– 更關注結果

● 創新主義者 (25%)– 喜歡能對現有結構發起挑戰的變革

– 會挑戰既有的假設

– 很少尊重既定策略

   

面對變革，個體不同的反應● 保守主義者 (25%)

– 喜歡在保持現有結構的情況下變化

– 熱衷於預見性

– 遵守傳統和公認的實踐

● 實用主義者 (50%)– 喜歡實用的改變

– 尊重雙方的觀點

– 更關注結果

● 創新主義者 (25%)– 喜歡能對現有結構發起挑戰的變革

– 會挑戰既有的假設

– 很少尊重既定策略

   

抵觸原因

● 抵觸原因可分成兩大類– 安於現況– 不喜歡 Scrum

   

抵觸類型

● 抵觸是主動還是被動 ?– 主動的抵觸發生在採取具體的行動阻礙或是干擾

Scrum 轉型。– 消極的抵觸通常是有人說會採取具體行動，但因為抵觸而不採取具體的行動。

   

四種不同的抵觸類型

主動｜　

如何抵觸？｜　被動

頑固者 破壞者

追隨者 懷疑者

安於現況＜－為什麼抵觸？－＞不喜歡 Scrum

   

優秀產品負責人的特質

● 始終都在● 懂業務● 善於溝通● 果斷● 得到授權的

   

優秀 Scrum Master 的特質

● 負責● 謙遜● 協作● 投入● 有影響力● 知識淵博

   

Scrum Master 像是一個指揮家

● http://www.ted.com/talks/itay_talgam_lead_like_the_great_conductors?language=zh­tw

● http://www.ted.com/talks/benjamin_zander_on_music_and_passion?language=zh­tw

   

架構師的角色轉換

● 在敏捷開發中，架構師主要的職責是考慮變化和複雜度。– Andrew Johnston

● 不編碼的架構師出現是眾所周知的麻煩出現的先兆， Scrum專案要擺脫他們！

   

專案經理的角色轉換

由下而上｜　

管理風格？｜　

由上而下

團隊推動者“你有權這樣做！”

學習型組織的建構者“這就是我們的目的和方向　 ­­  我將給予指導和輔助！”

官僚主義者“ 照章辦事！”

任務經理“這裡說明了做什麼，怎麼做！”

一般的管理專家＜－知識？－＞對工作的深入了解

   

UED 和開發能並行

   

實踐技術

● TDD● Refactory● Collective Ownership● CI● Pair Programming

   

設計：有意的而又湧現（ emergence ）

● 早期計畫

● 大的前期設計

● 後期測試

● 移交簽字

● 早期的，大而全的需求

● 即時的計畫

● 湧現式的設計

● 整合測試

● 協作討論

● 即時的，洽到好處的需求

需求是慢慢湧現的，漸進明細的。

   

三、團體

● 向外擴展到團隊的話題。

   

兩個 Pizza

   

時間 vs 規模

   

團隊協作

● 培養團隊承諾● 透過承諾鼓勵合作

– 『我的職責是讓我的二十五位隊員為他們 T恤前的名字而不是為了背後的號碼比賽』 – Tommy Lasorda @ Dodgers

   

「反對」● 如果人人都負責，將沒有人可以負責。

● 年終考績的依據是我做了什麼，不是團隊做了什麼。

   

「試一試」● 下次 Sprint會議上，不要給個人分配特定任務。

● 一次只關注一個 User Story 。

   

激勵目標

● Highsmith– 寫一兩個句子的產品說明– 設計運輸產品的包裝盒– 寫一頁產品說明書

● Mike Cohn– 寫一份假想的新聞稿– 寫一份刊登在雜誌上的產品評估

   

整理 Product Backlog

● 黃金法則：– 我們應該花 Sprint 中 10% 的精力整理 Product 

Backlog

● 對於 Product Backlog 的討論，不侷限於某個時段的會議

● 優秀的團隊不需要在 Sprint 開始前已經充分了解Product Backlog

   

建立 DEEP 的 Product Backlog

● Detailed Appropriately (評估得當 )● Estimated ( 做過估計的 )● Emergent (湧現式的 )● Prioritized (排列優先級的 )

   

Scrum 是一種迭代和增量的整合開發

● 增量 ● 迭代

   

可工作的軟體

● 可工作的軟體是指功能完成，同時潛在可發佈的軟體

● 敏捷強調「可工作的軟體」的原因– 鼓勵反饋– 幫助團隊衡量他們的進度– 允許產品在需要時及早發佈

   

潛在可交付軟體的指導方針

● 潛在可交付意味著「測試過」● 潛在可交付並不意味著「系統功能完整」● 潛在可交付意味著「整合測試已完成」

   

固定 Sprint 長度的好處

● 團隊受益於定期的節奏● Sprint計畫變得容易● 發佈計畫變得容易

   

逐步完善計畫的優點

● 可以減少最大限度地減少時間上的投資● 允許在最佳的時機作決定● 允許我們改變● 可以幫助我們避免落入相信計畫的陷阱

   

除非你是特殊材質，否則不要用加班來趕計畫！

   

如果可能，支持改變範圍

   

估算 vs 承諾

● 問題的關鍵式，估算往往變成承諾！

   

工作進度的預估

Sprint Velocity

1 13

2 15

3 17

4 12

5 11

6 15

7 14

8 16

9 12

11 12 12 13 14 15 15 16 17

# of observation ranking

5 1

8 2

11 3

13 4

16 5

團隊速度： (12+16)/2 = 14

90%信賴區間的速率表

Sprint 速率表

   

為什麼最後才測試沒有效果

● 很難改進現有產品的質量● 錯誤一直未被發現● 專案狀態難以測量● 錯誤反饋時機● 測試可能被削減

   

四、組織

● 進一步擴展到企業級別的話題。

   

「反對」

● 如果專案真的達到敏捷狀態，就不需要整合團隊。

   

形成凝聚力

● 承認顯著的文化差異● Geert Hofstede 的文化差異分析五個指標

– 權威距離指數（ PDI ），接受權威部平等– 個人主義（ IND ），注重個體表現– 成就導向型（ ACH ），以成功可見標誌– 不確定規避指數（ UAI ），不確定的容忍指數– 長期導向（ LTO ），長期利益考量

   

各國文化間的差異國家 PDI IDV ACH UAI LTO

台灣 58 17 45 69 87

中國 80 20 66 30 118

印度 77 48 56 40 61

以色列 13 54 47 81

美國 40 91 62 46 29

＊以色列同事最會挑戰權威，而中國同事最不會＊美國同事重視個人主義，而台灣同事對團隊團結最感興趣＊前一個項目成功，下一個項目失敗下：中國同事認為是「成功」，而台灣同事可能認為是「失敗」＊以色列同事習慣不確定性，而中國同事最不能忍受＊ Sprint 展示出來的定期可視化進度：能給美國團隊帶來正面的激勵，而中國團隊可能不會。

http://www.clearlycultural.com/geert­hofstede­cultural­dimensions/power­distance­index/

   

最遙遠的距離

● 對分佈式團隊而言，難的不是距離而是時差– 留一些閒聊的時間– 分擔痛苦– 告訴大家誰在發言

   

分散式團隊的 Sprint計畫會議

● 如果團隊在同一個時區，一次長時間電話● 如果團隊在不同時區，兩次短時間電話

– 第一次，主要討論產品負責人的最高優先級別的功能與期望。

– 第二次，同步各個子團隊的任務。

   

五、下一站（幸福？）

● 歸納企業敏捷轉型的各種度量方法。

   

常見的評估方式

● 撒丹遵守度調查● Agile: EF● 比較式敏捷評估

   

我們在乎的是什麼？

● 數據可以幫助對抗企業內部的反抗● 指標可以幫助我們宣傳 Scrum● 指標有助於我們知道從哪裡著手進一步改善