書摘《敏捷與 Scrum 軟體開發速成》

前言：老實說，從中文書名無法聯想回原文書是《The Elements of Scrum》，雖然書名翻譯沒有太離譜(和內容無關之類的)，但總覺得貼近原意會好一點。

『Scrum團隊週記』這一章，整個讀完，其實就差不多可以了解Scrum的大部分，所以，若要讀這本書，又沒有太多時間，就先看這一章吧！

第一章 起點：瀑布方法

有點諷刺的是，Royce之所以提供這個模型(瀑布模型)，是要拿它當例子來說明軟體開發不能這樣做！ _{p. 24}

第二章 加入敏捷實踐者行列

我們所設計的複雜系統，主要是由可變性和高度非線性的人類組成，但一直以來，我們在設計系統時卻從未把人類或人類對系統的影響考慮進去。回想起來，雖然覺得很荒謬，但在這行業中，投入了大量精力致力於理解人們對軟體開發所造成影響的人員，真的是少得可憐。 _{p. 31}

文件邊做邊寫，只寫必須的文件。將文件作業融入流程，只寫有關的、有效用的文件。 _{p. 33}

第三章 敏捷價值觀與原則

大多數的人普遍誤以為敏捷團隊是不寫文件不做計劃的，但實際上，敏捷團隊為規劃(planning)和文件工作所花費的時間、精力遠多於傳統團隊，因為計畫(plan)需要不斷地進行詳細劃分和更新。 _{p. 39}

敏捷計畫在整個專案生命期間是一直在累積和演變的，是有生命的，而不是奉為圭臬的厚重書籍。這意味者，不管在任何的時間點，計畫都能代表我們當時對專案的最佳理解，但我們仍然期待，在我們檢驗和調整的同時，它也在演變和改進。 _{p. 39}

在團隊內部，效率最高且效果最佳的資訊傳遞方式，就是面對面的交談。 (中略) 敏捷團隊是在更加開放的共用空間中工作，且只要有可能都會選擇以口頭交流的方式。 _{p. 47}

最佳的架構、需求與設計都源自於能夠自我組織的團隊。 (中略) 在scrum團隊中，她可不是『那個架構師』(The Architect)而已，團隊會將她的專業技能視為非常重要的資源，也經常會尋求他的指導，架構工作也會有她的參與和貢獻，旦絕不會是由她來『負責架構』，而是由團隊平均分擔這個責任。 _{p. 51}

第五章 Scrum歷史簡述

Schwaber覺得，新方法成功的秘訣在於，他使用了經驗式(empirical)流程(檢驗和調整)，而不是自定義流程(計畫和執行)。 _{p. 70}

第六章 Scrum角色

產品負責人(Product owner)的責任就在於，幫公司得到最高投資回報，作法是引導團隊做最有價值的工作，並遠離價值較低的工作。也就是，產品負責人控制著團隊待辦清單(product backlog)上的優先順序。在scrum中，產品負責人是唯一有權要求團隊做(什麼)事以及改變待辦清單修先順序的人。 _{p. 74}

後註：我還是不喜歡專有名詞硬要翻譯成中文。

scrum master總是和團隊間『保持著一定的距離』，不至於太過親密，但會密切注意流程和進度的情況，獻計獻策幫助團隊解決小問題，有需要時還會扮演共鳴板角色。 _{p. 76}

一個高產出和更為自我管理的團隊，他們可能已經不再需要scrum master來主持scrum會議。稱職的scrum master會退居幕後並鼓勵他們放手去做。事實上，稱職的scrum master會不斷地調整自己的風格去適應團隊的需要。 _{p. 77}

scrum master還有另一個關鍵的作用，為團隊移除障礙。任何拖累團隊的都是障礙，它們的形式多樣、規模各異。 _{p. 77}

一個scrum團隊應該有多少個隊員呢？經驗法則通常是七個人，再或多或少兩個人，也就五到九個人。如果團隊人數再少，可能會欠缺多樣化的足夠技能，而難以全部完成使用者故事(user story)所需的工作。如果團隊人數更多，溝通開銷會開始過度地增長。務必牢記，這只是參考而已，人數更多或更少的成功團隊我們都見過。 _{p. 79}

Scrum並不追求做到團隊所有成員都可以互換，只要他們在團隊需要時，願意選擇舒適區以外的工作即可。 _{p. 80}

第七章 Sprint週期

一個典型團隊要掌握敏捷流程的精髓大約需要六個sprint，至於使用的是一天還是四週的sprint則無關緊要。 _{p. 84}

我們建議，按照每個開發週期2小時的比例來安排sprint規劃會議(sprint planning meeting)，一週的sprint適合開2小時的會，而一個二週的sprint開4個小時的會應該也夠了。 _{p. 85}

