前言
这次读书会来得非常突然。
某天：重庆敏捷之旅群成员过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问题转换：如何与团队进行问题处理？
左队：通过沟通，分析问题的本质；通过一系列方法（鱼骨图等），找到问题的根因，进而找到对应的解决方案；而且这个过程是可以不断迭代的。
右队：要先对问题进行分类，然后进行优先级决策；对于优先级高的，需要立即去解决，而且要定责任人。问题
