前面我们提到了需求变更。当客户提出了需求变更,经过与我们的需求人员的详细讨论与分析,最后确定下来了变更内容和修改方案。但这时草率地开始进行设计和开发是不正确的,它将成为项目后期的一个巨大的风险,一颗定时zhadan,为什么呢?我们来详细分析分析。
每当发生需求变更的时候,不管是大是小,项目的许多因素都会相应地发生变化。首先发生变化的是工作量。每次的变更必然造成工作量的增加,到底增加了多少呢?我们需要对其进行评估。同时,我们还要对增加的工作进行优先级评估。一般来说,新增加的工作往往优先级都是最高的,是客户急切想看到结果的部分,那么其它的工作的优先级就会收到影响,优先级就会有所下降。当工作量的增加与优先级的调整完成后,随后的工作就是项目计划的调整。
前面我们说过,迭代式开发的项目计划与传统的项目计划是存在巨大差异的。迭代式开发的项目计划其核心,就是如何将各项任务合理分配到各个迭代期中去。任务就像一个个大小不一的石子,迭代期就如同一个个网格,项目计划就是将石子分发到各个网格中,虽然有一些空隙,但大体是满的。现在新任务来了,就如同要将新的石子放到已满的网格中,有几种可能:石子很小,利用网格的空隙就可以填满了;石子太大了,如果要把这个石子放进这个网格中,就必须将里面的某个石子取出来,放到别的网格里。现在项目计划的变更就是这样。
如果新的工作量很小,往下一个迭代期挤一挤,即使超了1、2天也能挤下,那就挤挤吧,但这个迭代期可能会延期,后面工作的时间节点也必然随之调整;如果新的工作量还不小,优先级还比较高,那么只能将下一个迭代期中已有的任务取出,调整到其它迭代期中,这可能会导致后面整个的工作计划都将调整。不论怎样调整,我们都应当将调整后的工作计划告知客户。
不论业务需求怎样变更,不论项目计划怎样调整,通知客户,让客户理解,并与我们共同承担项目延期的风险,这是从无数失败的项目中总结出来的血的教训。一定要让客户明白,你们可以改需求,可以提出修改意见,但必须与我们一同承担风险。当客户意识到这一点时,也许他们就会慎重考虑了,甚至一下变更需求就会被取消。
在变更项目计划的同时,另一项重要的工作就是变更我们的产品需求说明书。在项目管理中,需求文档往往分为两个:原始需求和产品需求说明书。原始需求是客户编写的,站在客户角度描述的业务需求,而产品需求说明书是我们在对原始需求分析、理解、调研以后,剔除那些技术无法实现的内容,最后形成的文档,是我们的软件最终做成什么样的依据性文档(需求文档其实很多,如需求规格说明书、产品规格说明书等等,但都大同小异)。产品需求说明书是程序开发的依据,软件测试的依据,用户验收的依据,贯穿整个软件开发的核心。因此,当业务需求发生变更之后,产品需求说明书一定要进行相应的变更,并做好变更的记录,与客户签字确认。这样做的另一个好处就是防止客户随意变更需求,使客户对变更的提出更加慎重。
另外一个需求变更中常常出现的尴尬局面就是,当所有情况都清楚告诉客户以后,客户提出需求必须要变更,但最终交付时间却不能改变。这着实是一个相当矛盾的问题,变更必然造成工作量增加,工作量增加必然影响最终交付时间,但交付时间又不能变,这听起来既不合情又不合理,但在现实的项目中经常发生,而且各有个的充分理由,我们这怎么办呢?其实解决这种情况的办法就是在制订项目计划之初就提前考虑到。记得我们前面提到,我们在制订项目计划时应当在时间上留有一定的富余。如何制订项目计划,《越狱》这部电影给了我们很多的启示。如何成功越狱,主人公在越狱过程中的每个风险点都制订了风险规避和补救的办法,项目计划也是这样。项目需求变更就是一个风险点,因此项目经理应当在制订计划之初就应当做好准备,并提前预留出相应的时间,当项目进行过程中风险出现时才能从容应对。
总之,需求变更不是什么洪水猛兽,也不是一个项目可以完全规避得了的。我们提前准备好,从容应对之,就不是什么大不了的事情。
一次迭代式开发的研究:软件开发的风险
一次迭代式开发的研究:什么是迭代式开发
一次迭代式开发的研究:怎样进行迭代式开发
一次迭代式开发的研究:迭代开发从这里开始
一次迭代式开发的研究:准确的工作量评估
一次迭代式开发的研究:功能的优先级评估
一次迭代式开发的研究:一个迭代式项目计划
一次迭代式开发的研究:开始真正的工作
一次迭代式开发的研究:从容应对需求变更
一次迭代式开发的研究:需求变更的关键步骤
一次迭代式开发的研究:Where you are
(续)
分享到:
相关推荐
7. 迭代步骤本身可在进行过程中得到改善和精炼:一次迭代结束时评定不仅要从产品和进度角度来考察项目标情况,而且还要分析组织和步骤本身有什么待改善之处,方便在下次迭代中愈加好地完成任务。 迭代软件开发作业...
每个阶段性目标(即一次迭代)都包含了一系列开发活动,如需求分析、设计、编码、测试等。每个迭代结束后都会对完成的结果进行评估,以便为下一次迭代提供反馈和调整方向。 迭代化开发的主要特点包括: 1. **允许...
在应对需求变更时,开发人员需要采取以下策略:一是与用户建立良好的协作关系,充分交流,理解并尊重用户的需求,即使面对看似“过分”的要求,也应积极寻求解决方案。二是安排专职人员负责需求变更管理,确保及时...
- **迭代开发**:分阶段完成项目,每阶段结束后提供可运行的产品。 - **需求变更**:灵活应对需求变化,确保项目适应性。 - **用户参与**:鼓励用户在整个开发周期中积极参与,及时获取反馈。 - **快速交付**:加快...
- **定义**:在软件开发过程中管理需求变更的过程。 - **原则**:确保变更必要且合理,并对其进行适当评估和控制。 **变更识别**: - **方法**:用户反馈、需求变更申请、技术评审等。 - **重要性**:能够及时发现...
这个模块强调迭代式的方法,随着需求的逐渐明确,不断调整和改进,直至形成可供实施的详细需求。需求开发(RD)过程的目标是将抽象的系统目标和所需能力转化为具体的产品需求,将利益相关者的需求驱动视角转化为产品...
4. **二次开发**:基于用户的反馈进行迭代开发。 这种方法能够充分利用现有资源,提高开发效率。但由于不同领域的需求差异较大,领域分析的成功往往依赖于跨学科团队的有效协作。 #### 面向Agent分析方法 Agent是...
本压缩包“软件开发必备文档”包含了软件生命周期中的关键文档,旨在为软件开发团队提供全面的需求分析、设计、实现和测试的支持。 1. 需求分析文档: 需求分析是软件开发的第一步,它定义了系统应具备的功能和非...
需求变更管理是软件开发过程中不可或缺的一环,尤其在面对用户反馈和项目迭代时显得尤为重要。本文档——"PRD2017-G2-需求变更管理文档2"——旨在为浙江大学城市学院计算机与计算科学学院的软件工程系列课程教学辅助...
6. 需求管理:在整个项目周期内,需求可能会发生变化,因此需要有一个系统来跟踪、管理和控制需求变更。 "软件需求.PDF"这个文件很可能包含了一份详细的需求分析文档,它涵盖了以上所述的所有方面。这份文档不仅...
2. 变更控制:当需求变更时,需经过评估、审批、通知等相关流程,以防止随意变更导致项目混乱。 3. 需求沟通:定期与所有利益相关者沟通,更新需求状态,确保所有人都对当前需求有清晰理解。 4. 需求优先级排序:...
- **迭代开发**:通过一系列短周期的迭代来逐步完善需求模型。 - **用户参与**:在整个开发过程中保持与用户的密切合作,确保需求能够被正确理解和满足。 - **模型驱动**:使用不同的模型来表示不同层面的需求,以便...
在IT行业中,需求分析是软件开发过程中的关键步骤,它为整个项目的成功奠定了基础。一个详尽的开发项目计划书则是确保团队沿着正确的路径前进的导航图。下面将详细阐述需求分析及其在开发项目计划书中的重要性。 ...
标题中的“需求.rp.zip”表明这是一个包含需求文档的压缩文件,通常在IT项目开发中,需求分析是首要步骤,这个文件可能包含了项目的详细需求规格说明。RP可能是Rational PurifyPlus、Redmine Project或其他某种特定...
- **需求管理**:跟踪需求变更,保持需求文档与实际开发进度的一致性。 #### 4. 需求管理 - **需求跟踪**:建立需求与设计、编码、测试之间的对应关系,确保所有需求都被正确实现。 - **变更控制**:当需求发生变化...
综上所述,软件需求分析是确保软件项目成功的关键步骤。通过遵循上述法则,开发团队不仅能更准确地捕捉到用户的真实需求,还能有效地管理项目的风险,最终交付高质量的软件产品。此外,加强与用户的沟通、深入了解...
3. 采用迭代开发方式,逐步完善和细化需求。 4. 建立风险管理机制,对需求变更可能带来的影响进行评估。 【案例分析】 以某通信产品供应商A公司为例,该公司通过改进海外硬件维修服务流程,提高了维修效率和客户...
2. 敏捷方法:敏捷开发强调迭代和增量式开发,通过频繁的反馈和调整来管理需求,如Scrum和Kanban。 3. 用户故事:用户故事是从用户角度描述需求的一种方式,简洁明了,便于理解和沟通。 四、需求质量管理 1. 需求...