ACP敏捷实践指南

‘个体以及互动’而不是‘过程和工具’

‘可用的软件’而不是‘完整的文档’

‘客户合作’而不是‘合同谈判’

‘应对变更’而不是‘遵循计划’

我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求

欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。

要经常交付可用的软件，周期从几周到几个月不等，且越短越好。

项目实施过程中，业务人员与开发人员必须始终通力协作。

要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务

无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈

可用的软件是衡量进度的首要衡量标准

敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。

对技术的精益求精以及对设计的不断完善将提高敏捷性。

简洁，即尽最大可能减少不必要的工作，这是一门艺术。

最佳的架构、需求和设计将出自于自组织团队。

团队要定期反省怎样做才能更有效，并相应地调整团队的行为。

定义

目的

人员

过程

优点

职责

我们为什么要做这个项目？这是项目愿景。

谁会从中受益？如何收益？这可能是项目愿景和/或项目目标的一部分。

对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准。

我们将怎么合作？这说明预期的工作流。

回顾

待办事项列表编制

待办事项列表的细化

每日站会

展示/评审

规划基于迭代的敏捷

帮助团队交付价值的执行实践

迭代和增量如何帮助交付工作产品

回顾

待办事项列表编制

待办事项列表的细化

每日站会

展示/评审

规划基于迭代的敏捷

帮助团队交付价值的执行实践

迭代和增量如何帮助交付工作产品

敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型衡量指标。敏捷衡量团队所交付的成果，而不是团队预测将交付的成果。

基准通常是尝试预测的产物。在敏捷中，团队的估算是多限于未来几周时间。在敏捷中，如果团队工作的可变性不高，如果团队成员没有从事多任务，则团队的能力就会变得稳定。这样才能对未来几周做出更好的预测。

基于流程的敏捷团队使用不同的衡量指标，交付周期（交付一个工作项目花费的总时间，从项目添加到看板直至项目完成）、周期时间（处理一个工作项目所需的时间）和响应时间（一个工作项目等待工作开始的时间）。

Scrum是用于管理产品开发的单个团队过程框架。采用迭代方法来交付工作产品，Scrum是运行在1个月或更少时间的时间盒上的，其中包含持续时间一致的多个冲刺，在这些冲刺中会产生潜在可发布的产品增量。

产品负责人

开发团队

Scrum 主管

Scrum事件

Scrum工件

极限编程（XP）是一种基于频繁交付周期的软件开发方法。

将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践

XP实践领域

该演变是通过筛选核心价值观（沟通、简洁、反馈、用气、尊重）并根据主要原则（人性化、经济、互惠互利、自相似、改进、多样性、反思、流程、机会、冗余、失败、质量、循序渐进、承担的责任）信息来设计和采用技术的结果

看板在精益制造中是一种用于规划库存控制和补给的系统

看板方法应用并适合于多种场合，可以确保工作流和价值交付的持续性。

与大多数敏捷方法不同，看板方法未规定使用时间盒迭代。在看板方法中可以使用迭代，但应是始终遵循在整个过程中持续拉去单个条目并限制在制品以优化流程的原则。

看板方法适用团队

定义原则

核心属性

水晶方法是一种方法论家族。水晶方法论旨在根据项目规模（项目中涉及的人员数量）以及项目的关键性来量化并提供方法严格程度选择。

核心价值观

常见属性

Scrumban是一种敏捷方法，最初设计为Scrum到看板之间的过渡方法。它是通过其自身衍生演变而成的另一种混合敏捷框架和方法，其中团队将Scrum作为框架，而将看板作为过程改进方法。

工作被分解到许多小的‘冲刺’，并利用看板面板来可视化和监督工作。

将故事列在看板面板上，团队通过使用在制品限制来管理其工作。

通过召开每日例会来维持团队之间的协作并消除阻碍。

团队通过设置规划触发因素来了解何时规划下一步工作，通常发生于在制品级别低于预设限制时。

Scrumban看板中没有预定义角色-团队保留其当前角色。

功能驱动开发项目分为五个过程

功能驱动开发活动由一组核心软件工程最佳实践提供支持

功能驱动开发项目生命周期

DSDM因强制约因素驱动交付而著称

该框架从一开始便可设置成本、质量和时间，然后利用正式的范围优先级来满足这些制约因素的要求

八个原则

敏捷统一过程（AgileUP）是软件项目中统一过程（UP）的分支

与紧前统一过程相比，该过程具有加速周期和轻量级的过程。其目的在于在七个主要元素之间执行更多迭代的周期，并在正式交付之前纳入相关反馈。

发布中的因素

指导因素的原则

SCRUM OF SCRUMS

