前言
這次讀書會來得非常突然。
某天：重慶敏捷之旅群成員過100，清華大學(xué)出版社的文老師馬上發(fā)布消息說送我們書籍。
接下來就是順理成章了：明確讀書會的要求——>秒名額——>個人讀書——>線上問題收集——>線下集中交流。
如果一定要說這次讀書會有什么特殊的，就是我們進行了線上問題收集。
關(guān)于讀書，我們認為有兩點很重要：1）搞清楚書的內(nèi)容 ；2）解決（實際）問題。
在問題收集環(huán)節(jié)，其實我內(nèi)心是忐忑的，我非常擔心我們重慶的軟件從業(yè)者，會比較內(nèi)斂，不愿意提交問題。但結(jié)果令人興奮，我們收集到9個問題，并且其中大部分問題非常具體、非常有代表性。這9個問題，就是這次讀書會的主角。
所以，請允許我們感謝一下參與讀書會的小伙伴。你們的積極參與是這次讀書會順利進行的關(guān)鍵！
《scrum實戰(zhàn)》讀書會實錄
破冰游戲
這次讀書會的小伙伴，基本上都是第一次見面。為了后續(xù)討論環(huán)節(jié)更有效，我們通過一個畫手連線的小游戲讓彼此認識一下。
在這個環(huán)節(jié)中，我們發(fā)現(xiàn)100%的人都來自研發(fā)相關(guān)崗位（希望后續(xù)有產(chǎn)品、測試、運營等加入進來）；70%以上沒有出游計劃，喜歡家里蹲；比較反常識的是，80%的研發(fā)小伙伴都喜歡運動。另外，這次連接達人的奪冠數(shù)目是22條連線。
實際工作中的問題
Q1:如何解決研發(fā)過程中重復(fù)的惡心循環(huán)？
一個項目的正常開發(fā)流程為：原型設(shè)計-》UI設(shè)計-》功能開發(fā)-》產(chǎn)品交付。
實際工作中的流程卻是：原型設(shè)計-》UI設(shè)計-》功能開發(fā)-》產(chǎn)品交付（客戶不滿意，修改功能）-》功能修改（UI又不滿足）-》UI重新設(shè)計這樣一個重復(fù)的惡心循環(huán)。
有段時間，我個人一直認為這是原型設(shè)計的不合理與客戶的反復(fù)修改造成的一個惡性循環(huán)，直到有一天有人跟我說了一句話：“所以都有一個壞毛病，我只要把功能完成，就可以了”。是的，在我個人的開發(fā)工作中這樣的心態(tài)確實是有的，項目的開發(fā)周期越緊，這樣的心態(tài)就越嚴重。
1）引導(dǎo)客戶。在前期跟客戶確認好，不允許變更。但是存在客戶不滿意的情況。
2）XH：之前是沒有循環(huán)，到一個循環(huán)，到多次循環(huán)。這是量變引起質(zhì)變。我們通過縮小反饋周期，可以更好的適應(yīng)客戶需求變化。
3）ZYM：參考本書第30章，我們可以得到如下的一張圖。
Q2：在開發(fā)過程中，應(yīng)該如何來理解功能？
在編碼開始之前，我應(yīng)該思考哪些問題？
提問者的思考方式為：1、思考功能業(yè)務(wù)流程。2、數(shù)據(jù)驗證。3、數(shù)據(jù)存儲。
左隊：梳理技術(shù)難點（包括研發(fā)路線）；判斷時間風(fēng)險，要給后續(xù)留緩沖；要寫出用戶故事。
右隊：通過業(yè)務(wù)--技術(shù)--干活（編碼）--評審 來搞定需要研發(fā)的功能。并且需要注意樹立各功能之間的關(guān)系。
ZYM：參考本書P205，其中體現(xiàn)了用戶故事三要素：角色、功能、價值。傳統(tǒng)的研發(fā)管理，容易聚焦功能，而忽視了用戶和價值。實際上，從商業(yè)目標的角度看，我們的軟件不是由于他有功能就有價值，而是因為實現(xiàn)了用戶價值才有價值。所以建議大家后續(xù)嘗試從典型用戶開始進行需求的梳理。如何找出用戶故事，具體方法有用戶旅程等。分析用戶故事的具體方法可以參考《用戶故事和敏捷方法》。
Q3：敏捷轉(zhuǎn)型如何啟動？
對于正在進行中的項目，是否有辦法切換至敏捷開發(fā)？或者說暫時沒有新項目時，如何逐步將敏捷開發(fā)引入到日常開發(fā)中來。
右隊：關(guān)鍵詞是理解、支持、信任。一定要取得領(lǐng)導(dǎo)的支持。
左隊：自上而下（老板的支持）。自下而上，同時結(jié)合培訓(xùn)、學(xué)習(xí)，讓團隊實施（承諾）。
ZYM：各小組說都很重要，但是到具體怎么行動（具體的步驟）而言，還是比較寬泛的。實際上，我們可以按照本書的第5-8章+17章+可視化落地。具體而言，就是確定PO、SM、TEAM三大角色，確定迭代周期，確定DOD，站會+可視化。當然，如果能把計劃會、評審會、回顧會也一起開起來，那就更好了。
Q4：如何與團隊進行問題預(yù)處理？
提問者的解決方案：遇見問題，思考問題，解決問題。
ZYM問題轉(zhuǎn)換：如何與團隊進行問題處理？
左隊：通過溝通，分析問題的本質(zhì)；通過一系列方法（魚骨圖等），找到問題的根因，進而找到對應(yīng)的解決方案；而且這個過程是可以不斷迭代的。
右隊：要先對問題進行分類，然后進行優(yōu)先級決策；對于優(yōu)先級高的，需要立即去解決，而且要定責任人。問題解決后要有回顧和總結(jié)。
ZYM：本書第279頁有個案例，大家可以先看一下。從這個案例來看，其實給人這樣一種啟發(fā)。解決問題有兩大挑戰(zhàn)。其一是找到問題的解決方案；其二是暴露問題。第二個挑戰(zhàn)往往容易被人忽視。實際上，我們的團隊都很厲害，只要是具體的問題，我們都能去解決它。但是隱藏的問題，就沒有那么好解決。敏捷，在某種程度來說，最大的效用不是解決問題，二是暴露問題。跟精益一樣，敏捷通過限制在制品數(shù)量，可以有效的將研發(fā)過程中的問題暴露出來。有個經(jīng)典的比喻“湖水與巖石”，我們的積壓的在制品就像湖水，問題就像巖石。只有當水面降低后，巖石才能逐漸暴露出來。
ZYM：對于如何定義和解決問題，有本書推薦大家看一下《你的燈亮著嗎》。
Q5：如何解決敏捷自組織和成員參差不齊的矛盾？
敏捷講究的是全員參與，集體制定進度和分工等，如果團隊中新人較多(對整體框架不熟悉)，隊員能力參差不齊，該如何應(yīng)對？
ZYM問題轉(zhuǎn)換：1）新員工較多的團隊進度（計劃）如何確定？ 2）如何分工（分任務(wù)）
左隊：1）“走著瞧”。2）鼓勵主動選，但是實際情況是領(lǐng)導(dǎo)安排。
右隊：1）“走著瞧”。2）根據(jù)興趣、特長領(lǐng)取+主管分配。
ZYM：對于分工的問題，有個實踐給大家參考下。就是團隊對于某項任務(wù)，根據(jù)自己的能力進行評估，這項任務(wù)的工作量取大家評估的算術(shù)平均。同時，評估工作量最少的那個人有優(yōu)先領(lǐng)取權(quán)。通過這個制度解決了主管和員工之間的評估矛盾，同時鼓勵多勞多得。
書本內(nèi)容相關(guān)問題
Q1：如何達到DOD標準？（第7章）
在設(shè)定了DOD之后, 受限于團隊的能力, 長期不能滿足DOD要求, 這個時候應(yīng)該怎么辦? 如果短期內(nèi)不能提高團隊能力的話, 又怎么樣團隊達到DOD標準?
教練：參考本書P120。里面有一句話很有意思：每個團隊都應(yīng)該確定一個針對自己的特定公司、產(chǎn)品或者情況的DoD。另外有個觀點供大家參考下：DoD是自組織的基礎(chǔ)。大家一旦根據(jù)團隊的情況制定出一致認可的DoD，他就能夠，也應(yīng)該像虛實線和紅綠燈一樣發(fā)揮作用。不管你是新司機還是老司機，都應(yīng)該自覺遵守。但是如果要違反，團隊是需要有相應(yīng)的處罰機制的。例如，每次發(fā)個小紅包。
用戶故事DoD分組練習(xí)
左隊：測試用例通過，文檔齊備
右隊：滿足，滿意。
ZYM：DoD應(yīng)該明確具體。給個例子大家參考一下：設(shè)計片段通過；代碼走查通過；UT/FT/ST編寫并通過；CI通過；相關(guān)BUG關(guān)閉；評審會通過。
Q2：ScrumMaster如何發(fā)揮作用？（第8章）
絕大部分開發(fā)人員受到傳統(tǒng)瀑布管理模式的影響, 往往會對ScrumMaster產(chǎn)生一種ScrumMaster就是傳統(tǒng)項目經(jīng)理的錯覺. 但是按照ScrumMaster的職責來看, 他往往是不具備那么多(甚至沒有)權(quán)力的, 在這種情況下, 作為一個ScrumMaster怎么才能更好的去推進一個項目呢, 怎么讓團隊成員遵從項目的安排呢?
YDW：要主動分享，要傾聽團隊的意見。
ZYM：本書P96有個觀點很準確。PO--驅(qū)動團隊；SM--保護團隊。給張圖大家感受一下（這張圖借鑒了中興通訊敏捷教練張瑩的觀點）：
Q3：敏捷里面，哪些實踐是必須的？（第9章）（5分鐘）
敏捷開發(fā)是一個框架或者說是模型，那么對應(yīng)的軟件開發(fā)方法，比如測試驅(qū)動開發(fā)，結(jié)對編程，極限開發(fā)等，對于敏捷開發(fā)而言是否必須的？
QHJ：CI（持續(xù)集成）+重構(gòu)。
ZYM：建議。初期，管理實踐+可視化。這樣對團隊的侵入比較小，可以先玩起來。中后期，特性團隊+持續(xù)集成。其實，引入敏捷實踐，最重要的是根據(jù)團隊的情況逐步引入。
Q4:為什么p2和p3的缺陷需要放入產(chǎn)品列表？（第13章）（5分鐘）
缺陷管理最好的辦法是實時修復(fù)，但為什么p2和p3的缺陷需要放入產(chǎn)品列表等待審核與確定優(yōu)先級
ZXJ：先做有價值的事情，影響不大的缺陷可以跟蹤起來。
YDW：跟蹤起來的主要目標是讓老板知道工作量（可視化）。
ZYM：提供另外一個參考。這個跟蹤起來，肯定是需要的。但是這些缺陷不一定要解決。假設(shè)這個迭代的交付物客戶驗收了，有部分需求不要了，恰好遺留的缺陷跟這部分需求相關(guān)，那么低優(yōu)先級的缺陷其實就不用再去解決了。
XH：TW對于缺陷的處理比較極致。如果出現(xiàn)缺陷，拉停研發(fā)線，然后補一個測試用例，修復(fù)并通過后，才能繼續(xù)研發(fā)。
W：CI，重中之重。
回顧會
ZYB：今天研討之后發(fā)現(xiàn)其實我們做的很多實踐，都屬于敏捷的范疇。例如持續(xù)集成，甚至我們做了微服務(wù)。但是我們不知道，也沒有人跟我們說，這些就是敏捷。今天懂了。
DW：通過對本書的學(xué)習(xí)，發(fā)現(xiàn)我們工作中的一些事情其實是有問題的。后續(xù)會嘗試在小組進行敏捷試點。希望后續(xù)這種交流可以多一點。
LH：從TEAM成員到現(xiàn)在負責開發(fā)團隊的敏捷推進，視角變了，想法也變了。以前是被動去做一些敏捷實踐，現(xiàn)在是想辦法怎么搞好。這本書內(nèi)容很多，是不是可以結(jié)合這邊書，多搞幾次類似的活動。
ZXW：通過看書有了大概的了解。通過這次的帶著實際問題的交流，有了更深的了解。
W：這本書有個很大的特點，就是每個主題都是用故事、模式和成功經(jīng)驗三段論在描述。我們看別人的故事，會比較沒有壓力。另外，敏捷其實可以用在很多方面，包括家庭。
ZXJ：希望后續(xù)能多分析一些項目中能落地的實踐。
QHJ：之前讀書時知道這些是什么。通過今天的討論，對一些內(nèi)容能夠理解WHY了。 希望大家能帶來團隊里能落地的方法、技巧。
LH：已經(jīng)在做敏捷了，今天收獲挺大。
YDW：希望后續(xù)多組織類似活動。主題不一定是scrum，可以靈活一點。包括聚餐都可以。
小遺憾
沒有合照……
