《《软件研发项目策划》PPT课件》由会员分享，可在线阅读，更多相关《《软件研发项目策划》PPT课件（30页珍藏版）》请在金锄头文库上搜索。
1、软件研发项目策划泥泥1需求以及可行性合适的菜谱调查客人的口味偏好、尝试新口味的意愿（习惯和亮点）客人差异情况（年龄、宗教、健康禁忌）合适的原料符合时令条件的安全、无毒副作用合适的规模数量：多少客人，吃饱？吃好？预算时间：吃多久引子：在家宴请客人Page:2需求以及可行性可行性如何掌厨的水平（技术可行性）时间是否来得及（时间资源）是否有条件准备适用的原料（资源可行性）是否有能力接待这么多客人（最大响应容量）可行性不满足怎么办改变策略，直接预定饭店（全部外包）客人指定要吃正宗西湖醋鱼，只好去楼外楼买现成的了（购买第三方组件）洗菜刷菜劳动附加值太低，时间来不及，全家也没人愿意做，超市买净菜（非核心工
2、作外包）有些原料不懂得怎么选购，委托隔壁马大嫂帮忙挑选（专家评审）引子：在家宴请客人Page:3主要任务分解原料准备生鲜、保质期（关键时间）是否脱销或涨价（市场变化）储存能力（储备）辅料准备设备准备是否有适配的锅碗瓢盆桌椅是否足够并且完好，小孩的座位怎么安排半成品存放空间是否足够应急照明燃具灶具（煤气瓶是不是快空了）引子：在家宴请客人Page:4主要任务分解原辅料处理洗涮、切块/片、榨汁预处理（焖/煮/熘/炸/冻、腌制、酿制）混合处理（拌/糊/包/堆砌/封装）品尝或目测（自测），纠偏（比如拌面，水多了放面，面多了放水）制作依据菜单落实生产【Feature By Feature】品尝（自测），纠
3、偏（汤太咸的话放包米一起煮）请家人品尝（测试），纠偏（重复以上）发布桌上堆者水果和零食呢，要先清空一下桌面【安装环境】上菜顺序很重要【安装步骤】空盘子不要留桌面上【卸载】引子：在家宴请客人Page:5需求以及可行性任务分解和执行计划和准备制作发布是否一切都好了Page:6自我评价和客人评价不好意思，大家先多喝点酒水饮料（一个没注意饭烧焦了，重新来过）【没有定时跟踪】好菜都是有点辣啊（贵客因病不能吃辣的）【需求变更没有及时跟踪】这个又稍微偏咸（装盐的勺子不小心掉火上了，只好拿手抓，过量了）【缺少度量】，吃到死螺蛳了（晕，手忙脚乱，实在没时间再检查一遍了）【缺少单元测试】这个是鱼翅还是凉皮啊（买这
4、个的时候，马大嫂没空，就凭着网上看来的攻略自己去挑了）【关键输出，专家评审缺失】小宝宝大闹饭桌了，死活哄不好，扫兴（饭前玩具被其它小孩抢走了）【风险跟踪管理】引子：在家宴请客人Page:7早知道问候一下重要客人的身体情况，临时的食物禁忌更应该关注。（关键客户保持密切联系）昂贵的菜一定要找懂行的人帮忙挑选和加工（关键工件专家评审不可或缺）准备一些有趣的玩具哄小孩用（有些客户经常有出格的需求，不关注也会导致大的风险，这些客户需要教育和引导）为什么还会有这么多情况？Page:8家宴显性的计划采购计划拿方抓药生产计划菜单生产（Feature By Feature）每步骤测试（随时品尝）上桌是否只有这些
5、？隐含在大脑中的计划采购计划采购时间预处理计划可复用的半成品统一加工保存关键资源统筹燃具灶具数量有限，需要支持并行排程，防止资源使用冲突所有资源冗余备份引子：在家宴请客人Page:9隐含在大脑中的计划优点：高速运转、随时调用、机动性强缺陷：不确定、随机、无规则项目策划把大脑中的计划展示出来分解任务平衡资源管理风险安排进度Buffer主题什么是项目策划Page:10了解并接受需求确保项目成员了解并能够在此基础上进行设计 尽可能避免口头确认；不要想当然的理解；需求说明应该有必须的信息 你认为不能完全理解的要请产品经理充实稳定；把你知道的写成技术工件；并邀请产品经理参加对他们的评审，确保产品经理认可
6、这些技术文档。主题了解需求Page:11理解需求的不确定性需求的不确定性在项目开始时，并非所有的需求都会很明确在项目过程中，也会有新的需求插入即使在项目开始后已经确定的需求也会发生返工或出现不符合产品目标或偏离客户需求的情况对策在项目开始时尽可能理解已有需求兼顾进度、成本和效率细分大需求主题了解需求Page:12确定阶段目标阶段目标参考目标客户的期待产品市场策略客户需求分批交付有效的项目管理周期资源投入状况平衡各角色工作细化各阶段目标确定每个阶段的关键任务确定每个需求完成的时间和日期必要的集成或封装活动主题阶段定义好比往一个容器中放细好比往一个容器中放细砂石和大石头，总是先砂石和大石头，总是先
7、放大石头，再倒入细砂放大石头，再倒入细砂石更容易点。石更容易点。Page:13Feature List将较长的开发周期分解为若干迭代确定每个迭代完成哪些Feature；每个迭代都有其核心Feature同一迭代的Feature建议确定优先级，便于项目成员自我管理；也便于评估每一次Delivery是否满足基本目标 集成、封装等必须投入的活动建议做为Feature主题设置迭代周期Page:14Work Breakdown Structure 分解工作任务 对于软件项目来说，分解工作任务不是一项单纯的计划活动，而是要根据项目的特点决定工作任务的分解结构。实际工作中更多地会考虑技术因素来确定工作分解结构
8、的形式。定义活动依赖关系 活动之间的依赖关系取决于实际工作的要求 不同活动之间的依赖关系决定了活动的优先顺序及其重要性 活动依赖关系是确定项目关键路径和活动浮动时间的必要条件 目的是确定每一项活动所需的输入、输出关系分配时间和资源 通常活动都会产生自己的交付物 在软件项目计划中，资源分配主要指人员的分配，指定了时间资源以后，应该指定人力资源。如果已经确定了活动的完成时间，则指定相应的人员作为完成活动的责任人。主题WBSPage:15关键路径法是时间管理中很实用的一种方法，其工作原理是：为每个最小任务单位计算工期、定义最早开始和结束日期、最迟开始和结束日期、按照活动的关系形成顺序的网络逻辑图，找
9、出必须的最长的路径，即为关键路径。时间压缩是指针对关键路径进行优化，结合成本因素、资源因素、工作时间因素、活动的可行进度因素对整个计划进行调整，直到关键路径所用的时间不能再压缩为止，得到最佳时间进度计划。主题关键路径关键路径的时间压缩是有限度的，关键路径的时间压缩是有限度的，一旦压缩后，会产生新的关键路径一旦压缩后，会产生新的关键路径Page:16参考历史经验数据确定各种研发资源投入比例 确定预计投入的管理时间量 管理工作分类 确定预计需评审的文档量和代码量 注意项目可以分配的资源 时间上的限制必要的剪裁，但必须保证关键作业 慎重对待团队活动，比如评审、会议、培训人力资源 减少同类活动的切换
10、形成良好工作习惯主题工作量分解Page:17代码行估计对源代码行数的统计是对软件产品的一种直接的度量估计代码行数通常需要对待开发软件的类型有一定经验，有可用的历史数据，和代码行数的一个标准定义。代码行估计通常用不包括注释的代码行（SLOC）或千代码行（KSLOC）来计算。这些代码可能是新开发的代码，也可能是修改已有的代码，两者的规模估计同等重要。功能点估计功能点估计是一种面向功能的软件度量，是使用软件所提供的功能的度量作为规范化值基于外部应用接口和内部应用复杂性的主观判断以及全局性能特点的综合考虑 功能点从用户的角度体现了一个应用的大小。它通过对主要的外部数据录入，输出，和文件类型等相关的信息
11、处理功能的数量来度量软件应用。功能点分析是一种具有清晰商业意义的度量方法。它量化了软件中包括的对软件使用者有意义的功能。这种度量直接与软件的商业需求有关主题软件规模估计（简介）Page:18Delphi法介绍最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。但专家“专”的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多 这种方式对决定其它模型的输入时特别有用 Delphi法鼓励参加者就问题相互讨论 这个技术，要求有多种软件相关经验人的参与。主题软件规模估计（简介）
12、Page:19人力资源关于标准评估的关注点每个Feature消耗的资源单位（人天）目标是保质保量完成应该包含计划在开发自测、修改缺陷所投入的集成、封装等独立活动依据项目需要可以独立设置Feature在每个迭代设置一定的冗余时间，而不要在每个Feature上设置冗余评估人天时避免将分配到任务的工程师对号入座主题估计资源Page:20如何设置项目Buffer错误的理解每Feature？每周？每阶段？正确的思路Buffer的目的：对不可控的工作加强控制为高风险的任务设置Buffer进度控制风险技术评估风险外部风险（设备、客户）有效的设置具体任务（关键技术试验、集成/封装、回归测试）具体目标（确认技术
13、方案、性能优化目标）具体责任人（方案确定、方案评估、编码实现）主题BufferPage:21关于任务分配高技能等级意味着更强的技术处理能力更高的工作输出质量技能等级高的工程师必然占用更少的工时来完成任务注意人月神话用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话 主题资源分配Page:22“如果你不主动地攻击风险，风险将主动地攻击你”风险评估列出风险源，分优先级排序评估性能/成本/支持/进度风险变成现实的可能性或概率当风险变成现实时所造成的后果。风险管理包括风险标识/风险分析/风险计划/风险跟踪和风险控制将一个大风险分解为多个风险来排除。主题风险管理Page:23休息时间5分钟分钟Pag
14、e:24如果你想要理直气壮地向自己的客户推销一个新款的软件，唯一的方法便是在它初次发布前，就先在自己公司的内部广泛地进行试用。由于对Exchange、Office和Vista产品进行“吃狗食”检测带来了显著的效果，微软公司开始着手推广名为“724促进”的活动。微软声称，只要它的员工能够使用这些软件产品24个月，就能够为公司节省700万小时的生产时间。Eating its own dog foodMicrosoftPage:25指望计划不变更是不切实际的大部分的失败者不能坚持为失败的计划创建新计划关于计划变更Page:26了解需求，以及需求交付目标WBS分解分析关键路径估计工作量风险评估估计规模
15、估计资源回顾一下Page:27问题1：从需求到Feature ListFeature来源Feature是否仅来自SPEC？不合适的Feature ListSPEC的节选？或者大纲？仅仅是功能点是否够用？科学的Feature List颗粒度合理、均匀按照迭代顺序排序包含必要的工程活动能够体现依赖关系和关键路径和WBS相合主题面对实际情况Page:28问题2：从Feature到人*天人天估计对象是否仅仅是预计工作时间？不合适的人*天评估目标理解不一致（A认为有三个子功能，要两天，B认为有二个子功能，要三天，评估结果是天，由C来实现）过大或过小的估计（过小的建议合并，过大的建议分解）科学的工时估算估
16、计范围明确（检查、交付方式（试验、评审、走查）大小合适避免资源冲突主题面对实际情况Page:29问题3：从人*天到schedule关于里程碑仅仅、RC是否足够？不合适的schdeule里程碑分配不均每次计划下一个delivery过于乐观（预期投入人天总值大于或等于项目投入人天）过于悲观（到处留有冗余时间，或投入人天远大于MD总值）科学的Schedule明确每个任务项成果正确区别Delivery递交和项目执行过程中递交流程注意项目中可能存在的技术风险或难点不同技能等级的工程师折算MD系数不同，须看得到差异注意关键资源是否存在冲突结合关键Delivery和、RC形成完整的Schedule主题面对实际情况Page:30
