任务驱动的发展

随着公司的发展，扩展敏捷产品开发变得更加困难。 根据第 13 次敏捷状态报告中 52% 的受访者，组织文化和敏捷价值观之间的差异是他们工作中的主要缺陷。

组织领导者能够利用敏捷文化来改进产品开发。 稳健的敏捷文化涉及团队在解决复杂问题方面的自主权、与客户的密切合作以及长期愿景和战略。

这些抽象价值很难评估和参与。在一个组织中，实施有效的战略来利用它们变得非常重要。 任务驱动开发 (MDD) 方法已从中期初创公司兴起，作为发展这种文化的替代方案。

扩展挑战

扩展时可能会出现几种减速模式。 随着项目的结束不明确，团队积极性可能会降低。 产品经理可能会在运营会议中迷失方向，从而失去设计战略产品路径的时间。 随着系统变得越来越复杂，新功能和产品的部署可能会放缓。

应该从文化和实践的角度来处理这些障碍。 克服它们包括放弃控制权、提高团队自主权、实施彻底的透明度以及建立有效的产品开发框架来推动成果。

扩展传统敏捷框架的挑战

在扩展敏捷时，管理和团队级别需要同步。 管理层负责制定公司战略、创建和传达产品愿景、执行人员配置决策以及促进团队发展。 团队级别执行必要的任务，以有效地将这一愿景和战略转化为有价值的产品和功能。

传统的敏捷框架（XP、Scrum 和看板）经过优化以在团队级别运行，而管理关系主要未得到解决。 新一波规模化敏捷框架的发展填补了这一空白，即 SAFe、LeSS、Scrum of Scrums、Nexus、DAD 等。然而，这些方法需要大量的计划来实施以及管理和维护。

任务驱动开发框架是一种轻量级的方法，它提供了足够的指导来围绕扩展开发和利用敏捷价值实现一个健壮的结构。

任务驱动发展的核心要素

任务

起点是任务发现。 业务任务需要时间和精力，并且应该识别潜在问题、解决方案空间和期望的业务成果。 准确定义后，任务可以激发动力、促进协作并促进对更广泛设计空间的研究。

小队

每个任务成功的负责人是小队。 与产品经理合作，由 2-4 人组成的小团队开展必要的活动，以提供符合任务目标和时间限制的解决方案。

6周周期

6 周的时间框允许所有小队遵循相同的时间线进行基地规划，同时也有足够的时间来交付有意义的结果。

缓冲期

MDD 框架通常包括一到两周的缓冲期，用于最终集成和部署、培训和技能开发、创新活动和下一个周期规划等。

6 周周期的重要性

虽然对于一些敏捷从业者来说，六周的时间似乎很长，但它包含几个重要的好处。

工作周期短的团队往往会失去对产品愿景的参与，因为他们觉得他们正在检查修复、错误和小功能的“洗衣清单”。 这威胁到团队探索和选择交付解决方案的最佳方式的自主权。

随着周期变长，产品估计精度会降低。 因此，它需要产品团队进行大量的规划工作。

六周被称为产品时间表的“金发姑娘”，通过创新思维、快速原型设计和持续交付提供了足够的时间来交付最小可行产品。

6 周的周期通过利用自主权进一步提高了团队愿景的参与度。 只要任务明确且周期短到足以让团队专注于期望的结果，就不需要微观管理。

最后，产品经理可以每六周参与一次计划活动，为团队保持足够的可预测性，以跟踪任务。 因此，可以将更多时间集中在产品开发的战略性和探索性方面。

任务驱动发展的实施

让我们以一家中期创业公司为例，该公司的 B2B 产品提供网络定价优化，通过使用人工智能应用程序增加客户收入。 该公司最近签署了新一轮融资，目标是巩固自己作为相关行业参与者的地位，并将市场份额提高 300%。

在这种情况下，有几个产品开发挑战：

• 如何获得当前和潜在客户的反馈来验证待定价值假设？
• 应该从平台构建或删除哪些功能以获得引人入胜的用户体验？
• 如何建立管理结构来处理规模扩大和利用文化价值观来加速增长？

最后，为了避免复杂的框架，公司决定应用任务驱动开发框架。 在任务驱动开发中，每个组织都定义了“最后一英里”的细节。 需要定义的主要元素是：

• 任务发现
• 任务结构
• 小队集结
• 检查和适应
• 缓冲迭代
• 容量规划

任务发现

起点是任务发现。 Tim Herbig 将发现描述为减少围绕问题或想法的不确定性的迭代过程，以确保为正确的受众构建正确的产品。 在迭代周期中提交任何任务之前，应尽可能全面地对其进行验证。

任务发现过程由专门分配的团队进行。 发现团队由产品经理领导，由产品研究人员、业务分析师和设计师组成。 当存在多个产品经理时，他们向首席产品官 (CPO) 报告，首席产品官 (CPO) 确保产品的共同愿景、产品和全球公司战略的契合以及及时交付。

任务发现的建议起点是挑战、问题或机遇。 例如，从挑战开始，帮助团队探索更多的设计空间，最终拓宽解决方案的可能性。

