今年開始嘗試做PM, 在我看來PM貌似就是個打雜的角色, 不管了, 先嘗試一下, 因此找了一些書來看看, scrum也是我今年規(guī)劃中需要了解的一個東東, 因此就選了這本書.

這本書據說是scrum的入門書, 也是scrum的鼻祖ken schwaber的大作. 以前也在網上對scrum有過只言片語的了解, 從這本書, 可以了解scrum個大概,  里面基本上是通過一個個案例來講解在scrum中的角色(scrummaster, 產品負責人, 團隊), 非常通俗易懂.

看完之后發(fā)現(xiàn)scrum還算簡單, 而且我們目前的日常開發(fā)管理, 與scrum非常類似, 計劃安排也算是僅僅有條. 不過scrum中有一些東西規(guī)定的非常死, 還不是很理解, 比如說一個sprint是30個日歷日(為什么不是60, 不是15? 實際上我們是兩周), 每天必須開晨會(我們團隊內部從開始每天早上一次, 到每隔一天一次, 到現(xiàn)在干脆不開了, 貌似也沒什么問題, 關鍵是我們team人少, 感覺沒有開的必要), 還有燃盡圖, 這本書中我沒有看到詳細的介紹, 主要是任務時間估算方面的,

對了, 我們是采用JIRA來做項目管理, 每兩周發(fā)一個版本, 一個版本中的任務列表類似sprint backlog. 我們基本沒有產品backlog, 當然我們的需求會源源不斷的進來, 算是產品驅動, 如果技術無法支撐現(xiàn)有的需求, 我們會起一個項目來對系統(tǒng)做一次變革升級, 也可以說是技術驅動. 從需求, 技術方案, 代碼編寫基本上開發(fā)都全程參與, 自我管理算是不錯了, 不過sprint結束時的驗證主要通過測試人員(單元測試, 功能測試, 回歸測試)來完成. 每一個sprint的開發(fā)進度跟蹤由開發(fā)人員輪流擔任.


====================以下是讀書筆記的分割線===================
處理復雜問題時, scrum強調將控制權下放到獨立個體

項目復雜度越高, 便越需要將決策權委派到工作前線的獨立個體.

團隊規(guī)定30天的工作內容, 以交付最優(yōu)先的商業(yè)價值

scrum的科學原理
產品負責人代表項目中每位利益相關者的權益, 并為項目產出的軟件系統(tǒng)負責

產品負責人的職責就是利用產品backlog, 督促團隊優(yōu)先開發(fā)最具有價值的功能, 并在其基礎上繼續(xù)開發(fā).

產品負責人必須頻繁檢視產品待開發(fā)需求的優(yōu)先次序, 將最具有價值的開發(fā)需求安排在下一次迭代中完成.

團隊的任務是開發(fā)軟件功能, 他們是自我管理, 自我組織和跨職能的, 他們負責找出實現(xiàn)待開發(fā)需求的實現(xiàn)方法, 并管理自身的工作, 以達到這一目標.

scrummaster對scrum過程負責, 向所有成員講授scrum方法, 負責實施scrum, 確保它符合企業(yè)文化, 又能交付預期利益, 還需督促全體成員遵從scrum規(guī)則和實踐.

scrum區(qū)分兩類人("豬"和"雞"):
對承擔項目責任的人賦予權力, 使其完成必要的工作. 確保項目成功
無責任人員則無權對項目施加不必要的干涉.

必須時刻區(qū)分責任人和出主意的.

哪些人對投資回報負責,哪些在投資回報中分成, 但不承擔責任.

scrum規(guī)則區(qū)分雞和豬, 提高生產力, 創(chuàng)造勢頭, 防止混亂局面.

產品backlog排列出不同優(yōu)先級, 最易產出價值的事項享有最高優(yōu)先級.

分出優(yōu)先級的產品backlog是項目的起點, 中途內容和優(yōu)先級也會發(fā)生變化.

產品負責人從最優(yōu)先級的待開發(fā)事項列表中進行篩選, 告知團隊其預期目標, 團隊在接下來的sprint中

