敏捷项目管理

为何要用敏捷?现在,项目管理的步伐愈来愈快。项目管理须要更灵活、更积极地,响应客户的需求。使用敏捷项目管理方法,项目经理能够在不影响价值、质量和商业规则的前提下实现全部目。程序员

1.项目管理的目标与策略

1.1 目标数据库

主要目标:在预算和时间范围内交付符合客户须要的高质量的软件产品设计模式

其余目标:提升团队成员能力得到度量数据以改进流程和提供可预测性安全

1.2 策略架构

项目成功的关键:工具

  • 准确的需求分析——功能
  • 优雅的设计,简洁的编码——质量
  • 全面的测试,自动化构建和持续集成——可靠性
  • 透明、可控、可持续、可预测的⽣产过程——项目管理

1.2.1 需求分析 —功能单元测试

将需求转化成功能:用例( RUP),用户故事(敏捷)。测试

1.2.2 领域建模 —理解业务领域编码

如何实现领域建模:spa

  • 发现业务领域中的本质抽象和共同机制
  • 发现领域概念的类型层次结构和组成层次结构
  • 实现业务逻辑和业务规则。

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 展现成果

  • 天天向团队展现已完成的成果
  • 确保每一个人理解每一个功能的实现
  • 纠正误差,提供改进意见
  • 防止“各人自扫门前雪”
  • 让我的成果变成团队资产

以上是以前培训的一些东西,整理一下分享给你们。

相关文章
相关标签/搜索