以团队痛点为起点

摘要

本文大约4200字，主要内容包括：

• 不要为了敏捷而敏捷
  • 你才敏捷，你们全家都敏捷
• 开始于问题
  • 为什么选择问题驱动
    • 痛感是意识的第一步
    • 问题驱动的作用
• 什么是软件团队的常见痛点？
  • 痛点的表现
  • 痛点的根源
  • 从痛点看到的问题涟漪
• 痛点之外：深化敏捷实践
  • 如何理解并应用敏捷教练实践的名词
  • 不止于痛点与问题的解决
• 结论

阅读完成后，你将更深入地理解什么是软件团队的痛点以及问题涟漪，并对如何深化敏捷实践有更清晰的理解。此外，你也会明白在解决痛点的同时，如何推动敏捷文化的深化和团队成员的积极性，并清楚如何向持续改进的方向进发。

不要为了敏捷而敏捷

记得在2015年写过的一篇文章：

你才敏捷，你们全家都敏捷

这个小标题是否看着挺冲动的？

作为一个深耕敏捷圈子的一员，我注意到了对敏捷的各种赞美和簇拥，但有时，我对一些观点感到诧异。敏捷被描绘得像一双万能丝袜（现在可能是精益、DevOps或设计思维），各种生产力方法和过程都被包含其中。但在我看来，敏捷的本质并不仅仅是某种方法或框架，更是一种状态，一种心态，一个“Being”的过程而非“Doing”。

令人疑惑的是，随着越来越多的方法和经验被归入敏捷，我们更少的关注这种“Being”的状态，而更多地关注“Doing”的过程。我认为真正的敏捷应该是一个持续学习，不断自我否定，保持开放心态，专注于实际事物的过程。

有时，我发现敏捷被作为一面大旗，成为一种口号，所有正确的都被标记为敏捷，而不正确的都被视为传统，需要被改变。但我不再对此纠结。我现在告诉我的团队，无论敏捷是否成为了大旗或口号，只要我们每天比昨天做得更好，更快乐，那就足够了。我们并不需要关心是否叫它敏捷。

我时常思考，也许我自己也在某种程度上贬低了敏捷这个词。我不希望我的收入全来自敏捷。我希望我们能够回归到软件、代码，人与人之间的交互。因此，我会继续教课，传播我的思想，并希望通过这种方式最终减少对“敏捷”这个词的依赖。

文章链接：你才敏捷呢，你们全家都敏捷 | 思维发条

开始于问题

敏捷的本质是适应性的不断提高，以应对不断的变化。适应性的提高约等于，开始要思考甚至质疑一切的行为和思路。这让我想起，一些敏捷教练面试的场景。当被问道，你做过什么的时候，回答可能是：某些概念名词我们使用过，或敏捷就是一堆检查列单（Checklist）。

当听到这些回答的时候，我会进一步的问应试者：

• 团队有什么问题或挑战吗？你是如何应对的呢？
• 如果说，我们50人的团队之前没有接触过敏捷，如何在一周的时间把整体敏捷过程运行起来？

看，这就是一种问题驱动的方式。这并不是说敏捷就是问题驱动的方式来推进一个个的去解决，这种方式更是探测敏捷教练是否积极思考的一种方式。你可能会问问题驱动的意义是什么？为什么我不能就实施某个框架甚至某个方法？

为什么选择问题驱动

前文说到，敏捷是：可以以目标为导向的快速反馈和调整的能力。

快速反馈与调整依赖于“看到”或“感知到”。我们希望每一个敏捷教练能够看到一个又一个的真实问题与情况，针对一个又一个的问题，又有自己应对的思路。拥有思路之后还能推进细节行动，并得到阶段反馈。然后ta可以扩展这样的这种过程，让团队更多的人看到，做到。这一切开始于感知，更简单的说是疼痛的感知。

痛感是意识的第一步

1. 生物学角度：痛感是生物为了生存进化出来的一种基本感觉。痛感可以帮助生物了解自己处于一个不利或有害的环境中，这有助于其避免伤害并改善生存状况。所以，痛感可以被视为意识的一种基础形式。
2. 心理学角度：在心理学中，痛感也被视为人们意识到自我需求和情感反应的重要方式。比如，当人们体验到情绪痛苦时，他们可能会更加深入地思考自己的情绪和需求，从而更好地了解自己。在这种情况下，痛感也可以被看作是自我意识的一种触发器。
3. 哲学角度：在一些哲学观念中，痛感被视为人们对自我存在的直接感知。换句话说，痛感可以使我们意识到我们的存在，从而开启我们对世界的认知和理解。在这种意义上，痛感也可以被看作是意识的起点。