sprint計劃會議包括兩部分, 第一部分4小時, 產品負責人向團隊提供最高優(yōu)先等級的產品backlog, 后4小時團隊計劃本sprint的安排

晨會內容:
昨天做了什么, 今天準備做什么, 在實現(xiàn)目標中遇到了哪些困難

sprint結束后的評審會議, 限定為4小時

產品backlog是初始設計, 會隨著產品和環(huán)境的變化而變化.

scrum中心原則之一是團隊管理自身事務, 企業(yè)中的其他管理者均扮演"雞"類角色.

scrummaster類似傳統(tǒng)管理中的項目經理一職, 但又有區(qū)別, 項目經理負責界定工作范圍和管理工作, 而scrummaster負責管理scrum流程, 即確保scrum正常運轉.

項目中的個人類似空曠草場上的羊, scrummaster類似牧羊犬, 將羊團結在一起, 防止餓狼靠近.

產品負責人利用產品backlog將具有最高商業(yè)價值的需求界定為最高優(yōu)先等級事項.

產品負責人的職責是提升項目的投資回報.

在scrum中由團隊決定每個sprint的工作內容.

一般理想團隊是7個人

scrummaster負責使項目成功, 幫助產品負責人挑選最具有價值的產品backlog

scrummaster只是項目的推動者.

學習scrum類似學自行車, 開始需要一點時間, 然后自然而然地掌握騎車方法之后, 一切都會輕而易舉.

沒有完全理解scrum的scrummaster就像在主干道上行駛的自行車新手.

scrummaster的角色轉換: 從控制者轉變?yōu)榻▽д? 從上司轉變?yōu)榻叹?

牧羊犬絕不會擅自離開羊群, scrummaster也一樣.

團隊必須感受到有人全心全意關注其工作, 并在任何情況下, 都能提供保護和幫助, scrummaster的態(tài)度將反映項目的重要性

scrummaster是領路人, 不是管理者.

當改變不符合企業(yè)文化時, scrummaster必須做出讓步.

在sprint過程中, 不受外界干擾.

如果出現(xiàn)一個比當前sprint工作更有價值的機會, 管理者可以采取非常手段, 終止當前sprint, 團隊, 產品負責人和管理層重新召開sprint計劃會議, 若新機會確實具有最高優(yōu)先級, 可以加入產品backlog

scrummaster的職責:
排除產品開發(fā)和產品負責人之間的障礙, 確保產品負責人直接推動開發(fā)工作
教授產品負責人如何實現(xiàn)投資回報最大化, 以及如何利用scrum達成目標.
激發(fā)創(chuàng)造力和放權, 從而改善開發(fā)團隊的環(huán)境.
千方百計提高團隊生產力
改善工具和工程實踐, 確保每個功能增量具有潛在可交付性
向各方確保團隊工作進展實時更新并高度可視

scrummaster應該關注能做之事, 不要為不可能之事耿耿于懷.

如果開發(fā)工程師像流水線的裝配工人各自完成屬于自己的任務, 這樣會扼殺合作機會, 工作的順序也會導致工作開開停停 // 不敢茍同

先開發(fā)系統(tǒng)中的曳光彈功能, 為其他功能指明方向

scrum向團隊放權, 讓他們自己找到解決復雜問題的方法.

一個完成的產品所需的工作: 需求收集, 分析, 編碼, 測試以及文檔編制都應在一個sprint內完成, 并通過sprint功能增量展示, sprint限期不宜過長, 應確保利益相關者在各個sprint結束之前對項目保持興趣.

規(guī)劃scrum項目
scrum計劃過程涉及回答3個問題:
項目投資人希望項目結束時獲得哪些成果?
每個sprint應該有哪些進展?
如何使項目投資人相信該項目是有價值的投資, 以及項目申報者有能力交付預期收益?

在每個sprint結束時匯報進展, 以保持項目可視性.

啟動scrum項目最簡計劃: 一份愿景及產品backlog
愿景描述產品的背景和預期目標, 產品backlog是產品交付時完成的功能和非功能性需求,它要事先劃分優(yōu)先級并經過評估.