任务验证涉及一些有助于公司更好地了解客户需求的活动：

1. 进行市场研究和竞争对手分析
2. 了解定义任务的问题空间
3. 设计低保真草图和原型
4. 为任务定义明确的范围
5. 收集客户反馈和验证

这些活动有助于使命成为开发团队的可靠指南，并保证为用户创造价值。

结果，一些任务被验证进入任务积压，随着发现活动和反馈收集而不断发展。

在示例中，让我们接受这个挑战：应该从平台构建哪些功能来产生引人入胜的用户体验？ 只有一个由产品经理领导的发现团队就足以应对这一挑战。

假设目前，示例公司的平台获取客户的原始数据并返回已处理数据文件的优化定价网络。 但是，平台 UX 并未针对迷人体验进行优化。 此时的目标是确定客户价值是否来自改进用户体验、开发新功能或增强平台服务。

经过初步市场调查后，决定开发新功能。 该平台的候选功能包括：

• 超快速重新定价
• 快速响应的界面
• 智能和先进的定价规则
• 重新定价和销售历史

出于发现的目的，该公司决定采用设计冲刺方法：一个为期五天的流程，通过设计、原型设计和与用户一起测试想法来回答关键业务问题。 为每个候选功能运行发现过程，以查看哪些将为当前和潜在客户创造更多价值。 选择用于开发的首要功能是智能和高级的重新定价规则。

任务结构

实现可靠的任务定义并非易事。 它必须描述一个明确的业务挑战并为其结果设定界限，同时也为小队提供足够的空间来达成创新和有效的解决方案。 明确、准确的使命：

• 明确指出业务挑战，确定并描述了问题空间。
• 综合之前阶段发现的所有信息和见解。
• 链接到期望的业务成果。
• 以结果为导向，清楚地表明任务成功的画面。
• 在 6 周的周期机会内是现实且可实现的。
• 足够窄以保证焦点和足够宽以远离细节。

在示例中，经过一周的发现，信息和用户反馈已被收集和综合。

目标用户：客户定价分析师。

问题空间：用户希望能够设置和管理智能和高级的定价规则，以便在特定条件下自动调整定价。

规则最有价值的条件是竞争对手的价格、运输紧迫性、订单总额、可用库存和高级客户的折扣。

见解：规则应在自定义优先级中应用，并可根据需要进行修改。

分析师希望轻松查看特定产品在特定时间适用哪些规则。

期望的业务成果：将用户平台参与度提高 25%，以在平台上花费的时间衡量。

小队大会

团队组建过程是针对每个开发周期临时完成的。 团队自治和自组织原则仍然是核心。 团队组建受多种因素的指导，包括任务复杂性、开发人员和设计师技能、兴趣和小队化学。

敏捷教练促进了小队形成的过程。 在做出任何决定之前，会询问每个人在接下来的六周内他们想做什么类型的工作。 然后，根据经验、知识和技能，组建小队，确保他们拥有成功完成任务所需的知识和技能。

敏捷教练在开发周期中与多个小组一起工作，帮助他们提高障碍和依赖性。 当存在多个敏捷教练时，他们会向敏捷负责人汇报，后者负责团队组建、持续改进和敏捷产品交付。

建议的小队规模为 2-4 人：通常是一名设计师和一两名开发人员，具体取决于任务的复杂性。 QA 工程师被认为可以帮助一个或多个小队达到所需的质量标准。

每个周期后，小队往往是混合的，所以每个人都可以与不同的人合作，传播知识，在不同的产品维度上工作，尽管一个高绩效的小队可能会一起工作几个周期。

示例中的特定小队应考虑具有 UI 设计、数据处理和数据可视化能力的人员。

在周期内检查和调整

敏捷教练应通过标准敏捷实践不断鼓励透明度、检查和适应。

每周举行一次简短的会议来组织工作并促进提高障碍和依赖性。 如有必要，会进行梳理，以确保小队完全了解任务和用户故事。 每周结束时都会进行简短的回顾，以识别和实施变更和改进。

应在整个周期中保持持续交付实践。 任务目标可以更早地实现，因为 6 周的周期时间框是一种基于节奏的方法来设定基本规则，同时帮助实现班组的可预测性。

根据小队和产品经理之间商定的里程碑，提高透明度的一个好做法是在第四周结束时进行演示。 这些演示的目标是根据需要调整、缩小或增加范围。

对于示例任务，小队和产品经理已就四个不同版本的发布计划达成一致：

1. 发布 1：
   • 新规则功能 UI
   • 竞争对手价格规则
2. 发布 2：
   • 出货紧急规则
   • 订单总计规则
   • 规则优先级
3. 第 3 版：
   • 可用库存规则
   • 可视化应用规则
4. 第 4 版：
   • 高级客户折扣

第 3 版被同意作为第四周的演示。 由于在整个开发周期中都进行了发布，因此应从开发周期开始的那一刻起跟踪期望的业务成果（在这种情况下，用户参与度）。 从图形上看，预计进展如下：

