实施敏捷

四大价值观

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

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

客户合作而不是合同谈判

应对变更而不是遵循计划

十二大原则

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

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

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

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

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

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

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

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

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

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

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

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

创建敏捷环境

使用敏捷方法管理项目，要求项目团队采用敏捷思维模式。以下问题的答案将有助于制定实施策略：

• 项目团队如何以敏捷方式行动？
• 为了使下一交付周期受益，团队需要快速交付哪些成果并获得早期反馈？
• 团队如何以一种透明的方式行动？
• 为了专注于高优先级的项目，可以避免哪些工作？
• 仆人式领导对团队达成目标有何益处？

仆人式领导为团队赋权

• 目的，与团队一起定义“为什么”或目的，以便他们能围绕项目目标进行合作互动。整个团队 在项目层面而不是在人员层面优化。
• 人员，目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作 中做出贡献。
• 过程，不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能够常常交付完 成的价值并反思产品和过程，团队就是敏捷的。团队将其过程称作什么并不重要。

以下仆人式领导的特征让项目领导变得更加敏捷，促进团队的成功:提升自我意识

• 倾听;
• 为团队服务;
• 帮助他人成长:
• 引导与控制;
• 促进安全、尊重与信任;以及
• 促进他人精力和才智提升。

项目经理的价值不在于他们的岗位，而在于他们能够让每个人都变得更好。

团队构成

《敏捷宣言》的价值观和原则的一个核心宗旨是强调个人和交互的重要性。敏捷优化了价值流， 强调了向客户快速交付功能，而不是怎样“用”人。

以下好处是显而易见的：

• 人员更有可能合作。
• 团队更快地完成有价值的工作。
• 由于不从事多任务，也不必重新建立环境，团队减少了时间浪费。

敏捷团队

敏捷团队注重快速开发产品，以便能获得反馈。

在实践中，最有效的敏捷团队往往由三到九个成 员组成。

敏捷鼓励自我管理团队，由团队成员决定谁执行下一阶段定义的范围内的工作。

当团队成员合作打造全部功能 中的少量功能时，随着工作的推进和交付少量已完成的功能，他们也在不断学习。

敏捷团队中有三种常见的角色：

• 跨职能团队成员；

  跨职能团队包括具有生产可行产品所需的各种必要技能的团队成员

  跨职能团队通常包括设计人员、开发人员、测试人员等

• 产品负责人；

  产品负责人负责指导产品的开发方向。

• 以及团队促进者。

  也称为项目经理，Scrum 主管、项目团队领导、团队教练

在敏捷环境中交付

对于敏捷项目而言，团队至少还需要项目愿景或目标，以及一组清晰的工作协议。敏捷项目章程 要回答以下问题：

• 我们为什么要做这个项目？这是项目愿景。
• 谁会从中受益？如何受益？这可能是项目愿景和/或项目目标的一部分。
• 对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准。
• 我们将怎样合作？这说明预期的工作流。

回顾

在这些关键时刻进行回顾：

• 当团队完成一个发布或者加入一些功能时。这不一定是一个巨大的增量。它可以是任何发布， 无论它有多小。
• 自上次回顾以来，又过了几周时间。
• 当团队出现问题时，以及团队协作完成工作不顺畅时。
• 当团队达到任何其他里程碑时。

回顾并不是责备；回顾是让团队从以前的工作中学习并做出小的改进。

回顾针对定性的（人的感觉）和定量的（衡量指标）数据，然后利用这些数据找到根源，设计 对策，并制定行动计划。项目团队可以采取许多行动事项来消除障碍。

待办事项列表编制

工作开始之前，不需要为整个 项目创建所有的故事，只需要了解第一个发布的主要内容正确即可，然后就可以为下一个迭代开发 足够的项目。

产品负责人可能 会制作一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规 划路线图。

待办事项列表的细化

产品负责人往往在迭代中期的一次或多次会议中与团队合作，为即将进行 的迭代准备一些故事。这些会议的目的是细化足够的故事，让团队了解故事的内容，以及故事之间 的相互关系。

法处理待办事项列表的细化准备与会议，其中包括

• 鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作，一起讨论和 撰写故事。
• 把整个故事的概念呈现给团队。团队进行讨论，并根据需要将其细化为许多故事。
• 与团队一起寻找各种方法探索和撰写故事，确保所有的故事都足够小，以便团队能源源不断地 交付完成的工作。考虑每天至少完成一个故事。

每周用不超过 1 小时的时间来为下一批工作细化故事。团队希望把时 间尽可能花在工作上，而不是计划上。

每日站会

团队成员利用每日站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行。

不超出 15 分钟。团队以某种方式“过一下”看板或任务板，而团队中的 任何人都可以主持站会。

每个人都轮流回答下列问题：

• 上次站会以来我都完成了什么？
• 从现在到下一次站会，我计划完成什么？
• 我的障碍（或风险或问题）是什么？

从这样的问题得出的答案能够让团队自我组织，并让团队成员为完成之前和整个迭代中承诺完成 的工作承担彼此的责任。

要鼓励任何团队成员主持会议而不是由项目经理或领导主持，以确保它不会变成状态 报告会议，而是作为团队进行自我组织和相互承诺的会议。

展示/评审

式完成特定功能时，团队会定期展示工作产品。看过展示后，产品负责人 接受或拒绝故事。

指导方针是，每两周至少展示一次团队的工作产品。这种频率对于大多数团队来说是足够 的，这样，团队成员就可以得到反馈，防止他们朝着错误的方向前进。

使项目敏捷的一个基本要素是频繁地交付工作产品。

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

如果团队不重视质量，很快就会无法快速发布任何东西。

• 持续集成。
• 在不同层面测试。

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

迭代可以帮助团队为交付和多种反馈创建一个节奏。团队会为交付和反馈创建增量。

交付的第一 部分是一次演示。

团队会收到关于产品的外观和运行方式的反馈。团队成员回顾如何检查和调整有 关过程以取得成功。

演示或评审是敏捷项目流程的必要组成部分。为团队的交付节奏安排适当的演示。

参考

敏捷实践指南 - 国际标准书号 (ISBN)：978-1-62825-421-1