第三单元 项目计划
第一部分 听说
A. 对话：软件项目计划
Jason：这么多工作要做啊！
Kevin：我认为我们需要一个正式的项目计划作为指导。
Sharon：是的，首先是时间，这也是影响我们项目的最重要的因素之一，我们需要一个进度表，尤其是项目的最终期限。
Kevin：我们总共有40天的时间，而需求已经花了5天的时间，因此我们还有35天时间。
Jason：哦，听起来时间确实很紧张。
Sharon：我们似乎应该尽快开始编程，对吗？
Jason：尽管编程是软件项目中非常重要的一个部分，但是，我认为现在最重要的事是，必须确定一个合适的时间进度表来控制我们的进度，并确保能够按时交付。
Kevin：是的，在需求阶段，我们还需要三天时间来对需求进行描述、分析和建模。之后，我们需要三天时间来完成结构设计，五天时间完成详细设计；由于这些工作量都是用于软件设计，因此接下来的编程相对不会很难，我认为在一周内应该能完成；测试及后续的调试在十天时间内应该能完成。
Sharon：也许我们可以用甘特图来描述我们的进度表，对于项目计划来说，甘特图是一种形象生动并且实用的工具。
Kevin：好主意！
Jason：事实上，测试不应该被看成是仅在编码阶段完成后才开始并仅限于以检测错误为目的。实际上，测试计划在需求阶段的早期就应该开始了，并且测试计划和流程应该系统地、不断地改进。我觉得，在编码阶段，我们可以同时执行单元测试，这将会节省大量时间并会获得更好的测试效果。最后，我们可以通过与客户一起工作来进行验证测试，检查开发出的软件客户是否满意，以确保客户能够获得他们所需要的。
Sharon：另外，我们需要三台计算机，必须安装客户所要求的具有统一版本的软件作为开发工具，以Visual Studio 2005作为开发平台，以Microsoft SQL server 2005作为数据库管理系统。
Jason：我们还需要网络。
Kevin：我将尽快为大家准备开发环境，然后给每个人分配一些管理任务。Sharon，你负责文档管理，Jason，你负责变更管理，我负责软件质量保证，怎么样？
Jason和Sharon：没问题。
Kevin：好，我已经把刚才讨论的内容做了记录，并会在两天内完成一份项目计划文档。
B. 短文理解：软件项目计划
有许多种项目计划方法。有些人是“最简单派”，他们认为，变化经常使得进行详细计划变得没有必要。其他人是“传统派”，他们认为，计划提供了有效的路线图，并且设计越详细，团队失败的可能性就越小。还有一部分人是“敏捷主义者”，他们认为，一个快速的“设计活动”是有必要的，但路线图将会在软件开始时作为实际工作出现。
那么到底应该如何做？在许多项目中，往往会因过度计划而事倍功半(太多的事情在变化)，但过于简略的计划也会导致开发混乱。像生活中的大多数事物一样，应该适度进行计划，足以为团队提供有用的指导即可，不用多也不用少。
在一篇优秀的关于软件过程与项目的论文中，Barry Boehm提出：需要按比例缩减的组织原则来为简单的项目提供简单的计划。Boehm建议一种方法来处理项目目标、里程碑、日程表、项目分工职责、管理及技术手段以及所需资源。他称此方法为W5HH原则，在一系列引出关键项目特性的定义和随之产生的项目计划的问题之后：“为什么要开发系统”、“将要做什么”、“什么时候将完成”，上述三项是最必不可少的。此外，还有“一个功能由谁负责”、“人员被组织安置在哪里”、“工作将如何在技术和管理上完成”以及“每项资源各需要多少”。对于Bohehm的W5HH问题的回答十分重要，这点与软件项目的复杂度及规模无关。
C. 听写：软件项目中的四个变量
项目是使用资源来达到预定目的和目标的一系列特定的活动，是具有特定起止日期的有限努力和具有一系列的时间安排、预算及组织约束条件的管理过程。
通常情况下，在软件项目中，我们将控制四个经典变量——费用、时间、范围和质量。这四个变量通过相互作用共同影响着整个项目：增加的范围往往意味着要花费更多的时间和可能超过预算；紧迫的时间压力要求更强的资金支持，同时质量也可能受到影响；资金不足就难以解决范围之内的客户业务问题；更高的质量可能需要更长的开发生命周期和更高的费用成本。
看起来这四者之间的关系并不那么简单。例如，不能仅仅依靠投入更多的资金提高软件的开发速度。正像谚语所说：“即使是九个女人，也不可能在一个月之内生出孩子。”
Kent Beck在他的《解析极限编程：拥抱变化》一书中提到，解决方法就是使这四个变量是可见的。如果每个人——程序员、客户和经理——都能注意到这四个变量，那么他们就可以有意识地选择控制哪些变量。如果他们不喜欢这四个变量可能带来的结果，那么可以改变投入或是选择不同的其他三个变量来进行控制以最终达到项目目标。
第二部分 阅读
A
233
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
