AgilePM 入门学习

Contents – Agile Foundation Version
source: SKEMA, Paris
Session 1: Introduction
Session 2: Roles and Responsibilities
Session 3: The DSDM Process and Products
Session 4: Techniques
Session 5: Planning and Control

Session 1: Introduction

Welcome to this introductory training course in Agile Project Management, the certified approach to running projects in an agile way, which has been developed jointly by APMG International and the DSDM Consortium.

This course is based on the Agile Project Framework which is the latest release of DSDM

Once you have completed this course you will have an appreciation of Agile Project Management or Agile PM, understand the principles of the DSDM and know how those principles apply to the management of projects.

You will also understand the essential differences in management style between projects run using DSDM and those run on traditional lines.

The course aims to provide you with sufficient knowledge to successfully take the
APMG’s Foundation examination in Agile Project Management and thereby become qualified at that level.

If you have any other questions about the exam, please feel free to email or call us directly. When you have completed this first Session of the course you will:
Know the background and history of the Agile movement and be able to identify the key organisations involved.

Be familiar with the Agile Manifesto

• Describe the benefits of using DSDM
• Describe the principles of DSDM and
• Describe the instrumental Success Factors.

敏捷历史

要了解敏捷PM的完整历史和背景，您必须一直追溯到20世纪90年代初。那时，大多数软件开发项目都遵循所谓的瀑布方法。这是一种线性或顺序的开发方法，项目分为几个不同的阶段，例如，启动，分析，设计，编码，测试和维护。

这个想法是项目将从一个阶段流向另一个阶段 ： 有点像一个阶段瀑布，每个阶段必须完成并在下一阶段开始之前签字。当时存在的许多系统开发和项目管理方法都是基于这种方法，并且本质上往往具有规范性和官僚性。

这种做事方式还有另一个问题。在后期阶段出现的问题，错误甚至是好的想法变得非常难以克服或纳入，因为这将需要重新开放已经关闭的早期阶段。它不允许项目的客户可能不完全知道他们想要什么，直到他们看到一些早期原型出现在实施阶段。

到90年代初，技术正在以更快的速度发展，企业通常都在寻找能够在几天内交付几个星期的软件解决方案，而不是IT部门习惯采用的传统月份和年份。

第一次尝试解决这些问题并加快开发过程采用的是：快速应用程序开发方法（RAD）。

RAD的方法是尽量减少前期规划和设计，以便快速进行原型设计，并使用迭代周期来开发和优化解决方案，以尽快满足业务需求。RAD在市场上获得了动力，许多供应商发布了所谓的RAD产品和顾问，他们提出了自己对RAD概念的解释。但是，没有行业标准可以准确定义RAD框架的外观。为了满足这种标准化需求，动态系统开发方法（DSDM）由英国的软件开发人员引入，他们组建了一个非营利组织，旨在开发和推广一个名为DSDM Consortium的独立RAD框架。

DSDM成为众多所谓的“轻量级”方法和技术中最重要的一种，这种方法和技术是在RAD运动之后出现的。他们采取了这个名字，以区别于与瀑布方法相关的“重量级”方法，如SSADM。

敏捷宣言

2001年，一组来自XP，SCRUM，DSDM和其他几个代表
犹他州的一个滑雪胜地遇到了“轻量级”的方法，目的是找到共同点，并试图就他们的活动达成一致。
他们认可第一件事：他们不喜欢被称为“轻量级” ，而 “敏捷”听起来好多了。因此，会议的结果是一份名为“敏捷软件开发宣言”的文件，现在通常被称为“敏捷宣言”。

为了促进敏捷宣言并鼓励敏捷软件开发方法的传播，他们组建了敏捷联盟，这是一个致力于推动全球敏捷原则和实践的非营利组织。

敏捷宣言实际上是对价值观的一种陈述，总的来说：
个人和互动比流程和工具更重要；
工作软件比综合文档更可取；
客户协作优于合同谈判；
而且，响应变化比遵循计划更有价值。

注：这并不是说右边的项目没有价值 - 只是在敏捷中，左边的项目优先。

DSDM Atern

The DSDM Consortium continued to develop and improve the method over the years with the latest version being released in 2007 and called DSDM Atern.

The word Atern is derived from the bird the Arctic Tern which is an agile, long-distance flyer and was felt to share many characteristics with DSDM.

In 2010 the DSDM Consortium decided to extract the exclusively project management related parts of the DSDM Atern method and launched Agile Project Management or AgilePM to give it its trade name.

They worked in collaboration with APMG International to produce the Agile Project Management Handbook and it is APMG who accredit training organisations and supervise the examination and certification processes.

Since its introduction in 2010 DSDM Atern has evolved into Agile PF or the Agile Project Framework.

It retains DSDM’s project focussed principles and at the delivery level the DSDM process has been simplified to reflect current trends in evolutionary solutions development.

DSDM

DSDM背后的理念是基于务实的现实，在大多数情况下，任何项目的80％的商业利益都可以相对容易和快速地实现。实现剩余的20％通常会花费不成比例的更长时间和更高的成本。

因此，重点是确保尽早交付最重要的商业利益。如果提供100％的解决方案将涉及延长项目的时间范围，那么不太重要的功能将被丢弃，以便业务可以毫不拖延地获得真正重要的好处。在这方面，DSDM将传统的项目管理观点放在首位。传统的项目管理首先要定义要交付的功能，这些功能的质量要求，然后是提供这些功能的估计成本和时间尺度。

随着项目的进展，功能和质量要求通常被视为固定，但项目的成本和时间尺度将被视为变量或可协商的，具体取决于项目的进展情况或程度。DSDM采用完全相反的方法，并且在项目的早期阶段和成本以及所需的质量标准上同意时间表和成本。优先考虑要求或特征，并确认这些要求或特征的最小可用子集。如果在项目期间出现问题，那么时间和成本要素将保持固定，并且将删除较不重要的特征，以便可以实现原始期限。

按时交付工作但不到100％的解决方案被认为比延迟交付所有东西更可取。

DSDM Principles - Focus On The Business Need

这一理念的一个基本要求是关键利益相关者对其所包含的现实的“认同”。

他们必须了解业务目标和优先事项，接受这种变化是不可避免的，并且愿意接受“适合目的”的解决方案，因为“铃声和口哨”证明太耗时或昂贵。因此，这一理念得到了一系列8项基本原则的支持，这些原则需要应用于项目以实现最大利益。

原则1强调需要关注业务需求。
根据这一原则，项目期间采取的每项决策都必须与总体项目目标相一致，即在最短的时间内为企业带来最大利益。这一原则要求所有团队充分了解真正的业务优先级，为他们正在进行的工作建立合理的业务案例，寻求持续的业务赞助和承诺，并保证已达成一致的最小可用功能子集。

后面，我们将研究具体的业务角色和产品使DSDM能够实现这一原则，以及支持Timeboxing和MoSCoW优先级等技术。

DSDM Principles - Deliver On Time

第二个原则：按时交付。
时间，换句话说，截止日期，在Atern被视为不可谈判。 准时交货通常是最重要的成功因素，延迟交货可能会破坏项目的基本原理。同样，Timeboxing和MoSCoW优先排序可以帮助DSDM团队建立产品交付的及时性和可靠性的声誉。

DSDM Principles – Collaborate

第三个原则是协作。

要让团队取得进步，所有成员必须朝着同一方向努力。 并且为了整个项目取得成功，其中的所有团队必须协调一致并朝着共同目标前进。以积极的相互合作精神工作的团队将比松散关联或不协调的团队更快地产生更好的结果。

该原则要求团队：在适当的时间，在整个项目中让合适的利益相关者参与进来; 确保团队成员有权做出决定; 积极参与业务代表，并在整个项目组织中建立一个团队文化。

为了支持这个原则。 DSDM提供各种业务角色和Facilitated Workshops技术，我们将在后期探讨。

