初创团队敏捷之路：Scrum or Kanban？

Posted 2021-04-25 项目姐

对于初创团队而言，在人力、财力、物力都非常有限的前提下，如何选择合适自己的研发流程尤为重要。特别是身处所谓的VUCA时代，活下去是首要任务。团队能获得试错的机会少之又少。资本没有耐性也没有能力再为项目的失败、延期等问题不断买单。团队从创立初期就需要想清楚，做什么、为什么做以及怎么做的问题。细化到研发环节，究竟使用哪种研发流程能最快速地交付价值，实现ROI的最大化？这是团队务必要考虑的问题。

目前在互联网软件研发领域使用最多的流程为Scrum及看板。对于初创团队而言，由于组织文化、产品类别、所处阶段等的不相同，要确定符合自身特点的研发流程，可通过以下维度对敏捷实践方法的选择进行思考。

一、核心理念差异

Scrum的核心：Scrum是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。^[1]

换句话说，就是引入这个方式，团队能清楚知道自己每个周期内需要做什么，并朝着目标及截止日期进行冲刺。这种行为是自发的，并且能够不断演进。对于初创团队而言，此种方式前期投入成本较高。需要在团队内进行培训，说明Scrum每个要素及角色的定义。通常也需要至少1个迭代的时间来跑通整个流程，需要约2-4个迭代的时间来稳定速率。

看板的核心：基于丰田TPS生产系统，通过拉动的方式由下游带动上游的生产，减少中间环节的浪费。在软件研发领域，看板最早由David Anderson定义，他仍将拉动作为看板的核心，同时强调限制在制品及缩短前置时间（lead time）。

换句话说，就是在引入这种方式后，团队能够可视化自己的工作进度、流程，清楚了解阻塞环节在哪里。对于初创团队而言，这种方式变革成本及阻力最小。

二、周期及范围差异

Scrum要求固定周期，固定单次迭代范围。一旦过程中出现范围变更，则停止此次冲刺。Scrum周期通常为1-4周不等，视组织及业务需求而定。通常迭代周期在稳定后不轻易变更。

看板需要明确发布时间（每周一次还是每天一次，根据团队自身情况设定），团队以用户故事为单位，“追赶”发布“火车”。每次版本发布的时间基本固定（紧急需求除外），发布范围不定。

三、前置条件差异

Scrum属于侵入式的框架，需要重建现有流程方可启动。对变革持有否定或者质疑态度的组织建议谨慎选择。

看板则可在现有项目参数不变的前提下启动。通过梳理价值流图，搭建泳道，设置在制品限制，持续改进来推动持续变革。

四、业务类型差异

新建项目，即从0-1的项目类型。由于此类项目对短时间上线某种功能的需求不高。更多的是每个迭代完成后有增量输出，scrum固定周期及范围的开发模式较为适合。

运维类、服务类、纯服务端或前端业务。由于此类项目已正式上线，线上环境复杂，需要对用户反馈快速响应。因此，经常会遇到临时发布紧急需求的任务。Scrum固定时间及范围的模式就显得不太适用了。这种情况下，则优先选择看板模式，与团队确定好服务协议水平，明确不同优先级的任务如何处理。

最后，回到初创团队面临的最大挑战，即身处纷繁复杂的行业背景下，需要快速拥抱变化，响应变化。而选择合适的敏捷实践，并持之以恒地走下去，才能帮助组织以事半功倍的效果达成目标。毕竟，得其法者得天下。

参考

1. ^ Scrum Guide, Ken Schwaber, Jeff Sutherland, May, 2009

   
   

更多原创推荐阅读：

• 
  

扫码获取更多项目管理新鲜资讯