菜单
菜单
动态系统开发方法（DSDM Dynamic Systems Development Method）是一种敏捷项目交付框架，最初用作软件开发方法，于1994年首次发布，最初试图为快速应用程序开发（RAD）方法提供一些学科。后来的版本中，DSDM敏捷项目框架进行了修订，成为项目管理和解决方案交付的通用方法，而不是专门关注软件开发和代码创建，可以用于非IT项目。DSDM敏捷项目框架涵盖了整个项目生命周期中的广泛活动，包括很强的基础和治理理论，这使它与其他一些敏捷方法不同。DSDM敏捷项目框架是一种迭代和增量的方法，它包含了敏捷开发的原则，包括持续的用户/客户参与。
在20世纪90年代初，快速应用程序开发（RAD）在整个IT行业传播开来。软件应用程序的用户界面正在从旧的绿色屏幕转移到今天使用的图形用户界面。新的应用程序开发工具即将上市，例如PowerBuilder。这使开发人员能够更容易地与客户分享他们提出的解决方案——原型设计成为现实，经典的顺序（瀑布）开发方法的挫折感可以被搁置一边。
然而，RAD对于合适的流程没有达成一致的定义，许多组织都提出了自己的定义和方法。许多大公司对这些可能性非常感兴趣，但他们也对这种自由式开发流交付在质量水平产生质疑。
DSDM起源于巴特勒集团在伦敦组织的一次活动。参加会议的人都为英国航空公司、美国运通、甲骨文和Logica等蓝筹组织工作。联盟成立于1994年，由软件工程领域的供应商和专家组成，其目标是通过结合他们的最佳实践经验，“共同推动开发一个独立的RAD框架”。
2006年7月，DSDM公共版本4.2可供个人查看和使用；然而，任何转售DSDM的人必须仍然是非营利财团的成员。
2014年，DSDM手册在网上公开发布。此外，还可以下载DSDM的模板。
2016年10月，DSDM联盟更名为敏捷商业联盟（ABC）。敏捷商业联盟是一个非盈利、独立于供应商的组织，拥有并管理DSDM框架。
DSDM构建在常识以及实用主义之上，以确保敏捷价值观“个人和互动”优先于“过程和工具”得以贯彻。
常识：应用普通的自有才智，不依赖于专业知识以及训练地进行合理且适用的判断。
实用主义：行为或者规则是以事实为依据出发而不是理论或者某种教条。
进一步讨论之前，我们先需要理解项目管理过程中的各种因变量，即必须平衡管理过程中相互冲突的需求，最常见的四个需求是：时间、成本、范围和质量。在项目一开始就试图解决这四个问题是不现实的，因为这只会在一个完美的世界里起作用，即业务需求永远不会变，一切都提前得到充分准确的理解以及预测，问题永远不会发生。这种修复一切的愿望是许多项目失败的原因，由于缺乏足够的应急措施导致有缺陷的决策，而这些通常会最终影响项目的交付。
因此，在项目开始时，重要的是要问这样一个问题：“如果我们遇到了问题，我们应该保护（修复）什么？如果必要，我们可以协商（改变）什么？”
在传统的管理项目方法中范围是固定的，而时间和成本可能会发生变化。如果项目偏离轨道，通常会增加更多的资源（这会改变成本）和/或延长交付日期（这会影响时间）。然而，为进度落后的项目添加资源往往会使项目交付更慢而且拉高了项目成本，并且从业务角度看，错过最后交付期限可能是灾难性的，而且往往会损害多方的信任度。在多重压力下，还可能未经深思熟虑地进行妥协妥协，比如减少了必要的质量控制步骤或减少了测试，质量也会成为一个变量。
DSDM管理项目方法在早期阶段结束时确定了时间、成本和质量，而应变措施则是通过改变要交付的功能的范围施以管理。当需要执行应变措施时，根据MoSCoW的优先级规则，经过业务利益相关者的确认，推迟较低优先级需求的交付。只要遵循MoSCoW和时间盒的实践，DSDM项目就可以始终按时、按成本（按预算）交付可行的解决方案，即便是最差的情况也可以保证按MVP范围完成交付。
每个项目的质量水平取决于单个项目的实际要求。所以并不是每个项目都要“最高质量”，只需要达到在对应项目开始时商定的质量标准即可。DSDM确定项目质量的方法之一是在开发开始前就单个需求的验收标准达成一致。开发的迭代和增量方法确保了更重要的需求被构建到一致明确的质量标准。只有在实现了这一点之后，才开始对后续的需求进行开发。这种演进式解决方案的增量交付确保在解决方案生产发布的当天，其已集成的部分合乎一致的质量标准。
项目期间做出的每一个决定都应该围绕项目目标来权衡，以确保在需要交付的时候交付业务所期望的内容。
为了实现这一原则，DSDM团队需要：
DSDM通过明确特定业务角色、基础阶段定义的业务产品、时间盒和MoSCoW等关键实践，使DSDM团队能够实现这一原则。
按时交付解决方案是非常理想的项目结果，而且往往是最重要的成功因素。延迟交付通常会破坏项目的根本，尤其是在涉及市场机会或法规截止日期的情况下。
为了实现这一原则，DSDM团队需要：
结合时间盒和MoSCoW排序实践，使DSDM团队能够在调整功能的同时保护截止日期，并建立及时和可预测交付的声誉。基于时间盒技术在较短的时间周期内按时交付以及满足业务的期望，构成了通过及时交付增量来管控长期项目交付的基础。
本着积极合作和守护承诺精神工作的团队将永远胜过只在松散关系中单打独斗的个体。协作鼓励团队增进理解、提升效能和集体共有，这使团队的集体表现超越了每个人单独能力的总和。
为了实现这一原则，DSDM团队需要：
DSDM的商业远见者、商业大使和商业顾问角色将适当的主题专家带入项目，以便他们能够为解决方案做出贡献。解决方案开发团队将业务和技术角色聚集在一个团队中。团体文化体现在两方面，一是业务分析师引导团队就需求达成共识，另一方面是团队负责人负责促进所有解决方案开发团队成员之间的高水平协作。被有效引导的工作坊使利益相关者能够与项目团队的其他成员有效地分享他们的知识。
在DSDM中，应在开始时就交付的质量水平达成一致。所有工作都应以达到这一质量水平为目标——不多也不少。所以，解决方案也必须“足够好”。如果业务部门认同最小可用子集中的功能符合约定的验收标准，那么交付成果就应该刚刚好可以使用以满足。
为了实现这一原则，DSDM团队需要：
确保测试正确地集成到迭代开发过程中，并在整个项目生命周期中进行定期审查，有助于DSDM团队构建高质量的解决方案，以证明解决方案的质量符合预期标准。
使用DSDM，一切都会尽早进行测试。MoSCoW和时间盒用于确保实施了合理的测试，并且没有引入不必要的风险。在IT项目中，通过确保在开发开始前了解解决方案的可验证性，使用测试驱动的开发技术也可以显著提高解决方案的质量。
DSDM主张首先了解要解决的业务问题的范围和可选解决方案，但不要过于详细以防止项目因过于详细的需求分析而瘫痪。一旦建立了坚实的开发基础，就以增量方式交付解决方案，以便在实际可行的情况下尽早地交付真正业务价值。增量交付增强了利益相关者的信心，是在后续的时间盒活动中获得反馈的基础，以最终达成业务价值尽早实现。
为了实现这一原则，DSDM团队需要：
DSDM团队通过在可行性分析和基础构建阶段提供坚实的知识基础，然后在增量开发阶段逐步构建解决方案来实现这一原则。
DSDM结合迭代开发、频繁演示和全面审查来促成及时反馈。拥抱变更，并将其视为能使团队能够交付准确的业务解决方案的产品演进过程的组成部分。迭代的概念是DSDM方法的核心。
为了实现这一原则，DSDM团队需要：
在时间和成本的限制下变更被以积极的态度处理，以制定最合适的解决方案。DSDM使用迭代和持续地审查来确保正在开发的内容是业务真正需要的。
沟通不畅经常被认为是项目失败的最大单一原因，DSDM实践就是专门为提高团队和个人的沟通效率而设计的。
为了实现这一原则，DSDM团队需要：
DSDM强调个体互动的价值，建模和原型制作使解决方案的早期实例可供仔细地审查。这些实践远比使用大型文本文档更有效，这些文档有时是出于实现项目业务目标以外的原因而编写的。
在项目的全周期进行管控并且能够验证这一点是非常关键的。这只能通过检查即将完成工作的计划来实现，而这个计划要与确定的业务目标保持一致。并且团队在过程中要保持所有工作的透明。
为了实现这个原则，DSDM团队尤其是项目经理和团队负责人，需要“
定义明确的时间盒、持续的审查点、管理基础的准备和时间盒计划等实践都是为了帮助项目经理和项目团队的其他成员遵循这一原则而设计的。
开发和交付的DSDM方法都是迭代的和增量的，最重要的业务需求通常在早期得到解决，而不太重要的功能则在稍后交付。DSDM的迭代性质使业务代表能够在解决方案的演进过程中就能看到解决方案，并基于此提供反馈，使其可以在整个解决方案的开发过程中请求变更。与大多数敏捷方法不同，DSDM将项目管理和产品开发集成到一个过程中。
DSDM过程模型包含了一个有六个主要阶段（项目预备期、可行性分析、基础构建、迭代开发、部署以及后项目阶段）的框架，该框架显示了DSDM阶段及其相互关系。
在此阶段，组织确保启动了对的项目，并且这些项目基于清晰定义的目标被组建得当。
可行性分析阶段主要旨在确定拟建项目从技术角度来看是否可行，以及从业务角度来看是否具有成本效益。
项目在此阶段被进一步推进，旨在从顶层视角理解业务的初衷、形成项目的潜在解决方案并对如何开发和交付解决方案进行初步管理。在此阶段要避免过于追求大而全，下沉到底层细节中，即便是大型复杂项目也要确保这个阶段在几周内就可以结束。和需求细节相关以及如何该解决方案这类工作是在迭代开发阶段才进行处理。
在项目实施一段时间以后有时会需要重新审视项目的基础，包括重新审视在项目初期确定的计划，例如在外部环境瞬息万变的情况下项目生命周期内为了响应变化而产生的变更，或者在部署在生产环境后发现的不符合预期的情况等。
对项目基础的更新和细化所需的时间比第一次做的时候要少很多，可以像组织一次工作坊一样。对于更小的项目，可行性分析和基础构建阶段甚至可以合并在一起。
这个阶段的目标是明确工作的范围以及交付方式（谁、何时、何地）。基础构建阶段也决定了项目的生命周期，确定了DSDM的过程该如何被实施以解决项目的特殊需求。
项目基础已经构建，接下来就是在此阶段通过迭代交付的方式演进解决方案。需要解决方案交付团队应用包括迭代交付、时间盒、MoSCoW排序、建模技术和工作坊等实践以随着时间推移从技术视角以一个正确的方式交付符合业务需求的精准解决方案。
在时间盒内开展工作，解决方案交付团队创建解决方案的增量，迭代式地发掘底层需求细节以及持续测试以向前推进。
此阶段的目标是为不断演进的解决方案的投入运营使用构筑基线，包含了三个主要的活动：集成、审查以及部署。
在实际部署之前，通常会进行一些活动，以确保交付的内容是一致的。这也可能包括汇集任何相关的支持信息，也包括将要发布的内容集成的工作。
在一个简单的小项目中，汇集过程中所涉及的工作可能是最少的。在更大、更复杂的项目或计划中，多个项目被整合到一起，或将多个解决方案增量整合到单个版本中的工作量可能很大，例如，将新的业务流程、培训时间表、用户指南和新的IT解决方案相结合。
一旦发布的所有元素都汇集好了，在大多数情况下，就会有某种形式的“部署批准”。这将基于在解决方案投入运营使用之前对其进行的最终审查，以确保提交的发布符合适当的标准，并且足够完整、可行。
在这一点上，团队还对项目增量进行了回顾，重点关注工作方式和潜在的改进领域。来自产品回顾和正式审查的信息有助于制定未来增量计划，并可用于促进投资组合中项目间的学习。
一旦获得批准，部署就是将已集成的内容投入运营使用的实际行为。它包括任何与发布有关的工作，如将解决方案转移到生产环境中、制定任何业务变更计划等。
在项目的最终部署之后，后项目阶段检查预期业务效益的实现情况。可能看上去更强调眼前的效益，因为绝大部份的收益将在解决方案投入生产后的全生命周期内进行累加。
需要注意的是，后项目阶段针对这些与商业案例相关的收益进行一次或多次评估。但是根据组织的需要，业务收益分析也可以在项目期间对独立版本开展，这意味着收益评估应在后项目阶段之前就开始了。
成员有效地协作是任何项目成功的基础，最好的解决方案来自于自组织、有能力的团队。然而，组成屯对的成员必须在商定的范围内积极地承担角色所赋予的权利以及责任，密切合作，打破潜在的沟通障碍。
团队成员在一起协作需要：
包括：业务投资人、业务负责人、业务大使和业务顾问。
包括：技术架构师、解决方案开发人员、解决方案测试人员和技术顾问角色。
包括：项目经理和团队负责人
包括：工作坊引导师和DSDM教练
项目层级的角色在所需要的情况下（业务投资人、业务负责人、技术架构师、项目经理和业务分析师）指导、管理和协调项目工作。他们是项目治理委员会的成员共同对项目方向有主导权利，并且负责项目外部的沟通和协调。业务投资人提供总体的战略和项目预算控制。业务负责人和技术架构师分别负责业务以及技术的愿景规划。项目经理确保项目的资金被有效使用以在商定的时间范围内交付目标解决方案。
业务分析师在项目层级以及在解决方案开发团队中都有参与。一方面可以帮助业务形成商业案例，也在可行性分析以及构建阶段帮助定义需求。另一方面在更多需求细节涌现时持续支持解决方案开发团队以及项目层级角色。
所有项目层级的角色需要采用引导、授权式的领导力风格，以帮助敏捷团队在前进的过程中反思、调整以及改进流程。他们需要确保解决方案开发团队工作方面的自由度，在授权的框架范围内，按照他们自己的方法达成最终目标。
项目层级的角色围绕积极向上的成员构建项目，相信团队会按他们的能力做到最好，为团队营造自组织环境并且满足他们工作所需。
解决方案开发团队的角色包括业务大使、解决方案开发人员、解决方案测试人员、业务分析师和团队负责人，这些角色构成了项目的“引擎室”。他们制定和构建解决方案，并共同负责其日常开发和确保其符合于商业目标。一个项目中可能有一个或多个解决方案开发团队，每个团队都包括解决方案开发团队的所有角色，并承担其对应职责。
每个解决方案开发团队的成员在整个项目中都应该是稳定的，即便在最坏的情况下，每个解决方案发展团队在一个项目增量中都应该保持稳定。解决方案开发团队的每个成员都是一个有专业能力的个人，他们对自己的责任领域拥有主人翁意识，并代表同行的利益。
辅助角色（业务顾问、技术顾问、工作坊引导师和DSDM教练）在整个生命周期中为项目提供临时协助和指导。如有必要，顾问职位可由一名或多名主题专家担任。顾问角色不是授权的决策者，但他们在需要专业知识的领域（如法律和合规事务、技术知识、特定业务规则和法规）向解决方案开发小组提供建议。辅助角色在必要时参与项目，例如业务或技术顾问将在项目基础构建阶段积在特定的时间盒内极参与，应用他们的专业知识协助正确塑造演进式解决方案。
所有DSDM角色都需要在过程中适当地参与项目，以充分履行其角色的职责。
项目级别的角色需要充分参与项目过程，以确保持续开展的项目工作与业务需求保持一致、交付的解决方案符合商定质量，并确保商业案例的可行性被持续验证。因此，项目层面的角色不仅要参与高层级的审查和规划会议，也要参与需要他们进行关键问题和战略决策的更底层的详细级别会议。通常不需要他们参加日常的活动，主要在时间盒开始、结束以及过程中的评审中给予支持。
解决方案开发团队的角色需要在细节层面积极参与项目的日常工作，形成、构建、审查和测试在每个时间盒结束时交付的解决方案增量。团队中所有人都必须参加每日站会，以便对进展和任何问题保持共识。作为自组织的团队，就履行交付承诺所需的详细计划和行动达成一致，持续、公开、诚实的沟通和日常合作是取得良好进展的关键，进展的透明度和工作在展示控制力方面很重要。
如果项目级别的角色确实参与了细节层面的工作，那么重要的是，他们应该作为观察者、领导者和问题负责人，而不是作为团队或正在进行的工作的管理者。
一个DSDM角色并不一定意味着固定一个人。一个人可以扮演一个角色或多个角色。同样，一个角色可以由两个人或多个人分担。然而，当一个角色在个人之间分配时，这些人密切沟通和合作是至关重要的。
例如：
在大型IT项目中，技术架构师的职责可能分配给多个人，例如系统设计师/架构师、网络经理、基础设施经理等。
在品牌项目中，解决方案开发人员的职责可能是分开的，一个解决方案开发人专注于徽标设计，另一个专注于关键营销信息。
相反，在较小的项目中，一个人往往扮演多个角色。
例如：
一个人可以同时履行项目经理和团队负责人的职责。
然而，有些角色通常只由一个人完成，无论项目规模如何，例如，应该只有一个业务负责人和一个业务投资人。（尽管通常情况下，一个人同时担任业务投资人和业务负责人的角色）。
地理限制或人员可用性等问题可能会影响理想项目团队的创建，但强烈建议考虑所有角色，并酌情理解和接受他们的个人责任。角色定义可以作为项目个人职权范围的基础。
此角色是最高级的项目级业务角色。业务投资人是对项目、提交的解决方案以及交付方法承诺的项目支持者。在正式和非正式的情况下，业务投资人都专门负责整个商业案例和项目预算。
其必须在组织中担任足够高的职位，以便能够解决业务问题并做出财务决策。这一角色对确保整个项目的快速进展负有至关重要的责任。
业务发起人应在项目期间提供承诺、支持和可用性，提供明确的向上沟通路线。在较小的项目中，业务投资人的角色将始终由一个人完成。然而，在大型项目或复杂组织中，其财务责任可能由更高的组织机构履行，如投资委员会或执行委员会。在这种情况下，DSDM希望企业同意由特定的人来“代表”这个角色。这确保了项目只涉及一个最终决策者和一个最高层，避免因多方对项目的不同看法而缺乏明确的决策。
职责
这是一个项目层面的高级业务角色，应该由一个人担任，因为一个项目需要一个清晰的愿景来避免混乱和误导。业务负责人比业务投资人更积极地参与项目过程，负责解释业务投资人的需求、将这些需求正确地传达给团队，并确保这些需求在商业案例中得到体现。业务负责人始终参与整个项目，为团队提供战略指导，并确保所提供的解决方案能够实现业务案例中所述的目标利益。项目结束时，业务负责人将拥有部署的解决方案，并负责实现与之相关的任何利益假设。
职责
作为项目的技术权威，提供技术相关的愿景规划。技术架构师确保解决方案/技术的角色以一致的方式工作，确保项目技术方案的合理性以及符合所需的技术标准。技术架构师整合项目范围内的所有技术相关因素，为技术决策和创新提供建议。
职责
除了以敏捷领导力风格在高层级方面与解决方案开发团队协作外，该角色还专注于管理解决方案演进过程中团队所处的工作环境。项目经理在高层级协调项目管理的各个方面，但根据DSDM的授权理念，项目经理应将产品实际交付的详细规划留给解决方案开发团队的成员。管理一个被授权的团队需要一种服务型的风格，而不是通过“指令和控制”。
尽管项目经理的职责是专注于交付项目，但该角色的任命也取决于所需的技能、知识以及项目自身要求。项目经理可能来自业务，也可能来自解决方案/技术侧的人员。对于一些项目，特别是由外部供应商交付的正式合同项目，可能有两名项目经理，一名来自业务部门（客户），另一名来自解决方案/技术部门（供应商）。通常情况下，项目经理的职责贯穿在整个项目期间。
职责
业务分析师既积极支持项目级别的角色，又与解决方案开发团队全面地协作，促进业务和技术角色之间的关系，确保每天对不断演进的解决方案做出准确和适当的决策。业务分析师确保业务需求得到正确的建模和分析，并正确反映在团队生成解决方案所需的指导文件中。
用户在开发解决方案的过程中的积极参与对DSDM项目的成功至关重要。因此，要确保业务分析师不会成为解决方案开发团队成员盒用户之间的中间人，而是支持和促进他们之间的沟通。
职责
团队负责人是解决方案开发团队的服务型领导，确保团队作为一个整体发挥作用并实现业务目标，在细节层面与团队一起规划和协调产品交付的各方面工作。需要注意的是，这是一个领导角色，而不是管理角色。理想情况下，担任该角色的人是作为领导团队度过项目特定阶段的最佳人选由团队共同选出。因此，除了他们的团队领导职责外，他们很可能还将担任另一个解决方案开发团队角色（如业务分析师、业务代表、解决方案开发人员或解决方案测试人员）。同样可行的是，基于各自关注重点不同，担任团队领导角色的人可能在不同时间盒内由不同人承担。
职责
业务代表在解决方案开发团队中是输出业务需求的关键角色，因此需要有满足角色相关的需求、权力、责任以及领域知识。
在基础构建阶段，业务代表在需求的创建和优先级方面有显著的输出。一旦需求达成一致并形成基线，业务代表将基于他们自己的知识和经验，或者借鉴业务顾问的经验，在迭代开发的日常协作过程中逐步提供需求的细节。
在项目的迭代开发阶段，业务代表是业务领域的主要决策者。因此，业务代表需要有足够的资历、授权和信誉来代表业务做出决策，以确保不断演进的解决方案符合业务目标。
通常，业务代表的角色是那些已经很忙的人。因此，他们必须能够在整个开发过程中确定投入适当的时间精力，帮助引导不断演进的解决方案为了满足业务需求朝着正确的方向前进。有些项目认为任命一个全职的业务代表是确保交付时间的唯一途径。然而，这实际上会带来一种风险，即该业务代表可能会不知道业务工作中发生的事件。对于大多数项目，在构建基础阶段按照商定的时间需求任命一名兼职业务代表。但同样重要的是，业务代表需要履行对项目承诺的时间，因此他们部分本职工作可以委托给同事，这样他们的所有工作（日常业务工作和DSDM项目）都可以在正常完成。上述的业务代表的承诺时间需要基于可行的层面公开进行讨论并最终确定。
职责
解决方案开发者与其他解决方案开发团队角色合作，诠释业务需求，并将其转化为满足功能和非功能需求的解决方案增量。担任解决方案开发者的人需要得到技术协架构师的适当授权，以便在其专业领域做出日常决策。理想情况下，他们应该被全职分配到他们正在进行的项目中。如果他们不是全职的，项目工作也应该是他们的首要任务。如果无法实现这一点，则会在引入重大风险，该风险需要由项目经理主动管理。
职责
解决方案测试者是一个被授权的解决方案开发团队角色，全程紧密与团队协作并根据商定的策略在整个项目中执行测试。
职责
业务顾问通常是业务代表的同行，被要求为解决方案开发或解决方案测试提供具体的、专业的意见，即业务主题专家。
业务顾问通常是解决方案的预期用户或受益人，也可能是焦点小组的代表。然而，他们也可能只是提供解决方案必须遵守的法律或监管建议。
职责
基于业务顾问所从事的专业：
技术顾问通常从负责运营变更管理、运营支持、解决方案持续维护等方面的角度，通过向项目提供具体且通常是专业的技术输入来支持团队。
职责
技术顾问在下述场景中为团队提供支持
负责管理工作坊流程，是准备和沟通的促成者。引导师负责组织和引导工作坊，使参与者能够实现工作坊的活动目标，其本身应不直接参与预期成果的输出。
职责
DSDM教练
在团队DSDM经验有限的情况下，DSDM教练的作用是帮助团队成员在其所工作的组织背景和约束下最大限度地利用该方法的关键。理想情况下，DSDM教练应被认证为DSDM教练，以确保他们履行这一职责的能力得到验证。
与在任何情况下工作的任何方法一样，这种方法不能盲目遵循。如果项目环境中有什么东西会阻碍特定DSDM技术的有效性，那么解决潜在问题至关重要。通常，有两种方法可以解决这样的问题：第一种是影响环境，使技术有效；二是调整或替代技术。无论哪种方式，作为DSDM专家的教练角色都将有足够的知识和经验以提供帮助。
职责
DSDM敏捷项目框架描述了项目进行过程中要考虑的一组制品。这些制品描述了解决方案本身（项目的主要可交付物），以及为帮助其发展过程而创建的、帮助项目治理和控制所需的任何内容。并非每个项目都需要所有制品，因项目和组织而异，其的形式受到合同关系、公司标准和治理需求等因素的影响。
DSDM确定了两种不同类型的制品：
演进式制品会随着时间的推移而变化。它们通常（但并不总是）跨越多个项目阶段，并且在这段时间内可能会被基线化不止一次。
里程碑制品是在一个阶段创建的，通常在该阶段为实现特定目的作为检查点或促进治理过程而产生。
制品及其在项目生命周期中的功能如上图所示。橙色制品以商业为中心，绿色制品都有助于项目创建的解决方案，蓝色制品涵盖项目管理/控制所关注的内容。其中一些特殊标记的制品也可能在审批关卡等治理流程中发挥作用，并可用于证明解决方案在需要时符合公司和监管标准。
商业案例是一个演进式的制品，它从业务角度为项目提供了愿景和初衷。商业案例的基线通常在可行性研究结束时首先作为大纲创建，然后在基础构建阶段结束时作为批准开发的基础。在每个项目增量结束时对其进行正式评审，以确定进一步工作是否合理。
创建者：
由资深业务和技术协作，基于其业务分析技能、制作业务案例的经验创建。
目标：
为推动项目治理机构批准项目，并帮助在投资组合中优先级排序创建，同时整个参与到项目团队中的人也需要知道需求是什么以及其背景原因。
审批人：
业务投资人
有序的需求清单（PRL）是一个演进式的产物。它在高层次描述了项目需要解决的需求，并指出了它们在满足项目目标和业务需求方面的优先级。从可行性分析阶段开始考虑要求，PRL的基线在基础构建阶段结束时划定了项目的范围。此后随着细节的涌现，深化产品所需的更进一步的变化自然发生。但需要对范围的变更（添加、删除或显著调整高层级的需求）进行正式控制，以确保与项目的业务愿景保持一致，并保持对范围的控制。
创建者：
由具有发掘和定义需求的技能和经验的业务分析师制作
目标：
为整个项目团队制作，每个相关人员都需要了解需求
审批人：
业务负责人
解决方案架构是一个演进式的制品。它为解决方案提供了一个顶层设计框架。它旨在涵盖解决方案的业务和技术领域，以达到使解决方案的范围清晰但不限制迭代开发的详细程度。
创建者：
由负责业务流程和组织变革总体设计的业务分析师制作
技术架构师负责解决方案的整体设计和技术方面的完整性
目的：
为解决方案开发团队在所述框架内构建解决方案而制作，
审批人：
业务负责人、项目经理
开发方法的定义是一个演进式制品。它提供了将应用于解决方案进化开发的工具、技术、习惯、实践和标准的顶层定义。重要的是，它描述了如何确保解决方案的质量。因此，测试和审查策略是开发方法的关键部分，并在开发方法定义中进行了描述
创建者：
由技术架构师制作，负责定义技术标准并确保应用开发最佳实践。
目的：
为负责以专业的方式构建解决方案并达到所需的技术质量水平的解决方案开发团队制作。
审批人：
项目经理
交付计划是一个演进式制品。它提供了交付项目增量的顶层时间计划，基本不会任务级别的详细信息，除非有些任务由非解决方案开发团队成员处理，或者在解决方案开发小组成立之前就处理的事情。
创建者：
由项目经理制作，确保负责确保解决方案的增量在商定的预算和时间限制内可预测地交付。
目标：
为所有项目参与者和利益相关者制作，每个需要在高维度上了解何事、何时以及参与者等信息。
审批人：
经业务负责人、技术架构师批准，确保业务价值的增量交付对整个业务是最佳的。
管理方法定义是一个演进式制品。它反映了整个项目的管理方法，并从管理的角度考虑了项目将如何组织和规划、利益相关者将如何参与项目，以及如何展示和报告进展（如有必要）。该制品在可行性分析阶段进行了概述，并在基础构建阶段结束时形成了基线。
创建者：
由项目经理制作，负责确保项目正确设置，以便可预测地交付项目产品。
目的：
为所有项目参与者和利益相关者制作，每一个需要从高层次了解如何管理项目的人。
审批人：
经业务投资人批准需要确信项目设置正确，能够在正确的时间以正确的成本交付所需的产品。
可行性评估报告是一个里程碑制品。它提供了上述不断演进的业务、解决方案和管理制品在可行性阶段结束时的快照。每种制品都应该足够成熟，能够对项目是否可行的决策做出合理的贡献。可行性评估可以表示为上述制品的基线集合，也可以表示为涵盖每个基线关键信息的执行摘要。
创建者：
由负责项目管理和控制的项目经理制作
目的：
为项目管理层制作，帮助决定项目是否应按提案执行
审批人：
由业务投资人批准
项目基础摘要是一个里程碑制品。它提供了上述不断演进的业务、解决方案和管理产品的快照，因为它们在基础构建阶段结束时已经存在。每种制品都应该足够成熟，能够对项目是否有可能实现所需的投资回报做出合理的贡献。项目基础摘要可以表示为上述制品的基线集合，也可以表示为涵盖每种制品关键信息的执行摘要。
创建者：
由负责项目管理和控制的项目经理制作
目标：
为项目管理层制作，帮助决定项目是否应按提案进行
审批人：
由业务投资人批准
演进式解决方案是演进式制品。它由组成最终解决方案的所有内容，以及探索需求细节和正在构建的解决方案所需的任何中间产物组成。在任何给定的时间，这些部分可能是完整的、部分解决方案的基线（解决方案增量）或正在进行的工作。基于价值交付的需要，这些内容可以包括：模型、原型、支持性材料以及测试、在制品评审等。
在每个迭代交付结束时，解决方案增量将部署到实际使用中，并成为已部署的解决方案。
创建者：
由解决方案开发团队制作，负责创建满足PRL要求的解决方案
目标：
为负责投资回报的业务投资人、参与解决方案的用户。
审批人：
由业务负责人批准负责确保交付的解决方案符合业务目标，技术架构师负责确保交付的解决方案符合技术目标。
时间盒计划是一种演进式制品，其详细阐述了时间盒的目标，并详细说明了该时间盒的可交付成果、产生这些可交付成果的活动，和开展工作的资源。时间盒计划由解决方案开发团队创建，通常体现在团队板的待办、正在进行和已完成的工作列中，并且至少每天在站会中更新一次。
创建者：
由解决方案开发团队制作，体现自组织团队即将要做什么
目的：
为解决方案开发团队制作
审批人：
由项目经理批准，技术经理需要共同负责确认团队适当专注于及时交付合理的解决方案增量。
时间盒评审记录是一个演进式制品，汇集了时间框盒每次评审的反馈。它描述了到目前为止所取得的成就，以及可能影响未来计划的任何反馈。
创建者：
由团队负责人制作，负责确保迭代开发过程得到适当的关注和控制，并确保所有测试和评审活动都得到适当的执行。
目的：
为项目管理层，以确保开发过程得到适当控制，所有测试和评审活动都得到适当执行。帮助项目经理正式跟踪交付最终解决方案的进度。
审批人：
业务负责人批准确认不断演进的解决方案增量继续符合业务目标，技术架构师批准确认不断演进的解决方案增量仍然符合技术目标。
《项目评审报告》是一个里程碑制品。它通常是一个单独的文档，在每个项目增量结束时，通过添加与该增量相关的新章节同步进行增量地更新。
在每个项目增量结束时，该产品的用途是：
创建者：
由项目经理制作，全面负责项目及其产品的交付
目的：
为所有项目参与者和利益相关者以及负责支持未来项目的人（如PMO）制作，他们有兴趣了解已经取得的成就、已经交付的价值，为后续项目积累经验。
审批人：
业务负责人，以确保解决方案符合业务目标；
技术架构师，确保解决方案在技术上符合目的
团队负责人，确保迭代开发过程得到适当的关注和控制，并确保所有测试和评审活动都得到适当的执行。
收益评估是一个里程碑制品。它描述了在实际运营一段时间后，收益累积的实际情况。对于商业案例中的收益预计是长期累积的项目，可能会根据用于证明投资合理性的时间盒定期进行收益评估。
创建者：
业务负责人、业务分析师负责确保根据业务关怀和业务需求评估收益
目的：
为项目管理层制作，帮助其了解项目投资是否合理，并了解预测值和应计值之间的差异
审批人
由负责投资回报的业务投资人批准
时间盒是DSDM的关键实践之一。DSDM将时间框定义为一段被锁定的、在结束时交付商定目标的时间。时间盒的目标通常是完成一个或多个可交付成果。其的重点是交付完整而有意义的成果，而不是体现团队很忙。结束时，进度和成功是通过产品的完成（需求或其他可交付成果）来衡量的，而不是完成一系列任务。
时间盒的最佳长度通常在两到四周之间。在一个非常短且快速进行的项目中，可能短至一天。在特殊情况下可能长达六周，但缺点是团队可能会失去专注力。通过一系列小规模的时间盒交付产品，团队能够更频繁地评估他们的真实进度，即“我们实现了什么？”。如果他们的进度没有达到他们自己的期望，就给团队提供了预警，在早期就为解决问题提供了机会。
时间盒以迭代的方式支持产品的创建，包含了频繁的检查点，以确保这些产品的质量和迭代开发过程的效率。通过应用MoSCoW方法对时间盒的交付内容进行初步的优先级排序，并持续地对商定的时间范围内可实现的目标进行再评估，以确保每次都能按时完成并提供一个符合业务预期的解决方案来实现业务目标。
项目增量和整个项目也可以被视为时间盒，因为它们具有在预定时间内提供适合用途的解决方案的共同特征。这些较高层级的时间框的管理是通过控制较低层级时间框来实现的。除非被项目或项目增量限定，否则“时间盒”一词将始终指代迭代开发过程中的时间盒。
DSDM定义了两种类型的时间盒：
时间盒类型的选择可能受到业务代表和其他业务角色的参与程度或正在开发的产品类型等因素影响。
这是最初的DSDM时间盒，它为时间盒提供了一个标准的、可复用的内部结构。
时间盒内的结构非常有用，可以提前帮助业务代表在繁忙的日历中规划需要参加团队具体的计划、反馈和评审会议的时间。除了这些具体的计划会议外，日常还需要业务的参与，例如参加每日站会和及时回答紧急问题。通过将此结构映射到未来的时间盒，可以为项目增量中的所有时间盒安排各种控制点（启动、评审、结束等）。
DSDM结构的时间盒提供了一个框架计划，重点关注时间盒内的迭代开发活动，以确保聚焦于实现准确的业务解决方案。有了这种结构，解决方案开发团队就知道他们应该在什么时候完成初步调研、什么时候收尾、什么时候准备好产品，最后几天的重点是最后的调整和微调，以确保时间框利落地关闭。整个解决方案开发团队随时可以看到进度，并在总体目标面临风险时发出预警。
DSDM结构的时间盒包括三个主要步骤：
每一个步骤都以评审回顾结束。
|
时间盒 |
要完成的工作内容 |
时间建议 |
|
启动 |
帮助解决方案开发团队理解以及切实接受时间盒目标的小型活动 |
针对2～3周的时间盒需1～3小时 |
|
调研 |
调研的范围包括确认所有在时间盒内需要交付的产品以及其细节，包括以下共识： undefined 时间盒目标交付物 undefined 交付物的验收条件 调研工作在评审通过后结束，为精化活动提供信息，可能是一个有价值的治理触点。 |
约占时间盒总的10～20% |
|
精化 |
针对时间盒的目标交付物按照优先级开展开发、需求澄清以及测试（技术测试和业务测试）。 精化活动在评审通过后结束，为集成工作提供信息，可能是一个有价值的治理触点。
|
约占时间盒总时间的80% |
|
集成 |
将迭代开发过程中任何分散的工作成果结合在一起，确保所有的产品符合早期商定的验收条件。 集成工作在评审通过后结束，为收尾工作提供信息，可能是一个有价值的治理触点。 |
约占时间盒总时间的10～20% |
|
收尾 |
业务负责人和技术架构师对于时间盒交付物正式验收环节，结束后会有简短的回顾活动以从时间盒的过程中学习并且为后续的时间盒制定改进行动。 |
对于一个2～3周的时间盒约1～3小时。 |
时间盒启动的目的是：
解决方案开发团队的所有成员（包括业务代表）以及项目经理、技术架构师和业务负责人都应参加启动仪式，他们将在时间盒内共同协作。
调研的目的是为精化期间要进行的工作提供坚实的基础，并进一步澄清需求及其验收条件，验收条件为每个需求圈定了合适的范围需要被正式确认。作为解决方案演进过程的重要环节，需要解决方案开发团队共同调研需求的细节，并就如何满足这些需求达成一致。只要条件允许，就应该基于解决方案创建初始模型或原型，通过将解决方案可视化来支持早期的评估和反馈。
整个团队需要共同围绕在启动阶段所确定的需求和目标开展协作，明确它们的细节和优先级，必要情况下可以基于实际情况将优先级较低的需求移出时间盒。业务代表和业务分析师以及解决方案开发团队共同规划时间盒的测试计划，基于澄清的验收标准计划此时间框的测试。
输出物：
依赖：
团队明确在时间盒内各个需求的依赖关系以及与其他解决方案交付团队的依赖关系，并明确管理计划。
时间表计划：
团队检查仍有待完成的工作，就团队中哪些成员将从事哪些工作达成一致。这样可以确保每个人的工作负载，确保计划的可行性。
风险：
根据从调研过程中获得的信息，以及从交付计划和风险日志中为该时间盒识别的风险，解决方案开发团队分析与该时间框相关的风险。
邀请法务、合规、业务或技术顾问参与正式、有文件记录的成果评审可以作为对不断演进的解决方案的一种可证明的管控方式，并提供有价值的审计线索。
精化的目的是完成尽可能多的开发工作，包括完成产品的测试。开发和测试是迭代进行的，交付的成果满足当下的业务需求同时也要满足商定的详细验收条件细节（由调研阶段结束时产生的最新版本）。交付的顺序以MoSCoW产出的的优先级为主，但也会受到其他因素的影响，例如：
最终，时间盒内所包含的内容被业务代表以及其他利益相关者评审，其确定了在时间盒结束前根据验收条件完全完成了工作所需的措施，在此之后，时间盒内不应再开始任何新的工作，同时在这个阶段所获得的反馈都应给予足够的重视。需要注意的是，如果业务在时间盒早期阶段参与不足，此时就可能发生重大的需求变更，这是历史的教训。
评审通常涉及在时间盒内开发的产品的演示。这个阶段的评审结果也作为时间盒的评审记录，还可以有效地作为法务及合规的依据。
在集成过程中会落实精化评审中商定的行动、最终测试和满足组织或项目标准所需的任何工作（包括诸如同行评审、代码环境迁移等）。任何最终质量控制检查都由解决方案开发团队执行，以确保所有产品或需求/用户故事都能满足业务需要，并达到可接受的质量标准。集成以检查时间盒目标是否达成为结束。任何未达到约定的验收条件的产品都视为未交付，将仍被保留在有序的需求清单中。
由质量顾问在此期间正式签字，确认解决方案符合法务及合规要求。
收尾的主要目的有三个：
如果要满足总体时间表，重要的是要避免未完成的工作自动进入下一个时间框，而不考虑总体优先级。
当时间盒比较成功或者团队已经比较成熟，回顾活动可能会很短。如果在时间盒过程中出现了问题，或者这是新团队的第一次回顾活动，就可能需要额外的时间。
无论采用哪一种方式，每日站会都是时间盒的关键组成部分。这是解决方案开发团队在整个团队中共享信息的机会，并在出现问题时进行任何必要的日常重新规划和重组。然而，需要强调的是，团队沟通不仅仅是发生在每日站会，所有团队成员在一天中都会根据需要进行持续的非正式沟通。
解决方案开发团队每天都会聚在一起进行一次站立会议。通常每天在同一时间和同一地点进行，这部分信息在时间盒计划中需要加以体现，以便非解决方案开发团队成员的其他人可以按需参与。通常由团队负责人组织引导，是每个人每天都有机会详细了解目标进展情况，并揭露可能阻碍实现目标的问题和障碍。
参与者：
过程：
持续时间通常不超过15分钟
以下人员可以按需参加站会：
业务负责人——为了与进度保持联系，提供持续可见的支持
项目经理——为了观察进展并发现升级的问题
技术架构师——以便及时了解技术决策并解决升级的技术问题
需要注意的是，站会用于识别问题，并就谁需要参与解决出现的任何问题达成一致。但如果达成解决方案需要超过一两分钟的时间，就不应在此时试图解决这些问题。把问题记录下来，并且问题相关人员站会后可以继续讨论。
迭代开发使团队能够在时间框结束时交付真正适合其预期目的的产品。在业务代表的领导下，在业务分析师的支持下，根据业务部门的评审，通过不断改进产品，实现符合业务目标的解决方案。至关重要的是，在任何给定的时间，关于解决方案是否正确，或者是否需要改变以使其正确的决定，都要迅速且明确。否则就有可能损失（等待决策）或浪费（决策被推翻）大量时间。重要的是，解决方案开发团队的所有成员都有适当的授权来处理时间盒目标商定范围内的任何变更，而不需要超出团队范围的正式变更控制流程。
根据经验，以下场景总是意味着范围的变化，因此需要更正式的管理（在解决方案开发团队授权之外）：
然而，围绕解决方案细节（深度）的谈判通常可以由授权的解决方案开发团队处理，而无需任何升级或解决方案开发小组以外的人员的正式批准
无论变更是否被视为影响范围，解决方案开发团队通常都有权在商定的范围内运作，而无需升级到项目经理或其他项目级别的角色。
例如：
按照MoSCoW的做法，从时间盒（甚至从项目增量或项目）中删除可能包含的需求通常是在事件发生后报告的，而不是需要许可。
但是，对时间盒内容的所有变更都必须得到整个解决方案开发团队的同意和接受，授权的界限应在基础构建阶段结束时确定，并定期（至少在每个时间盒结束时）评审其有效性。
引用
https://en.wikipedia.org/wiki/Dynamic_systems_development_method
New Directions on Agile Methods: A Comparative Analysis
Pekka Abrahamssona , Juhani Warstab , Mikko T. Siponenb and Jussi Ronkainena a Technical Research Centre of Finland, VTT Electronics