DSDM Principles - Never Compromise Quality

DSDM的第四个原则是：绝不妥协质量。

虽然功能被视为可能的变量，但质量当然不是。所需的质量水平应在项目开始时达成一致，所有工作都应针对达到这一水平：不多也不少。

为了满足这一原则，团队需要通过不断的审查来适当地设计，记录和测试并建立质量。早期和持续的测试将确保不断发展的解决方案的质量，并避免在后期阶段发生令人讨厌的意外如果企业同意最小可用子规则中的特征或必须满足商定的验收标准，那么解决方案应该足够有效地使用。

DSDM通过提供各种业务和技术测试产品以及整个生命周期中的定期审核来支持此原则。

DSDM Principles - Build Incrementally From Firm Foundations

原则5说团队应该：从企业基础逐步建立。

DSDM通过倡导满足敏捷对早期商业利益的要求增量交付产品。 换句话说，让基本产品工作尽可能快地向相关的利益相关者展示，并根据他们的反馈，改进和改进产品，直到满足业务需求。

这种工作方式有时被称为 Enough Design Up Front，而不是传统方法的 Big Design Up Front 或大多数其他方面的 No Design Up Front 敏捷方法。

为了满足这一原则，团队将争取早日实现商业利益，尽可能不断确认和纠正正在构建的解决方案，并正式重新评估优先级以及项目的持续可行性以及每个交付的增量。

DSDM Principles - Deliver Iteratively

第六个原则实际上是第五个原则的延伸，并说“迭代地交付”。

被描述为“增量和迭代”方法，这个特殊的原则反映了这样的现实，即很少有东西，软件或其他东西在第一次完美地构建。 该方法依赖于迭代来接受变化并产生更好的解决方案。

这个原则要求团队：做好前面的设计，建立坚实的基础; 采用迭代的方法来构建产品; 在每次迭代中建立客户反馈; 接受细节将在以后出现，而不是越早; 将变革视为获得正确解决方案和创造，学习和发展的必要部分。

迭代和不断审查是DSDM确保找到最合适的解决方案的方法。 DSDM项目中唯一无法改变的是时间和成本。

DSDM Principles - Communicate continuously and clearly

原则7：持续清晰地沟通。

沟通不畅是项目失败的常见原因。 DSDM提供专门用于改善团队之间，团队之间以及项目与外部世界之间通信的技术。

团队满足这一原则方法：每天举办一次会议; 从SCRUM技术中采用的一种管理团队的想法; 使用便利的讲习班; 采用丰富的技术，如建模和原型设计; 保持文档精益和及时; 在整个项目中管理利益相关者的期望，并鼓励各级的非正式，面对面的沟通。

DSDM强调人工交互和建模的价值，以实现最终解决方案的早期可见性。 这种技术比大量文本更有效。

DSDM Principles - Demonstrate Control

最后，第八个也是最后一个原则是演示控制。

项目必须始终处于控制之中，如果您是项目经理或团队负责人，那么控制权是不够的。 你必须能够证明你在掌控之中。

为了实现这一原则，团队成员必须; 使用适当的正式程序进行跟踪和报告; 制定计划并取消所有人都能看到的计划; 衡量交付产品而非完成活动的进展情况; 根据业务目标主动管理并评估持续的项目可行性。

关键控制技术是Timeboxing和各种产品，如管理基础和时间箱计划。

因此，我们有DSDM和AgilePM所基于的全部八个原则。 任何一项原则的不遵守或破坏都应被视为敏捷过程的风险，并最终成为项目的成功

注：成功因素
•采用DSDM方法，这意味着所有利益相关方都应该了解DSDM拥有这样一种理念：“当项目符合明确的业务目标，经常交付并参与有动力和有能力的人员的协作时，就会出现”最佳商业价值“。利益相关者还应该了解DSDM处理动态变化，项目可能无法提供10％的可能解决方案。
•有效的解决方案交付团队需要基于四个要素：
o授权，以便团队可以根据他们的专业知识做出决策
o在项目期间，团队成员保持稳定，这有助于沟通，建立团队精神和合作
o技能，这意味着让合适的人员担任正确的角色
o规模，DSDM建议最佳团队规模为7人，加上或减去两人。

•商业参与 - 积极和持续。这个因素依赖于业务在三个方面的参与：
o承诺时间和参与项目
o积极参与业务角色和
o支持性的商业关系
•通过使用Timebox的迭代开发，集成测试和增量交付是DSDM成功的关键，这些应该是这样的，即每个Timebox都可以提供可扩展的解决方案。
•透明度，确保所有人都能看到进度和正在进行的工作。团队委员会和每日立场是提供有关当前状态的清晰和最新信息的有用方式。
•项目方法问卷 - 评估选项和风险。我们将在课程后面详细考虑这一点，但它确实提供了一个简单的清单，用于评估是否可能满足上述因素，或者是否需要采取行动来鼓励这些因素或减轻它们被破坏的风险。

Summary
In this first Session we have looked at the history AgilePM and how it has emerged from the Agile products and initiatives of the 1990s, in particular the DSDM methodology for running IT software development projects.
We have seen how the DSDM Consortium produced AgilePM and how there have collaborated with APMG International to produce the handbook and qualification standards.

We have looked at the role of the Agile Alliance and their Agile Manifesto.
DSDM uses Agile principles as the basis for its own philosophy which is focussed on delivering the greatest business benefit in the shortest possible time. Underpinning this philosophy are the eight principles. The whole structure is then supported by a Process, a set of Roles and Responsibilities (or people), defined Products and a range of Practices).

Subsequent sessions will examine each of these supporting pillars in greater detail.

Session 2: Roles and Responsibilities

Objectives
In the first session we saw how Agile stresses the importance of people interacting and collaborating to the successful delivery of projects.

In this session we will be examining the various team roles.

When you have completed the session you will be able to name 13 distinct DSDM roles and describe the principal responsibilities of each.

You will also be able to categorise each of the roles into the Business, Solution or Technical, Management and Process interests with which they are associated.

DSDM团队模型
我们在第一次会议上看到的DSDM结构模型将People作为其主要支柱之一。

参与项目的人员需要以这样的方式进行组织，即所有基本职责都已定义并广泛理解所有权。为了实现这一目标，DSDM提出了一个通用的团队模型，看起来像这样。

此模型包含大多数项目通常需要的大多数角色。它不被认为是详尽无遗的 - 一些项目可能需要额外的专家角色。每个项目都没有强制执行所有角色。重要的是，项目的所有重要职责必须由某人拥有。

该模型显示了各种角色如何组合在一起，并且还给出了不同角色之间通信方式的一些指示。在解决方案开发团队内部，沟通将主要是非正式的，尽可能多的面对面互动。而在项目层面，沟通将更加正式，更多的书面确认协议和承诺正在进行。

关于这个图的另一个重点是它显示了角色和责任，而不是人。角色和人之间的关系可以定义为多对多关系。
换句话说，一个人可以承担这里显示的不止一个角色，并且几个角色实际上可以由一个人执行。对此的主要例外是业务赞助商，企业愿景和项目经理角色最好由一个人满意。

项目级角色是项目工作的主管，经理和协调员。这些角色通常由坐在或直接向项目委员会或指导委员会报告的人员填补。

解决方案开发角色，包括团队负责人组成项目的研讨会，因为他们塑造和构建解决方案，并共同负责确保其适用性。

在较大的项目中，可能有多个解决方案开发团队，每个团队的成员资格都是稳定的，涵盖了为开发角色定义的所有职责。

支持角色在整个生命周期中更加临时地为项目提供服务，帮助和指导。正如我们所说，这里可能需要其他专家角色，这取决于项目的需求。

接下来，我们将更详细地研究每个角色。

DSDM角色 - 商业赞助商
就项目而言，“树顶”或最高级的商业角色是商业赞助。这个角色几乎总是由一个人担任，他将充当项目的支持者，完全致力于项目，提议的解决方案和提供它的方法。

