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

閱讀時間約 8 分鐘
raw-image

前言:老實說,從中文書名無法聯想回原文書是《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

52會員
102內容數
這是從 Medium 開始的一個專題,主要是想用輕鬆閒談的方式,分享這幾年軟體開發的心得,原本比較侷限於軟體架構,但這幾年的文章不僅限於架構,也聊不少流程相關的心得,所以趁換平台,順勢換成閒談軟體設計。
留言0
查看全部
發表第一個留言支持創作者!
Spirit的沙龍 的其他內容
你可能也想看
書摘-《孤獨的冷漠:逃避型依戀障礙的分析與修復》前言   活了30幾年終於要正式自身的問題,於是大量的找這類型的書籍來了解。看到書中許多有共鳴的分析句子或情境,心臟會隱隱的抽痛;我想,那會不會是身體在告訴我,過去真的積壓太多情感。   只有我自己才能成為自己最堅強的後盾!現在的我,是這樣想的。於是,正式開起了這段探訪自我之旅。
Thumbnail
avatar
川流大海
2022-08-30
書摘《遠距團隊的高效領導法則》:遠距工作是組織文化與個人紀律的試煉受到疫情的影響,許多企業嘗試遠距工作、在家工作或是混合辦公方式持續維持營運,但疫情逐漸消退後的「後疫情時代」,卻發現員工已回不了辦公室。過去我們的生活是圍繞著工作所建構,例如交通、住屋、生活圈都以工作為考量遷移。然而疫情期間,生活反倒成為了重心,各式工具滿足在生活中工作的需求,人們關注工作生生活
Thumbnail
avatar
鄭智維 Wesley
2022-05-31
書摘《精準回饋》:用回饋力創造正向連結、成長心態的職場人生本書作者Chandler及Grealish長期以來協助非營利組織及跨國企業改善「績效管理」的制度,發現績效管理不彰的重點就在於缺乏回饋。HR除了改善績效管理制度面向外,也應該教育主管使用正確的回饋方式,讓績效管理功能得以發揮。
Thumbnail
avatar
鄭智維 Wesley
2021-08-07
書摘《成長駭客》:從網絡產業借鏡,以成長為中心的新世代工作思維自從上次看了商業思維學院產品經理Final Pitch後,覺得同學們的報告也太強,不僅透過市場規模了解潛在商機、蒐集需求設計APP原型,或針對現有APP的用戶使用體驗作改善、各個決策的步驟都輔以用戶心理及數據做佐證,讓我不禁懷疑,產品經理平常的工作內容,是什麼養成他們信手拈來跨學科的思考。
Thumbnail
avatar
鄭智維 Wesley
2021-07-25
書摘《教練:價值兆元的管理課》-人性管理中的正面價值管理與領導技巧固然重要,這都是工作技能的一部份。然而真正的教練與頭銜無關。你可以是自己的教練、也可以是同事的教練、朋友的教練。但謹記這些管理叢書的原則是人實踐出來的,而非唯一參照準則。真正重要的是在異化的職場中,不論遭受到多少的批判、掙扎、落在何種困境,你都能在自我對話中保有自己、練習先回到「人性」
Thumbnail
avatar
鄭智維 Wesley
2021-07-21
書摘《懂用人,當主管心不累》:所有主管都是人資主管在聊這本書前,我想說一個概念,那就是: 「所有主管都是人資主管」 這個概念是我第一份工作時的經理不斷叮嚀我的。那時候公司在推「四角色模型」的專案時,把所有的單位主管都拉進來參加,但有些主管反對、消極應付,有些主管則是很認真地思考策略,定時回復資料。
Thumbnail
avatar
鄭智維 Wesley
2021-07-11
書摘《情緒經濟時代》:打造正向情緒的企業管理本質邁入情緒經濟學 「如果光看交易所裡的價值升降,而不考慮其心理作用,不考慮大眾因企望和沮喪而生的情緒反應,以及引發投機客狂熱的好壞消息如何傳播,那麼這些數字一點意義都沒有。」──塔德 早在行為經濟學盛行前的十九世紀末,社會學家塔德已觀察到許多經濟行為的背後並非理性的算計,而是充滿了許多激情。
Thumbnail
avatar
鄭智維 Wesley
2021-07-03
書摘《你拿什麼定義自己?》:人生多變,總會連成自我追尋的一條線。生日時恰巧翻到英國管理學大師查爾斯‧韓第(Charles Handy)的自傳。雖然他不是跟我同一天生日,但同為文科哲學背景、又曾有外派東南亞的經驗,十分相似。雖沒提出什麼讓公司賺錢的方法、離開殼牌後也沒在大公司任職過,卻提出許多關於組織、工作的趨勢洞察,被後人傳誦。我將他視為為職涯典範。
Thumbnail
avatar
鄭智維 Wesley
2021-06-29
書摘《讓大象跳起來》:組織轉型的關鍵是找回人與人之間的連結。「人與人之間的連結」一詞雖然在疫情的脈絡下有種被汙名化的意涵。但是在社會學者的眼中,「人與人之間的連結」—也就是關係,卻是建立團體、組織、社群等群體社會構成的基礎。
Thumbnail
avatar
鄭智維 Wesley
2021-06-24
書摘《訂閱經濟》將顧客轉換為訂戶(subscriber),以創造經常性收入。稱為「訂閱經濟」(Subsrciption Economy)。
Thumbnail
avatar
two
2019-10-17