痛的反义词不是快乐，而是麻木。敏捷的部分意义就是让大家走出这种麻木状态。

问题驱动的作用

1. 强化敏捷的目的：敏捷方法的目的不仅仅是为了保持灵活和快速反应，更重要的是要解决实际问题，满足用户需求，并实现商业价值。如果只是盲目地追求敏捷，而没有明确的目标和问题驱动的策略，可能会导致团队失去方向。（很多团队经常说的一句话就是告诉我怎么做就好，但这与敏捷的追求有着本质的差距）
2. 敏捷的适用性：虽然敏捷方法在许多情况下都能带来好处，但并非在所有情况下都适用。有些问题可能需要不同的管理方法，甚至是更传统的方法，或者需要结合其他方法来解决。如果只是盲目地追求所谓的敏捷，可能会忽视这些问题的复杂性和多样性。
3. 敏捷的持续改进：问题驱动的敏捷实施还可以促使团队进行持续的反思和改进。通过定期检查和调整敏捷实施的策略，团队可以更好地适应变化，提高其敏捷性（Agility）。
4. 能够被别人理解：敏捷有的时候是一堆奇怪的名词，而且很多人特别擅长”回字的若干种写法“。这是一种不愿意融入团队的倾向，不愿意触及细节的倾向。我们要尽可能的弱化这种趋势。没有必要不要增加显得专业的名词，哪怕把敏捷这个词汇完全剔除也是可以的。

什么是软件团队的常见痛点？

痛点的表现

在针对无数团队问题的改进过程中，我们收集了近万条团队的问题与障碍，经过人工智能进行大数据整理和分析。团队的关键痛点以提及的次数排序如下：

1. 需求变更频繁且不明确(339)
2. 测试覆盖率低,测试环境不稳定(135)
3. 团队沟通效率及协作存在障碍(124)
4. 人员能力与技术水平需要提高 (198)
5. 版本管理和发布过程需要改进 (84)
6. 对接外部团队效率及配合度存在问题(74)
7. 多线程任务和突发任务打断工作进度(69)
8. 统一的价值观和执行力度需要加强 (58)
9. 测试数据和环境准备不充分(51)
10. 项目管理水平和目标需进一步明确 (45)
11. 非版本计划任务量过多(36)

痛点分析和根源

可以分析出以下几个是最重要的问题:

1. 需求变更频繁且不明确。

这是导致后续诸多问题的根源。需求变更容易导致:

• 测试用例与环境需多次调整来适应需求变更,降低覆盖率。
• 开发人员需要重新分析需求并修改代码,干扰正常开发进度。
• 团队内部沟通频繁,协作效率降低。
• 导致版本管理和发布过程里程碑修正频繁。
• 多线程任务和突发任务干扰进度。
• 测试数据和环境需要重新准备来适应需求变更。
• 项目目标与计划需要重新制定。
• 因此,清晰明确且稳定的需求是项目顺利推进的基础。改进需求分析与沟通机制是根本性的问题。

2. 团队沟通协作存在障碍。

沟通障碍会导致:

• 需求理解不一致,进一步影响需求变更。
• 开发缺乏协调,效率降低。
• 测试无法全面发现问题。
• 项目目标难以达成。
• 在人员能力和技术水平存在差距的情况下,信息难以交流。

这两个问题是整个过程中最重要的痛点,必须加强改进。有了明确的需求和良好的沟通,其他方面才能得以推进。

从痛点看到的问题涟漪

对于组织层面，团队的问题可能引发项目延误、质量下降、员工满意度减少、组织声誉损害和成本上升。

对于个人层面，员工可能面临工作压力增加、职业发展停滞、工作满意度下降、工作效率减少和生活平衡被打破等问题。

就如同上图这样的情况，不同层面的问题会导致其他层面的问题。但我们应该始终把关注与优化的方向定位为向客户所交付的价值流。团队的问题与障碍始终要与客户交付的内容所对应。

团队问题（交付价值流）可以被看作是干流，因为它们直接影响了客户的满意度和价值交付。这个“干流”中的问题，如需求频繁变更、测试覆盖率低、团队沟通效率低等，都是直接影响最终产品或服务质量的关键因素。