采用经济视角；应用系统思维；假设可变性；预留方案；以快速整合的学习周期进行增量式构建；根据对工作系统的客观评估设定里程碑；直观显示并限制在制品，减小批次规模并管理队列长度；应用节奏；与跨域规划同步；解锁知识员工的内在动力；决策分散化

以拓展Scrum方法为共同目标来组织多个开发团队的框架，核心组织原则是尽可能保留传统单个团队Scrum模型的元素

Less与Scrum相似性

在Scrum中添加Less技术

企业Scrum是一种旨在通过更整体性组织层而不是单个产品开发层来应用Scrum方法的框架

该框架尤其建议领导

规范敏捷是一种在综合模型中整合多种敏捷最佳实践的过程决策框架。DA旨在平衡专注范围过于狭窄（如Scrum）或细节过于规范（如AgileUP）的流行方法。为实现这种平衡，该方法根据以下原则混合了多种敏捷技术：

以人为先。枚举不同层级的角色和组织元素。

面相学习。鼓励协作改进

完全交付生命周期。提倡多个符合目的的生命周期

目标驱动。定制过程以实现特定结果

企业意识。提供跨部门治理方面的指导。

可拓展。涵盖多种项目复杂性维度。

将大项目重建为多个小项目。首先尝试技术实验项目，然后再执行实施项目；考虑频繁发布较少的功能，以创建较小的项目团队；考虑将团队裁剪到仅包含关键核心成员。通常人员过多会阻碍过程而不会有所助益；所限团队规模可减少内部动荡和成本；将大型团队分解为多个小团队，并利用项目管理进行同步和协调；利用敏捷和精益项目管理来组织大型项目。

许多项目都会包含（一些）分散团队成员。即时信息、视频会议和团队电子板都有助于确保通讯流畅。 如果团队保存稳定，请尽快构建面对会议以提高未来远程交流的效率。面对面交流时更容易建立信任感，提高对话质量； 如果在远程会议过程中参与者缺乏面部表情和身体语言交流，请考虑循环提问以确认他们的参与程度以及对决策是否认可。 此外，请考虑使用基于迭代的敏捷方法。如果团队成员所在时区差比较大，请避免使用整个项目迭代方式，而是鼓励开展更多更频繁的私人会议（每次两到三人）。

在这些环境中仍可使用敏捷方法，但还需要该领域所要求的其他相应的合规性审查、文档和认证。在这种情况下，文档可能需要随已完成的功能一起交付。只有文档完成后功能才算完成。

考虑使用混合方法（多种敏捷方法），按照产品环境所要求的更高严格程度，从敏捷所带来的协作和沟通改善中获得益处。航空飞行系统开发商和药物公司采用敏捷方法并结合自己的其他过程，充分利用这些优势并保留了相应的控制权。

是否真正需要敏捷方法？如果需求不确定性较低、变更速度缓慢、或者执行风险很小，则可能不需要整套敏捷方法。尽管协作和透明程度提高对任何项目都有益处，但某些迭代构建和审查周期可能会是多余的。

如果构建/反馈周期无法定期发现或优化需求，请考虑延长其持续时间以减少审查时间对成本的影响。

如果项目在设计和开发期间的变更速度极快，但向客户交付是一个确定性的可重复的过程，在每个项目阶段采用相应生命周期模型的混合方法可能更有意义。

敏捷是基于跨职能团队的理念。考虑让这些员工自行创建跨职能团队，而不采取管理干预手段，并了解其后果。

如果能够通过组织报酬系统认可职能领域并给予奖励，请考虑首先变更该系统。除非对自己的报酬有一定影响，员工才会为产品或团队的利益行事。

敏捷将创建透明文化：员工会在整个开发期间展示和分享其成果。这种分享中间可交付成果的方式以及对成败得失和当前状态的开诚布公的态度即反映了透明化。透明需要勇气。通过使用状态版或白板，示范引导并在决策过程中展示透明化。

敏捷方法将会提高团队的主动性并发挥其优势，作出工作内容相关的本地决策，例如任务安排顺序以及在解决问题时采用哪种方法。如果大多数团队成员经验不足，基于共识的方法可能会产生问题并导致返工。因此，对于这些团队来说，在获取必要技能之前，一些‘分配’和‘指导’方面的额外帮助可能是必需的。换言之，不要盲目地采用敏捷方法，授权经验不足的自指导团队尝试解决一切问题。考虑构建能力中心以帮助提供指导并积累领域知识。

如果缺乏管理层支持，团队将会在敏捷思维模式和方法与更具预测型的思维模式和方法之间遇到冲突。

根据组织需求找到共同点和改进之处，然后利用实验和回顾取得进展。

考虑管理层教育/培训。考虑从精益思维方面揭示敏捷：周期短、规模小、频繁审查、回顾与小幅改进。

如果不是敏捷语言，就修改术语，让员工了解并同意这些活动。说明每个术语的特定含义。