规划项目

规划项目

• 规划和日常安排

  • 两种不同的活动&＃xff0c;规划是制定带有发布条件的项目计划&＃xff1b;日常安排是对工作项目的有序描述

• 开始规划

  • 有了章程就可以对接下来要做什么做些有明确方向的预先规划&＃xff0c;
  • 可以和项目团队成员一起完成项目规划&＃xff1a;未来几天&＃xff0c;几周要做什么&＃xff1b;或者开始原型化工作&＃xff0c;或开始第一个迭代&＃xff1b;敏捷开发过程不妨将项目规划看作发布计划

• 使项目足以启动的规划

  • 无需完美&＃xff0c;只要让项目启动起来&＃xff1b;完美会花费太多时间且不稳定
  • 用时间盒来限制启动规划活动
    • 时间盒&＃xff1a;特定的时间长度&＃xff0c;个人或 团队用它来完成某项特定的任务
  • 要根据经验而不是预言来规划项目&＃xff1a;不妨先做少量规划&＃xff0c;再根据实际过程中收集到的信息反馈来修改未来的规划

• 规划的模板&＃xff08;包括&＃xff09;

  • 产品意图&＃xff1a;如果项目的愿景可能不够用&＃xff0c;确保当前项目的意图清晰无误&＃xff0c;和远景大方向一致&＃xff0c;但不完全相同。
  • 历史记录
    • 如管理某产品的后续版本&＃xff0c;复查之前或相关版本的历史记录&＃xff0c;可说明之前任何已知的技术债&＃xff0c;复查数据包括&＃xff1a;发布频率&＃xff0c;发布后发现的缺陷数&＃xff0c;客户报告的问题&＃xff0c;以及会影响项目经理对质量的定义&＃xff0c;对项目管理方式的任何内容
    • 对复查的内容进行分析&＃xff0c;了解技术债的严重程度和类型&＃xff0c;或者文档有问题还是代码问题
  • 发布条件
    • 详细列举出项目产品的关键可交付物&＃xff0c;要将功能&＃xff0c;性能和质量要求都涵盖在内
  • 目标&＃xff0c; 分类如下
    • 产品目标&＃xff1a;产品代办列表&＃xff0c;设好优先级的
    • 项目目标&＃xff1a;包括性能标准之类&＃xff0c;或者使缺陷数目的减少&＃xff0c;或解决特定的技术债务
    • 团队目标&＃xff1a; 自动化测试所占比例等
    • 组织目标&＃xff1a;减少项目耗时&＃xff0c;提升组织敏捷性等
  • 项目组织
    • 团队在项目中的职责分配要明确&＃xff0c;具体细节取决于项目所采用的生命周期模型和团队结构
    • 是否任命产品负责人&＃xff0c;多人决策人时要区分责任的领域
  • 日程总览 (类似产品路线图&＃xff09;
    • 主要里程碑&＃xff0c;迭代结束后可以预期得到的产出
    • 确保理解项目的价值&＃xff0c;而不是只看到不同方案的成本
  • 人员配备&＃xff1a; 人员变动很正常&＃xff0c;需要调动人手需说明何时需要多少&＃xff0c;何种类型的人员
  • 建议日程
    • 列出主要的里程牌&＃xff0c;可用甘特图并保持更新
    • 无需过早细化日程
  • 制定项目风险列表
    • 10大风险列表&＃xff0c;尽快识别和管理风险&＃xff1a;风险描述&＃xff0c;发生概率&＃xff0c;严重程度&＃xff0c;暴露程度&＃xff08;发生概率*严重程度&＃xff09;&＃xff0c;反应时间&＃xff0c;应对计划

• 制定发布条件

  • 制定发布条件不是为了责怪哪个组&＃xff0c;而是要为产品是否可以发布提供一些客观的评判标准。出资人和客户可以用发布条件做出合理的决策&＃xff0c;对产品的质量和风险做出判断。
  • 制定和使用发布条件的步骤&＃xff1a;

    • 确定当前发布最重要的因素&＃xff0c;可以将监控发布条件的活动贯穿项目始终

      • 项目的关键因素是由组织需要和客户需要共同组成
      • 考虑要为客户解决什么问题而不是仅仅包括缺陷相关的内容
      • 通常来说&＃xff0c;日程安排&＃xff08;发布日期&＃xff09;&＃xff0c;功能特性和低缺陷率共同构成了项目的关键因素
      • 需从大局出发&＃xff0c;应该知道何时发布软件

    • 草拟发布条件&＃xff1a;可以将整个产品的职责分工贯穿到产品发布之中

      • 草拟发布条件&＃xff0c;以它们为基础展开讨论
      • 制定条件时&＃xff0c;要在上市时间&＃xff0c;客户需求&＃xff0c;缺陷&＃xff0c;性能和可靠水平之间达成平衡。
      • 草案非承诺

    • 让发布条件符合SMART原则&＃xff1a;确定的&＃xff0c;可测量的&＃xff0c;可达成的&＃xff0c;相关的和可跟踪的

      • 确定的&＃xff1a;每个条件都是确定的
      • 可测量的&＃xff1a;可根据这个条件来评估软件
      • 可达成的&＃xff1a;不是延展性的目标&＃xff0c;是可达成的目标
      • 相关的&＃xff1a;符合客户和管理层的要求
      • 可跟踪的&＃xff1a;可在项目进行过程中评估条件的状态

    • 获得项目团队与高层领导人员认可

      • 达成多方共识&＃xff1a;是不是必须满足这个条件&＃xff0c;如果不能满足会怎样&＃xff0c;产品或公司会不会因此承担风险&＃xff0c; 人们安全感是不是会破坏
      • 整个团队草拟并团队会议来讨论发布条件&＃xff0c;和各个只能经理一起草拟。

• 使用发布条件

  • 只有满足和未满组两种状态。 部分满足就是没满足
  • 团队会议时&＃xff0c;跟团队一起讨论距离满足发布条件还有多久
  • 发布条件可以作为早期预警信号&＃xff0c;察觉无法准时完成的因素

• 在必要时变更发布条件

  • 变更的情况&＃xff1a; 进一步了解项目中完成的含义&＃xff1b;认识到无法在预定发布日期前满足所有发布条件
  • 无法满足发布条件&＃xff1a;跟团队确认为什么无法满足&＃xff1b;向管理层解释无法满足条件的愿意

总结&＃xff1a; 项目规划是不断进行的&＃xff0c;这只是开始&＃xff1b;为项目团队&＃xff0c;出资人和项目经理自己制定发布条件&＃xff0c;以明确完成的含义&＃xff1b; 项目规划不必完美但必须存在