缓冲期

将一到两周作为缓冲期是一种通过任务驱动开发实施以及其他扩展方法（如 SAFe）复制的做法。

在 SAFe 中，每个开发周期都会进行一次创新和规划迭代。 它充当上下文切换器，支持通常被其他以交付为重点的框架遗漏的探索和创新过程和活动。 在这个缓冲周实施的活动示例：

• 最终集成解决方案。 在 6 周周期快结束时进行部署时，集成、验证、文档和验证可能仍处于未决状态。 投入时间有助于确保将新解决方案有效和顺利地集成到现有产品中。
• 任务规划和优先次序。 任务被细化，分成小批量或大批量，并为下一个开发周期确定优先级。 在确定任务的优先级时，一些公司会实施推介日，在此期间向公司介绍最重要的任务，然后以协作的方式承诺下一个开发周期。
• 黑客马拉松。 黑客马拉松在初创公司和公司中越来越受欢迎，这要归功于他们以有趣的方式促进创新、创建社区和建立新知识和技能的能力。 结果将呈现给其他人，并成为任务积压的候选人。
• 实验原型开发或副项目。 通常的做法是让工程师和设计师有时间去做他们决定的任何事情，只要他们展示在缓冲时间结束时完成的工作。
• 工程工作。 通常会执行纯工程工作，例如基础设施开发、测试自动化、技术债务减少和系统迁移。
• 开发新的技能和知识。 知识进化的快速步伐迫使开发人员随时了解全球趋势。 缓冲时间适合举办现场培训、实践社区和技术研讨会等。

缓冲期应依赖于确定的知识差距、创新目标和下一个周期的需求。 例如，一周的缓冲期可能如下所示：

容量规划

根据 Basecamp 联合创始人 Jason Fried 的说法，在决定下一个开发周期的任务承诺时，一种常见的做法是首先确定小批量或大批量。 大批量是指大的产品特性或功能，而小批量是指较小的迭代或任务。 在给定的示例中，为新功能选择的任务可以被视为大批量。

这里的建议很简单：总是混合使用小批量和大批量。 小批量是估计需要 3-4 周的任务，大批量可能需要 6 周或更长时间。

如果小批量团队在第 3 周或第 4 周之前完成了任务，商定的演示是评估小队是否应该继续努力改进实施的解决方案、帮助另一个小队、执行新的小批量任务还是开始计划外的工作。

大批量和小批量的良好混合可以防止人们以 100% 的能力工作，从而使他们能够在计划外工作的情况下进行机动和适应。 大批量团队在周期中尽可能多地关注，而小批量团队可以处理因意外工作而产生的临时任务。

结合小批量和大批量也可以降低风险。 只有大批量会增加对用户体验产生负面影响的可能性。 如果几个新功能的发布彼此接近，它们应该伴随着良好的变更管理。 此外，在计划外工作的情况下，可用容量将减少。 最后，如果几个大批量的团队失败了，迭代可能会被认为是徒劳的，从而使团队士气低落。

任务驱动开发的风险

实施任务驱动开发有很多好处，但作为任何规定性框架，它有几个需要考虑的固有风险。

任务范围

任务应该是现实的，旨在很好地适应挑战的复杂性和小队技能； 否则，对发展成果的影响可能很大。

过于雄心勃勃的任务可能会让人感到沮丧和焦虑，从而对小队的表现产生负面影响。 另一方面，不热情的任务可能会导致小队士气低落和无聊。 因此，最小可行产品的心态应该在框架内保持不变。

使命的原因

强大的业务任务应该对问题空间及其与公司愿景的关系有一个全面的定义。 如果这种关系不明确，由于缺乏对问题解决如何影响公司目标的了解，可能会丢失有价值的见解。

瀑布陷阱

在六周内陷入瀑布模型是小队的自然趋势。 这有两个主要因素。 首先，部署压力在周期快结束时更大。 其次，小队希望在任务中尽可能多地压缩范围，从而导致在开发周期结束时进行部署的紧迫性。 因此，应鼓励持续交付实践以在整个周期中实现敏捷发布并避免与瀑布相关的风险。

产品运营

管理基础设施、服务或监控组件等产品运营任务应保持在小队范围之外，因为它们可能会影响速度。 依赖于原子设计等开发标准和实践可以减少开发工作，从而加速扩展。 该框架下的另一种常见做法是，除了管理产品运营和监控之外，还有一个中央运营团队负责处理基础设施。

6 周周期作为短视框架

有些场景对于框架来说是不够的。 在处理可能对客户体验产生巨大影响的大型复杂系统时尤其如此，例如研发项目或关键系统的迁移。

扩展敏捷的轻量级选项

扩展敏捷以跟上产品开发和公司发展的步伐是敏捷从业者的潜在挑战。 作为最近开发的敏捷方法，任务驱动开发框架因其易于使用和实施而在公司中广受欢迎。 MDD 框架启动了一个端到端的横向产品创新过程，从发现到交付，填补了传统敏捷结构中存在的空白。 任务驱动开发有可能成为成长型公司的新 Scrum。