本書作者Henrik Kniberg以自己團(tuán)隊為例介紹如何實施Scrum走贪，從介紹最基本的如何編寫產(chǎn)品待辦事項大渤，到如何準(zhǔn)備計劃會吸耿，布置團(tuán)隊房間祠锣，如何開每日例會，怎樣做評審咽安，回顧會伴网，再到怎樣做發(fā)布，測試和管理多團(tuán)隊妆棒。這本書不是說教式的講解理論知識澡腾，而是通過作者團(tuán)隊的成功案例來介紹怎么做的，我們當(dāng)然要學(xué)習(xí)的是最佳實踐糕珊，而不是單單停留在理論空想蛋铆。
這本書適合小白讀，也適合有scrum經(jīng)驗的人們讀放接，你總會得到新的思路刺啦，想法和啟發(fā)。
怎樣編寫產(chǎn)品backlog纠脾，在這一章節(jié)中介紹了作者團(tuán)隊編寫產(chǎn)品待辦事項的方法玛瘸，除了基本的介紹和舉例蜕青，令我受到啟發(fā)的是在編寫backlog的時候會定義這個backlog在驗收時如何演示，這是我們從來沒有思考過和實踐過的糊渊，我個人認(rèn)為在backlog里面添加這一字段真是令人眼前一亮右核，它能讓需求更加明確，讓團(tuán)隊很輕易的達(dá)成一致理解渺绒，真是太棒了贺喝！
怎樣做planning中，提到了很多計劃會議中的細(xì)節(jié)宗兼。例如躏鱼，提到了每個故事的三個變量的平衡，范圍殷绍，重要性和估算染苛，其中范圍和重要性由PO負(fù)責(zé)，估算由開發(fā)人員負(fù)責(zé)主到，那么還有一個變量質(zhì)量呢茶行，當(dāng)然不可忽視，它由整個團(tuán)隊負(fù)責(zé)登钥，當(dāng)估算和PO預(yù)期不符畔师，是犧牲質(zhì)量還是縮小范圍，顯而易見牧牢。還提到了sprint的時間長短哪種更好呢看锉，它各有好處，最終還是要找到團(tuán)隊適應(yīng)的節(jié)奏结执，共同的心跳頻率度陆。對于sprint的目標(biāo)艾凯，好像我的團(tuán)隊從來沒有認(rèn)真對待過献幔，即使是敷衍都沒有過，反思我們到底有沒有認(rèn)真想過我們?yōu)槭裁匆M(jìn)行這個sprint趾诗？就像作者說的不如直接放假算了蜡感。對于估算了解到還有直覺估算的方式，雖然適合小團(tuán)隊恃泪，但是似乎也很有意思郑兴，有機(jī)會可以嘗試一下。還提到了像很多名詞“昨日天氣”贝乎，“投入程度”情连，其實在項目實踐中都有用到，只是不知道還有專門名字表達(dá)他們览效。：）甚至細(xì)節(jié)提到了計劃撲克的使用却舀，你有沒有真的思考過紙牌里0代表什么虫几，？又代表什么呢挽拔？
怎樣寫sprint backlog一章中辆脸，印象深刻的是關(guān)于燃盡圖，因為在工作中也經(jīng)常向公司敏捷社區(qū)交付scrum培訓(xùn)螃诅，在講解燃盡圖的時候一直以來都是在說識別風(fēng)險拿出去交付不了的故事啡氢，從來沒有意識通過燃盡圖識別需要增加故事的情況，也恰恰說明在日常工作中忽略了這一點术裸。
布置房間一章中倘是，提到讓團(tuán)隊坐到一起，是的穗椅，深有體會辨绊，我們團(tuán)隊每天靠的很近，甚至有時候吼一嗓子就可以“把事辦成”匹表，以及讓產(chǎn)品負(fù)責(zé)人的座位不要離團(tuán)隊太近门坷，這個真的切中要害，產(chǎn)品負(fù)責(zé)人離團(tuán)隊太近很難不關(guān)注細(xì)節(jié)袍镀，也影響團(tuán)隊凝聚力默蚌，深有體會。
每日站會中苇羡，提到當(dāng)有人不知道做什么時候绸吸，scrum master該如何做，以往我選擇的是守舊式做法會去找事情給他們做设江，看到作者的建議后覺得還是有很多其他方式可以嘗試锦茁，羞辱式，施加同事壓力叉存，奴役式码俩，仿佛打開新世界的大門。
在sprint review中歼捏，很同意作者觀點稿存，即使很一般的演示，也會帶來深遠(yuǎn)的影響瞳秽，我們了解了真正完成的事瓣履，得到了認(rèn)可，也吸引了干系人的注意练俐，演示在某種程度上也是團(tuán)隊交流互動的機(jī)會袖迎。參加過很多團(tuán)隊的review會議，很多團(tuán)隊并沒有意識到到底演示什么，演示一定是基于業(yè)務(wù)層次燕锥，做了什么浴韭，而不是技術(shù)細(xì)節(jié)的怎么做的，以及修理的bug和維護(hù)的邊邊角角就無需演示了脯宿。
sprint 回顧念颈，作者認(rèn)為是scrum中第二重要的事件，第一是計劃會議连霉，因為它是團(tuán)第改進(jìn)的最佳時機(jī)榴芳。很多書中都專門介紹如何做回顧，這本書中作者提到一個“知識橋梁”跺撼，團(tuán)隊中需要這樣一個人做為知識的橋梁參加所有團(tuán)隊的回顧會在團(tuán)隊中傳播經(jīng)驗窟感，實踐起來雖然很難，但不得不說很棒歉井，值得借鑒柿祈。
組合使用scrum和XP，我們團(tuán)隊從最初轉(zhuǎn)型到現(xiàn)在進(jìn)入擴(kuò)展框架哩至，成功的轉(zhuǎn)型的確得益于scrum和XP相結(jié)合的方式躏嚎，scrum注重管理和組織實踐，XP關(guān)注實際的工程實踐菩貌，他們互為補(bǔ)充卢佣。結(jié)對編程，測試驅(qū)動開發(fā)箭阶，代碼重構(gòu)虚茶，持續(xù)集成的確幫助提升了產(chǎn)品質(zhì)量，最直接的數(shù)據(jù)是產(chǎn)品上線后的bug率以及用戶提出問題比以往的降低很多很多仇参。開始很難嘹叫，但一旦開始做就好起來了。最重要的是一定不要加班诈乒！
測試階段罩扇，開發(fā)人員通常是最差勁的測試人員，尤其是測試自己的代碼抓谴，想到當(dāng)前項目暮蹂，因為測試人員少寞缝，每個故事的測試用例要求開發(fā)人員提供癌压，我看過很多開發(fā)人員寫的測試用例，非常的技術(shù)角度荆陆，十分危險滩届，想了很多辦法改進(jìn)，但仍然是個風(fēng)險。
在怎樣管理多團(tuán)隊中帜消，提到寧可團(tuán)隊數(shù)量少棠枉，人數(shù)多，也比弄上一大堆總在相互干擾的小團(tuán)隊強(qiáng)泡挺。聯(lián)想到自己當(dāng)前的項目辈讶，一個scrum團(tuán)隊光開發(fā)人員就有十幾個，這簡直太恐怖了娄猫，一開始真的很頭疼贱除，一個站會能開四五十分鐘，一度很想拆分團(tuán)隊媳溺，當(dāng)深入探討后月幌，一但拆分，小團(tuán)隊間可見一定會有很多相互干擾悬蔽，得不償失扯躺，所以目前看來雖然很痛苦，但保持現(xiàn)狀是最好的選擇蝎困。
以上是我在初次讀這本書后的記錄和感想录语，相信當(dāng)過一段時間幾個月幾年后再讀，一定會有更多不一樣的感受禾乘，非常同意翻本書譯者李劍在序中所寫：敏捷不是說出來的钦无，是干出來的！
