随着公司的成长，规模扩大 敏捷 产品开发变得更加困难. 根据52%的受访者 敏捷报告的第13个状态, 组织文化和敏捷价值观之间的差异是他们工作中的主要缺点.
组织领导者能够利用敏捷使命来改进产品开发. 强健的敏捷文化包括团队在处理复杂问题时的自主权, 与客户紧密合作, 以及长期愿景和战略.
这些抽象的价值观很难评估和参与. 在一个组织中，实现一个有效的策略来利用它们成为一项非常重要的工作. 使命驱动开发(任务驱动型开发, MDD)方法是从初创公司的中期发展起来的，作为培养这种文化的一种选择.
扩展时可能出现几种减速模式. 目标不明确的项目会降低团队的积极性. 产品经理可能会在运营会议中感到迷失，从而浪费时间来设计战略性产品路径. 随着系统变得越来越复杂，新功能和新产品的部署可能会放缓.
这些障碍应该从文化和实践的角度来解决. 克服它们需要放弃控制, 不断增长的团队自主性, 实施彻底透明, 并建立一个有效的产品开发框架来推动结果.
| 减速模式 | 管理手段 |
| 团队积极性下降. | 放弃控制权，增加团队自主权 |
| 产品经理被业务会议搞得不知所措. | 实施彻底透明 |
| 新特性的部署会变慢. | 建立高效的产品开发框架 |
当 扩展敏捷，管理和团队级别需要同步. 管理层负责制定公司战略, 创建和沟通产品愿景, 执行人员配置决策, 促进团队发展. 团队级别执行必要的任务，以有效地将此愿景和策略转化为有价值的产品和特性.
传统的 敏捷框架 (XP, Scrum, 和看板)被优化以在团队层面上运行, 管理关系基本上没有解决. 新一波 规模化敏捷框架 进化来填补这个空白，我.e., 安全、LeSS、Scrum of Scrum、Nexus、DAD等. 然而，这些方法需要大量的计划来实现，并需要大量的工作来管理和维护.
轻量级方法, 任务驱动开发框架提供了足够的指导方针来实现围绕扩展开发和利用敏捷价值的健壮结构.
起点是探索任务. 业务任务需要时间和精力，并且应该识别潜在的问题, 解空间, 以及期望的商业结果. 当定义准确时, 使命驱动动力, 促进合作, 并促进对更广泛的设计空间的研究.
对每项任务的成功负责的行为者是小队. 与产品经理合作, 由2-4人组成的小团队进行必要的活动，以交付符合任务目标和时间限制的解决方案.
6周的时间表允许所有小队遵循相同的时间表进行基地规划，同时也有足够的时间来交付有意义的结果.
MDD框架通常包括一个或两个星期的缓冲期，用于最后的集成和部署, 培训和技能发展, 创新活动, 下一个周期计划, 除此之外.
虽然对于一些敏捷实践者来说，六周的时间似乎很长, 它有几个重要的好处.
在短周期内工作的团队往往会失去对产品愿景的参与, 因为他们觉得自己正在检查修复的“洗衣清单”, 错误, 还有小特征. 这威胁到团队探索和选择交付解决方案的最佳方式的自主权.
随着周期的延长，产品估计的准确性会降低. 因此，它需要产品团队进行大量的计划工作.
六周被称为 产品时间框架的金发姑娘, 提供足够的时间，通过创新思维交付最小可行产品, 快速原型, 持续交付.
6周的周期通过利用自主性进一步增强了团队的愿景参与. 只要任务明确说明，并且周期足够短，团队可以只关注期望的结果，就没有必要进行微观管理.
最后, 产品经理可以每六周进行一次计划活动, 为团队保持足够的可预测性，以保持对任务的跟踪. 结果是, 更多的时间可以集中在产品开发的战略和探索性方面.
让我们来, 例如, 这是一家处于中期阶段的初创公司，其B2B产品提供网络定价优化，通过使用人工智能应用程序增加客户收入. 这家公司最近签署了新一轮融资协议, 目标是巩固自己作为相关行业参与者的地位，并将市场份额提高300%.
在这种情况下，有几个产品开发挑战:
最后, 为了避免复杂的框架, 公司决定采用任务驱动开发框架. 在任务驱动开发中，“最后一英里”细节由每个组织定义. 要定义的主要元素有:
起点是探索任务. 蒂姆Herbig 描述了 发现是减少问题或想法不确定性的迭代过程，以确保为正确的用户制作正确的产品. 在迭代周期中提交任何任务之前, 它应该得到尽可能全面的验证.
任务发现过程是由专门分配的小组进行的. 发现团队由产品经理领导，由产品研究人员组成, 业务分析师, 和设计师. 当多个产品经理同时存在时, 他们向首席产品官(CPO)汇报。, 谁保证产品之间的共同愿景, 产品与公司全球战略的契合, 及时交货.
建议任务发现的起点是挑战、问题或机会. 从挑战开始, 例如, 帮助团队探索更多的设计空间, 最终拓宽了解决方案的可能性.
任务验证包括帮助公司更好地了解客户需求的几项活动:
这些活动帮助任务成为开发团队的坚实指导方针，并保证为用户创造价值.
结果是, 有些任务经过验证后进入任务积压, 随着发现活动和反馈收集不断发展.
在这个例子中, 让我们来面对这个挑战:应该从平台构建哪些功能来产生引人注目的用户体验? 只有一个由产品经理领导的发现团队才能应对这一挑战.
让我们假设目前, 示例公司的平台获取客户的原始数据，并根据处理后的数据文件返回优化的定价网络. 然而，该平台的用户体验并没有为吸引人的体验而优化. 此时的目标是确定客户价值是否来自于改进用户体验, 开发新功能, 或者加强平台服务.
在最初的市场调查之后，决定开发新的功能. 该平台的候选功能包括:
出于发现的目的，该公司决定采取 设计冲刺 方法:通过设计回答关键业务问题的五天过程, 原型设计, 和用户一起测试创意. 为每个候选特性运行发现过程，以查看哪个将为当前和潜在客户创造更多价值. 选择开发的首要功能是智能和先进的重新定价规则.
实现一个坚实的使命定义并不是一项微不足道的任务. 它必须描绘出一个清晰的商业挑战，并为其结果设定界限, 同时也给球队提供了足够的空间来达成一个创新和有效的解决方案. 明确、精确的任务:
在这个例子中, 经过一周的探索, 收集和综合了信息和用户反馈.
目标用户: 客户定价分析师.
问题空间: 用户希望能够设置和管理智能的高级定价规则，以便在特定条件下自动调整定价.
规则最有价值的条件是竞争对手的价格, 航运的紧迫性, 订单总, 可用库存, 高级客户有折扣.
见解: 规则应该在自定义优先级中应用，并且在需要时可以修改.
分析师希望很容易地看到哪些规则在特定时间适用于特定产品.
期望的业务成果: 以用户在平台上花费的时间来衡量，将用户的平台参与度提高25%.
团队组建过程是针对每个开发周期进行的. 团队自治和自组织原则仍然是核心. 团队组合是由多种因素组合而成的, 从任务的复杂性, 开发人员和设计师技能, 利益, 球队的化学反应.
敏捷教练促进了团队的形成过程. 在做出任何决定之前, 每个人都被问及在接下来的六周冲刺中他们想做什么类型的工作. 然后, 基于经验, 知识, 和技能, 小队的建立确保他们拥有成功完成任务所需的知识和技能.
敏捷教练在开发周期中与多个团队一起工作, 帮助他们提高障碍和依赖性. 当有几个敏捷教练时, 他们向敏捷主管汇报, 谁负责班组集结, 持续改进, 敏捷产品交付.
推荐的小队规模通常是2-4人, 一个设计师和一个或两个开发人员, 取决于任务复杂度. A QA 工程师被认为是协助一个或多个班组达到所需的质量标准.
在每个周期后，小队通常都是混合的, 所以每个人都可以和不同的人合作, 传播知识, 在不同的产品维度上工作, 虽然一个高绩效的团队可能会在几个周期内一起工作.
这个例子中的特定团队应该考虑具有UI设计的人, 数据处理, 以及数据可视化功能.
透明度, 检查, 敏捷教练应该通过标准的敏捷驱动开发实践来不断鼓励适应.
每周举行简短的会议来组织工作，并促进提出障碍和依赖关系. 梳洗完毕, 如果有必要的话, 确保团队完全理解任务和用户故事. 每周结束时进行简短的回顾，以确定和实现更改和改进.
应该在整个周期中保持持续的交付实践. 任务目标可以更早实现, 6周周期的时间表是一种基于节奏的方法，可以在帮助球队实现可预测性的同时制定基本规则.
提高透明度的一个好方法是在第四周结束时进行演示, 基于团队和产品经理之间商定的里程碑. 这些演示的目标是根据需要调整、减少或增加范围.
对于示例任务, 团队和产品经理已经就四个不同版本的发布计划达成一致:
版本3被同意作为第四周的演示版本. 随着发布在整个开发周期中被执行, 期望的业务结果(在本例中), 用户粘性)应该从开发周期开始的那一刻开始跟踪. 从图表上看，预期进展如下:
将一到两周作为缓冲期是任务驱动开发实现中重复的实践, 以及通过其他扩展方法，例如 安全.
在安全中， 创新和计划迭代 在每个开发周期中完成. 它充当上下文切换器, 支持探索和创新的过程和活动通常被其他以交付为重点的框架所忽略. 本缓冲周实施的活动示例:
缓冲期应该依赖于确定的知识差距, 创新目标, 以及下一个周期的需求. 例如，一周的缓冲期可能是这样的:
| 周一 | 周二 | 周三 | 周四 | 星期五 | |
| AM | 最后集成 | 上一周期回顾 | 这家网站 | 这家网站演示 | 宣教宣讲日 |
| PM | 文档 | 培训及工作坊 | 培训及工作坊 | 下一次迭代计划 |
在决定下一个开发周期的任务承诺时，一个常见的做法是， 根据 对Basecamp联合创始人杰森·弗里德(Jason Fried)来说，首先要确定小批量或大批量. 大批量指的是大量的产品特性或功能, 而小批量指的是较小的迭代或任务. 在给定的示例中，为新特性选择的任务可以被视为一个大批.
这里的建议很简单:总是将小批量和大批量混合使用. 小批量任务估计需要3-4周, 大批量生产可能需要6周甚至更长时间.
如果一个小批量团队在第3周或第4周完成了任务, 商定的演示是评估团队是否应该继续改进实施解决方案的机会, 帮助其他小队, 执行一个新的小批量任务, 或者开始计划外的工作.
大批量和小批量的良好混合可以防止人们以100%的产能工作, 从而允许他们在计划外工作的情况下进行机动和适应. 大批量团队在周期中得到尽可能多的关注, 而小批量团队可以处理由意外工作产生的临时任务.
将小批量和大批量结合起来也降低了风险. 只使用大批量会增加对用户体验产生负面影响的可能性. 如果几个新功能相互接近地发布, 它们应该伴随着良好的变更管理. 此外，如果出现计划外的工作，可用的容量就会减少. 最后, 如果几个大团队失败了, 迭代可能会被认为是无效的，从而使球队士气低落.
实施任务驱动的技术开发有很多好处, 而是任何规范性框架, 它有几个需要考虑的内在风险.
任务应该是现实的, aiming at a good fit between challenge complexity and squad skills; otherwise, 对发展成果的影响可能是巨大的.
一个过于雄心勃勃的任务可能会引起挫败感和焦虑, 负面影响球队表现. 另一方面，一个不热情的任务可能会导致球队士气低落和无聊. 因此，最小可行产品的心态应该在框架中保持不变.
健壮的业务任务应该对问题空间及其与公司愿景的关系有一个全面的定义. 如果这种关系不清楚, 由于缺乏对问题解决如何影响公司目标的理解，有价值的见解可能会丢失.
在六周内陷入瀑布模式是团队的自然趋势. 这主要有两个因素. 首先，在周期接近尾声时，部署的压力更大. 第二个, 小队想要在任务中尽可能多地挤压范围, 导致在开发周期结束时紧急部署. 因此, 应该鼓励持续交付实践来实现整个周期的敏捷发布，并避免瀑布相关的风险.
产品操作任务，如管理基础设施, 服务, 或者监控组件应该保持在小队的范围之外, 因为它们会影响速度. 依托开发标准和实践等 原子设计 减少开发工作，从而加速扩展. 在此框架下的另一个常见实践是一个处理基础设施的中央操作团队, 除了管理产品运营和监控.
有些场景不适合该框架. 在处理可能对客户体验产生巨大影响的大型复杂系统时尤其如此, 比如R&D项目或关键系统的迁移.
对于敏捷实践者来说，扩展敏捷以跟上产品开发和公司成长的步伐是一个潜在的挑战. 作为最近开发的敏捷方法, 任务驱动开发框架因其易于使用和实现而在公司中受到欢迎. MDD框架启动了端到端, 横向产品创新过程, 从发现到交付, 填补了传统敏捷结构中存在的空白. 这种开发模式有潜力成为成长型公司的新Scrum, 预测一个使命驱动型创业公司的时代.
有许多不同的敏捷框架适用于不同的情况. 一个或几个团队的传统框架包括Scrum、看板和XP. 规模化敏捷框架包括安全、LeSS、DAD、Scrum@Scale、任务驱动开发等.
正常的开发周期, 根据SDLC, 包括计划, 分析, 设计, 实现, 和维护.
产品开发过程的六个阶段是创意产生, 市场研究, 概念的发展, 产品设计与开发, 测试, 和发射.
项目周期的五个阶段是:启动、计划、执行、监视和结束.
项目周期的要素是范围、资源、进度、质量和风险.
世界级的文章，每周发一次.
世界级的文章，每周发一次.
作者都是各自领域经过审查的专家，并撰写他们有经验的主题. 我们所有的内容都经过同行评审，并由同一领域的Toptal专家验证.