一次迭代式开发的研究 笔记

1,首先是项目计划的前期分析——工作量评估和优先级评估，然后是制订迭代式的项目计划，最后是按照项目计划执行项目。每天，运用Burn-Down Table监控项目进程，随时掌握项目进度的偏差（是滞后还是超前），然后制订相应的应对方案予以调整，直到最后的项目结束，一切似乎进行得比较顺利。但真实的情况往往不是这样，这里忽略了一个最重要的因素，那就是需求变更
2,当客户对需求提出变更时，我们往往第一反应就是记录，然后回去照着做，但很多经验证明这样是不对的。不加分析而草率地修改客户提出的变更需求，是造成客户频繁变更需求的根本原因。我们前面提过，客户提出需求的一个重要特点就是，当软件没有真正设计出来时，客户往往是说不清楚自己的真正需求的。因此，当他再次看到上次提出变更以后修改的内容，很有可能还不满意，这就意味着还要继续改，直到他满意为止。这样，反复修改是再所难免。

当客户提出需求变更时，我们首先应当弄明白的是客户为什么要提出这样的需求。这时候，需求分析员应当站在使用者角度，站在业务角度，去理解这样的需求，理解其提出来的动机。也许客户在做这个操作时要查看一些相关信息，也许这个数据和那个数据有逻辑关系，甚至其原因就是一个非计算机专业的人看到这个界面不容易理解、有误解，或者操作就有困难。

当理解了用户提出变更的真实动机以后，随后分析的就是这样的变更有没有必要，可不可实现，或者是否有更合理的解决方案。每次我们都会将一些客户提出的不合理的，或者无法实现的需求变更退回去，并且提出我们的理由。只要遣词得当、理由充分，客户往往能接受我们的建议而取消这些需求（多用建议的语气，少用命令的口吻）。而另一些变更需求，我们常常从用户表面的语言中分析出他们真实的需求，并提出一个更加合理的建议。这样做，客户不仅会欣然接收你的建议，而且会有一种你就是他肚里的蛔虫那种感觉，对你更加信任，你在客户心里的威信也就随之增加。
3,首先，将分解好的各项工作，按模块按功能罗列在一个表格中，依次描述每项工作的业务需求和工作任务，使每一个参与评估的人都清楚每项工作。然后将工作量评估分配给多个人，保证每项工作都有2~3个人同时给予评估。
4,该阶段的评估应当是独立的，即每个人的评估结果都不会影响另一个人。当每个人完成了自己的评估以后，项目经理收集每个人的评估结果，组织会议进行讨论。
最后，当所有工作量被评估出来以后，是否就可以提交客户了呢？一个成熟的项目经理应当考虑更多。并非所有人在所有时间都能满负荷工作，生病、接收突发任务、人事变动，都可能影响项目进度。因此，适当地为每项工作增加一个备用时间的系数，提供一些富余的时间，可以确保项目过程更加稳健。
5,在工作量评估讨论会上，会议组织者将一项一项地讨论每项工作。对某项工作，如果参与评估的每个人评估的工作量差异都不大，说明大家对该项工作的分歧不大，选取最合适的一个工作量评估；如果某个人的评估与其他人差距较大，认真听取他的意见。也许他对该项工作的某个细节存在误解，但也可能该细节正是需求不明确的地方。停下对该项工作的评估，联系客户明确需求，之后才可以继续该项评估。
6,迭代式开发的特点就是持续集成，也就是首先开发最重要、最基本的功能，而暂时忽略掉分支的、次要的功能。正因为如此，迭代式开发需求将优先级最高的功能放到前面最先完成，然后安排次优先级的，依此类推。总之，优先级评估决定了迭代式开发的工作安排。

那么，如何决定每个功能，每项工作的优先级呢？其决定因此很多，但通常来说，有两个因素是最基本的：是否靠近主营业务，以及用户使用是否频繁
7,根据这样的思路我们就明白了为什么我们需要进行优先级评估。将主营业务的、使用频繁的功能首先开发出来。在开发时，也主要考虑主流程而忽略分支流程。经过第一次迭代，一个可运行的、主要功能都有的软件雏形就出来了。之后，再在此基础上继续丰富、完善，直到整个项目的完成。
8,在制定时间计划时不要安排得太满，应当留有一些富余，以应对一些突发事件，如项目成员生病，或者有其它突发任务需求处理。每个迭代期结束的时候，都应当对项目进度进行一个评估，是超前了还是滞后了。一个留有富余的项目计划，可以使那些滞后的工作的处理拥有更多的回旋余地
9,，当我们为软件分解工作项目，评估了工作量，确定了优先级。同时，整个项目的人员安排，也就是哪些人负责需求分析，哪些人负责设计，哪些人负责开发，哪些人负责测试，被确定下来，我们就可以制订我们的迭代式开发的项目计划了。
10,不论业务需求怎样变更，不论项目计划怎样调整，通知客户，让客户理解，并与我们共同承担项目延期的风险，这是从无数失败的项目中总结出来的血的教训。一定要让客户明白，你们可以改需求，可以提出修改意见，但必须与我们一同承担风险。当客户意识到这一点时，也许他们就会慎重考虑了，甚至一下变更需求就会被取消
11,业务需求发生变更之后，产品需求说明书一定要进行相应的变更，并做好变更的记录，与客户签字确认。这样做的另一个好处就是防止客户随意变更需求，使客户对变更的提出更加慎重。
12,，当所有情况都清楚告诉客户以后，客户提出需求必须要变更，但最终交付时间却不能改变。这着实是一个相当矛盾的问题，变更必然造成工作量增加，工作量增加必然影响最终交付时间，但交付时间又不能变，这听起来既不合情又不合理，但在现实的项目中经常发生，而且各有个的充分理由，我们这怎么办呢？其实解决这种情况的办法就是在制订项目计划之初就提前考虑到。记得我们前面提到，我们在制订项目计划时应当在时间上留有一定的富余。如何制订项目计划，《越狱》这部电影给了我们很多的启示。如何成功越狱，主人公在越狱过程中的每个风险点都制订了风险规避和补救的办法，项目计划也是这样。项目需求变更就是一个风险点，因此项目经理应当在制订计划之初就应当做好准备，并提前预留出相应的时间，当项目进行过程中风险出现时才能从容应对。
13,而产品需求说明书是我们在对原始需求分析、理解、调研以后，剔除那些技术无法实现的内容，最后形成的文档，是我们的软件最终做成什么样的依据性文档（需求文档其实很多，如需求规格说明书、产品规格说明书等等，但都大同小异）。