写在前面
由于敏捷是一个复杂系统（complex），因此一些问题可能会重复出现，或者具有相关性。而敏捷实践对情景（context）有着极高的要求，所以下面的切入点均不可以直接操作，而是需要教练在团队辅导过程中，针对场景做出适当的行为。
另外，此处只针对“已经发现该问题”做出阐述，不考虑“如何发现问题”。那是另一个话题。
01 敏捷意识不足
我愿意将之称为最致命的问题。这点比较容易从业务方、管理者、团队成员的日常对话中看出来，比如是否强调“一次性交付”、“多做计划”、“要交付更多的工作内容”、“都敏捷了，还不快加班”等。针对这种场景，没有银弹，只能在日常工作中，“以成果说话”而不是“以概念说话”，以利诱之是改变意识形态的一个手段。另外建议在与这类人员沟通时，尽可能减少敏捷专有名词使用，减少抵触。
02 业务部门支持度低
我愿意将之称为最需要解决的问题。这直接影响了敏捷是否能够成功。这种现象的表现主要为业务部门不配合，比如不参会、不做需求澄清、不做反馈的同时，却又要求研发团队保质保量提交工作成果。
业务部门支持度低的可能原因：
-
业务部门过于强势，只要对研发不满意，就可以恣意投诉；
-
业务部门有自己的工作，配合研发部门工作，不是业务部门的分内之事且不在考核范围；
-
业务团队对研发团队失望，认为任何的支持都是徒劳
-
业务部门无暇支持
针对这个问题，可以从以下几点切入：
-
选择业务团队时，尽可能选择支持力度高的团队
-
通过私交，获得部分业务团队人员的认可及支持
-
改变业务部门的立场，用利益将之与研发团队绑定在一起
-
通过透明化等方式，重建与业务部门之间的信任
-
与业务部门协商，获得双方认可的沟通方式、频率、时间安排等
03 团队参与度不足
我愿意将之称为最容易被观察到的问题。团队工作需要管理者推动，团队不会主动找寻工作，对工作边界划分清晰，没有人从产品交付角度考虑问题。整体来看，团队参与度不足，大多数都是由组织制度、流程、治理等内容所导致，除了团队管理者自身管理能力不足之外，其他基本都要在团队上一层解决，而不可能在团队层级解决。
团队参与度不足的可能原因：
-
公司的绩效考核制度，对自组织团队起到了约束作用。比如对员工的考核关注在个人层面，比如代码行数、功能点交付个数等；
-
流程复杂，重复工作多。比如反复填写工时、工作日报等、多个工作平台数据互相不通等；
-
对犯错的包容度较低，对个人而言，创新的成本过高；
-
团队成员变动频繁，团队无法长时间处于塔克曼模型的规范或者绩效阶段；
-
团队负责人能力不足，天怒人怨——为数不多可以通过培训、辅导、导入流程改变的点。
针对这个问题，如果无法在制度层面进行改变，最终都会沦为局部优化。在没有改变制度的情况下，建议采取“访谈”的方式，针对事情本身解决，避免“雷声大雨点小”。也可以尝试采取一些规范流程（虽然看起来有点反敏捷），通过行动改变团队行为（虽然很难）。
备注：有人说可以通过建立团队信任获得团队参与度，这点我的观点比较悲观——没有制度支持下的信任是无意义的，这种信任只能在非常小的范围存在，比如因为某个人加入某个团队。换言之，组织环境是支撑“信任”很重要的支柱。
04 需求质量低
我愿意将之称为团队研发中最大的问题，没有之一。需求质量问题的表现是开发错误、返工、反复确认、反复修改等研发资源浪费，更是导致加班、996 的元凶之一。
需求质量低可能的原因：
-
业务人员自己说不清楚需求，或者直接给出解决方案；
-
需求人员没有把需求写清楚（能力或者态度均有可能）；
-
给出的需求不能解决业务方问题（这条还会引起评审会时业务方不满意）；
-
需求稳定性不足，迭代内也会会频繁改动。
针对需求质量问题，可以从这几个点下手（不与上面的原因形成一一对应关系）：
-
使用原型图、故事版等可视化引导方法
-
加强需求人员对业务分析基础知识（BA）的学习，重视需求的确认与核实步骤，做到高质量且正确的需求
-
引入故事、需求的书写规范（不要以为敏捷就不需要规范）
-
勇敢的对不合理的需求变更 Say No
05 业务方不满意交付物
我愿意将之称为最蛋疼的问题。团队辛辛苦苦开发的功能，在评审会上被业务方批得一文不值。团队积极性受到了重大打击、业务方对团队的信任度一落千丈。
业务方不满意的可能原因：
-
优先级错误。业务方觉得重要的你没做，不重要的你做了；
-
交付物的量偏低，业务方觉得成果不明显；
-
交付物质量差，甚至无法完成 Happy Path 的流转；
针对业务方对交付物不满意的问题，可以从这几个点下手：
-
优先级排序是否与业务方一致
-
管理业务方预期，避免业务方产生不切实际的期待
-
使用自动化工具、pipeline 等技术改善故事流动时间；使用 WIP Limit 等方法提升工作流动
-
定义合适的 DoD
-
如果是工作交付比较慢，可以看下一条
06 交付工作慢或波动较大
我愿意将之称为最“正常”的问题。这条的表现主要体现在每个迭代的可交付成果数量、规模无法预测或者迭代中有较多的工作会放入后续迭代完成。
剔除需求输入质量较低、需求变动频繁因素之外，工作较慢基本上都能归属到团队、工具层面。
交付工作慢或者波动较大可能的原因：
-
团队人员能力不足
-
团队人员比例不对
-
自动化工具使用不足
-
需求拆分不到位，导致部分工作无法在迭代内完成
-
把敏捷做成小瀑布
针对交付工作慢，可以从这几个点下手：
-
建设跨职能团队
-
合理的制定迭代、发布计划
-
建设自动化工具链
-
鼓励团队使用自己顺手的 IDE、工具
-
教会团队故事拆分方法
-
让团队意识到“每个迭代都有交付物”的重要性，并辅以度量指标衡量
07 自有、外包人员水平不一导致工作节奏被打乱
我愿意将之称为“成长的烦恼”。该问题在大公司不可避免且极易被察觉。有些组织会因为外包使用制度、策略问题，不敢开除不合格的外包人员，担心人员无法接续从而导致交付的不及时。
针对这种如果不能改变公司用工制度，可能唯一的解法就是改变对外包人员的管理方法。比如在自有人员之间实施敏捷工作模式，而在外包人员中间以任务分配、时间点追踪的方式管理。
备注：不推荐对外包人员进行培训，这是对组织成本的一种滥用。而且外包人员流动性也会造成培训成本的浪费。如果可以，最好招聘那些能够跑敏捷的外包，否则以资源池的方式管理外包可能是一个更有用的做法。
08 其他
还有一些其他的点，从我的经验看来，大部分都是 SM 或者 AC 的痛点，团队一般不会意识到这些点。
01）框架使用错误
通常来说，这个最容易被发现，也最容易被纠正。解决方案大家都熟，不做说明了。不外乎框架、工具的培训与辅导。
02） 团队没有持续改进
这点不太容易看出来，除非是团队长时间不开回顾会这种太明显的情况。有几个观察点可供判断：
-
团队是否经常犯相同的错误
-
团队的速率趋势过于平稳，长时间没有提升
-
其他度量指标过于平稳，比如故事流动时间
-
团队日常工作氛围过于安静，交流、讨论不多 针对这种情况，目前除了教练技术之外基本上无解，如果无法让团队认识到持续改进的重要性之外，别无他途。
03）团队形成孤岛
典型的表现是团队不能、不愿意做透明化，从外界看团队就像是一个黑盒。这种情况一般都可以归结到组织制度、管理制度层面，让团队有一种“黑盒才是安全感来源”的感觉。可以建议团队在小范围内透明化，比如先从团队内部开始，再伺机找寻机会在组织制度上对透明度提供支持。
04）不使用良好的工程实践
这可能是团队最困难的改变了，没有之一。针对这种，不建议 SM 或者 AC 直接对此进行处理，而是通过度量指标给予团队压力后，通过培训或者教练的方式，让团队意识到工程实践对度量指标的贡献后，一般会有所改变。
