实施敏捷过程中的常见问题

244 2023-08-19

写在前面

由于敏捷是一个复杂系统（complex），因此一些问题可能会重复出现，或者具有相关性。而敏捷实践对情景（context）有着极高的要求，所以下面的切入点均不可以直接操作，而是需要教练在团队辅导过程中，针对场景做出适当的行为。

另外，此处只针对“已经发现该问题”做出阐述，不考虑“如何发现问题”。那是另一个话题。

01 敏捷意识不足

我愿意将之称为最需要解决的问题。这直接影响了敏捷是否能够成功。这种现象的表现主要为业务部门不配合，比如不参会、不做需求澄清、不做反馈的同时，却又要求研发团队保质保量提交工作成果。

业务部门支持度低的可能原因：

业务部门过于强势，只要对研发不满意，就可以恣意投诉；
业务部门有自己的工作，配合研发部门工作，不是业务部门的分内之事且不在考核范围；
业务团队对研发团队失望，认为任何的支持都是徒劳；
业务部门无暇支持。

针对这个问题，可以从以下几点切入：

选择业务团队时，尽可能选择支持力度高的团队；
通过私交，获得部分业务团队人员的认可及支持；
改变业务部门的立场，用利益将之与研发团队绑定在一起；
通过透明化等方式，重建与业务部门之间的信任；
与业务部门协商，获得双方认可的沟通方式、频率、时间安排等。

02 团队参与度不足

我愿意将之称为最容易被观察到的问题。团队工作需要管理者推动，团队不会主动找寻工作，对工作边界划分清晰，没有人从产品交付角度考虑问题。整体来看，团队参与度不足，大多数都是由组织制度、流程、治理等内容所导致，除了团队管理者自身管理能力不足之外，其他基本都要在团队上一层解决，而不可能在团队层级解决。

团队参与度不足的可能原因：

公司的绩效考核制度，对自组织团队起到了约束作用。比如对员工的考核关注在个人层面，比如代码行数、功能点交付个数等；
流程复杂，重复工作多。比如反复填写工时、工作日报等、多个工作平台数据互相不通等；
对犯错的包容度较低，对个人而言，创新的成本过高；
团队成员变动频繁，团队无法长时间处于塔克曼模型的规范或者绩效阶段；
团队负责人能力不足，天怒人怨——为数不多可以通过培训、辅导、导入流程改变的点。

针对这个问题，如果无法在制度层面进行改变，最终都会沦为局部优化。在没有改变制度的情况下，建议采取“访谈”的方式，针对事情本身解决，避免“雷声大雨点小”。也可以尝试采取一些规范流程（虽然看起来有点反敏捷），通过行动改变团队行为（虽然很难）。

备注：有人说可以通过建立团队信任获得团队参与度，这点我的观点比较悲观——没有制度支持下的信任是无意义的，这种信任只能在非常小的范围存在，比如因为某个人加入某个团队。换言之，组织环境是支撑“信任”很重要的支柱。

03 需求质量低

我愿意将之称为团队研发中最大的问题，没有之一。需求质量问题的表现是开发错误、返工、反复确认、反复修改等研发资源浪费，更是导致加班、996 的元凶之一。

需求质量低可能的原因：

业务人员自己说不清楚需求，或者直接给出解决方案；
需求人员没有把需求写清楚（能力或者态度均有可能）；
给出的需求不能解决业务方问题（这条还会引起评审会时业务方不满意）；
需求稳定性不足，迭代内也会会频繁改动。

针对需求质量问题，可以从这几个点下手（不与上面的原因形成一一对应关系）：

使用原型图、故事版等可视化引导方法；
加强需求人员对业务分析基础知识（BA）的学习，重视需求的确认与核实步骤，做到高质量且正确的需求；
引入故事、需求的书写规范（不要以为敏捷就不需要规范）；
勇敢地对不合理的需求变更 Say No。

04 业务方不满意交付物

我愿意将之称为最蛋疼的问题。团队辛辛苦苦开发的功能，在评审会上被业务方批得一文不值。团队积极性受到了重大打击、业务方对团队的信任度一落千丈。

业务方不满意的可能原因：

优先级错误。业务方觉得重要的你没做，不重要的你做了；
交付物的量偏低，业务方觉得成果不明显；
交付物质量差，甚至无法完成 Happy Path 的流转。

针对业务方对交付物不满意的问题，可以从这几个点下手：

优先级排序是否与业务方一致；
管理业务方预期，避免业务方产生不切实际的期待；
使用自动化工具、pipeline 等技术改善故事流动时间；使用 WIP Limit 等方法提升工作流动；
定义合适的 DoD。

如果是工作交付比较慢，可以看下一条：

05 交付工作慢或波动较大

我愿意将之称为最“正常”的问题。这条的表现主要体现在每个迭代的可交付成果数量、规模无法预测或者迭代中有较多的工作会放入后续迭代完成。

剔除需求输入质量较低、需求变动频繁因素之外，工作较慢基本上都能归属到团队、工具层面。

交付工作慢或者波动较大可能的原因：

团队人员能力不足；
团队人员比例不对；
自动化工具使用不足；
需求拆分不到位，导致部分工作无法在迭代内完成；
把敏捷做成小瀑布。

针对交付工作慢，可以从这几个点下手：

建设跨职能团队；
合理的制定迭代、发布计划；
建设自动化工具链；
鼓励团队使用自己顺手的 IDE、工具；
教会团队故事拆分方法；
让团队意识到“每个迭代都有交付物”的重要性，并辅以度量指标衡量。

06 自有、外包人员水平不一导致工作节奏被打乱

我愿意将之称为“成长的烦恼”。该问题在大公司不可避免且极易被察觉。有些组织会因为外包使用制度、策略问题，不敢开除不合格的外包人员，担心人员无法接续从而导致交付的不及时。

针对这种如果不能改变公司用工制度，可能唯一的解法就是改变对外包人员的管理方法。比如在自有人员之间实施敏捷工作模式，而在外包人员中间以任务分配、时间点追踪的方式管理。

备注：不推荐对外包人员进行培训，这是对组织成本的一种滥用。而且外包人员流动性也会造成培训成本的浪费。如果可以，最好招聘那些能够跑敏捷的外包，否则以资源池的方式管理外包可能是一个更有用的做法。