所涉及的人员必须在组织中具有足够高的地位，以便能够解决业务问题，做出财务决策并打开可能对较初级项目员工关闭的大门。

业务发起人的工作是从始至终拥有业务案例，一旦交付后拥有解决方案并负责实现预期收益。商业赞助商的才能及其在角色中的有效性可能会比其他任何因素对项目结果产生更大的影响。 至关重要的是，一旦商业赞助商被任命，他们应该在项目期间可用并且可见。

DSDM角色 - 商业梦想家

Business Visionary是一个高级项目级业务角色，比业务发起人更积极地参与日常工作。商业梦想家的职能之一是解释和传达商业赞助商的需求。

该角色为项目提供了“全局”视角，并在更广泛的组织内定义了项目的背景。如果项目是作为更大项目计划的一部分进行的，那么有远见者能够根据更广泛的公司影响来判断项目问题。建议将此角色分配给需要在整个项目期间参与的单个人。他们的主要重点是提供战略方向，并确保交付的解决方案能够实现业务案例中描述的好处。

DSDM角色 - 项目经理

项目经理角色是项目组织的核心，位于高级业务角色和解决方案开发团队之间，提供了两者之间的接口。

这是一个要求很高的角色，需要有良好的沟通能力，具备规划，管理和组织能力。对团队正在进行的技术工作的基本了解也是一项要求。

项目经理负责提供解决方案的各个方面，为项目团队或团队提供高层次的指导。该职位的重点是交付和管理解决方案不断发展的工作环境。

根据授权的概念，项目经理完成的规划工作应该是高级别的。实际交付产品和日常决策的详细规划应留给团队领导和解决方案开发团队的成员。项目经理通常在从基础到部署的整个过程中负责项目。

DSDM角色 - 技术协调员

技术协调员是该项目的技术设计权威。将此角色视为业务愿景的技术等同物是有用的，确保交付的解决方案合理，有凝聚力并符合所需的质量和技术标准。

确保整个解决方案开发团队的一致性和一致性，并充当“粘合剂”，在技术和创新方面将项目结合在一起，这是此角色的一部分。

DSDM角色 - 解决方案开发团队

解决方案开发团队的成员有权制定不可避免的日常决策，这是一项重要原则。在商定的职权范围内，他们没有必要与项目经理商定每一项决定。

正如我们已经看到的，Atern项目通常会有几个解决方案开发团队通过他们的团队负责人向项目经理报告。

重要的是要意识到团队领导者不一定是职位。对于其中一个团队成员来说，这通常是兼职角色，不同的人在项目的不同阶段履行职责并不罕见。

这是一个领导而不是管理角色，理想情况下，团队领导者将被同行选为最合适的人选，以引导他们完成项目的特定阶段。

该角色的基本职责是;

• 促进专注于按时交付商定的产品
• 鼓励团队成员的充分参与
• 确保迭代开发过程得到集中和控制
• 确保所有测试都得到妥善安排和进行
• 在Timebox级别管理风险和问题，根据需要升级到项目经理，业务愿景或技术协调员
• 每天监控进度并向项目经理报告进度
• 促进每日站立
• 促进与团队的审查和回顾

The interface between the business and the solution development team is a role which Atern calls the Business Ambassador. This is a key role and is responsible for day-to-day communication between the project and the business.

People nominated for this role are usually very good, knowledgeable and busy people from the business area to be served by the project outcome. We all know people like this in the organisations we work for. They will typically be a section leader or manager who has worked in the department concerned for many years and knows the business processes of that department in very great detail.

This can lead to a problem because the business often finds it hard to spare these people from their day-to-day duties, to spend time on the project. But their involvement is crucial and spare them they must if the project is to ultimately satisfy the end-user requirements.

The role is aimed at providing business-related information from the end-users perspective and input to the many decisions that will be required regarding the solutions fitness-for-purpose. The Business Ambassador can therefore be viewed as working with the Solution Development Team to guide the evolving solution towards a satisfactory end product.

The Business Analyst role may, in smaller projects or in smaller organisations be combined with that of the Solution Developer.

In any event the Business Analyst is a fully integrated member of the solution development team and is focused on the relationship between the business and technical roles. The aim being to ensure that accurate and decisive direction is provided to the team on a day-to-day basis.

The Business Analyst is responsible for ensuring that the business needs are properly analysed and reflected in the guidance that the team needs in developing the solution.

It is important that this role does not act as a barrier between the solution development team and the business. The Business Analyst works alongside the business but is not empowered to make decisions on its behalf.

As the guardian of the Prioritised Requirements list it is the Business Analyst who ensures that significant scope creep does not occur and that only low-level details are added during the development of the solution.

The actual work of creating the required solution is carried out by the Solution Developer or Developers. So, on a technical project this would normally be somebody like an analyst/programmer.

The person or persons fulfilling this role should be allocated full-time to the project. If this is not possible then the project should certainly be their top priority. Failure to achieve this level of commitment would bring significant risks to the project, particularly with regard to timeboxing, and such risks would need to be carefully managed by the Project Manager.

Although technical skills are obviously at the forefront here, softer skills such as communication, team working and listening are also very important and should not be overlooked in the requirements for this role.

The roles of Solution Developer and Solution Tester are often merged, but in larger organisations there may be dedicated specialist testers. Their role is to ensure that the solution meets the defined quality and is tested in accordance with the Technical Testing Strategy throughout its evolution.

Although it is an important principle that the Solution Tester is a fully integrated role within the Solution Development team, it is quite common for the role to report directly to the Technical Coordinator in order to ensure a degree of independence for the testing function.

DSDM角色 - 支持角色

业务顾问是一个专家角色，可以被视为具有非常特殊知识的主题专家，这些知识可能是相关的，通常只是解决方案的一部分。一个很好的例子可能是需要特定的法律建议以确保合规，或者涉及非常特殊的财务或安全特征。

履行这一职责的人通常会成为商务大使的同行，并可能被要求为解决方案开发和/或测试流程提供专家意见。

较大的项目通常会在生命周期的不同阶段要求多个业务顾问，并且至少其中一个项目是项目产品的预期最终用户是很常见的。业务顾问的技术对应方是技术顾问，他们通过提供所需的专业技术输入来支持团队。

他们可能是数据库设计专家，IT安全专家或技术学者。

促进研讨会是一种广泛使用的技术，在整个商业世界中使用，它们是Atern的关键实践之一。这种做法需要一个中立的协调人，与研讨会的结果无关，使小组能够共同努力实现既定目标。

研讨会主持人负责管理研讨会进程，并作为筹备和沟通的催化剂。重要的是要了解协调人负责研讨会的背景，而不是内容。

如果团队的DSDM经验有限，则DSDM Coach的作用是为了帮助团队应用原则并充分利用该方法。DSDM Coach应该是经过认证的DSDM教练，具有应用DSDM和敏捷项目管理的实际和实际经验。

DSDM角色 - 其他角色

团队模型旨在涵盖敏捷项目所需的大多数通用角色。实际上，在项目生命周期的各个阶段和不同阶段，通常需要专业技能。

当解决方案开发团队需要特定的技术技能时，这些角色最常见 - 但也可能是项目级别也需要专家。

无论何时何地，只要他们参与，这些专家必须适当地融入项目团队，他们的参与需要正式规划。这将涉及识别相关个人，检查他们的可用性，正确定义他们的角色和要执行的工作，并确保他们理解敏捷方法。

Summary

In this session we have been exploring the various roles which DSDM identifies as being commonly required on Agile projects.

DSDM defines a team model and identifies roles in three categories and four interests. The roles are: Project level, Solution Development Team roles and Supporting roles.

The Business interests are represented by the Business Sponsor, the Business Visionary, the Business Ambassador, and the Business Advisor roles.

