引子：
这是个人在学习ACP相关知识后，在项目团队发起的第一个尝试用Scrum方式来运作的迭代的回顾会上的记录内容。当时也没有老鸟，就是边学边用，还有容纳旧组织习惯的行为模式。作为小白的成长记录吧。现在看起来，削足适履的痕迹很明显。但，谁不是小白走起来的呢？
第一次迭代回顾会时候的惊喜，到现在2年了，至今还有最深的印象：原来我们团队有这么多优点！（显化的价值！）
——————————————————————————————————————————
首先非常感谢大家的努力和支持，我们团队再磕磕碰碰中，勉强的走完了一个有敏捷意义的开发历程，在本周五下午我们做了一个Sprint的总结，此处对我们团队总结的内容做了一下分析和探讨，现将结果与大家分享，望后续的活动中我们继续优化与提升，塑造一个更好的自己，打造一个更好的团队。
一、Sprint成果
我们在本次迭代中，用了11天（12/3-12/17），7个开发人员（5个后台+2前端），完成故事点106个。
按照正常的一个迭代为2周，80%的功能实现时间，一个迭代工作日应该为8天。11天的一个迭代过程，可以换算为1.375个迭代。
由此得出我们这个7人开发团队速率为77个故事点/迭代。人均速率是11个故事点/迭代。其中，我们认为1个故事点的规模为“一个增删改查的后台逻辑实现”，前端的2个故事的规模位“一个增删改查的前端实现”。
至此，我们再进一步分析，我们目前对开发的执行中缺少了：测试、bug修改的严谨遵守、也缺少了个人对任务的承诺和探索（仍是由A同学安排每天任务及指导技术方案，整体的技术实现考虑在12月3号正式迭代前做了）。如果完全遵循敏捷Scrum的实践要求，目前的团队速度应该为当前的50%。则最终得出能比较切合我们团队的当前速度是：
二、Sprint收获：
三、Sprint需要继续努力的方向
1、个人行为：
1）提升点：多参与业务理解、实现细节方面多思考、个人要更细心已减少bug、思考要全面、改善上午的工作效率、多讨论与分享。
2）应对计划：个人自行注意提升。
2、团队能力：
1）提升点：使用更高效的工具、组件化开发、接口开发优化和规范
2）应对计划：A同学与B同学为下个Sprint的提升责任人，学习自动化工具，在下个迭代中进行分享至少一次。组件化开发暂时由个人自助优化代码，项目开发完成后再统一规划。
3、团队管理：
1）提升点：任务领用方式需要改为自行领任务，TB上一个迭代的任务做完了需要及时增加任务、开会时间较长、需求理解能力加强、增加个人开发内容的测试（准备测试数据或者流程）、沉淀好的做事习惯成为团队工作流程。
2）重点问题分析：因为成员对任务不理解，所以不赶主动去领取任务；因为前期的需求评审会议没有最终开下去，所以成员对需求及任务并不能理解；因为需求拆分的不合理，所以造成开会时间长开会多但是最后也没有成功的完成任务拆分和评审；同时也因为需求分析时候没有识别出测试要点，则无法在开发中进行清晰的测试。按照“用户故事”的相关书籍介绍，无法对用户故事进行估算，有三个原因：开发人员缺少领域知识（对业务的理解）、开发人员缺少技术知识（需要用新的技术或者方案）、故事太大了。
3）应对计划：
① 把需求拆分到“适合大小”的用户故事：按照书籍建议适合大小的用户故事是“一两名开发人员用半天到两周能完成的”但是对于我们团队的情况反映，我们最好能把用户故事拆分到一名工程师1-2天就能完成的大小。然后再发布给开发团队进行评估。对用户故事大小的识别，需要需求工程师与开发代表在会前讨论确认先。特别对于我们团队目前的情况，C同学需要花更多的时间来与A同学沟通，逐步积累对故事规模判断的经验。
② 对需要探索技术实现方法的用户故事，拆分为“探针”任务与“功能实现”。在一个Sprint中，先执行“探针”任务，探针任务预研结束后，确认了开发实现的方法，再把“功能实现”的任务加入后续的Sprint中来实现，以为确保任务的清晰。
③ 改善团队会议时间：对于评审会，需要先确保评审内容的准入性，再召开全员参与的会议，例如：确认了本次Sprint需要完成的用户故事，而非把所有用户故事都摆出来评审分散参会者的注意力；确认本次讨论用户故事拆分到了适合的大小，而非在会议上才讨论这个故事里有多少内容需要实现。
④ 需求信息整理的方式改善：
a、需求工程师后续考虑使用“便签纸”记录初始的用户故事。
b、需求工程师需要维护一份不在TB上的ProductBacklog，以迭代刷新
c、需求工程师需要拿到一份“SprintBacklog”，无论是从项目经理处获得还是从客户处获得，用以界定一个迭代里要完成的工作范围。
d、需求工程师需要与开发代表加强沟通，拆分适合大小的用户故事。
⑤ 开发人员对适合大小的用户故事的评估能力提升：在用户故事已经拆分的适合大小的情况下，通过“探针”来解决问题之后，如果开发人员仍然未有能评估得了用户故事的实现问题，需要京华介绍指导开发人员的技术能力提升。如果经一段时间无法改善，我们需要评估该成员的能力是否存在不适合岗位要求的情况。
4、更深一步的探索：
在经历本周三上午技术经理A同学、需求分析师C同学与项目经理D同学三个人的讨论后，针对我们的“持续交付”问题进行的总结。按照团队保守的38.5个功能点的开发速度（当时我们规划的是一个功能点为“一个增删改查的后台实现”大概为半天能完成的），如果用户故事大小为一天能完成工作量，那么意味着要保持团队的持续交付能力，需求工程师需要在一个Sprint中完成下一个Sprint的大约20个用户故事的确认。但是照目前的政府类项目来说，此工作模式不太适合。政府类项目都需要在开发前提供完成的详细的“需求规格说明书”后，才能进入开发阶段的。此情况与敏捷的应用结合由D同学后续继续探索。
