《软件开发项目沙盘计划模板》由会员分享，可在线阅读，更多相关《软件开发项目沙盘计划模板（9页珍藏版）》请在金锄头文库上搜索。
1、XXXXXX版本沙盘计划版本沙盘计划 第2页，共9页 目录 1文档说明文档说明.4 2项目的目标分析项目的目标分析.4 2.1项目愿景 .4 2.2客户亮点设计 .4 2.3干系人期望 .4 2.4所有要素汇总 .5 2.5生命周期模型选择 （项目计划里也有此部分，只做一处）.5 2.6项目质量路径定义 .6 3项目总体工作思路项目总体工作思路.7 3.1完成项目目标的因果分析 .7 3.2上述关键因素的提升计划 .7 3.3敏捷项目产出文档说明 .8 3.4企业文化落实计划 .8 3.5行动计划汇总及市场预期达成计划 .8 4团队个性展示团队个性展示(可选。可选。4个月以上跨度项目强烈推荐做
2、个月以上跨度项目强烈推荐做) .9 5自定义改进计划自定义改进计划(可选可选) .9 6复盘分析及跟踪定义复盘分析及跟踪定义.9 1 文档说明文档说明 本文档意在加强项目前后端的衔接，将以前沙盘分析着重进度和质量、转换到重点关 注客户需求的准确性、项目为客户带来哪些价值。将“按时发布版本”向“发布卖的 出去的版本”靠近。 本文档开发和测试要作为一个团队共同完成，要整个项目组目标一致。 2 项目的目标分析项目的目标分析 项目成功要素除来自于上面客户的关注点之外，还应该来自关系人的期望（比如公司高层的长远 发展规划等）、及来自后端的产品运维。 上面分析清楚之后，才开始进入项目的具体事务分析。这里并
3、不是要弱化项目的进度和质量的重 要性，而是要指出项目本身的进度和质量等指标应该是以上面大的要素为前提。 2.1 项目愿景项目愿景 2.2 客户亮点设计客户亮点设计 分类价值点设计如何做？ 客户亮点设计此版本而言，在 哪个功能、哪个客户价值链环节给客户带去 惊喜 客户的痛点认为针对此版本功能而言，客户存在的主要 痛点 如何改进 2.3 干系人期望干系人期望 此节内容分析所有和项目相关的干系人的期望，需要在规划评审之后使用邮件或者电话获取。干 系人可以没有期望，但是不可以不收集。对干系人的期望可以在这里进行分析也可以在下章分 析，但是最终必须记录到行动计划汇总里。 每个干系人一个表格进行分析 干系
4、人 期望内容 期望分析 行动方案 干系人 期望内容 第4页，共9页 期望分析 行动方案 1. 干系人 期望内容 期望分析 行动方案 干系人 期望内容 期望分析 行动方案 干系人 期望内容 期望分析 行动方案 2.4 所有要素汇总所有要素汇总 本章所有的目标汇总起来，方便后续跟踪。 目标及期望期望来源优先级 2.5 生命周期模型生命周期模型选择选择 （项目计划里也有此部分，只做一处）（项目计划里也有此部分，只做一处） 生命周期选型的基本原则：生命周期选型的基本原则： 1.精品化打造伟大产品，核心模块和主要场景高质量/高价值 2.新机会点，加快版本发布速度，快速迭代 瀑布模型：瀑布模型：优点，模型
5、简单易于控制。缺点，对于大型版本每个阶段内工作太多难于 监控。 敏捷模型：敏捷模型：优点，对需求的变化可以快速响应。缺点，无明显的里程碑控制造成项目 整体质量风险，并且需求快速变化造成测试资源的浪费。 产品线快速模型：产品线快速模型：在瀑布、敏捷两种模型的情况下，针对全新产品的“产品线快速模 型，此模型的流程和SQA沟通，在瀑布、敏捷两种模型之间，依据两种模型的做法， 定制针对全新产品的另外一种快速模型，便于快速验证。 前提选型原则本项目应该选择？ 需求确定的情况下1.如果模块间耦合不是很大，并且有明显的先后 顺序。可选择敏捷模型 2.如果模块间耦合度高，但是有明确的优先级依 赖。也可选择敏捷
6、模型 第5页，共9页 3.其它情况，推荐使用瀑布模型 在需求不确定的情况 下 推荐使用敏捷模型，全新产品也可以选择产品 线快速模型 在开发资源比较少的 情况下（测试资源在 评审会上现场讨论） 1.如果模块间耦合度小，且质量风险不大的情况 下。可选择敏捷模型 2.有客户急需的功能，等不到版本发布，可分出 一个build先完成急需功能给客户测试 3.预研完成，且需求较少如少于1个月周期，需 要快速推出，选敏捷模型 4.其它情况，推荐使用瀑布模型 本项目最终选择的模型本项目最终选择的模型 选择模型后的注意事项（如和“前期测试流程”里的规定有 冲突时，则以流程为准。） 简短说明如何落实的 迭代、瀑布模
7、型都需要有明确的项目计划和里程碑（都要 进行转集成评审） 迭代、瀑布模型的里程碑？ 迭代模型需要测试前期计划配合，需要在每个迭代开发完 成前要设计完成测试用例，并有资源投入进行测试 迭代模型，用例和测试的保证？ 生命周期模型的选择要慎重，需要先和开发经理确认后， 并体现在项目计划中邀请RDM进行评审 是否和RDM评审了？ 其它模型如果想探索，可以根据实际情况，通过开发经 理、RDM审核后选择 如果有探索的想法？ 瀑布模型 2.6 项目质量路径定义项目质量路径定义 通过产品、项目特点，定义出质量和进度方面的主要策略. 实际上就是明确出什么情况下质量最重要 ，什么情况下进度最重要 项目分类问题是/
8、否如果答案“是”，推荐做法说明 是否全新产品？否建议严格评审架构，做好设计，考虑可测试性； 架构师必须参与技术评审和指导 是否有明确的目标客户？是建议对目标客户做研发调研，并让其参与进研发 是否需要拿到市场上去试水？否建议做好基本场景，适当牺牲质量，再快速试 错，所以进度上要求比较高 是否很明确客户需求，及知晓明确的客户痛点？是建议围绕明确的客户场景做需求、实现和交付 是否需要定义测试接口方便后续自动化测试？是选是的，一般针对新产品、需求比较确定的版本 目标客户对稳定性、可靠性非常关注？是必须做好稳定性、可靠性方面的兜底机制，严格 评设计 市场是否有确定的客户等着在某个时间用此版本？是进度方面
9、需要明确要求 新人很多？是建议用培训、代码走读等方式来关注他们的质量 是否对海外发布？是海外不能发出试水的版本，要达到海外客户的质 量标准 产品先自己定义的问题？. 第6页，共9页 5Why.doc 项目质量和进度总策略 质量总策略？1.借鉴历史版本的缺陷预防经验，加强前期质量控制。 2.沿用可靠性、稳定性测试发布指标，可靠性连续两周无A类问题，稳定性环境持续稳定运 行两周，控制发布质量。 进度总策略？按计划达成各里程碑时间点，偏差在2周以内 3 项目总体工作思路项目总体工作思路 3.1 完成项目目标的因果分析完成项目目标的因果分析 上面的每个目标都需要分析关键要素，也就是找到达成此目标的关键
10、因子。如： 1. 所有重要风险都能提前发现，RDM 关键因子：一、风险识别率：需要重要的风险能够提前识别，降低风险的遗漏。二、风险处理方 法：发现的风险对高级别要有明确并有效的处理方法 2. 。 温馨提示：这里主要讨论的是完成项目目标的因因，而不是具体的行动。比如需要使用全新的技 术，此时人员技能就是关键因子，而培训和学习就是行动。本章节意在将因分析出来，下一章节 再讨论行动。因素分析推荐使用5why的方式得到根本的原因/措施（什么是5why? 右键文档对象 打开）。 鱼骨图，只要求这样做，不是要画到文档里，下同 3.2 上述关键因素的提升计划上述关键因素的提升计划 第7页，共9页 版本全局角
11、度的工作思路，这里需要对上述关键成功要素进行覆盖分析。如果一张图画不开，建 议分几类多画几根鱼骨头。在鱼骨图下方对具体的点进行展开分析。 和上一章节的区别在于本章节针对上面分析出来的因，给出提升这些因的方法和计划。 例如上一 章节分析到影响项目的关键因素是新员工技能，这一章节则讨论准备引入哪些行动来提高新人的 技能，包括培训、导师指定每日辅导、专门的代码审查等提升计划。 3.3 敏捷项目产出文档说明敏捷项目产出文档说明 在项目前期，不做针对产出文档的定义。会导致在项目过程中对于模块设计，或模块原理之类 的有价值的技术文档，会随着项目过程中紧张开发编码工作，逐步被大家遗忘。 后续版本在对这个模块
12、进行改进或优化时，这样做可以有该模块参考的文档。 下面逐一列出 文档名称1 文档名称n 3.4 企业文化落实计划企业文化落实计划 讨论如何落实企业文化，可以从五大企业文化总选择性找一些落实点在项目中展现。 第8页，共9页 3.5 行动计划汇总及市场预期达成计划行动计划汇总及市场预期达成计划 本章所有的产出汇总起来，放在下面列表里方便后续跟踪。下面的所有行动计划需要在项目管理 系统、PBL等中可查，避免项目中压遗漏这些工作。 对于风险明确的版本，开发经理同意的前提下，可以只写此章节和后面章节可以只写此章节和后面章节,关键在于前面的内容 做到位。 目标及期望（来自 2.4节） 关键因子（来自3.1
13、 节分析） 行动计划（来自3.2节分析）是否加入在 项目计划 中？ 风险识别率1. 每周周会都重新识别是否有新的风险是/否所有重要风险都能 提前发现风险处理方法1.所有高级别风险的处理方法需要经过产品线内专家评估通过 2.所有高级别风险每周跟踪处理进度 4 团队个性展示团队个性展示(可选。可选。4个月以上跨度项目强烈推荐做个月以上跨度项目强烈推荐做) 此章节可以写一些团队的内容。所有写到此章节的内容都必须获得项目组人员的认同，可作为共 同的目标。这些内容可以是团队的口号、团队的目标、图片展示等。 项目代号：建议考虑项目特点、研发难度、对公司的价值等。例如AC Everest、歼2014等 激励
14、和共勉口号：先紧后松不掉队，按时发布争优秀 如何庆祝：重大里程碑点，转集成、预发布时间点，开展表彰会议，吃喝玩乐搞 起。 鼓励和不鼓励的行为 见团队宪章 5 自定义改进计划自定义改进计划(可选可选) 自定义内容 6 复盘分析及跟踪定义复盘分析及跟踪定义 1)在每个里程碑进行，需要对上个阶段行动计划的效果进行总结，并重新对下个阶段的行动计 划进行检视。 至少在转集成/最后一次迭代、预发布阶段进行复盘 2)风险类的记录到风险管理表中跟踪 3)其它无法分类的，版本经理/SM定义日常跟踪方法 复盘里程碑复盘里程碑复盘日期复盘日期复盘分析结论复盘分析结论( (哪些因果分析、措施是有效和无效的哪些因果分析、措施是有效和无效的) ) 第9页，共9页