The Solution and Technical interests are represented by the Technical Coordinator, Solution Developer, Solution Tester and Technical Advisor roles.

The Management interests are represented by the Project Manager and Team Leader Roles.

The Process interests are represented by the Workshop Facilitator and the DSDM Coach roles and finally the Business Analyst covers both the business and solution or technical interests.

On a project, one role may be taken by several people and one person may take several roles.

Session 3: The DSDM Process & Products

Objectives

In this session we will be exploring the DSDM process, and the Products that are used within the DSDM framework

When you have finished the session you will:

• Understand the DSDM Process and how it is used
• Be able to describe each of the process and recognise the DSDM products associated with them.
• Appreciate how the process is scalable and can be configured to suit differing project and organisational needs.

The DSDM Process

The process has six distinct phases, these being:
Pre-Project, Feasibility, Foundation, Evolutionary Development, Deployment and Post-Project.

前三个是按顺序完成的，项目前阶段确保只启动正确的项目，并且它们将被正确设置。

可行性和基础为后续的迭代和增量开发和部署阶段设定了基本规则。

每个项目都使用该流程来推导其生命周期，重要的是要记住，流程可以配置为满足一系列项目，从具有轻量级治理要求的小型项目到具有强大治理框架的主要项目

在进化发展阶段，解决方案将通过建立在前几个阶段建立的坚实基础来发展。它要求解决方案开发团队（SDT）获得满足业务需求且技术准确的可接受且准确的解决方案。SDT将使用迭代开发，时间盒和MoSCoW优先级等实践，以及建模和辅助研讨会。在时间框内工作，SDT以迭代的方式探索需求的低级细节，以创建解决方案增量，每个增量在向前推进时不断进行测试。

部署阶段采用演进解决方案的基线将其投入运营使用。

部署有三种可能的结果;

• 已发现一个主要的范围变化，暂时不得不忽略，以便按时交付。这将涉及返回基础阶段并从那里开始进程。
• 现在要添加计划用于下一个增量的功能，因此该过程返回到 Evolutionary Development。
• 或者，现在完全满足所有要求，我们将进入后期项目阶段，这包括维护运营解决方案并确保实现预期效益。

有一系列可交付成果与流程的每个阶段相关联，DSDM将其称为产品。此上下文中的术语“产品”适用于在项目期间生成和使用的文档，以及项目设置为创建的主要可交付项目。并非每个项目都需要所有产品，产品的形式将根据合同关系或公司标准等问题而有所不同。

DSDM定义了两种类型的产品：
•随着时间的推移而演变的进化产品，通常在多个阶段和
•在阶段内创建的里程碑产品，通常以阶段作为检查点或促进治理流程来实现特定目的。

现在，我们将更详细地介绍这些阶段中的每个阶段以及在每个阶段中创建或使用的产品。

项目前阶段

项目前阶段的基本特征是简洁。它应该保持简短，尖锐和恰到好处，并且仅限于制作一份简短陈述，以证明可行性阶段的合理性和优先顺序。

此阶段的目的仅仅是澄清在可行性阶段需要调查的内容，并将其置于组织内正在执行或计划的其他工作的上下文中。许多项目作为其他项目组合的一部分存在，或作为具有共同业务目标的项目计划的一部分存在。无论如何，必须始终在项目开始时正确设置项目，以确保成功。

因此，这一阶段的目标是：

•描述要解决的业务问题

•确定商业赞助商和商业远见者。

•确认项目与业务战略一致。

•并确定可行性阶段的范围，计划和资源。

这一阶段只有一种产品，即职权范围。这是项目业务原因和目标的高级定义。主要目的是证明可行性调查的合理性，文件应保持很短，最多一页或两页。在许多组织中，可能根本没有文件，只是简单地通过电子邮件或甚至口头协议允许进入可行性阶段的潜力。

职权范围等同于Prince2项目中的项目授权。可行性阶段从业务或技术角度来看，可行性阶段提供了第一次停止不可行的项目的机会。

在这个阶段停止项目不是弱点或无能的表现，而是表明组织的成熟度和工作方法。如果这个阶段的结论是项目风险太大，或者太昂贵，或者可能只是现在不适合开始项目，那么唯一合理的选择是停止。如果一个项目不可行，越早停止就越好。

AgilePM建议在此阶段使用辅助研讨会，而不是连续采访。我们将在稍后的会议中讨论这种技术，但总的目标是加快这一阶段，避免“分析瘫痪”。

因此，可行性阶段的目标可归纳为：

• 确定是否有可行的解决方案来解决职权范围中描述的业务问题。

• 确定提交解决方案可能产生的收益。

• 概述提供解决方案的可能方法，包括采购和项目管理。

• 描述项目的组织和治理方面。

• 提供时间表和成本的首要估算。

• 计划和资源基础阶段。

可行性阶段有三个必要条件;

• 该项目的职权范围必须得到批准，
• 调查所需的资源必须可用，
• 并且业务愿景必须有时间来帮助塑造项目。

基础阶段

基础阶段建立在可行性阶段的结果之上。
它旨在建立对项目业务基本原理，将要创建的潜在解决方案以及如何管理开发和交付的基本理解。它无意对这些方面进行详细的理解，这些方面将在进化发展阶段随着时间的推移而发展。因此，即使是大型复杂的项目，这个阶段也只能持续几周。

对于更简单，更复杂的项目，可行性和基础阶段通常合并为一个阶段。

对于大型复杂项目，可能需要在每个部署阶段后重新审视基础阶段。

这一阶段的目标是：
•了解工作范围
•如何从广义上进行
•谁来做这项工作
•何时何地完成并最终完成
•通过老化DSDM流程应用于此特定项目的方式来确定项目生命周期。

在基础期间审查和更新可行性阶段的产品，并创建称为新里程碑产品。

基础期间提供了基础阶段结束时不断发展的业务，解决方案和管理产品的快照。与可行性摘要一样，摘要的内容应该足够成熟，以便能够决定是否继续项目，它可以是基线产品的集合，也可以是每个产品关键点的执行摘要。

进化发展阶段

顾名思义，演化开发阶段是使用迭代方法开发解决方案的地方，以便解决方案发展。

解决方案开发团队或团队在此阶段使用迭代开发，时间盒和MoSCoW优先级等实践以及建模和促进研讨会。这些方法有助于团队在一段时间内开发解决方案，并在每次迭代时更接近最终解决方案。

在时间框内，解决方案开发团队创建解决方案增量，迭代地探索低级需求，并在前进的过程中不断进行测试。这可确保解决方案满足业务需求，并从技术角度以正确的方式构建。

在此阶段创建了三种进化产品：
•不断发展的解决方案
•时间箱计划和
•时间框审核记录。

发展阶段

一旦我们对演进解决方案进行了基线增量，就应将其部署到受影响业务区域的运营中。部署的版本可以是最终解决方案，也可以是最终解决方案的子集。最终版本发布后，项目结束。
假设部署是临时版本，下一步是返回进化开发阶段继续进行进一步的迭代，或者在更大的项目中，可能需要返回基础阶段。在此阶段，我们制作项目审查报告。这是一个里程碑产品，但它会在每个项目增量结束时逐步更新，其中新增部分与该增量相关。

该产品的目的是：
•捕获对交付解决方案的审核反馈，并确认已交付或未交付的内容
•从审查或回顾中获取已完成增量的学习要点，这些增量应侧重于过程，使用的实践以及不同角色的贡献及其职责和
•适当地描述通过正确使用交付的解决方案应该产生的业务收益。

在最终的项目增量之后，对项目进行全面审查或回顾。此审核的关键输入是项目审核报告及其包含的每个增量的信息。

项目后阶段

DSDM流程的最后阶段是项目后阶段。这是在部署最终解决方案之后进行的，其目的是检查实现预期业务收益的程度。