產品backlog:
本期sprint:已精確定義且在30天內可完成并產出可執(zhí)行程序的工作
下一個sprint:次優(yōu)先級的backlog, 取決于前一個sprint的成果
一個sprint內的sprint backlog是固定的, 僅隨當前sprint工作改變, 當前sprint之外的backlog保持變化, 發(fā)展并重新劃分優(yōu)先級.

計劃的目的之一是說服投資者為項目注資, 計劃向投資者提供詳細的信息, 證明項目具有價值, 能在規(guī)定的時間完成.其收益超出成本及風險, 且項目開發(fā)人員有足夠的能力執(zhí)行計劃.

預估的目的是了解需求本身, 以及相對其他需求的規(guī)模, 該信息有助于劃分產品backlog的優(yōu)先等級, 并將之分到各個sprint

生魚片法則: sprint審核時演示的潛在可交付產品功能的每一個增量都必須是完整的, 包括分析, 設計, 編程, 文檔以及作為完整產品一部分要求的使用步驟.

如果成員不能明確指出其工作內容, 其晨會是無意義的

晨會可以使各個成員工作同步, 否則便沒有價值

scrummaster須保持所有事項信息足夠詳盡可視.

scrum的生產力源于:首先選擇正確的事項, 然后高效完成選定事項.

一個團隊做出承諾, 時鐘便開始倒計時.

晨會是為團隊而開的, 各成員不能只看scrummaster, 團隊成員在匯報時, 互相之間應該有眼神交流.

scrummaster僅扮演顧問角色或促進對話進展

由于團隊負責管理自身開發(fā)行為, 他們可以在sprint內只有調整.

scrummaster的職責不是管理團隊, 他們應該學會自我管理, 不斷調整方法, 提高成功機會.

sprint評審會議也有時限, 防止團隊花大量時間追求完美.

scrummaster負責流程和消除障礙, 但不管理功能開發(fā).

scrum有難度, 它需要經常檢查和調整, 這是已知的解決復雜問題的唯一控制機制.

經歷scrum之后, 培養(yǎng)出來的應該是團隊英雄主義, 而不是個人英雄主義.

晨會

每日晨會限時15分鐘, 他是全天工作中的第一件事, 便于提醒成員思考前一天的工作和當天的計劃.

晨會必須全體成員出席, 遲到者必須接受罰款., scrummaster請他左邊的第一位開始匯報工作情況, 按逆時針方向挨個匯報, 每位成員僅回答3個問題:
自上次晨會后的1天里你為該項目做了什么?
從現(xiàn)在到下一個晨會的1天時間里, 你準備為項目做什么?
什么妨礙你盡可能高效地工作?

晨會上成員不得離題講其他事宜, 設計, 討論問題或者閑談, scrummaster必須確保成員輪流且干脆利落地匯報情況

晨會上其他成員是聽眾, 不可在一旁私下談話.

晨會上當某成員匯報的情況涉及到其他成員興趣或者需要協(xié)助時, 可在晨會后召集有關人員開會討論.

晨會上雞類人員不得講話, 評論等. 且必須站在團隊外圍, 以免干擾會議, 若雞類人員過多, scrummaster必須做出限制.

雞類人員不可在會后請團隊成員深入解釋或者向團隊提供建議或指示 // 不敢茍同


sprint
在sprint期間, 其他人不可向團隊下達通知, 指令, 評論和方向指示, 團隊完全進行自我管理.

若sprint發(fā)生異常, scrummaster可非正常終止sprint, 召開新計劃會議啟動下一個sprint.

團隊準備sprint審核的時間不得超過1小時

sprint完成的定義是功能已經完成建造, 潛在可交付或實施.

sprint評審會議上全體成員必須回答兩個問題:
上一個sprint有哪些成功方面?
下一個sprint應該做出哪些改進?

scrummaster出席會議的目的不是提供答案, 而是促使團隊發(fā)掘scrum過程的最優(yōu)方法.