需求与软件估算技术.ppt

估算的再修正 1991年对300多个项目的调查表明，项目几乎不能弥补损失的时间（Van Genuchten, 1991) 第一阶段估算不准确的原因一般会分布再整个项目中 * 估算的技巧 避免无准备的估算 不要随口说出一个估算 留出估算的时间，并做好计划 估算本身也是一个项目 开发人员参与估算 不要忽略普通任务 使用几种不同的估算技术，并比较它们的结果 估算的群体讨论 * 过于乐观的进度计划 Microsoft Word for Windows 1.0开发 包含249，000行代码，投入660人月，前后历时5年，实际花费时间为预期时间的5倍 * 过于乐观的进度计划 导致WinWord1.0开发延迟的几个主要因素： 项目初期制定的开发目标是不可实现的。盖茨下达的指示是用最快的速度开发最好的字处理软件，争取在12月内完成。实现这两个目标中的任何一个都是困难的，同时达到则是不可能的。 过紧的进度计划降低了计划的精确度。 开发过程中频繁换人。5年中共换了4个组长，其中有2人因进度压力离职，1人是出于健康的原因而离职。 迫于进度压力，开发人员匆忙写出一些低质量的和不完整的代码，然后宣称已实现某些性能。这造成了WinWord不得不将用于提高软件稳定性的时间由预计的3个月增加到12个月。 由于该项目中，创新比速度更重要，因而试图缩短开发周期，反而使周期变长 * 产生过于乐观的进度计划的根源 为了赶在某些特定时间前展示或出售产品。如计算机交易展示会。 管理人员和客户拒绝接受仅给出范围的估算，而是按照他们认为的“最佳”估算来制定进度计划。 项目管理人员和开发人员为了享受挑战的乐趣或在压力下工作的刺激，而故意缩短进度计划。 管理部门和市场部门为了迎合客户而缩短进度计划。 项目管理人员认为较紧的进度计划能够使员工勤奋工作。 原先的估计是合理的，但是在项目进行过程中又加进了很多新特性，从而变成了过于乐观的进度。 …… * 过于乐观的进度计划的后果 进度计划准确性 * 进度完成日期 按期完成概率 开发人员一般采用的较乐观的进度计划 典型的过分乐观的进度计划 过于乐观的进度计划的后果 计划的质量：错误的假设必将导致无效的项目规划。 抛弃计划：当面临进度压力时，大多数开发组织会抛弃原有规划，而走入盲目开发的歧途。 如果试图在关键阶段节省时间，必将在后续阶段加倍补偿。 分散了管理者的注意力：管理者将分散经历在不断调整计划上。 客户关系：项目一拖再拖，客户将失去耐心。 * 过于乐观的进度计划的后果 仓卒收尾 要排错只能将系统拆分后再进行，一个小的变动要花很长时间。 开发人员清楚地知道系统中存在一些应作修改却未做的地方。 测试人员发现错误的速度大于开发人员排错的速度。 排除已发现错误的同时，产生了大量新的错误。 由于软件变化频繁，难以保证用户文档的同步更新。 项目估算多次调整，软件交付日期一拖再拖。 * 超负荷的进度压力 产品质量的降低 赌博心理导致风险管理的忽略 激励效应不再起作用 创造性思维受损 精疲力竭：在后面的项目中难以提起热情 中途退出：这些人通常是有能力的人 长期地进行快速开发：难以补充新知识 开发人员与管理人员的关系：不切实际的进度压力会使开发人员丧失对管理人员的尊重。 * 解决之道：有原则的谈判 该谈判的策略的中心是致力于探求一种双赢的解决方案。 将人从困境中解脱 站在他人的立场上加以考虑（各人有各人的烦恼） 以合作的态度来努力改善与管理人员和客户的关系，制定比较现实的进度估算，尽量使各方都能理解进度估算的意义。 不要针锋相对 * 有原则的谈判 关注共同利益，不要过分坚持立场 有时候必须作出让步 可以从下列几个方面加以说服： 真正提高开发速度 增加成功的机会 引用以前类似项目的失败教训 * 有原则的谈判 提出多种备选方案 1、与产品有关的灵活变通： 将一些设计功能放到下一版本实现，大多数人在提出需求时，并不清楚这些需求是否必须全部在当前版本被满足。 分阶段交付产品。如版本0.7.0.8,0.9,1.0，每版实现最迫切的功能。 砍去某些实现起来费时或者需要谈判后才能确定的特性，包括与其它系统的整合能力。与旧版本兼容的能力，以及产品性能等。 对某些特性不必精雕细琢，只需实现到某种程度即可。 尽量轻松地实现各特性地详细功能需求。可以通过一些商业组件来实现。 * 有原则的谈判 2与项目资源有关的灵活变通 如果处于项目初期，则增加更多的开发人员 增加高层次的开放人员（如领域专家） 增加更多的测试人员 在管理方面给予更多的支持 提高开发的支持力度，如更安静，更独立的工作间，速度更快的计算机，技术人员随时维护环境 提高最终用户的参与度，最好在项目组中配备一个能够对特性设置最终拍板的用户 提高主管人员的参与度 * 有原则的谈判 3.与进度计划