在具有多个部署的大型项目中，与此阶段相关联的工作可以在进化和部署其他增量时发生。这里生产的产品是福利评估，这是另一个里程碑产品。在长期累积福利的项目中，有必要进行一系列福利审查，因此将编制一些福利评估报告。应该记住，仅仅因为部署了解决方案，不一定能实现效益。业务需要确保将新解决方案嵌入业务领域，以实现结果或新业务流程。这反过来又带来了实现的好处。

Summary

In the session we have been examining the DSDM process model and the various phases within it.

We have seen how the early phases of Pre-Project, Feasibility and Foundations are carried out sequentially with the over-arching aim of deciding, firstly, if a project is worth doing and then, if it is, laying firm and solid foundations for its conduct in order to give it the best chance of success. The motto for each of these phases, in an Agile project, is “do just enough to move on”.

The Evolutionary Development Phase is where the real work of the project is done and where the required end-product or solution is iteratively and incrementally developed.

Once the solution, or increments of it, have been completed they pass into the Deployment phase for transitioning into operational use.

The final phase is Post-Project, which is carried sequentially following the final increment of Deployment. The aim being to assess the degree to which the expected benefits are being accrued.

We have also considered the various Business, Management and Solution products that are used or generated within each phase of the DSDM process.

Session 4: Techniques
Objectives

In the first session we saw how one of the supporting pillars of DSDM is called Practices and there are five of these which are called: Facilitated Workshops, MoSCoW Prioritisation, Iterative Development, Modelling and Timeboxing.

In this session we will be exploring each of these practices and when you have completed the session you will be able to describe each in some detail and explain how and where they are applied within an Agile Project.

We will also examine another technique which, whilst not specifically referenced within DSDM, is commonly encountered on Agile projects in relation to the management of development teams, namely SCRUM.

Facilitated Workshops

Facilitated Workshops is a key practice in supporting the principles of Collaboration and Communicate Continually and Clearly.

The formal definition of a Facilitated Workshops is “A structured approach to ensure that a group of people can reach a predetermined objective in a compressed timeframe, supported by an impartial facilitator.”

In essence, a Facilitated Workshop is a specialised type of meeting with the following key ingredients:

• Clear objective deliverables
• A set of people or Participants specifically chosen and empowered to deliver the required outcome and
• An independent person called a Workshop Facilitator to enable effective achievement of the objective

It is most important that the Facilitator is neutral and their job is to guide the group through the process enabling them to work together to achieve an agreed goal.
Facilitators:
• Have no stake in the outcome
• Have no opinion on the content
• Are focussed on group dynamics
• Enable group members to collaborate
Facilitated Workshops ensure a team-based approach through verbal ad visual communication and collaboration. This enables the results to be achieved with speed, commitment and buy-in to the outcome.

Facilitated Workshops confer many direct and indirect benefits and they can be used throughout the project.

Principal benefits include:

Rapid, high-quality decision-making. By ensuring the relevant stakeholders are present and focused on the objectives in front of them, collaboration and communication are more effective and results can be achieved far more quickly and with greater confidence.

Greater buy-in from all stakeholders. By virtue of having had the opportunity to participate in and contribute to the decisions that are made, the participants of the workshop feel more involved and committed to the end results.

Building team spirit. A significant by-product of the use of Facilitated Workshops is improved rapport across the project community. It is for this reason that they are considered to be very supportive of the Atern principle of Collaboration.

Building consensus. The interactive nature of
workshops enables group discussion which encourages the participants to come to consensus gaining agreement
on each aspect before moving on to the next topic.

Clarification of issues. Workshops provide a platform for problems, ambiguities and misunderstandings to be identified and resolved and

ensure that all participants share the same vision of what a successful outcome will look like.

The areas of a project which can typically benefit from the use of facilitated workshops include; requirements capture, requirements prioritisation, project kick-off, planning, risk identification and analysis, and retrospective reviews of timeboxes, increments and whole projects.

In order to maximise the success of Facilitated Workshops there are a number of factors to bear in mind.

Firstly, the skills and independence of the Facilitator will be perhaps the most potent success factor. An effective, trained and unbiased facilitator is essential and it is often found that Business Analysts have the right sort of skills and can facilitate each other’s workshops.

Secondly, all workshops do not have to have the same format, there is room for flexibility here but the objective must always be clearly defined.

There must be thorough preparation before the workshop by both the Facilitator and the Participants.

A mechanism must exist to ensure that the results of previous workshops are built-in, where appropriate so that previous decisions are not changed or ignored.

It is important that decisions and agreements are not forced. If the group cannot reach consensus the Facilitator should determine with the group the actions required to remedy the shortfall.

Finally, a report describing the decisions, actions and outcome of the Workshop should be produced quickly after the workshop has concluded. This maintains the focus and impetus of the decisions.

Questions

Which of these is TRUE about a workshop?

1. It has Participants
2. It has a Workshop Facilitator
3. Only Senior Stakeholders should attend
4. The Facilitator should be independent

a) 1,2, 3
b) 1, 3, 4
c) 2, 3, 4
d) 1, 2, 4

Answer: C

Which of these is NOT a benefit of facilitated workshops?

a) Building consensus
b) Rapid, high quality decision-making
c) Ensures the users get everything they want
d) Clarification of issues

Answer: C

For which of these are workshops particularly helpful?

1 Problem solving
2 Requirements capture
3 Progress Reviews 4 Building a Plan

a) 1, 2, 3
b) 2, 3, 4
c) 1, 3, 4
d) 1, 2, 4
Answer: D

MoSCoW优先排序

在DSDM项目中，成本，时间和质量是固定的这一事实，并且它是可以变化以适应这些约束的特征，这是一个非常重要的问题。

您如何确定可以删除或延迟哪些功能以满足计划预算或截止日期？这意味着必须对提议的特征进行某种形式的优先排序，这应该包含在项目的原始计划中。为了确保以系统化和结构化的方式做出优先级决策，DSDM提倡所谓的MoSCoW优先排序技术。

该名称的来源是基于缩写：必须拥有，应该拥有，可能拥有，并且不会有。
这个想法是，在项目开始时，预期解决方案的每个提议和潜在特征将被分类到这些标题中的每一个。如果证明完整的解决方案无法在计划的预算或时间范围内交付，则可以使用此列表来确定合适的遗漏候选人。

Must have
必须拥有类别中包含的功能包括项目保证提供的所需要求的“最小可用子目标”。

可以使用以下部分或全部方法来解决这些问题：
•如果没有这个目标，交付目标日期是没有意义的。如果没有交付，则部署解决方案毫无意义。
•没有它就不合法
•没有它不安全
•没有它，无法提供可行的解决方案。

DSDM建议与必须要求相关的工作量不应超过可用总工作量的60％。

如果努力需求超过可用总量的60％，那么提供最小可用子集的保证将面临风险。
“应该拥有”类别中的功能通常被认为是重要的，但并不重要。未能将它们包含在最终解决方案中可能会很痛苦，但解决方案仍然可行。可能需要某种形式的解决方法，例如，管理期望，使用基于文档的解决方案等。

“应有”和“有可能”之间的区别总是主观的，区别通常由特征遗漏导致的疼痛量来定义。这可以用商业价值或受影响人数来衡量。MoSCoW优先事项应在项目早期进行讨论和商定，并构成商业案例的一部分。随着项目的进展，优先事项可能会发生变化，但所有利益相关方的期望越早达成一致，并且理解结果就越好。

就商业案例中经常包含的最佳案例/最坏情况/预期案例情景而言，Must Haves的交付构成了最坏情况。Must Haves由项目团队保证给业务赞助商，并且是企业有权期望的最低要求。

实现所有Must Haves的计划工作量不应超过项目总工作量的60％，这是一个很好的经验法则。这允许非常好的应急余量来确保这一点，它们将在规定的时间和预算范围内实现。
剩下的40％应该在应有希望和能量之间平均分配。