即使團隊已經全力以赴地確認澄清需要完成的所有工作(task)，但實際上得到的清單仍可能有欠完整。當實際工作展開後，新工作就會顯露出來，此時，把新工作記錄下來，並添加到目前sprint的工作清單(sprint backlog)即可。高效率團隊通常能在sprint規劃會議上確認60%到70%左右的工作。 _{p. 87}

那工作估算該怎麼做呢？用什麼單位？推薦三種常用方式：工作小時(用工作小時做估算單位，有時候會造成混亂，因人們總是期待著，工作可以在估計的時間內完成，這就是估算的本質，也是估大小往往比估時間更有效的原因)、工作點(sprint過程中，團隊只要追蹤需要完成的剩餘點數即可)和工作數(缺點是他無法在一開始就發現工作過大或過多的情況並警示團隊)。哪種方式最好？團隊得自己拿主意。要記住，最終目標還是在團隊偏移原計畫時程能及早發現，如此就還來得及採取行動。 _{p. 88}

其一，清單修整(user story refinement)屬於事前行工作，在週期中要趁早完成以便有充足的前置時間，讓產品負責人可以在他們的計畫和優先順序排序工作中用上這些估算。其二，在sprint長度超過一週的情況下，1小時的會議多開幾次，效果會比一次開幾個小時更好。(中略)其三，你應該不想將sprint結尾弄得跟馬拉松會議一樣長(結尾有sprint review和自省會議，再開refinement會議實在太長)。 _{p. 91}

第八章 Scrum產出物

在產品待辦清單上方的，大多是較小型且定義完善的項目。這樣正好，因為團隊接下來要實做的就是這些故事。清單再往下，故事的規模更大，定義也更粗略。沒關係，只要在把它們挪到上方之前，好好地改善即可。當特性(feature)在產品待辦清單中不斷地往上移動，就代表越來越接近它將被實現的時刻，而團隊對它的檢查也會更加詳細，估算和驗收標準也更精確，大故事也會被拆解成小故事。(中略)清單的優點就在於，絕不會浪費時間為那些可能永不見天日的特性撰寫詳細規格書。 _{p. 102}

值得一提的是，完成之定義(Definition of Done, DoD)和驗收標準(Acceptance Criteria)是有區別的。驗收標準是屬於產品負責人或客戶的領域，明確定義了被視為『可接受』(的)產品必須滿足的條件並記錄在案。但像是回歸測試或版本整合這些內容，則不屬於驗收標準的範疇。完成之定義歸開發團隊所有，關注的不是產品的使用者導向的功能，而是若產品要能交付，必須要做完那些工作。(可參考書摘《Executable Specifications with Scrum》) _{p. 113}

第九章 使用者故事

使用者故事是對談的敲門磚。使用者故事不是完整的需求或說明書，它們是佔位關係(placeholder)。它們的資訊量足以提醒團隊有東西要完成，但我們刻意地不過多探討細節……直到必須(開發)之時。 _{p. 118}

對談中，如果某一刻大家覺得對使用者故事已有共識，那就該寫驗收標準了。(中略)完善驗收標準也是修整清單工作(user story refinement)的一部分。專家級產品負責人應符合以下要求，在sprint開始前他們就已定義所有驗收標準並和團隊達成一致，而且sprint中不做改變。 _{p. 119}

第十章 用故事大小值估算工作

產生估算的真正目的是要提供進度的可預測性度量。 _{p. 123}

團隊估算遊戲規則
第一部分：集體排隊
所有玩家輪流上場，輪到自己時可以做以下任何一件事：
- 在牆上放置新的故事卡。
- 移動已在牆上的故事卡。保持其他卡片的順序，即使為了給那張換位卡留出空間，而移動很多卡片也完全沒關係。
- 移交行動權給下一個玩家。
卡片請依從左到右且從小到大的順序放置。可以將它們調鬆些，後面在調整順序時才方便。所有人都輪流上場待(故事卡)選擇完時遊戲宣告結束。

第二部分：你的數字是？
所有玩家輪流上場，輪到自己時可以做以下任何一件事：
- 在某章故事卡上方放下一張費式數列卡片，代表此處的故事大小增加了。
- 將費式數列卡片換到另一個故事的位置。(移動時必須維持數字的順序，也就是說1在2之前，13在21之前。)
- 像第一部分那樣移動故事卡片。
- 移交行動權給下一個玩家。
所有人都輪流上場待選擇完後遊戲宣告結束，代表故事的順序和大小分配都無須再做調整。 _{p. 133}

Jul 19, 2020