随着公司的发展，扩展敏捷（Agile ）产品开发变得更加困难。在第13期敏捷报告中，52%的受访者表示，他们工作中最大的问题是公司文化和敏捷理想之间的差异。
组织领导者可以使用敏捷文化来促进产品开发。强大的敏捷文化需要团队在应对复杂挑战方面的自主权、与客户的紧密协作以及长期愿景和战略。
这些抽象的品质很难被评估和参与。实施有效的计划来利用它们在公司中变得困难。作为创造这种文化的替代方案，任务驱动发展（MDD）方法已经从中期企业中出现。
扩展问题
成长时，可能会出现许多缓慢模式。当项目的最终目标不明确时，团队的积极性可能会受到影响。产品经理可能会在运营会议上迷失方向，从而减少定义战略产品路线的时间。随着系统变得越来越复杂，新功能和产品的部署可能会滞后。
必须从文化和实际的角度解决这些障碍。为了克服这些问题，您必须放弃控制，增加团队自主权，应用彻底的透明度，并建立有效的产品开发框架来推动结果。
| 典型的减速 | 管理杠杆 |
|---|---|
| 团队积极性下降。 | 放弃控制权，增加团队自主权 |
| 运营会议使产品经理不堪重负。 | 引入彻底的透明度 |
| 新功能的推出速度较慢。 | 创建有效的产品开发框架 |
扩展传统敏捷框架的困难
在发展敏捷时，管理层和团队级别必须同步。管理层负责制定公司战略，生成和阐明产品愿景，做出招聘选择并鼓励团队成长。团队层面负责履行将这一愿景和战略有效转化为有价值的商品和服务所需的职责。
传统的敏捷框架（XP，Scrum和Kanban）旨在在团队级别运行，在很大程度上忽略了管理关系。为了满足这一需求，新一代的规模化敏捷框架应运而生，包括SAFe、LeSS、Scrum of Scrums、Nexus、DAD等。但是，这些技术需要大量的准备工作,管理和维护。
任务驱动开发框架是一种轻量级方法，它提供了足够的规则来围绕扩展开发和使用敏捷概念构建一个坚实的结构。
任务驱动型开发的基础
任务
发现任务是初始点。业务任务需要时间和精力来发现隐藏的问题、解决方案领域和所需的结果。当明确表达一个目标时，会产生动力，发展合作，并支持对更大设计领域的研究。
团队
小队是任务成功的责任。由2-4人组成的小团队与产品经理协调执行基本任务，以开发满足任务目标和进度限制的解决方案。
6周周期
6周的时间框架使所有小队能够遵守相同的基础计划日历，同时仍然有足够的时间来提供重要的产出。
缓冲时间
MDD 架构中经常包含为期一周或两周的缓冲阶段，用于最终集成和部署、培训和技能发展、创新活动和下一个周期规划等。
6周周期的价值
虽然六周对于一些敏捷从业者来说似乎是很长的时间，但它有许多关键的优势。
在短周期内运作的团队往往会对产品愿景失去兴趣，因为他们觉得自己正在勾选修复、问题和改进“清单”。这将威胁团队调查和选择最佳方式提供解决方案的能力。
产品估算精度随着周期的延长而下降。因此，产品团队必须在规划方面投入巨资。
六周被称为产品开发的“黄金”时间表，因为它有足够的时间通过创造性思维、快速原型设计和持续交付来构建最小可行产品。
6 周的周期通过使用自治进一步提高团队愿景参与度。如果任务明确阐明，周期足够短，小组只能集中精力实现预期目标，则不需要微观管理。
最后，产品经理可以每六周参与一次规划活动，确保团队朝着目标前进。因此，可以将更多时间花在产品开发的战略和实验方面。
任务驱动型开发实施
考虑一家拥有B2B解决方案的中期公司，该解决方案通过使用人工智能技术优化网络价格并增加客户收入。该公司刚刚完成了新一轮投资，目的是将自己打造成重要的行业参与者，并将市场份额增加300%。
此方案中存在各种产品开发问题：
- 如何通过从现有和未来客户获取输入来验证待定值假设？
- 应添加或删除哪些平台功能以提供引人注目的用户体验？
- 如何设计管理结构以承受增长，同时利用文化价值观来推动增长？
最后，组织选择使用任务驱动开发框架，以避免复杂的框架。每家公司都在任务驱动开发中定义“最后一英里”细节。以下是需要定义的主要元素：
- 任务识别
- 任务结构
- 小队组建
- 检查和修改
- 缓冲时间
- 容量管理
任务识别
任务发现是初始点。Tim Herbig将发现定义为消除问题或概念歧义的迭代过程，以便为正确的受众构建适当的产品。在迭代周期中提交每个任务之前，应对其进行彻底验证。
团队被分配以执行挖掘发现过程。产品经理领导团队，其中包括产品研究人员、业务分析师和设计师。当有许多产品经理时，他们会向首席产品官 （CPO） 报告，首席产品官确保产品愿景一致、产品与整体公司战略契合以及及时交付。
挑战、问题或机遇是发现任务的理想起点。例如，从问题开始允许团队探索其他设计领域，最终扩展解决方案选择。
任务验证需要许多举措，以帮助组织更好地了解消费者需求：
- 研究市场并分析竞争对手
- 识别描述任务的问题域
- 创建粗略的图纸和原型
- 制定定义的任务范围
- 获取和验证客户反馈
这些行动有助于作为开发团队的坚定指导方针，并确保为用户提供价值。
因此，某些特派团得到核实并添加到特派团待办事项表中，由于发现活动和反馈收集，待办事项不断增多。
考虑以下挑战：应从平台创建哪些功能以提供更好的用户体验？此任务只需要一个由产品经理管理的团队。
假设公司的平台目前接受来自客户的原始数据，并为处理后的数据文件提供最佳定价网络。另一方面，平台UX尚未针对良好的体验进行调整。在此阶段，我们的目的是为了评估增加客户价值是否来自改进用户体验、引入新功能或改进平台服务。
经过初步的市场调查，决定构建其他功能。以下是潜在的平台功能：
- 以闪电般的速度重新定价
- 快速且响应迅速的界面
- 智能而复杂的重新定价规则
- 销售历史和价格
该组织选择采用设计冲刺技术来实现探索目的：一个为期五天的过程，通过设计、原型制作和与人员一起测试概念来解决关键业务问题。针对每个候选特征执行发现过程，以确定哪些特征将为现有和潜在客户提供更大的价值。智能和复杂的重新定价规则被选为开发的首要功能。
任务结构
制定一个健全的团队定义并非易事。它必须说明一个明确的业务困境，并提供解决其问题的参数，同时仍然为团队留出足够的空间来提出创造性和高效的解决方案。明确的使命：
- 在确定并描述问题域后，清楚地概述业务挑战。
- 在前几轮中获得的所有信息和见解都是综合的。
- 与所需业务结果的连接
- 以结果为导向，对任务成功有清晰的愿景。
- 在 6 周周期窗口内可行且可实现。
- 足够限制以提供关注，同时足够广泛以避免细节。
在该示例中，经过一周的探索，收集和合成了信息和用户输入。
目标受众：客户端定价分析师
问题领域：用户希望能够创建和维护智能且复杂的定价规则，这些规则将根据特定条件自动修改价格。最重要的规则情况是竞争对手定价、交货紧迫性、订单总额、可用库存和高级客户折扣。
见解：规则应以自定义优先级实现，并在必要时可更改。分析师希望随时了解哪些规则适用于不同时期的特定产品。
期望的业务成果：以在平台上花费的时间衡量，将用户在平台上的参与度提高 25%。
小队组建
每个开发周期，团队建设过程都是临时完成的。团队自主和自组织的理想仍然很重要。各种因素会影响团队的形成，包括任务难度、开发人员和设计师的才能、爱好和团队友情。
敏捷教练帮助团队建设过程。在做出任何决定之前，每个员工都会被问及他们想在接下来的六周内完成什么样的工作。然后，根据经验、知识和能力，组建小队，以确保他们具备有效完成行动的基本知识和技能。
敏捷教练在整个开发周期中与许多小队合作，帮助他们识别障碍和依赖关系。当有大量敏捷教练时，他们会向敏捷主管报告，后者负责小队组建、持续改进和敏捷产品交付。
理想的小队规模是2-4人，包括一名设计师和一到两名开发人员，具体取决于任务的难度。质量保证工程师是帮助一个或多个小队达到必要质量标准的人。
虽然一个高绩效的小队可能会一起工作几个周期，但每个周期后通常会交换小队，以便每个人都可以与不同的人合作，转移专业知识，并从事不同的产品方面的工作。
具有UI设计，数据处理和数据可视化技能的人员应考虑用于示例团队。
检查和修改
敏捷教练应该始终如一地支持使用传统敏捷方法的透明度、检查和适应性。
每周组织简短的会议来计划工作，并更容易提出障碍和增进关系。如果有需要，会进行梳理，以确保小队完全掌握目的和用户故事。每周都会举行简短的回顾会议，以确定和实施修改和改进。
在整个周期中，应遵循持续交付方法。6周周期时间盒是一种基于节奏的策略，用于设置基本规则，同时协助小队的可预测性，因此任务目标可能会更快地实现。
在第四周结束时，根据小队和产品经理之间商定的里程碑进行演示，是提高开放性的明智方法。这些演示的目的是根据需要调整、降低或扩大范围。
小队和示例任务的产品经理之间已经商定了四个单独版本的发布计划：
版本 1：
- 新规则功能的 UI
- 竞争对手的价格规定
版本 2：
- 运输紧急性规则
- 总订单规则
- 通过规则设置优先级
版本 3：
- 存库规则的可用性
- 可视化应用规则
版本 4：
- 高级客户获得折扣
第四周的演示已商定为第 3 版。由于发布在整个开发周期中都发生，因此应从开发周期开始监视目标业务目标（在此示例中为用户参与）。
缓冲时间
使用一周或两周作为缓冲阶段是一种在任务驱动开发实施和其他扩展方法（如 SAFe）中重复的技术
SAFe 中的每个开发周期都包括创新和规划迭代。它充当上下文改变者，促进探索和发明的过程和活动，这些过程和活动通常被以交付为中心的框架所排除。在此缓冲周内执行的操作示例：
- 解决方案的最终集成。在 6 周周期结束时交付时，集成、验证、文档和确认可能非常出色。专用时间有助于将新解决方案成功无缝集成到当前产品中。
- 确定优先级和任务规划。为下一个发展周期，对任务进行细化、分类和优先排序。在任务优先级方面，有几家公司有推介日，在此期间，顶级任务被提交给团队，然后协作致力于下一个开发周期。
- 黑客马拉松。黑客马拉松在初创公司和企业中越来越受欢迎，因为它们能够在有趣的环境中激发创造力、建立社区并获得新的知识和技能。成果与其他人分享，并成为Mission Backlog的候选者。
- 开发实验原型或副项目。通常的做法是让工程师和设计师从事他们选择的任何事情，只要他们展示在缓冲期结束时完成的工作。
- 从事工程工作。基础设施开发、测试自动化、技术债务减少和系统迁移是纯工程活动的典型示例。
- 获得新的技能和信息。由于信息的不断发展，开发人员必须跟上全球趋势。缓冲期非常适合现场培训、实践社区和技术研讨会。
缓冲间隔应基于公认的知识差距、创新目标和下一个周期需求。
容量管理
根据Basecamp联合创始人Jason Fried的说法，选择下一个开发周期的任务承诺的常用方法是首先确定小批量或大批量。小批量涉及次要迭代或作业，大批量是指较大的产品特性或功能。在提供的示例中，为新功能选择的任务可以被视为大批量任务。
这里的建议很简单：始终保持小额和大量之间的平衡。小批量是预计需要3-4周的任务，而大批量可能需要6周或更长时间。
如果一个小批量团队在第 3 周或第 4 周完成其任务，则商定的演示允许小队选择是否应该继续改进当前解决方案、协助另一个小队、承担新的小批量任务或承担计划外工作。
大批量和小批量的适当平衡可以阻止个人满负荷工作，使他们能够在发生意外工作时进行机动和反应。大批量团队在整个周期中会得到尽可能多的关注，但小批量团队可能会处理由于意外活动而发展的临时工作。
将小批量和大批量相结合也可以最大限度地降低风险。只有大批量会增加对用户体验产生负面影响的可能性。如果同时引入许多新功能，则应通过有效的变更管理来补充它们。此外，如果发生意外工作，可用容量将减少。最后，如果许多大批量团队失败，迭代可能会被视为徒劳无功，使小队士气低落。
任务驱动型开发的危险
采用任务驱动开发有几个优点，但与任何规范性框架一样，需要考虑某些危害。
使命宗旨
任务应该是现实的，在任务难度和小队能力之间取得合理的平衡;否则，对发展成果的影响可能会很严重。
过于雄心勃勃的任务可能会引起烦恼和担忧，影响团队效率。另一方面，无趣的任务可能会导致小队士气低落和无聊。因此，应在整个结构中保持最小可行产品的态度。
使命的目的
在强有力的商业任务中应包括对问题领域及其与公司愿景关系的全面解释。如果这种联系不清楚，再来对问题解决如何影响公司目标的误解，可能会错过有用的见解。
瀑布陷阱
在这六周的时间里，小队有一种自然的倾向，会陷入级联模式。这背后有两个主要原因。首先，在周期结束时，部署的压力更大。其次，小队试图在任务中尽可能多地适应范围，这造成了在开发周期结束时部署的匆忙。因此，应支持持续交付方法，以便在整个周期中完成敏捷发布，同时避免瀑布问题。
产品利用率
维护基础设施、服务或监控组件等产品运营职责应排除在小队的职权范围之外，因为它们可能会影响速度。使用开发标准和方法（如原子设计）可以节省开发工作，从而加快可伸缩性。除了管理产品操作和监视之外，管理基础结构的中央运营团队是此方法中另一种普遍的做法。
六周周期作为短视结构
有些情况对于框架来说是不够的。在处理可能对客户体验产生重大影响的大型复杂系统时尤其如此，例如研发计划或关键系统迁移。
扩展敏捷的简单方法
扩展敏捷以跟上产品开发和企业扩张是敏捷从业者不言而喻的问题。任务驱动开发框架是一种新建立的敏捷技术，由于其使用和执行的简单性而在企业中获得了吸引力。MDD框架启动了一个跨职能产品创新过程，从发现到交付，解决了标准敏捷框架中的漏洞。任务驱动开发有可能在扩展业务中取代Scrum。
