敏捷，每个人都有自己的理解
2018年一直在尝试用敏捷的方式来管理团队，但执行的不够彻底，或者说不那么敏捷。 总结下来有下面一些问题：
- 每日站会没有能坚持下去，后面退化到一周一次了;
- 没有合适的看板，这可能是导致站会没坚持下去的原因；
- 需求都被分解成任务记录在
GitLab中，每个人员都以完成任务为导向，以至于不能清晰的了解需求； - 有大的里程碑，但缺少小的迭代周期。
最近看了一些阿里关于敏捷开发的视频，很受启发，所以决定在2019年作出一些改变：
- 每日站会要重新启动起来，强制执行，主要针对看板沟通下需求完成情况；
- 以需求为导向，而不是以任务为导向，将尝试采用腾讯的
Tapd来管理需求； - 每个需求设置需求负责人，负责人对该需求的交付负责；
- 引入迭代（周期不能太长，1 周或 10 天，视情况而定），让团队每个人都有阶段性目标。
站会
站会的核心目标是促进需求的顺畅流动，团队的目标是能快速的交付需求。在站会上我认为主要做三件事：
1、及时发现并处理阻碍事项，看板中的每一个阶段应该是均匀的，就像是流水线一样，从最左边的待处理需求到最右边的交付应该均匀而稳定的流动，如果某一个环节出现了堆积或中断，那就说明出现问题了，需要分析出原因并解决；
2、聚焦完成，看板的关注点从右往左，着重分析哪些任务应该交付了而没有交付；哪些bug还不能测试通过；哪些任务存在着风险等；
需求如果能正常稳定的流动，则能及时发现和解决问题；反之，如果需求出现积压或中断，问题也会随之隐藏，风险也会随之变大。
站会因为每天都会开，所以时间上要做控制，不能太长，10人的团队建议不超过10分钟，主要是暴漏问题，至于怎么解决，下去可以组团进行沟通和讨论。
需求
需求就是体现用户价值的东西，一个需求需要描述清楚：
- 谁使用这个功能；
- 这个功能要达到什么样的要求；
- 为什么会有这个功能，也就是常说的业务背景；
开发人员需要对需求有深入的了解，而不能只是“完成”分解后的任务，深入了解了需求，才知道自己开发过程中有没有偏离主线；才能够在做完任务后更好的自测。
测试人员在验证功能时，针对的也是需求，而不能只是验证某个完成的任务，所以测试人员也需要对需求有深入的了解。
需求设置负责人，团队成员每个人都会被设置为某个需求的负责人，可以更好的调动每个人的积极性。
迭代
没有阶段性的目标，每个人都会感觉到迷茫，时间一长就会丧失斗志，整个团队也会死气沉沉。所以里程碑的定义必不可少，具体计划如下：
- 根据年度计划制定几个大阶段性目标；
- 按照优先级将需求纳入到一个个小的迭代中，迭代周期可以为一周或10天，不宜太长；
- 对于每一个迭代周期中的需求，在周会中要向团队中每位成员讲清楚需求背景；
- 在迭代周期中如果有紧急需求进来，可以调整迭代中的需求，将一些优先级不高的移动到下一个迭代，确保每一个迭代都能按时交付。
每一个小迭代的完成，是最终大的里程碑实现的前提，也正因为每一个迭代周期足够小，才能够及时发现问题，减少风险。
Tapd
腾讯内部的项目管理工具，现在开放出来可以免费使用，对比了一圈，觉得Tapd目前比较符合我们团队。遗憾的是现在开发出来的是阉割版，全功能版本需要联系客服申请，有一定的要求，比如必须使用Tapd达到六个月以上。
Tapd的阉割版中不支持将需求分解到任务，目前能想到的办法就是将在需求下面创建子需求来模拟拆分任务。
总结
任何的软件开发流程最终的目的都是一样，敏捷在不同的公司实践落地肯定也都不一样，开发流程和开发一样，也将会一个迭代一个迭代的去优化和改进，总之，适合自己的就是最好的。
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
