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