解决后要有回顾和总结。
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：今天研讨之后发现其实我们做的很多实践，都属于敏捷的范畴。
