以下仅是我本人在敏捷方面的实践经验，仅供参考。。
方法论先进性问题
来源https://insights.stackoverflow.com/survey/2017#development-practices
每日站会（一直在践行）
- 昨天为冲刺做了什么
- 今天为冲刺要做什么
- 遇到什么阻碍冲刺的事情了
sprint == 迭代周期 ==冲刺
每一个迭代周期一般时间固定。
我们在第一次使用Scrum进行项目管理时，并没有看Scrum的规则，从直觉上做了以下几件事，巧合的是，跟Scrum中项目的前期准备sprint0 很多地方是一致的，这让我们后期切到Scrum更加顺滑。
我们在准备阶段，分别让
- 前、后端包括UED进行了架构设计，产品设计文档
- 进行了一些技术难点和问题点的调研
- 也有了第一个release的发布计划
- 初步的backlog
- 和测试、产品一起同步数据的抓取方案
不过还缺少审核检查表等。（缺的不多）
与产品梳理故事，并对故事的优化级进行了排序
将不同故事安排在不同的sprint中
评估时间
第一次评估故事和开发时间，是用计划扑克，将故事点和开发人天设置为一样，这样做是为了大家方便理解，先试用一次，并且是我自己将story拆分成task的。从第二次开始，将故事点和开发时间分开评估，由大家一起将story拆分成task,然后由大家认领task，交给最适合做这个task的开发同事。再根据task，每人分别评估开发时间。
与测试一起制定测试与开发周期的结合点，这块并没有完全按照scrum的方法做，我的做法是想尽量让测试与开发并行，将测试与开发的工作周期拉开一周，原因是在早期项目的开发节奏较快，任务比较多。
与UED一起制定了UED与开周期的结合点，UED整体早开发一个周期，这样当开发进行到一定任务时，UED已准备好。
通过 以上两点 设计、开发、测试 的工作周期能够比较好的咬合在一起，当然实际效果要在日后的工作中持续检验。
产品可以持续在backlog中添加待办事项，同事们就可以排sprint来进行一个又一个周期的安排。然后开发的同事们来具体实施完成。
“鸡”在scrum中不能说话。
鸡可以观察每日Scrum，但不能够参与 参考文章：https://cloud.tencent.com/developer/article/1073880
在开发中发现很多细节问题，这些问题都是在需求及设计阶段没有讲清或更新不及时导致的，所以在流程中又加入了评审过程。
评审分两块：
1：需求+设计 ，这部分的评审我们将需求和设计结合起来一起做，因为产品和UED是在开发的前一个周期的，所以时间上是有的，另外，二者合起来对于开发接收的信息更完整，更利于开发的顺利介入。评审时间是在开发拆分story之前。
2：测试评审，具体就是针对测试用例进行评审，主要目的是使开发和测试对所做的东西有一个一致的认识，让不同角度的双方进行一轮信息的交流，达成共识。评审时间是在开发的中前期，具体时间由测试负责人决定。
加入了验收人和验收时间，在每一个sprint结束后需要验收人来进行验收，我们并没做全员的成果演示，简化些流程，只做产品的验收。但是会在大版本发布前做一个多功能的成果演示。目的是让全员对产品成果有概念，让参与的同事有成就感。
验收人员由产品改为 产品+UED
在提测前加入了UED走查，这样UED在评审、走查、验收三个环节都有机会介入校验开发的成果是否和设计一致。
召开了敏捷回顾会议，通过总结
- KEEP（做的好的，要保持的）
- CHANGE（做的不好的，需要改进的）
- TRY（可以尝试的）
产出了 action list ,为后面每一个sprint的行动
keep change try 每人每项最多列举三项，然后大家匿名贴在白板上（反过来贴，字在里面）可以消除大家的心理障碍。开会时，主持一张一张的读出来，然后大家发言讨论下，直到最后一张讨论完，总结出ACTION LIST。
将bug fix的修改周期和提测周期粒度拆细，由原来的按sprint算，改为在一个sprint中分功能多次提测，在重要sprint中，按照当时项目的情况灵活掌握，具体来说就是:bug按优先级灵活处理,重要的先处理，排进当前sprint故事中，不重要的暂时搁置。
调整了故事和任务的粒度
因为经过了几次迭代后，大家对开发的模式很清楚了，在互相信任的前提下， 我们提高效率，减少了录入整理和频繁的看板操作，将任务的粒度变粗，而故事的任务变粗可以方便拆分成有意义的任务，否则如果故事太细，任务不好拆分，就算拆分了也意义不大。比如一个关注功能，虽然可以拆分成数据库设计、缓存设计、接口契约制定、实现，前端实现，后端逻辑实现，但如果所有故事都这么干，任务量太大和对任务的管理就会比较麻烦。
有关敏捷的思考
敏捷开发不是偷工减料，不是贪图速度。只是因为每一个人相对独立后，减少了沟通成本，从效果来讲变快了。如果在工作中，不做防范（写文档，测试，测试用例），一味降低成本。后来人走了，接不上，成本更高。
