得益于上家公司对于敏捷流程的严格要求，使得我在敏捷标准化这块比较敏感，因此入职新公司以来，陆续发现了一些问题。我们团队的敏捷可以说是画风跑偏了的，可能团队的一些成员对敏捷有哪些关键活动也还不太清楚？我就主要谈谈自己对敏捷的理解，也是对敏捷实践的一些总结。
1、梳理会议
产品经理会进行本次迭代的业务背景讲解，告知团队本次迭代内容的来由及价值。这样可以督促团队成员往前走一步，从业务价值角度思考自己负责的内容是否合理。比如开发人员，就不仅仅局限在实现功能上，而是可以思考该功能是否符合业务、是否是用户想要的，是否达到了迭代要求的“价值”。
会议的输入即是本次迭代用户故事，需要团队成员充分参与讨论，确保所有业务点理解一致，为后面评估故事点打基础，也可以避免后续开发的返工。记得某次迭代中有个“曾在职公司”的搜索功能，当时就是我对该需求理解有偏差，导致功能提交后测试有疑问，然后又拉着产品、测试一起三方讨论明确方案，折腾了不少时间。
估算用户故事，是估算其故事点数（规模、大小）而非时间，时间是一个细节性的指标，不适合在梳理会上给出，点数则是一个比较性的指标，通过与标准故事（点数为1）做规模上的比较，得出用户故事点数，然后与以往团队速率做比较，圈定本次迭代可以包含的用户故事。
这是一个由团队成员一起对产品经理提出的用户故事进行打磨的过程，绝不仅仅是传递需求、接收需求，应当是理解需求、完善需求。目前我们团队在需求讨论和估算方面都是有问题的，抛开时间不足的因素，团队成员对产品现有代码和功能不熟悉也是原因之一，另外意识上也需要从被动转为主动，梳理会上多积极思考。
1.1、用户故事及验收标准
用户故事三段论：作为xx角色，使用xx功能，达到xx价值。我们目前的用户故事写法并不规范，且偏向功能。用户故事应从业务点出发，用简洁的语言准确描述需求及价值，不涉及UI和实现。
什么是验收标准？决定一个用户故事达到完成状态的最小功能集或测试规则。确定好验收标准，可以避免测试过于陷入细节问题，当然，没有问题的发布是最好不过了，只是实际中会因为这样那样的问题导致发布延期，那么我们应当优先保证验收标准的内容测试通过，其余问题可考虑放入下个迭代消化掉，并不需要追求完美发布而不断延期，与其延期不如拆成多个小迭代也是可以的。另外一方面，验收标准也是保证产品、开发和测试对业务理解一致的一个有效手段，达到了验收标准的功能，是不会和发布目标有多少偏差的。
1.2、业务驱动开发
个人认为开发有一点也是很重要的一点，就是要契合业务。在领域驱动设计中，是由业务模型来驱动开发设计，代码要能很好的呈现出业务。自顾自的做代码设计而不考虑实际业务场景，是写不出高可扩展性代码的，甚至会做无用功。利用已有经验设计出满足现有及未来短期的业务变化的代码，才称得上是聪明的代码，而这一前提则是，确保自己对业务理解到位。
2、计划会议
有了上面梳理会的准备，团队成员便可以快速、准确的安排迭代计划了。这时需要对用户故事做功能点的拆分，对开发时间做估算，然后安排任务提交节点。不建议在此时明确任务责任人，敏捷提倡当天任务当天认领，我们不能只关注自己的任务。这个活动我们做的还是比较到位的。
2.1、开发实现讨论
敏捷并没有这个活动，但我强烈建议加上。开发实现讨论是集开发团队成员头脑风暴，来将需求落实到代码实现，需要至少全部开发人员参与，在计划会议后、迭代开始前展开。
一个人的思维总是有盲区的，团队的重要性就此体现，确保所有开发人员对所有功能实现的理解一致性，同时再一次确保对业务理解的一致性，避免中途任务换人结果就抓瞎了，或是代码审核时出现场景遗漏、非最优实现的尴尬境地。这也是为什么不要在计划会议上认领任务的原因，避免团队成员忽视自己之外的任务。
大家可以回想以往的迭代中，或是代码审核时，有多少个返工是可以在迭代早期就避免掉的？
3、每日站会
站会汇报对象是团队而不是个人，敏捷讲究自组织团队，站会也应是团队级的总结和交流，是需要让团队其他成员了解你做了什么、还有什么问题。让产品经理知道哪些功能已经测完，可以提前去体验；让测试了解哪些功能已经提交，可以开始测试；让开发人员知道目前的开发进度，是否需要作出调整。
虽然我们现在晨会是站在一起大家一起听，但形式上还是在向负责人汇报（注意，“汇报”这种形式就已经不太正确了，偏向管理式协作，而非自组织，站会是用来“交流”的），这种形式一定程度上会让其余成员忽视汇报内容，在团队协作上会带来卡顿。
3.1、燃尽图
燃尽图是直观呈现团队迭代是否健康的重要依据，可以及时的暴露迭代存在的问题，反映出团队步调是否一致，是否需要调整节奏。可惜的是，我们的燃尽图在后期咋就没了？
3.2、当面沟通的重要性
我们似乎太依赖在线上沟通问题，明明只隔着几步路？比如提交个pr反复reply不觉得很浪费时间吗？有时代码审核，看大家在群里通过各种截图回复对方我表示很焦灼啊，其实当面沟通清楚，然后reply一下结论，觉得有必要可以在群里把结论再发一遍就好了。
重沟通，更重沟通效率！
还有一点，复杂问题要三方讨论，哪三方？开发、测试和产品经理，得出结论后，如果有相关人员未参与讨论，也需要告知他们。保证信息透明化，这是团队协作中非常重要的一点。
3.3、2个习惯
- 提交代码前，一定要编译通过
- 一定要审视提交了哪些文件，再对比下差异代码（查漏补缺）
4、评审会议
给产品经理/用户演示本次迭代完成的功能，评审是否达到发布要求（验收标准），是否完成预期目标，有哪些功能是不达标需要及时修复的，有哪些是可以容忍而进入下个迭代需求池的。
那产品经理在这个阶段才去验收迭代成果，是不是迟了些？是的。所以，一般会建议产品经理在迭代过程中随时体验已完成功能，及时反馈，在评审会议就可以放心的过一遍最终成果了。当然现在公司产品经理人手不足也是很为难了。
5、回顾会议
个人认为这个是整个敏捷流程的重中之重，是为当前迭代划下句号的环节，也是决定下一个迭代能否健康进行的环节，承上启下。然而我们做的并不好......
总结本次迭代不足之处，流程方面的、技术方面的、协作方面的等等均可，只要是迭代中遇到的问题，都可以提出来讨论。这也是督促大家对自身、对团队如何进步的思考。
会议输出可以挑选最重要的3项（Top3）做为下次迭代改进项及下次回顾会议的输入，这样才能更好的让一个个迭代连续的滚动起来，团队也可以逐渐完善起来。
5.1、对Bug进行分类总结
这是一个建议，将迭代产生的Bug也作为回顾会议输入，并不追究责任人，而是作为团队问题讨论，个人有则改之无则加勉。另外，jira中也建议填写上Bug产生原因和解决方案，保证后续发生同样问题任何一个开发人员都可以迅速解决。
可以看出，敏捷迭代就是一个个连续的PDCA循环，Plan计划、Do执行、Check检查、Action行动，分别对应计划会议、迭代开发、评审会议和回顾会议。把迭代看做一个轮子，敏捷方法就是保证这个轮子尽可能的圆，而轮子的持续滚动，则是靠团队成员一起产生推动力了。
其实还有许多东西可以写，但考虑到这并不是一份教程而只是吐槽兼总结（虽然也没怎么吐槽），就算了吧。
还是那句话，一个人的思维总是有盲区的，团队要玩好敏捷，还得靠大家集思广益、一起努力！