这意味着只需要80％的计划资源来交付必须和必需的资源，因此仍有20％的意外情况可以保护预期案例解决方案的交付。如果事情按照计划完成，那么这些资源将可用于交付Can Haves。

很容易看出，在决定优先级时，业务和项目利益之间存在很大的冲突。
该企业通常会尝试将大多数或所有功能设置为Must Haves，期望他们能够获得更多他们想要的功能。该项目将尝试将功能降级为Can Haves，因为这将给他们带来更大的偶然性。这是60/20/20规则有用的地方。通过在业务和项目利益上强制执行这些划分，它鼓励每个部门更加切合实际，并努力达成双方同意的优先事项定义。

如果协议难以实现，那么商业远见者和商业大使对优先事项有最终决定权。无论商定的是什么，商业赞助商都有权期望所有Must Haves和大部分或全部的Should Haves作为最终解决方案的一部分交付。为了满足对截止日期的承诺，DSDM项目需要在优先级要求内创建意外事件 ：通常是通过Can Haves。

但是，在规划下一个项目增量时，重点是同意MoSCoW的优先级。此时，需求可能有两个优先级：一个用于项目，一个用于增量。当我们开始计划时间框时，解决方案开发团队将同意此时间框内的要求的特定优先级。此时，大多数要求将不具备此时间框。 解决方案开发团队只会将MoSCoW优先级分配给要在Timebox中处理的要求。

因此，我们有三个优先级：
•项目的MoSCoW
•MoSCoW用于项目增量
•此时间盒的MoSCoW。

Questions

Which are the levels of priority for requirements?
a) MoSCoW for the Project and Timebox
b) MoSCoW for the Project, the Project Increment and Timebox
c) MoSCoW for the Project Increment and Timebox
d) MoSCoW for the Project and the Project Increment

Answer: B

The Minimum Usable SubseT consists of:
a) All the Must Haves
b) All of the Must Haves and Should Haves
c) 60% of the Must Haves
d) 60% of the Must Haves, 20% of the Should Haves and 20% of the Could Haves

Answer: A

Which of these does not define a Should Have requirement?
a) Important but not vital
b) May be painful to leave out but the solution is still viable
c) May need some sort of workaround
d) Wanted or desirable but less important

Answer: D

迭代开发
迭代开发是一个过程，在这个过程中，不断发展的解决方案或其中的一部分从高级概念演变为具有公认业务价值的东西。每个周期都应使解决方案的一部分更接近完成，并且始终是一个通常涉及解决方案开发团队的两个或更多成员的协作流程。

每个周期应该尽可能短，通常是一天或两天，在时间框中发生几个周期：
•思考：我们考虑在与同事交谈时需要做些什么
•我们完成工作的行动
•对话，我们审查结果是否符合需求，并了解所需的任何进一步工作。
这个循环实际上以对话开始和结束。

最后，每个周期都应包括与正在完成的工作相关的解决方案开发团队的相应成员。最简单的是，这可以是与商业大使或企业大使合作的解决方案开发人员。它可能需要整个解决方案开发团队和几个业务顾问的参与。规划迭代开发在基础阶段进行，我们决定开发策略。

在这里，我们计算出如何将可能出现的解决方案的大问题分解为可管理的块，以便在Timebox中交付。在控制迭代开发周期时，完全有可能进化，而不是作为完全解决方案的一步，在某种程度上证明是不正确的。如果是这种情况，解决方案应该“回滚”到先前可接受的版本，因此，在配置管理下记录每次迭代非常重要，这样每次迭代的基线都可用，以便我们可以在必要时返回。

由于DSDM的原则之一是“永不妥协的质量”，我们必须确保解决方案的质量水平和每个增量的定义。
解决方案质量的初始定义是在早期生命周期阶段确定的。
在进化发展阶段，我们必须采用持续验证的过程。有两种方法可以做到这一点：
•静态，例如文档审查或
•动态，例如某种测试
这些都是迭代开发实践的核心。

评论可以从非正式的同行评审到涉及专家和人群的非常有条理的正式评审。形式的程度取决于产品和组织治理标准。
测试涉及三大类：
•正面测试，检查可交付成果，做它应该做的事情
•负面测试，检查交付物不会做它不应该做的事情
•不愉快的路径测试，在异常或未定义的事情发生时检查可交付物的行为。
基于这些类，可以为每个类考虑一些测试，每个测试都有自己的验收标准。
每项测试通常具有：
•定义的起始状态
•我们将执行的一组定义的操作
•我们期望看到的结果，
在职责方面，技术协调员从技术角度负责解决方案的整体质量。
此人必须确保非功能性要求在一开始就是合理的，并随后得到满足。技术协调员必须确保进行适当的技术审查，并且测试足够严格，以确保解决方案符合目的。
解决方案测试人员负责执行所有类型的测试，除了：
•业务验收测试，由业务大使和业务顾问负责
•解决方案开发人员负责的功能的单元测试。
作为协作团队的一员，Solution Tester将通过测试知识和专业知识支持其他角色。

建模
建模是另一种创建问题或解决方案的可视化表示的技术。模型可以定义为：
•用于帮助可视化无法直接观察的内容的描述或类比
•一些东西或小的精确副本
•要制作的图案或图形。
这些技术有助于改善沟通并促使人们提出问题，并且它们通常用于建立要求，确认期望并测试是否可以实现成功。建模有助于尽早使解决方案可见，并且通常有一定程度的抽象有助于澄清情况。这是通过从模型中省略一些信息来帮助我们专注于另一个关键方面。
它用于考虑What，Why，When，How，Where和Who的六个视角，以获得解决方案的连贯图片。

时间盒
时间盒不仅仅是一项关键技术 - 它是敏捷项目管理的核心。

Timeboxing包含了“按时交付”的基本原则，它通过在最低级别应用固定结束日期来实现这一点，从而确保在更高级别按时交付。事实上，整个项目可以被认为是一个大的时间框，具有固定的结束日期，并由几个增量组成，具有自己的固定结束日期。然后，在最低级别，解决方案开发团队的时间框架工作。

在此模型中，虽然整个项目及其中的增量类似于时间框，并以类似的方式进行管理，但术语“时间盒”专门用于指代解决方案开发团队的低级工作。

MoSCoW优先排序和对在规定时间范围内可实现的内容的持续重新评估，确保每次都能按时完成时间框，从而增加整个项目。
Timebox应该以Kick-Off开始并以Close-Out结束。两者之间的时间不是强制性的，但通常为2-4周。 6周应被视为合理的最大值。

DSDM识别两种类型的Timebox：
•DSDM结构化时间盒和
•免费格式的时间盒

您选择哪一个取决于诸如商务大使的可用性和其他业务角色或正在开发的产品类型等因素。

我们首先考虑结构Timebox。

在时间框内，工作应该迭代进行，DSDM建议将每个时间框分成三次迭代;调查，改进和整合 - 正如我们在迭代开发部分所看到的那样。

因此整个时间框可以这样表示，调查迭代通常占整个时间箱的10-20％，精炼60-80％和合并10-20％。

建议启动和结束会议的持续时间不超过1至3小时。

每个时间框都将由一个时间箱计划覆盖，该计划由团队创建，包括MoSCoW优先级，关键里程碑，角色和职责以及时间框可交付成果的定义。

启动的目的是使解决方案开发团队能够;同意时间范围;确认计划的可行性，否则重新计划;审查团队成员的可用性并重申MoSCoW的优先事项。

所有将在时间框内工作的解决方案开发团队成员都应参加启动仪式，包括业务大使，项目经理，技术协调员以及必要时的业务愿景。调查迭代应包括对Timebox可交付成果的初步检查，其验收标准以及将用于衡量和证明成功的指标。这里的目的是为以下改进提供坚实的基础。在细化迭代中，解决方案开发人员将根据商定的MoSCoW优先级处理解决方案。

合并迭代完全是关于完成并确保整体输出适合目的。应在精炼评审中达成一致的行动，并进行质量控制检查，以确保所有产品符合要求的标准。

