使用生命周期组织项目

使用生命周期组织项目

• 理解项目生命周期

  • 生命周期是项目经理和团队组织产品开发的方式。定义需求，设计，开发，测试以及与这些工作同时进行的过程，都是生命周期的一部分
  • 整体上组织项目，不要把现实状况理想化。 比如不要在规划时就希望先产生完整的需求。讲求实效性，选择的生命周期要有助于识别项目风险，帮助项目经理交付成功的产品
  • 考虑某种生命周期是否实用，不能只考虑内部项目风险。客户和他们的期望也是风险的一部分
  • 选的生命周期要很好地应对风险：能否及时发布，缺陷，特性，成本等

• 生命周期概览

  • 四种类型的生命周期：顺序式，迭代式，增量式，迭代/增量式（敏捷）
    • 顺序式：需求收集->分析->设计->编码->集成->测试
    • 迭代式：需求收集->原型阶段: 分析,设计,编码->原型阶段: 分析,设计,编码->…->集成->测试
    • 增量式：部分需求收集->分析选择整体框架 -> 设计，编码，集成和测试（n个循环)-> 最终集成-> 最终测试
    • 敏捷：部分需求收集和规划游戏->时间盒->时间盒（n个循环）
  • 项目经理可以根据项目的风险情况，整合其他生命周期管理方式

• 在项目中寻求反馈

  • 缺少反馈，式顺序式生命周期被称为"预测式"生命周期的原因，缺少足够数据，无法检查现有的工作能否作为未来的基础
  • 敏捷项目边写代码边测试，每天每个迭代都有反馈 ，是成功的根本原因

• 大规模项目需要组合使用多种生命周期：

  • 关键是：要定义出各个阶段交付物的模样，以及何时完成

• 包含硬件的项目

  • 硬件的问题不同于软件通过更新可以修复，选择更窄
  • 成功的软硬件相结合的项目需要组合使用多种生命周期

• 管理架构风险

  • 架构风险：指团队选择的架构能否满足当前项目的要求，没有哪种生命周期可以完全应对产品架构的风险
  • 在架构代码开发并集成完之前，无法断言设计的架构能否正常发挥作用
  • 早些发现架构风险的方法：
    • 对于接近完成的原型，尽早在项目中对其展开迭代，包括对这些原型进行测试
    • 尽早实现几个可以考验架构承受能力的功能
    • 用时间盒来限制整个架构相关的工作，让架构师和开发人员发出至少三种不同架构的选择，还要告诉项目经理每种架构的长处和风险所在
  • 要想完全 掌控架构风险，只有基于它实现某些功能并进行测试
  • 完整的完成一些功能的原型化设计，可以有助于判断能否放心在项目中使用这个架构
  • 要随时注意架构能否满足项目要求，发现越早风险越小。不能及时察觉可能功败垂成。

• 从瀑布中摆脱出来

  • 方法：
    • 迭代来规划所有工作，包括规划，需求收集和原型化等
    • 将产品原型化，并尽早向客户或代理人展示
    • 项目从一开始就加入测试工作
    • 功能逐个实现，完成后随即做集成和测试
    • 文档不是唯一的可交付物，可工作的软件才是重要的可交付物

• 推荐的生命周期

  • 敏捷生命周期， 退而求其次为阶段式交付

总结： 任何生命周期或是多种组合都可以让项目成功； 完美的生命周期是模型，真实创建实际情况的生命周期； 瀑布式如非确认可获得成功时，不推荐使用。