而其他的组织层面和个人层面的问题，如项目延误、员工满意度下降、工作压力增加等，则可以被视为“支流”，它们间接但深远地影响着干流。这些“支流”问题往往是由“干流”问题引发的，同时又会反过来影响和加剧“干流”问题，形成了一个恶性循环。

这就像河流的水系一样，干流的问题会引发支流的问题，反过来支流的问题又会回流到干流中，影响整个水系的健康。因此，解决这些问题需要整体思考和协调处理，不能只看到眼前的支流问题，而忽视了更为关键的干流问题。

在处理这些问题时，我们需要以客户交付的价值为导向，优先解决影响价值交付的干流问题。同时，也不能忽视那些可能引发更大问题的支流问题，需要通过改善组织和个人层面的问题，以增强整个团队的战斗力，从而更好地解决干流问题，实现高质量的价值交付。

痛点之外：深化敏捷实践

如何理解并应用敏捷实践的名词

你可能会纠结如果已经接受过培训，脑中只记得一堆名词的话，我们如何推进敏捷转型呢？你可以借鉴以下思路：

1. 回归基础：我们首先需要明确，敏捷转型的目标是改进工作方式和效果，而不是仅仅使用一种新的名词或术语。因此，我们需要把注意力放在那些永远不会改变的基础名词上，如"需求澄清"和"版本节奏"，这些都是无论在任何方法中都必须关注的关键点。
2. 适应现有认知：人们通常已经熟悉一些敏捷的名词和方法，如Scrum、SAFe和"版本火车"。我们可以利用这些已有的知识，让人们更容易地接受和理解敏捷转型。但是，我们必须明确这些名词是工具，而不是目标，我们的工作应该建立在这些名词之上，而不是仅仅停留在这些名词上。
3. 通用化名词：当我们开始在不同的团队和环境中应用敏捷，我们需要尝试通用化一些名词，以便更好地在整个组织中推广。例如，我们可以使用"迭代"这个更通用的名词来代替"冲刺"，这样可以让更多的人理解并接受这个概念。
4. 原子化实践：最后，我们需要逐步实施敏捷实践，而不是一次性全部应用。我们应该把每个实践看成是一个原子，可以独立使用，也可以和其他原子组合在一起。这种原子化的方法可以让我们更灵活地应用敏捷，而不是一股脑地将整个敏捷方法框架塞进组织，这种突变往往会引发抵触和混乱。

不止于痛点与问题的解决

解决团队的痛点和问题只是敏捷转型的一个起点，而不是终点。团队需要以此为契机，逐步建立和深化敏捷文化，包括但不限于自我组织、持续改进、反馈快速、结果导向等。这样才能真正地实现敏捷转型的长远目标，即提高客户的满意度，增强组织的竞争力。

同时，敏捷转型并非一蹴而就的过程，也不应该只看到表面的痛点和问题，而忽视了团队和个人的内在动力和潜能。因此，除了解决团队痛点，更重要的是要发掘和激发团队成员的积极性和创新性，让他们主动参与到敏捷转型的过程中来，共同面对并解决挑战。

此外，敏捷转型也应该超越团队的范畴，影响到整个组织的层面。因为组织的支持和配合是敏捷转型成功的关键。这包括调整组织结构以支持敏捷，优化工作流程以增强敏捷，以及培养敏捷的领导力，以推动敏捷的深度实施。

结论

本文主要探讨了团队问题在敏捷转型中的重要性，并指出真正的敏捷应以痛感和问题为起点，重视进步而非速度。只有这样，我们才能确保敏捷转型是由实际问题驱动的，而不是盲目地追求方法或名词。

同时，我们应将问题视为改进和成长的契机，而非只是要消除的障碍。通过以问题驱动敏捷转型，我们可以强化敏捷目标的适用性，促进团队的持续改进和自我反思，使得团队能更好地理解和接受敏捷。

在痛点的分析中，我们发现需求不明确以及团队沟通协作问题是影响客户价值的关键因素，这些干流问题应该被优先关注和解决。

然而，敏捷转型的过程并不应止步于痛点的解决。我们需要深化敏捷文化，激发团队成员的积极性和创新性，并将敏捷转型推广至整个组织。只有这样，我们才能实现敏捷的长远目标，即提高客户的满意度，增强组织的竞争力。

总的来说，敏捷转型是一场以问题驱动，以客户价值为导向的持续改进之旅。我们不应该止步于痛点的解决，而应该以此为契机，深化敏捷实践，实现组织和个人的持续成长。