1）“个体和互动”更优于“流程和工具” ；
2）“工作的软件”更优于“详尽的文档” ；
3）“客户合作”更优于“合同谈判” ；
4）“相应变化”更优于“遵循计划” 。

1）通过尽早和持续地交付有价值的软件来满足客户。
2）欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3）要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4）项目过程中，业务人员与开发人员必须在一起工作。
5）要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6）无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7）可用的软件是衡量进度的主要指标。
8）敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9）对技术的精益求精以及对设计的不断完善将提升敏捷性。
10）要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11）最佳的架构、需求和设计出自于自组织的团队。
12）团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

SCRUM 的团队角色

产品负责人（Product Owner）负责的事情主要是：
1）提供远景；
2）提供边界；
3）提供用户故事的优先级。

Scrum Master [SCRUM 教练、敏捷教练]

1）没有行政权力。例如：你不能决定项目团队某成员薪金或奖金，你无权说：你
被解雇了。
2）你要忍住帮团队做决定的冲动，让团队学会自我成长。
3）不建议你同时兼任产品负责人。产品负责人需要做不少重要的决定，这其实与
Scrum Master 角色冲突，一个人同时做两种角色的事情，容易搞混了角色，当然你是超
人能分得很清楚的话例外。

开发团队

开发团队如果没有项目经理这样的角色来协调和指挥，很可能会成为“乌合之众” ，无法谈得上敏捷。

敏捷最佳实践

需求方面最佳实践：
1）User Story（客户故事）
2）客户全程参与
设计方面的最佳实践：
3）简单设计
测试方面最佳实践：
4）测试驱动开发（TDD）
5）自动化测试
编码方面最佳实践：
6）重构
7）结对编程
8）代码共有
9）强调编码规范
10）持续集成（每日构建）
项目管理方面最佳实践：
11）Sprint（冲刺） 、小版本发布
12）每日站立会议、每日晨会
13）每周工作 40 小时
14）Burn Down Chart（燃尽图）
15）Lesson Learned
16）隐喻 <体验极限编程>

中国软件项目的一个大特点，就是“两大限死，两不确定” ！

限死 1：预算限死。
限死 2：工期限死。
不确定 1：需求不确定.
不确定 2：技术不确定.

*.IT项目求生法则
挨踢项目求生法则

敏捷不能当饭吃

机构设置

组织机构设置

组成项目部

矩阵式管理

弱矩阵：各人以部门职责为主，各人做好自己的事情就可以了，各人主要对部门经理
负责。

强矩阵：各人以项目利益为主，不仅仅完成本岗位的工作，还需要跨职能地工作， 只
要对项目成功有意义的事情，都鼓励项目组成员去完成，各人对项目成败直接负责。

弱矩阵：
1）流水线生产，适用于稳定的项目或产品。
2）每个人完成自己的工作职责，对岗位负责。
强矩阵：
1）适用于高难度、高挑战的项目或产品。
2）每个人都对项目成败负责。
3）每个人除了完成本职工作，还需要跨职能地工作。

敏捷对团队文化是有要求的，就是：我们要在一条船上！

敏捷更多是一种精神层面上的要求， 是一种精神文明， 但精神文明是建立在一定物质
文明的基础上的。 员工得不到尊重， 员工的生活得不到保障， 温饱不解决， 你跟我谈敏捷，
就是扯淡！

敏捷是精神文明

保证物质文明

敏捷的核心基础：我们在一条船上！包括：

1）项目组所有人在一条船上。
2）员工和公司在一条船上。

敏捷的几个重要特征：

1）所有人对项目成功负责。
2）所有人直接需求驱动地工作。
3）所有人都需要跨领域地工作。
4）持续交付、迭代前进。