在开源 ZenTao 项目的工作中，我不断收到反馈，表明在许多组织中启动和运行敏捷是一项艰巨的任务。与任何新流程一样，您都会遇到问题，并且其中许多问题对于您的组织来说都是独一无二的。虽然背景很重要，但在您指导了足够多的团队之后，一定程度的抽象是可能的。本文涵盖了我遇到的四个最常见的问题。虽然您的 敏捷教练 应该在您组织的背景下分析任何实际问题，但了解这些一般性问题可以帮助您和您的团队更好地为过渡过程做好准备。
请注意，我只讨论已发现的问题，而不是如何发现问题，那是完全不同的另一个话题！
缺乏敏捷意识
我认为这是最重要的问题。您可以在业务部门、经理和团队成员之间的对话中检测到这个问题。他们强调交付是在特定时间发生的单一事件。他们谈论制定“更多计划”，您会听到诸如“交付更多工作成果”和“这是敏捷，所以为什么不加班？”之类的短语。
这个问题没有单一的解决方案。您只能通过结果来纠正这些误解。不要陷入试图纠正认知的泥潭；相反，专注于用敏捷生产力的好处来吸引人们进入敏捷思维方式。
同样，为了降低任何感知到的障碍，在与尚不了解敏捷的人员沟通时，您可以尽可能减少使用专业的敏捷术语。
缺乏业务部门的支持
这个问题可能决定敏捷实施能否成功。业务部门可能不参加会议，不澄清故事，也不提供反馈。然而，与此同时，他们可能会要求研发团队按照“质量和数量”交付工作成果。
这个问题有几个可能的原因
- 业务部门具有攻击性。一旦他们对研发部门不满意，他们就会随意抱怨。
- 业务部门专注于自己的工作，与研发部门合作不在其职责和评估范围之内。
- 业务部门对研发部门感到失望，并认为支持毫无意义。
- 业务部门没有时间提供支持。
以下是一些解决问题的建议
- 尽力选择支持度高的业务团队。
- 友善一点！通过增加友好和尊重的沟通，您可以获得很多认可和支持。
- 将业务团队的利益与研发部门捆绑在一起。
- 通过透明度重建与业务部门的信任。
- 业务部门了解合同。与您的业务部门协商，以明确对他们的期望以及在沟通和支持方面对他们的要求。
缺乏团队参与
这个问题通常最容易检测到。团队参与是关键；当您没有团队参与时，您通常可以立即识别出来。当经理未能领导团队，并且团队成员没有感到有能力或受到鼓舞去改进团队的流程时，您就会看到这一点。
缺乏团队参与有几个可能的原因
- 公司的绩效评估限制团队进行自组织。例如，评估可能侧重于个人绩效和实际代码行数。
- 团队工作包括复杂的过程，其中包含大量重复工作。例如，成员花费时间重复编写工作日志和每日报告。
- 对错误容忍度低。当创新的代价是对个人工作的高风险时，创新就不会发生。
- 团队成员频繁更换。
- 团队经理可能缺乏管理技能。
理想情况下，应该对组织政策进行修改，以帮助团队成员参与和投入。在没有规章制度变更的情况下，与团队成员进行访谈以直接解决问题。
许多人认为，团队参与可以通过建立信任来获得。这是真的，但没有组织政策的信任是毫无意义的，因为只有更大的组织才能确保团队成员之间的信任。换句话说，系统和规章制度是信任的关键支柱。
低质量的用户故事
这是开发中最大的问题。低质量的用户故事表现为开发错误、大量返工、冗余确认、重复修改以及其他开发资源浪费。更糟糕的是，它是加班的最大原因之一。
低质量故事的可能原因
- 客户没有清楚地表达他们的需求或直接提出解决方案。
- 项目定义不明确，导致能力问题，有时甚至导致态度问题。
- 交付的产品无法解决客户的问题（甚至导致在评审会议中遭到投诉）。
- 故事不稳定且频繁更改。
以下是我如何解决低质量故事的问题
- 使用视觉辅助工具，例如原型图、速写笔记、故事板等等。
- 加强产品团队的业务分析课程。专注于故事确认程序和审查，以确保每个故事都是正确的。
- 建立故事和需求的编写标准。（不要认为敏捷不需要标准！）
- 勇敢地说不，拒绝不合理的故事。
总结
在现有公司中建立敏捷思维方式是一项艰巨的任务，其中潜藏着许多潜在的陷阱。然而，有些问题比其他问题更普遍，并且往往跨越各个组织。我已经确定了我遇到的四个最常见的问题。无论是缺乏意识、支持、参与还是低劣的用户故事，都有一些策略可以使处理这些问题变得更容易。您如何实施这些方法来帮助为敏捷的巨大成功铺平道路？
评论已关闭。