发布于 

敏捷,每个人都有自己的理解

2018年一直在尝试用敏捷的方式来管理团队,但执行的不够彻底,或者说不那么敏捷。 总结下来有下面一些问题:

  • 每日站会没有能坚持下去,后面退化到一周一次了;
  • 没有合适的看板,这可能是导致站会没坚持下去的原因;
  • 需求都被分解成任务记录在GitLab中,每个人员都以完成任务为导向,以至于不能清晰的了解需求;
  • 有大的里程碑,但缺少小的迭代周期。

最近看了一些阿里关于敏捷开发的视频,很受启发,所以决定在2019年作出一些改变:

  • 每日站会要重新启动起来,强制执行,主要针对看板沟通下需求完成情况;
  • 以需求为导向,而不是以任务为导向,将尝试采用腾讯的Tapd来管理需求;
  • 每个需求设置需求负责人,负责人对该需求的交付负责;
  • 引入迭代(周期不能太长,1 周或 10 天,视情况而定),让团队每个人都有阶段性目标。

站会

站会的核心目标是促进需求的顺畅流动,团队的目标是能快速的交付需求。在站会上我认为主要做三件事:

1、及时发现并处理阻碍事项,看板中的每一个阶段应该是均匀的,就像是流水线一样,从最左边的待处理需求到最右边的交付应该均匀而稳定的流动,如果某一个环节出现了堆积或中断,那就说明出现问题了,需要分析出原因并解决;

2、聚焦完成,看板的关注点从右往左,着重分析哪些任务应该交付了而没有交付;哪些bug还不能测试通过;哪些任务存在着风险等;

需求如果能正常稳定的流动,则能及时发现和解决问题;反之,如果需求出现积压或中断,问题也会随之隐藏,风险也会随之变大。

站会因为每天都会开,所以时间上要做控制,不能太长,10人的团队建议不超过10分钟,主要是暴漏问题,至于怎么解决,下去可以组团进行沟通和讨论。

需求

需求就是体现用户价值的东西,一个需求需要描述清楚:

  • 谁使用这个功能;
  • 这个功能要达到什么样的要求;
  • 为什么会有这个功能,也就是常说的业务背景;

开发人员需要对需求有深入的了解,而不能只是“完成”分解后的任务,深入了解了需求,才知道自己开发过程中有没有偏离主线;才能够在做完任务后更好的自测。

测试人员在验证功能时,针对的也是需求,而不能只是验证某个完成的任务,所以测试人员也需要对需求有深入的了解。

需求设置负责人,团队成员每个人都会被设置为某个需求的负责人,可以更好的调动每个人的积极性。

迭代

没有阶段性的目标,每个人都会感觉到迷茫,时间一长就会丧失斗志,整个团队也会死气沉沉。所以里程碑的定义必不可少,具体计划如下:

  • 根据年度计划制定几个大阶段性目标;
  • 按照优先级将需求纳入到一个个小的迭代中,迭代周期可以为一周或10天,不宜太长;
  • 对于每一个迭代周期中的需求,在周会中要向团队中每位成员讲清楚需求背景;
  • 在迭代周期中如果有紧急需求进来,可以调整迭代中的需求,将一些优先级不高的移动到下一个迭代,确保每一个迭代都能按时交付。

每一个小迭代的完成,是最终大的里程碑实现的前提,也正因为每一个迭代周期足够小,才能够及时发现问题,减少风险。

Tapd

腾讯内部的项目管理工具,现在开放出来可以免费使用,对比了一圈,觉得Tapd目前比较符合我们团队。遗憾的是现在开发出来的是阉割版,全功能版本需要联系客服申请,有一定的要求,比如必须使用Tapd达到六个月以上。

Tapd的阉割版中不支持将需求分解到任务,目前能想到的办法就是将在需求下面创建子需求来模拟拆分任务。

总结

任何的软件开发流程最终的目的都是一样,敏捷在不同的公司实践落地肯定也都不一样,开发流程和开发一样,也将会一个迭代一个迭代的去优化和改进,总之,适合自己的就是最好的。