为什么要用敏捷？如今，项目管理的步伐越来越快。项目管理需要更灵活、更积极地，响应客户的需求。使用敏捷项目管理方法，项目经理可以在不影响价值、质量和商业规则的前提下实现所有目。
1.项目管理的目标与策略
1.1 目标
主要目标：在预算和时间范围内交付符合客户需要的高质量的软件产品
其他目标：提高团队成员能力获得度量数据以改进流程和提供可预测性
1.2 策略
项目成功的关键：
- 准确的需求分析——功能
- 优雅的设计，简洁的编码——质量
- 全面的测试，自动化构建和持续集成——可靠性
- 透明、可控、可持续、可预测的⽣产过程——项目管理
1.2.1 需求分析 —功能
将需求转化成功能：用例（ RUP），用户故事（敏捷）。
1.2.2 领域建模 —理解业务领域
如何实现领域建模：
- 发现业务领域中的本质抽象和共同机制
- 发现领域概念的类型层次结构和组成层次结构
- 实现业务逻辑和业务规则。
1.2.3 设计与编码 —质量
如何保证代码质量：
- 设计要优雅，编码要简洁
- 领域驱动设计
- OO原则、设计模式、重构
- 简单性、一致性、灵活性、扩展性的对立统一
1.2.4 TDD
测试先行、自动化构建与持续集成保证项目的可靠性。
- 测试先行，测试用例要做到全面测试
- 自动化构建，自动化构建工具要做到自动测试
- 持续集成，持续集成工具要做到频繁测试
测试先行：
- 测试先行为产品代码提供实现目标和验收标准
- 测试先行保证有一套全面的测试集伴随产品代码终身
- 测试先行保证系统在各种异常条件下的表现符合预期测
- 试先行保证修改和重构产品代码不会破坏现有功能
- 测试先行为程序员提供信心、勇气和成就感
工具： Concordion,JUnit, Mockito, DBUnit, Fitnesse, Selenium, jsUnit，这些工具可以帮助我们做到测试驱动开发。
1.2.5自动化构建
- 自动化构建减轻重复性的机械劳动
- 自动化构建保证测试100%执行
- 自动化构建可以自动编译、打包、部署和验收测试
- 自动化构建保证构建的过程和结果可重复
-
自动化构建可方便切换操作系统、中间件和数据库
工具： Maven, Ant, Gradle，这些工具可以帮我们做自动化构建。
1.2.6 持续集成
- 持续集成保证频繁运行全套测试
- 持续集成可以在任何时间交付可靠可靠产品
- 持续集成在构建失败时及时通知正确的人
工具： Jenkins, Hudson, Continuum，这些工具可以帮我们做到持续集成。
1.2.7 质量度量和设计评审
| 开发人员的七宗罪 | 设计评审 |
| 复杂性 | 是否实现了预期功能 |
| 重复 | 是否适合整体架构 |
| 缺乏单元测试 | 是否安全、可靠、高效 |
| 不符合编码规范 | 是否足够简单、清晰、可读 |
| 注释不足或太多 | 是否易于扩展 |
| 潜在的Bug | 是否测试了各种边界条件 |
| 意大利面条式设计 | 能否提炼通用概念和逻辑 |
工具： Sonar可以帮我们做代码评审，管理代码质量。
2 敏捷项目管理
2.1 敏捷宣言
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
-
响应变化 胜过 遵循计划
虽然右项也有价值，但我们认为左项更有价值。
2.2 项目的敏捷开发方法
- 敏捷团队作为一个整体工作，团队所有成员对项目拥有共同责任.
- 按短迭代周期工作，固定四周一个迭代，绝不延长.
- 每次迭代交付一些成果，每次迭代实现一批用户故事，交付客户使用.
- 关注业务优先级的功能，优先实现具有高业务价值的用户故事.
- 进行检查和调整，每次迭代根据上次迭代获得的新知识进行调整.
2.3 估计故事规模
- 用故事点估计用户故事的规模
- 以某个众所周知的功能做参照系
- 用波多那契数列1,2,3,5,8,13表示故事点超出13点的故事要拆分为多个更小的故事
估计方法：规划扑克由开发团队估计故事规模，客户代表不干涉。
2.4 排定故事优先级
根据业务价值和风险设定用户故事优先级：
- 高价值高风险
- 高价值低风险
- 低价值低风险
- 低价值高风险
由客户代表或产品经理负责排定优先级
2.5 进度安排
2.5.1 发布规划
1.确定满意条件 2.估计用户故事规模 3.选择迭代周期长度 4.估计速度 5.确定用户故事优先级 6.选择用户故事和发布周期2.5.2 迭代规划
1.调整优先级 2.确定目标速度 3.确定迭代目标 4.选择用户故事 5.把用户故事分解为任务 6.对任务进行估计 2.5.3 每日例会
1.每天固定的时间进行 2.限时15分钟左右 3.每个人站立进行每个人回答三个问题:1.昨天做了什么？ 2.今天打算做什么？ 3.存在什么问题？ 2.6 跟踪与交流
2.6.1 看板
2.6.2 图表与度量
- 速度图——每个迭代完成的故事点
- 迭代燃尽图——迭代中每天剩余的故事点
- 发布燃尽图——发布中每个迭代剩余的故事点
- 故事/Bug比例
- 开发人员生产力
从下图可以看出每周实现的用户故事
2.6.3 展示成果
- 每天向团队展示已完成的成果
- 确保每个人理解每个功能的实现
- 纠正偏差，提供改进意见
- 防止“各人自扫门前雪”
- 让个人成果变成团队资产
以上是之前培训的一些东西，整理一下分享给大家。
来源：oschina
链接：https://my.oschina.net/u/1162040/blog/791566