敏捷开发的区域选择与投资策略

# 敏捷开发的区域选择与投资策略 ## 1. 敏捷流畅度区域概述 敏捷开发有三个主要的流畅度区域，分别是聚焦（Focusing）、交付（Delivering）和优化（Optimizing），它们各有其主要好处、所需投资和大致达到流畅度的时间，具体如下表所示： | 区域 | 主要好处 | 投资 | 大致达到流畅度时间 | 性能下降时间 | | --- | --- | --- | --- | --- | | 聚焦 | 专注业务优先级；了解团队工作；具备改变方向的能力 | 团队结构、管理、工作环境 | 2 - 6 个月 | 1 - 4 个月 | | 交付 | 低缺陷、高生产力；技术的长期有效性 | 开发技能、集成测试和运营 | 3 - 24 个月 | 2 - 6 个月 | | 优化 | 更高价值的发布和更好的产品决策 | 嵌入式产品管理、团队对预算和计划的掌控 | 3 - 9 个月 | 1 - 3 个月 | ### 1.1 选择合适的区域 选择团队应追求的流畅度区域，取决于组织的支持能力。理论上，同时追求聚焦、交付和优化三个区域是最佳选择，因为这种组合能带来最佳效果，最纯粹地实现敏捷理念。然而，选择全部三个区域需要最大的投资。如果无法证明这些投资的合理性，可能难以获得所需的支持，团队也难以达到流畅度，甚至可能产生比现在更糟糕的结果。 以下是针对不同区域的选择建议： - **聚焦**：每个敏捷团队都需要具备聚焦的流畅度，这是基础。如果组织连聚焦流畅度的投资都无法进行，敏捷开发可能不太适合，但可以先从交付流畅度入手，逐步提升。 - **交付**：交付流畅度能降低成本、提高开发速度。若缺乏交付流畅度，代码最终会陷入技术债务。不过，有些组织可能还未准备好为交付区域所需的学习和代码质量投入大量资源。可以先从聚焦流畅度开始，展示成功后再争取进一步投资。 - **优化**：优化流畅度是敏捷开发最闪耀的地方，但要求也较高。对于大多数组织而言，最好先在聚焦和交付区域展示流畅度，建立信任后再逐步承担更多责任。但如果组织已经有将决策权下放给跨职能团队的文化（如初创公司常见的情况），优化流畅度将带来显著成果。 如果不确定选择哪些区域，可先从聚焦和交付开始。无论选择哪些区域，都应同时投资学习所有相关实践，因为后续区域的实践能让前期区域的工作更有效。但如果无法对所有想选择的区域进行投资，也可以随着时间逐步积累。 ## 2. 投资敏捷开发 为了让团队获得敏捷开发的好处，组织不仅要在资金上投入，更要对组织结构、系统和行为进行真正有意义的改变。投资敏捷开发非常重要，因为这是在改变团队面临的约束条件。大多数阻碍团队发展的并非所使用的流程，而是所处的约束环境。进行投资而忽略实践，团队仍有可能改善；只执行实践而忽略投资，团队则会陷入困境。 ### 2.1 投资概述 以下是所有敏捷团队需要组织进行的投资： - 获得经理、团队和关键利益相关者的支持。 - 创建长期存在的跨职能团队，并将人员完全分配到各自的团队。 - 确保每个团队都有教练，帮助团队成员成为高效协作的团队。 - 将工作分配给团队而非个人，期望团队自行决定日常规划和任务分配方式。 - 让团队级别的经理专注于管理工作系统，而非个人和任务。 - 为每个团队创建物理或虚拟的团队房间。 - 为每个团队的首次工作选择有价值但不紧急、适合学习敏捷开发的目标。 - 用敏捷治理政策取代瀑布式治理政策。 - 消除、修订或绕过阻碍有效团队合作的人力资源政策。 不同流畅度区域的团队还有额外的投资需求： - **聚焦团队**： - 考虑每个团队 1 - 4 个月的性能下降期。 - 每个团队包含具备用户和客户技能的人员。 - 确保每个团队有能决定工作内容的人员或能定期接触到此类人员。 - 确保每个团队有能教授聚焦实践的教练。 - 确保每个团队能接触到利益相关者或其代表。 - **交付团队**： - 考虑每个团队 2 - 6 个月的性能下降期。 - 将所有必要的开发技能（如测试和运营）集成到每个团队。 - 确保每个团队有能教授交付实践的教练。 - 确保每个团队能控制其开发、构建、测试和发布流程。 - 为每个团队的首次工作选择涉及全新代码库的目标，除非团队教练认为不必要。 - 解决阻碍协作开发的安全问题。 - **优化团队**： - 考虑每个团队 1 - 3 个月的性能下降期。 - 确保每个团队包含具备业务、市场和产品专业知识的人员。 - 确保每个团队有能教授优化实践的教练。 - 赋予每个团队对其预算、计划和结果的责任。 ### 2.2 为学习留出时间 学习敏捷开发初期会使团队速度变慢，预计性能会下降 10% - 20%。随着团队熟练掌握敏捷技能，性能会逐渐提升，直至达到流畅度后增长逐渐平稳，这就是常见的 J 曲线。 不同流畅度区域的初始性能下降时间如下： - 聚焦：1 - 4 个月 - 交付：2 - 6 个月 - 优化：1 - 3 个月 这些时间段会有重叠，例如同时学习聚焦和交付技能的团队，性能下降期约为 2 - 6 个月；而先学习聚焦技能再学习交付技能的团队会经历两次下降期。 敏捷团队的性能变化还体现在其他方面，例如他们更注重在完成一个功能后再开始下一个功能，这对习惯同时开展多个功能的人来说可能感觉速度变慢。利益相关者可能会对敏捷开发的速度感到沮丧，这可能导致团队在未完成学习前就被要求专注于交付软件，这对各方都不利。因此，在团队开始敏捷之旅前，要确保经理和利益相关者理解并接受第一年的性能下降。 组织可以通过聘请人员帮助团队来缩短性能下降期，如偶尔的指导、培训、流程设计和实施帮助以及全职教练等。最有效的方式是聘请有经验的从业者为每个团队提供全职教练服务。在聘请时，应忽略众多的敏捷认证计划，通过向人脉网络咨询推荐、查看公开资料和核实参考信息来评估培训课程、顾问和教练。 如果没有学习时间，可以先从聚焦区域开始，以减少性能下降的明显程度，但总体成本会增加。如果组织完全不能接受性能下降，现在可能不是投资变革的好时机，需要说服管理层为变革留出时间。如果没有预算聘请外部帮助，团队可以利用各种免费在线资源和自身的学习热情，自行学习所需知识。 ### 2.3 创建敏捷团队 在敏捷组织中，团队是至关重要的资源。组织需要投资创建具备以下特点的团队： - **跨职能**：团队成员集体具备完成团队目标所需的所有专业知识。 - **完全投入**：核心团队成员完全专注于所在团队，偶尔可接受外部任务。 - **协作性**：团队成员之间关系友好、合作紧密。 - **长期存在**：团队成员需要数月时间才能找到最有效的合作方式，因此应尽量保持团队的稳定性。 不同流畅度区域的团队对人员技能的需求有所不同： - **聚焦团队**：需要能够站在用户和客户角度思考的人员，以确定软件的具体功能。如果团队目标以用户为中心，还需要具备 UI/UX 技能的人员。此外，团队需要有确定下一步工作内容的方式，可以由团队内部具备相应技能和权限的人员完成，也可以与外部人员合作。 - **交付团队**：负责软件的端到端交付，需要具备构建和部署产品所需的所有技能，包括将之前分配给其他团队的职责整合到团队内部，如构建管理、数据架构和管理、测试和运营等。 - **优化团队**：对产品的广泛业务成功负责，需要协调利益相关者并决定产品优先级。团队成员需要具备业务、市场和产品专业知识。 如果要创建新的敏捷团队，可以按照以下步骤进行： 1. 确定每个团队的目标。 2. 根据团队目标的价值和规模限制，确定每个团队的人员数量。 3. 确定每个团队所需的技能。 4. 选择具备所需技能、能够良好合作且愿意尝试敏捷开发的人员。 如果要创建或重组多个团队，可以考虑采用团队自我选择的方式，这有助于创建高效且积极合作的团队。 以下是在创建团队过程中可能遇到的问题及解决建议： - **无法让人员完全投入团队**：敏捷开发依赖紧密协作，如果人员无法随时参与，可能无法有效开展工作。偶尔的外部职责是可以接受的，但如果无法获得完全投入的团队成员，敏捷开发可能不适用。 - **团队成员相处不融洽**：新团队在磨合过程中遇到困难是正常的，团队教练和经理可以帮助调解冲突。 - **无法创建长期团队**：拆分高绩效团队会造成浪费，但不会阻止团队采用敏捷开发。 - **无法获得所需的业务、客户或用户专业知识**：优化团队至少需要一名具备产品管理技能的成员，但不一定是传统的产品经理。如果开发人员对产品和市场有深入了解，也可以满足需求。对于不追求优化流畅度的团队，虽然不需要产品经理直接加入团队，但仍需要相关技能的人员与团队密切合作，以及能代表客户和用户观点的团队成员。 - **无法获得所有所需的开发技能**：可能无法达到交付流畅度，但交付实践仍然值得学习和应用。 ### 2.4 选择敏捷教练 每个团队都需要一名教练来帮助成员成为高效的敏捷团队。不同区域的团队对教练的要求如下： - 所有团队：需要有人帮助团队成员学习如何成为高效协作的团队。 - 聚焦团队：需要能教授规划实践的教练。 - 交付团队：需要能教授技术实践的教练。 - 优化团队：需要能教授业务开发实践的教练。 有些教练可以涵盖多个类别，每个教练可以负责一到两个团队。如果无法聘请所需的教练，可以从团队中选择受成员尊重和信任的资深从业者，让他们担任教练，本书提供了他们所需的入门知识。全职投入单个团队的“球员 - 教练”模式是最佳选择。 ### 2.5 下放权力和责任 尊重人员能力是敏捷开发哲学的核心，在权力和责任分配方面体现得尤为明显。从组织投资的角度来看，这意味着： - **工作分配**：将工作分配给团队而非个人，团队自行决定如何将工作分解为任务以及由谁执行。这可能需要改变票务系统和其他工作流程，同时也会影响绩效评估。 - **流程决策**：团队自行决定工作流程，特别是可以采用轻量级、无工具的规划方法，而不必依赖公司指定的工具。管理层可以对团队流程设置约束，但必须明确每个约束的原因。 通过以上对敏捷开发流畅度区域的选择和投资策略的介绍，希望能帮助组织更好地实施敏捷开发，提升团队的效率和绩效。 ## 3. 投资敏捷开发的挑战与应对 在投资敏捷开发的过程中，会遇到各种挑战，下面为大家详细介绍常见挑战及相应的应对措施。 ### 3.1 性能下降挑战 性能下降是学习敏捷开发初期不可避免的问题。不同流畅度区域的性能下降时间不同，具体如下表所示： | 流畅度区域 | 性能下降时间 | | --- | --- | | 聚焦 | 1 - 4 个月 | | 交付 | 2 - 6 个月 | | 优化 | 1 - 3 个月 | 性能下降可能导致利益相关者的不满，进而影响团队的敏捷学习进程。为应对这一挑战，组织可以采取以下措施： - **提前沟通**：在团队开始敏捷之旅前，确保经理和利益相关者了解并接受第一年的性能下降，让他们明白这是学习过程中的正常现象，后续会带来更好的效果。 - **聘请外部帮助**：通过聘请有经验的从业者为团队提供全职教练服务，缩短性能下降期。教练可以帮助团队更快地掌握敏捷技能，提高工作效率。 - **调整策略**：如果没有学习时间，可以先从聚焦区域开始，以减少性能下降的明显程度，但总体成本可能会增加。 ### 3.2 团队组建挑战 在创建敏捷团队时，可能会遇到各种问题，以下是常见问题及解决建议的总结： | 问题 | 解决建议 | | --- | --- | | 无法让人员完全投入团队 | 偶尔的外部职责可以接受，但如果无法获得完全投入的团队成员，敏捷开发可能不适用。可与相关人员沟通，尽量减少外部任务对团队工作的干扰。 | | 团队成员相处不融洽 | 新团队在磨合过程中遇到困难是正常的，团队教练和经理可以帮助调解冲突，促进团队成员之间的良好合作。 | | 无法创建长期团队 | 拆分高绩效团队会造成浪费，但不会阻止团队采用敏捷开发。尽量保持团队的稳定性，但在必要时可以进行适当调整。 | | 无法获得所需的业务、客户或用户专业知识 | 优化团队至少需要一名具备产品管理技能的成员，不一定是传统的产品经理。可以挖掘团队内部有相关经验的人员，或与外部专家合作。 | | 无法获得所有所需的开发技能 | 可能无法达到交付流畅度，但交付实践仍然值得学习和应用。可以通过培训、内部交流等方式提升团队成员的技能水平。 | ### 3.3 教练聘请挑战 聘请合适的教练是投资敏捷开发的重要环节，但可能会面临一些挑战。例如，众多的敏捷认证计划质量参差不齐，很多只是为了盈利，不能真正反映教练的能力。为应对这一挑战，可以采取以下方法： - **忽略认证**：不要过分依赖敏捷认证计划来评估教练，而是通过向人脉网络咨询推荐、查看公开资料和核实参考信息来评估培训课程、顾问和教练。 - **内部培养**：如果无法聘请到外部教练，可以从团队中选择受成员尊重和信任的资深从业者，让他们担任教练，并提供必要的支持和培训。 ## 4. 敏捷开发投资的总结与展望 ### 4.1 投资总结 投资敏捷开发需要组织在多个方面进行投入，包括团队结构、管理、教练、时间等。不同流畅度区域的团队有不同的投资需求，具体如下： - **聚焦团队**：需要关注团队的业务优先级，确保团队有明确的工作方向。投资包括获得相关人员支持、创建合适的团队、配备教练等。 - **交付团队**：注重提高开发效率和代码质量，投资包括集成开发技能、控制开发流程等。 - **优化团队**：追求产品的更高价值和更好决策，投资包括赋予团队更多责任、配备具备专业知识的人员等。 ### 4.2 展望未来 随着市场环境的不断变化和竞争的加剧，敏捷开发将越来越受到重视。组织在投资敏捷开发时，应不断总结经验，调整策略，以适应不断变化的需求。同时，要注重培养团队的创新能力和协作精神，让团队在敏捷开发的过程中不断成长和进步。 通过合理的投资和有效的管理，组织可以充分发挥敏捷开发的优势，提升团队的绩效和竞争力，实现业务的持续发展。 下面是一个简单的 mermaid 流程图，展示了投资敏捷开发的大致流程： ```mermaid graph LR A[确定流畅度区域] --> B[进行投资规划] B --> C[创建敏捷团队] C --> D[聘请教练] D --> E[团队学习与实践] E --> F[应对挑战与调整] F --> G[持续改进与发展] ``` 希望以上内容能为大家在投资敏捷开发方面提供有益的参考和指导，帮助大家更好地实施敏捷开发，取得良好的效果。