我想解释一下为什么在开发期间不得针对新计划部门员工更改规范。
我想解释一下为什么在开发期间不得针对新计划部门员工更改规范。
Answers:
除了最简单的项目,规范在开发过程中几乎总是会更改。
原因如下:
对项目的开发或更可能的集成测试会发现原始规范完成后未发现的内容-从边缘案例到主要方面。例如,开发人员注意到可能会收到乱序的消息确认。
确定规格的实际条件未冻结。例如,创建了一个新的金融产品,需要将其添加到直接处理规范中。
最后期限的压力会导致要素修剪。
发现了项目的其他利益相关者(例如,在项目中期,在不同区域中发现了一个类似项目,并且需要对通用子系统进行集中/共享-这在我历时2年的项目中途发生,导致重大重新存档)。
该项目的其他赞助商有新的规格要求(最著名的例子之一是Bradley Fighting Vehicle的发展历史)。
关于规范更改为何会产生不利影响的原因(您不能说“绝不能发生”,因为您可以看到它们有很多原因,几乎所有的原因都在您的控制范围之外,而很多是有充分的理由的)-
规范更改导致代码更改,使您无法完成尚未编写的项目部分(众所周知,Joel Spolsky进行过宣传,重点更改对开发人员非常不利)
某些规范更改(有时看起来非常微小)可能导致需要完全重新设计/重新架构系统,因为在两种体系结构之间进行选择是基于从规范中得出的假设。
在使用TDD的情况下,投入测试的大量工作可能会无效。
如果规格更改来自如上所述的其他利益相关者,则它们可能与现有规格矛盾,从而导致产品质量显着下降(请参阅“战斗车辆”,布拉德利)。
规格更改可能会违反一些现有的业务要求,即更改者/请求者可能尚未意识到或不在意(这实际上与上一个要点相同)。
所有这些当然会延长(有时会大大延长)项目的交付日期,并可能增加出现缺陷的可能性。
对于有史以来最好的示例,说明规范中的微小更改会如何导致极端问题,我给您提供3个字母:
Y2K。
他们所做的只是将规格更改为“ 必须在2000年以后工作 ”。
另外,在某些情况下,确实确实必须更改规范(与“没有正当理由不应该更改”相反):
规范的一部分是(或依赖于)必须与之接口的外部系统的规范。
规范的一部分是(或依赖于)在其上实现系统的硬件。
与客户的合同要求(尽管限制严格地说是在更改规格时没有先与客户一起进行更改并更改合同,而不仅仅是更改的事实)
系统可能需要满足特定的法律或法规要求,无论客户喜好如何。例如:信用卡加密,税收数据保护。
对于开发人员来说,在开发过程中禁止对规范进行更改是理想的选择,但是在现实环境中这是不现实的。人们总是希望做出改变,即使东西已经运出门了。它永远不会停止。其中一些人可能正在签署您的薪水。他们越在乎,就越会思考,因此,他们越想修改设计。即使必须重新开始,您也必须能够容忍更改设计。
重要的是要清楚地传达变更的后果,以便每个人对设计过程都抱有现实的期望。
必须适当地讨论更改,并且负责事物的人员必须清楚了解更改将对交付日期产生什么影响。为此,他必须与开发人员交谈。但是,由于正在进行的有关更改的讨论将淹没开发人员,并使任何真正的工作无法进行,因此必须按计划的,不频繁的间隔对更改进行排队和讨论。当然,这就是您希望的。
理想情况下,您可以指导人们记录他们想要进行的更改,并让他们在每周/每两周/每月/每一次的协调会议上提出。在会议期间,将讨论每个变更请求,包括讨论为实现所请求的功能而需要进行的基础修改,以及对完成日期的影响。一旦确定了变更的“成本”,他们便可以确定是否将其包括在内。
该过程引入的重要内容是每个变更都有相关的成本,随着项目的进行,成本通常会更高,因为必须重复进行更多的工作。不在开发部门工作的人通常不知道更改会花多少钱。他们告诉的唯一方法是提出建议并评估您的反应。创建定义明确的变更审核流程将对他们和您都有所帮助。
请注意,程序员往往对更改的容易程度非常乐观,或者对更改的可能性非常悲观。尝试通过将原始估计值与结果进行比较来弄清楚自己是什么,然后进行相应调整。
我最好的比喻是将它与盖房子进行比较。架构师先制定计划,然后提出一个估计,然后客户同意(或不同意)该计划。如果客户想要增加一个额外的浴室,则工作停止,计划必须更改,进行新的估算并且客户同意(或不同意)。
编写软件没有什么不同。一旦达成协议(在设计和评估之后),则如果需要进行任何更改,则需要停止工作以制定新计划,然后进行新的评估(或不批准),然后继续工作。
无论我说什么,都意味着该项目将继续进行而不进行新的更改。当然,总会有时间和材料来提出新的计划和估算。