结束的主要目的是实现对已经交付的内容的签署或接受，并评估尚未完成的工作的影响。结束也提供了记录在时间框架内学到的课程的机会，这可能对将来有益。

自由格式时间盒影响其他流行的敏捷方法（如Scrum Sprint）使用的风格。当DSDM时间框的形式不可行或无用时，此类时间框非常有用。它从一个启动会议开始，以一个关闭会话结束，但在称为迭代开发之间有一个单独的元素。在这个元素中，开发是通过对Kick Off中约定的个性化需求，用户故事和其他产品的测试进行迭代进行的。

Timeboxing技术的一个重要组成部分是解决方案开发团队以简短的Stand-Up会议形式每天聚集在一起。

•解决方案开发团队的所有成员都参加，包括业务大使，任何业务顾问和积极参与时间框的任何技术顾问。

•遵循一种简单的格式，每个团队成员依次描述;自上次会议以来他们做了什么;在下次会议之前他们要做什么;以及他们在取得必要进展方面遇到的任何问题。

•有一个短暂的，固定的时间限制 - 通常约15分钟。每个团队成员2分钟是一个很好的经验法则。

•所有参与者都应该由他们的团队Bard站成一个圈子。

SCRUM

It is important to understand that whilst it is a commonly encountered Agile technique, SCRUM is not part of DSDM or AgilePM and is not discussed in the AgilePM manual, nor is it included in the AgilePM examination syllabus.

So we are going slightly “off-piste” here, purely for background information and general knowledge purposes. It is likely that when you are operating in an Agile environment SCRUM will often be mentioned and you will find it useful to have an understanding of at least what is meant by the term.

The origins of SCRUM go back to 1986 when two Japanese management consultants set out to define a product development strategy where a development team work together to reach a common goal. This was in contrast to the traditional sequential approach which could be stifling to creativity on the part of the developers.

SCRUM isn’t an acronym but is thought to be derived from the SCRUM in the game of rugby.

Essentially SCRUM is a way of teams working together to develop a product, and it is very much an Agile method in that development takes place in small pieces with each piece building on and extending what has gone before. It is iterative and incremental.

The greatest overlap between SCRUM and DSDM or AgilePM occurs in the way that the development teams are managed. The Timeboxing technique is an adaptation of SCRUM and has many of the same characteristics.

SCRUM Roles

SCRUM defines three core roles to represent the scrum team. They are the ones producing the product and committed to the project and the scrum process.

The first of these is the Product Owner. This is the person representing the customer’s interest in the project and who has primary responsibility for ensuring that the team delivers real value to the business.

Then there is the Scrum Master, who is there to facilitate the scrum and to remove any impediments to
the scrum’s ability to achieve its goals. This should not be the Team Leader but someone who is there to enforce the rules and to ensure that the scrum process is adhered to.

Finally there is the Development Team, typically consisting of 3 to 9 self-organising cross-functional specialists, who do the actual work of producing the end deliverable.

SCRUM also identifies several ancillary roles such as Stakeholders and Managers. These are people who are important to the project as a whole but have no formal role in the scrum process.

The basic unit of development in SCRUM is known as a Sprint. This is a timeboxed piece of work in that the duration is fixed in advance, normally in the region of 2 to 6 weeks.

Each Sprint starts with a brief planning meeting and ends with a review meeting or retrospective at which progress is assessed and lessons learned recorded for the next sprint.
During the course of each sprint the team create portions of the finished product and the set of features that are developed in a sprint are drawn from the sprint backlog. Which features are included in any particular sprint is decided by the team at the sprint planning meeting.

The Product Owner informs the teams which are the priority products that are needed from the Product Backlog but the sprint backlog is the property of the development team.

The sprint goals should not be changed during the sprint and since the sprint is timeboxed it must always finish on time. Any features that have not been finished by the end of the sprint will be returned to the product backlog and re-prioritised.

Each day during a sprint the team will hold a Daily Scrum, which is a brief stand-up meeting to review progress and identify any barriers to further progress.

The Daily Scrum is run to very strict guidelines;

All members of the development team must attend and prepare for their part in the meeting. The meeting should always start exactly on time and be timeboxed to 15 minutes duration.
The meeting should happen at the same location and same time every day. The location for the meeting should ideally be the team’s normal place of work.

Ancillary roles are welcome to attend, but normally only core roles contribute.

Each team member must briefly answer three questions; What have I done since yesterday’s meeting? What will I do before tomorrow’s meeting?
What obstacles are there to prevent me achieving my goals?

Any obstacles arising in answer to the last question will be picked up by the Scrum Master and resolved outside the meeting. The Daily Scrum is not the place for detailed discussion and problem solving.

Summary

In this session we have been examining the 5 key practices that DSDM recommends are used in support of the 8 Atern Principles.

We saw how the use of Facilitated Workshops throughout the project can support the principles of Collaboration and Communication.

We have explored the vital practice of MoSCoW prioritisation and seen how it can be used to support the principles of Focussing on the business need, Delivering on time and Never compromising quality.

The technique of Iterative Development was explained and we saw how it is used to support the principles of Building incrementally from firm foundations, Developing iteratively and Communicating continuously and clearly.

Modelling was also seen to be a powerful rich-communication technique in support of the principle regarding communication.

The critically important technique of Timeboxing was seen to lend support to just about every one of the eight DSDM principles.

Finally, we went slightly outside the scope of this course to have a brief look at the SCRUM method of managing development teams. This has many similarities with the Timeboxing technique of AgilePM and you will undoubtedly hear it discussed in Agile management circles.

Session 5: Planning and Control

Objectives

In common with other Agile approaches DSDM values “responding to change” over “following a plan” but unlike some does place a strong emphasis on planning, specifically high level planning.
These plans shape and structure the project and the work but they don’t go into the detail of exactly who does what and when.
We start planning with an agreement about the overall strategy which defines our approach to developing the solution and considers:
• Incremental delivery of the solution in Project Increments and Timeboxes and
• Quality Assurance of the solution in other words how the review and testing activity will be integrated into the development.
In order to address these considerations DSDM defines:
• three Agile Project Planning Concepts
• six Testing Concepts and
• four Tracking and Control Concepts.

During this session we will review these concepts, the DSDM approach to planning across the lifecycle and the approach to planning and quality.

Project Planning Concepts

The three planning concepts recommended by DSDM are:
• Outcome-based planning
• Planning to sensible horizons at the right level of detail and
• Plan and re-plan based on best available estimates.
We’ll consider each of these in turn starting with outcome-based planning.
When we discussed the roles and responsibilities we mentioned that the roles were empowered within the hierarchy of a DSDM project.
At the highest level the Business Sponsor empowers project-level roles to manage the delivery of a business solution that will deliver a Return on Investment.
The Project-level roles empower the Solution Development Team to self-organise and deliver the solution envisioned by the Business Visionary and Technical Coordinator that meets the business need. So within this framework the Project Manager is responsible for the high-level planning for the project, working in collaboration and plans the incremental delivery of the solution which is the outcome requirement by the Business Sponsor.
The Solution Development Team is responsible for planning the work within each Timebox with the team members agree amongst themselves who will do what work to achieve the objectives agreed at the Kick-Off of the that Timebox.

Let’s move on now to discuss the second planning concept of “planning to sensible horizons at the right level of detail”

Because the solution is evolving it is very difficult, if not impossible, to plan the detailed work well into the future.
The point we can see ahead to is called the planning horizon and DSDM defines two plans to cover the two very different planning horizons.
The plan which covers the entire project or a large Project Increment is called the Delivery Plan whilst the plan with the horizon of the end of a Timebox is called the Timebox Plan.

项目的交付计划通常包括：
•下一个或即将发生的项目增量的时间框和其他高级活动的时间表
•规划期限为6周至6个月
•在规划期限较长的情况下，未来项目增量的高级目标和交付日期。

