前言
这次读书会来得非常突然。
某天：重庆敏捷之旅群成员过100，清华大学出版社的文老师马上发布消息说送我们书籍。
接下来就是顺理成章了：明确读书会的要求——>秒名额——>个人读书——>线上问题收集——>线下集中交流。
如果一定要说这次读书会有什么特殊的，就是我们进行了线上问题收集。
关于读书，我们认为有两点很重要：1）搞清楚书的内容 ；2）解决（实际）问题。
在问题收集环节，其实我内心是忐忑的，我非常担心我们重庆的软件从业者，会比较内敛，不愿意提交问题。但结果令人兴奋，我们收集到9个问题，并且其中大部分问题非常具体、非常有代表性。这9个问题，就是这次读书会的主角。
所以，请允许我们感谢一下参与读书会的小伙伴。你们的积极参与是这次读书会顺利进行的关键！
《scrum实战》读书会实录
破冰游戏
这次读书会的小伙伴，基本上都是第一次见面。为了后续讨论环节更有效，我们通过一个画手连线的小游戏让彼此认识一下。
在这个环节中，我们发现100%的人都来自研发相关岗位（希望后续有产品、测试、运营等加入进来）；70%以上没有出游计划，喜欢家里蹲；比较反常识的是，80%的研发小伙伴都喜欢运动。另外，这次连接达人的夺冠数目是22条连线。
实际工作中的问题
Q1:如何解决研发过程中重复的恶心循环？
一个项目的正常开发流程为：原型设计-》UI设计-》功能开发-》产品交付。
实际工作中的流程却是：原型设计-》UI设计-》功能开发-》产品交付（客户不满意，修改功能）-》功能修改（UI又不满足）-》UI重新设计这样一个重复的恶心循环。
有段时间，我个人一直认为这是原型设计的不合理与客户的反复修改造成的一个恶性循环，直到有一天有人跟我说了一句话：“所以都有一个坏毛病，我只要把功能完成，就可以了”。是的，在我个人的开发工作中这样的心态确实是有的，项目的开发周期越紧，这样的心态就越严重。
1）引导客户。在前期跟客户确认好，不允许变更。但是存在客户不满意的情况。
2）XH：之前是没有循环，到一个循环，到多次循环。这是量变引起质变。我们通过缩小反馈周期，可以更好的适应客户需求变化。
3）ZYM：参考本书第30章，我们可以得到如下的一张图。
Q2：在开发过程中，应该如何来理解功能？
在编码开始之前，我应该思考哪些问题？
提问者的思考方式为：1、思考功能业务流程。2、数据验证。3、数据存储。
左队：梳理技术难点（包括研发路线）；判断时间风险，要给后续留缓冲；要写出用户故事。
右队：通过业务--技术--干活（编码）--评审 来搞定需要研发的功能。并且需要注意树立各功能之间的关系。
ZYM：参考本书P205，其中体现了用户故事三要素：角色、功能、价值。传统的研发管理，容易聚焦功能，而忽视了用户和价值。实际上，从商业目标的角度看，我们的软件不是由于他有功能就有价值，而是因为实现了用户价值才有价值。所以建议大家后续尝试从典型用户开始进行需求的梳理。如何找出用户故事，具体方法有用户旅程等。分析用户故事的具体方法可以参考《用户故事和敏捷方法》。
Q3：敏捷转型如何启动？
对于正在进行中的项目，是否有办法切换至敏捷开发？或者说暂时没有新项目时，如何逐步将敏捷开发引入到日常开发中来。
右队：关键词是理解、支持、信任。一定要取得领导的支持。
左队：自上而下（老板的支持）。自下而上，同时结合培训、学习，让团队实施（承诺）。
ZYM：各小组说都很重要，但是到具体怎么行动（具体的步骤）而言，还是比较宽泛的。实际上，我们可以按照本书的第5-8章+17章+可视化落地。具体而言，就是确定PO、SM、TEAM三大角色，确定迭代周期，确定DOD，站会+可视化。当然，如果能把计划会、评审会、回顾会也一起开起来，那就更好了。
Q4：如何与团队进行问题预处理？
提问者的解决方案：遇见问题，思考问题，解决问题。
ZYM问题转换：如何与团队进行问题处理？
左队：通过沟通，分析问题的本质；通过一系列方法（鱼骨图等），找到问题的根因，进而找到对应的解决方案；而且这个过程是可以不断迭代的。
右队：要先对问题进行分类，然后进行优先级决策；对于优先级高的，需要立即去解决，而且要定责任人。问题解决后要有回顾和总结。
ZYM：本书第279页有个案例，大家可以先看一下。从这个案例来看，其实给人这样一种启发。解决问题有两大挑战。其一是找到问题的解决方案；其二是暴露问题。第二个挑战往往容易被人忽视。实际上，我们的团队都很厉害，只要是具体的问题，我们都能去解决它。但是隐藏的问题，就没有那么好解决。敏捷，在某种程度来说，最大的效用不是解决问题，二是暴露问题。跟精益一样，敏捷通过限制在制品数量，可以有效的将研发过程中的问题暴露出来。有个经典的比喻“湖水与岩石”，我们的积压的在制品就像湖水，问题就像岩石。只有当水面降低后，岩石才能逐渐暴露出来。
ZYM：对于如何定义和解决问题，有本书推荐大家看一下《你的灯亮着吗》。
Q5：如何解决敏捷自组织和成员参差不齐的矛盾？
敏捷讲究的是全员参与，集体制定进度和分工等，如果团队中新人较多(对整体框架不熟悉)，队员能力参差不齐，该如何应对？
ZYM问题转换：1）新员工较多的团队进度（计划）如何确定？ 2）如何分工（分任务）
左队：1）“走着瞧”。2）鼓励主动选，但是实际情况是领导安排。
右队：1）“走着瞧”。2）根据兴趣、特长领取+主管分配。
ZYM：对于分工的问题，有个实践给大家参考下。就是团队对于某项任务，根据自己的能力进行评估，这项任务的工作量取大家评估的算术平均。同时，评估工作量最少的那个人有优先领取权。通过这个制度解决了主管和员工之间的评估矛盾，同时鼓励多劳多得。
书本内容相关问题
Q1：如何达到DOD标准？（第7章）
在设定了DOD之后, 受限于团队的能力, 长期不能满足DOD要求, 这个时候应该怎么办? 如果短期内不能提高团队能力的话, 又怎么样团队达到DOD标准?
教练：参考本书P120。里面有一句话很有意思：每个团队都应该确定一个针对自己的特定公司、产品或者情况的DoD。另外有个观点供大家参考下：DoD是自组织的基础。大家一旦根据团队的情况制定出一致认可的DoD，他就能够，也应该像虚实线和红绿灯一样发挥作用。不管你是新司机还是老司机，都应该自觉遵守。但是如果要违反，团队是需要有相应的处罚机制的。例如，每次发个小红包。
用户故事DoD分组练习
左队：测试用例通过，文档齐备
右队：满足，满意。
ZYM：DoD应该明确具体。给个例子大家参考一下：设计片段通过；代码走查通过；UT/FT/ST编写并通过；CI通过；相关BUG关闭；评审会通过。
Q2：ScrumMaster如何发挥作用？（第8章）
绝大部分开发人员受到传统瀑布管理模式的影响, 往往会对ScrumMaster产生一种ScrumMaster就是传统项目经理的错觉. 但是按照ScrumMaster的职责来看, 他往往是不具备那么多(甚至没有)权力的, 在这种情况下, 作为一个ScrumMaster怎么才能更好的去推进一个项目呢, 怎么让团队成员遵从项目的安排呢?
YDW：要主动分享，要倾听团队的意见。
ZYM：本书P96有个观点很准确。PO--驱动团队；SM--保护团队。给张图大家感受一下（这张图借鉴了中兴通讯敏捷教练张莹的观点）：
Q3：敏捷里面，哪些实践是必须的？（第9章）（5分钟）
敏捷开发是一个框架或者说是模型，那么对应的软件开发方法，比如测试驱动开发，结对编程，极限开发等，对于敏捷开发而言是否必须的？
QHJ：CI（持续集成）+重构。
ZYM：建议。初期，管理实践+可视化。这样对团队的侵入比较小，可以先玩起来。中后期，特性团队+持续集成。其实，引入敏捷实践，最重要的是根据团队的情况逐步引入。
Q4:为什么p2和p3的缺陷需要放入产品列表？（第13章）（5分钟）
缺陷管理最好的办法是实时修复，但为什么p2和p3的缺陷需要放入产品列表等待审核与确定优先级
ZXJ：先做有价值的事情，影响不大的缺陷可以跟踪起来。
YDW：跟踪起来的主要目标是让老板知道工作量（可视化）。
ZYM：提供另外一个参考。这个跟踪起来，肯定是需要的。但是这些缺陷不一定要解决。假设这个迭代的交付物客户验收了，有部分需求不要了，恰好遗留的缺陷跟这部分需求相关，那么低优先级的缺陷其实就不用再去解决了。
XH：TW对于缺陷的处理比较极致。如果出现缺陷，拉停研发线，然后补一个测试用例，修复并通过后，才能继续研发。
W：CI，重中之重。
回顾会
ZYB：今天研讨之后发现其实我们做的很多实践，都属于敏捷的范畴。例如持续集成，甚至我们做了微服务。但是我们不知道，也没有人跟我们说，这些就是敏捷。今天懂了。
DW：通过对本书的学习，发现我们工作中的一些事情其实是有问题的。后续会尝试在小组进行敏捷试点。希望后续这种交流可以多一点。
LH：从TEAM成员到现在负责开发团队的敏捷推进，视角变了，想法也变了。以前是被动去做一些敏捷实践，现在是想办法怎么搞好。这本书内容很多，是不是可以结合这边书，多搞几次类似的活动。
ZXW：通过看书有了大概的了解。通过这次的带着实际问题的交流，有了更深的了解。
W：这本书有个很大的特点，就是每个主题都是用故事、模式和成功经验三段论在描述。我们看别人的故事，会比较没有压力。另外，敏捷其实可以用在很多方面，包括家庭。
ZXJ：希望后续能多分析一些项目中能落地的实践。
QHJ：之前读书时知道这些是什么。通过今天的讨论，对一些内容能够理解WHY了。 希望大家能带来团队里能落地的方法、技巧。
LH：已经在做敏捷了，今天收获挺大。
YDW：希望后续多组织类似活动。主题不一定是scrum，可以灵活一点。包括聚餐都可以。
小遗憾
没有合照……