通常是时间箱计划：
•规划期为2至4周
•包含时间框内的详细任务，包括谁做什么以及何时做什么
•可以在团队委员会中非正式地介绍，并在每日站立会议上进行更新。
这引导我们进入第三个概念“基于最佳可用估计的计划和重新计划”，我们将在下面讨论。

由于我们无法看到未来的估计将随着我们对解决方案的了解而发展。估计不准确的数量在工作开始时最大，并随着时间的推移而改善。在基础阶段结束时，我们需要精确估算，因为我们需要对项目的交付日期和成本做出承诺。随着我们进入演化发展阶段并且我们越来越了解不断发展的解决方案，重要的是重新审视原始估算和我们对项目增量和整个项目所能提供的内容的期望。记住时间，成本和质量是固定的，此时我们将根据MoSCoW优先级调整我们提供的功能数量。通过使用一系列估算技术并让许多人输入我们知道的分组估算，可以提高估算准确度。

规划整个生命周期
在项目前阶段，计划重点是项目在项目组合中的位置。这可确保项目符合组织的战略，并形成投资组合的有效部分。随着项目要求在可行性阶段的探索，项目开始形成，并建立了交付计划的初步视图。这有助于业务发起人决定项目是否有效并应进入基础阶段。我们会做更多的规划并建立迭代开发，集成测试和部署的策略。交付计划得到完善，业务部门对项目的时间表和成本做出承诺。

当我们进入进化开发阶段时，我们会生成时间箱计划，根据正在进行（或不进行）的进度来完善交付计划，并计划部署和实现利益。

测试概念
DSDM提出了六个测试概念，我们将首先考虑这些概念，然后继续讨论规划和质量。

第一个概念是“整体测试”，确保有适当的测试策略，每个人都知道他们在解决方案质量方面的责任以及通过严格的审查和测试制度确保的方式。测试应该是迭代开发过程的一部分，测试应该完全嵌入到与开发活动相同的时间盒中。“随时测试”的过程有助于在最便宜的时候找到任何缺陷！理想情况下，该解决方案将在Timebox结束时进行全面测试并可能部署。

协同测试是下一个概念，这表明所有测试都应涉及所有利益相关方的协作，从而提高测试 - 修复 - 重测周期的生产率。通过让利益相关者参与进来，测试将是全面的，并有助于防止错误进入后期阶段，因为他们需要更多的修复费用。

第三个概念是“可重复测试”。顾名思义，这意味着确保测试是可重复的，因此当我们从Firm Foundations逐步遵循原则构建时，我们可以引入新的测试，但是在适当的时候重做之前完成的测试。有时可以自动执行其中一些测试。有时无法完全测试解决方案的所有方面，因此有助于根据风险确定测试的优先级。也就是说，我们有多大可能引入缺陷以及这种缺陷可能产生的影响。使用此方法测试检查较高风险区域将具有更高优先级的其他区域。 MoSCoW规则也可用于帮助确定测试的优先级。

进行独立测试非常重要，换句话说，测试应该由创作者以外的其他人完成，这可能也会被归类为“你无法检查自己的工作”。让业务大使或业务顾问进行一些测试可能会有所帮助，因为他们将始终独立于被测产品的创建。

最后，我们来到TDD或测试驱动开发的概念。这个概念转变了传统的设计测试方法以适应解决方案。

规划和质量
研究表明，TDD显着提高了解决方案的整体质量。
在可行性阶段，我们必须确定会影响我们提供所需质量标准的能力的高级别风险。除此之外，我们还必须了解解决方案需要具备的特殊品质，例如性能，安全弹性，易于访问等。

规划和高级分析在基础阶段完成。
在这里，我们将考虑质量观点，同时考虑如何限制解决方案以及需要哪些业务活动，以帮助从可能含糊不清的要求中提炼出良好的高级要求。这也鼓励了专注于需求的业务角色，专注于设计和构建的解决方案开发角色以及专注于证明质量的解决方案测试人员之间的协作。
进化发展过程有三个质量要点：
•第3点的详细分析和规划
•准备并在第4点和第4点运行
•评估第5点的质量和影响。
最后，我们进行了最终的端到端测试，并确保在部署阶段实施。

详细分析和计划涵盖了对要求的更详细分析以及正在进行的验收标准。准备和运行包括两组活动，测试准备，其中测试是针对正在构建的每个特征协同定义的，理想情况下使用TDD概念，根据需要确定测试的优先级。其次，运行测试，进行测试并根据上下文，已完成的内容和所看到的内容捕获测试信息，以便可以重复测试并在必要时向第三方演示。这为测试机制提供了重要的审计跟踪。

在测试过程中，我们评估质量和影响，以便我们尽快发现缺陷，并将补救工作安排到时间盒中。如果无法轻易纠正问题，则在另一个时间框中计划补救措施，或者正式接受缺陷。要考虑的最后一个方面是最终的端到端测试和对部署中实施的实施的保证。尽管我们已经在每个Timebox和每个Project Increment中测试了解决方案，但仍然需要对整个包和部署过程进行最终测试。最终验收测试也提供了一个有用的检查点。

并且不要忘记，一旦发生成功部署，就需要有一种验证成功部署的方法，并且我们还应该考虑在发生严重故障时测试任何退出计划。

跟踪和控制概念
第一个概念是Timeboxing和基于结果的测量。

时间盒提供嵌套计划的结构，并且在每个时间框的末尾将有某种形式的可交付成果或结果以及基于结果的测量检查，以查看可交付成果是否按计划生成。如果它一切顺利，如果不是那么我们需要考虑下一步该做什么。

时间框结束时解决方案增量的演示以及业务大使或可能的商业幻想家的正式接受为基于结果的测量提供了客观基础。这一过程为项目增量以及最终项目提供了明确和客观的进展指标。

第二个概念是透明度或过程和进展。

在Timebox级别，流程的透明度和进度来自使用应该在团队委员会附近进行的Team Bard和Daily Stand-up。

会议让每个团队成员有机会陈述：
•自上次会议以来他们所做的一切
•他们打算在下一次会议之前做什么
•什么，如果有什么可能锁定他们的进展。
共享这样的信息可以鼓励协作和主动解决问题，这是敏捷团队的特点和有效性。

跟踪和控制的最后两个概念是响应变更和异常管理。

在敏捷环境中，我们期望并接受变革，并将其视为我们获得正确解决方案的一部分。但是，保持对业务需求的关注，按时交付也很重要，这意味着需要一些变更控制元素。通常，这在项目层面比在解决方案开发层面更为正式。在项目级别，业务愿景负责确保解决方案符合业务愿景并且高级要求是正确的。但是，如果项目的进展如果有改变这些要求的压力（通常称为广度变化），那么变更应该由商业幻想家正式批准。

在解决方案开发团队层面，大多数变更都是由于对需求的理解和对需求的满足而产生的。对深度和细节的更改并不代表范围的正式变更，因此主要由解决方案开发团队自行决定。商业大使和顾问有权决定什么是适当和可接受的。

最后，我们来到Exception的管理层。在MoSCoW提供的容差范围优先排序解决方案开发团队负责日常的工作管理。但是，如果很明显解决方案增量不是必须的并且应该同意，或者存在质量受损的风险，则应将此异常情况升级到项目级角色以获得指导。授权提供快速决策和管理，通过例外弥合授权之间的界限，并确保项目层面的角色在必要时参与决策。

DSDM值“响应变化”而非“遵循计划”，但与某些计划不同，它强调规划，特别是高层规划。这些计划塑造和构建了项目和工作，但他们没有详细说明谁做什么以及何时做什么。
我们开始计划总体战略，该战略定义了我们开发解决方案的方法，并考虑：
•在项目增量和时间框中增量交付解决方案
•解决方案的质量保证，换句话说，审查和测试活动将如何集成到开发中。

欢迎在评论下方斧正