需求冻结问题

[David_Jiang]

本人初学者，最近一直在研究CMMI :(
看到敏捷开发的模式感到非常感兴趣，尤其是“需求变更”的部分

问题在于，在敏捷开发中还有没有“需求冻结”的必要？或者用其他什么形式来代替？
非常期待高手的答复，谢谢~！

[青润]

看你需求冻结的定义和作用了。
如果是作为需求一个阶段的锁定，完成需求内容后，进行版本提交，那么不存在CMM还是敏捷或者其他任何过程模型的差异，大家都需要。
如果是冻结代表锁定永远不再打开，那可能只有纯粹的瀑布才能适合，其他任何只要带有一定往复性的过程模型，都将不适合。

[以专业开发人员为伍]

敏捷开发时，并不做“不必要的事情”，不像简单的瀑布开发所说的要把需求全都列出来才开发，相反地，敏捷开发只是“小步快跑”。

一方面，真正的敏捷开发是把需求作为比较细节化的可测试代码，而不是纯粹文字（或者说文档）上的空谈，而是测试代码。如果敏捷开发被看作勤开会、勤作汇报，就成了假的敏捷开发了。所以敏捷开发从XP为其原型，那些没有掌握XP技术的人可以把一些过程模糊化为一些口头理论要求（例如你不懂得全面进行自动化测试的技术那么你可以手工测试、购买一些工具、开发一些工具相结合地来办自动化地测试），但是如果模糊的越多越是口头上的敏捷了。

另一方面，他要求你快跑，如果一个人1天做不完一个小任务，10个人2、3周都不能提交一组很有意义的新增特性，就有问题了。项目开始时只可能有原则性的需求，而不可能有具体的需求设计，否则就不是快跑而是冬眠了（多数人等着少数人做过细的设计，这些设计细节的80%往往在后边的快跑过程中被证明是垃圾）。

[以专业开发人员为伍]

实际上，敏捷开发的组织形式，就要求它的管理者不要做不必要的事情（不要哪天心血来潮地花费用户的时间和金钱把已经测试通过的代码改写得完美一些），而要随时保持用户参与需求开发和评估过程。在把握一个总的需求原则的前提下，具体的阶段性需求是由站在用户方的观点提出的。传统上，我们可能将一个项目分解为15个子系统，每一个子系统要求作出未来180天的一个超过30个验收步骤的开发日程计划。敏捷开发不是这样，我们“只看眼前”一小段时间（例如15天内）的任务细节，然后由需求评估师与用户在一起工作，来随时滚动地计划下一阶段的工作。看起来这不是敏捷而是鼠目寸光么？对的，这就是敏捷的关键。敏捷其实是可以增强程序员的信心的产品质量、组件协调的，设计师在评估工作中并且与用户的接触中把握长远目标，而不需要项目组内部太多的人说三道四，内部的几乎所有的人只要埋头把当前的一小段时间的工作做好就行了。单纯靠这个理论，是做不到敏捷的。所以，XP是以及其划时代的自动化工具和许多初看起来很“雷人”的理念来保证重构一个项目组织信息系统而提高敏捷的。而Scrum则是一个折中，那些又想敏捷又不相信XP的人从Scrum中找到了一种他所熟悉的东西。我认为Scrum不够敏捷。

[以专业开发人员为伍]

实际上,Scrum我看作是敏捷阵营中的瀑布开发，它具有多种解释（每个人可以自己按照自己的爱好随意解释），而又是站在敏捷这个时髦阵营里，而且又不像XP那样要求有较高的自动化测试和以人为本的bug跟踪处理技术，因此技术含量不高、门槛极低而容易上手，所以接触它的人比较多。但是Scrum其实很容易滑向非敏捷的。

[cmm2cmmi]

学习

[码农哈里]

冻结的意义是什么？

[以专业开发人员为伍]

其实，单纯说出敏捷其实是鼓吹在项目任务管理方面“只看眼前”地迭代这会很雷人。但是敏捷实际上还鼓吹随时自动化地“回归”来保证质量。这两个条件同时具备，就造成了不一样的变化。做到第二点，实际上需要XP流派那样的技术领域，许多人对XP的技术领域不以为然，于是空谈迭代。空谈迭代，就会造成很多奇怪的问题，例如说需求需要冻结，因为他担心产品中的没有解决的问题在某一天累计到了任何pm都无法撑下去了。这种敏捷团队的做法，其实最终直接完全回到了非敏捷。

[以专业开发人员为伍]

我在一些地方写过，敏捷开发就像“丰田模式”中那跟绳子代表柔性、敏捷生产过程一样。如果一个人发觉产品质量发生了问题，它就可以把整个流水线停下来，这就敏捷的威力，因为整个工厂不再怕这种行为的影响了，反而拥抱这种极端地重视质量的行为。丰田可以同时在一个流水线上为客户定制生产多款产品（而没有一个工人去说需要冻结订单），而许多学丰田模式的企业则仅仅是学一点皮毛走形式，结果都没有达到类似的结果。

[以专业开发人员为伍]

另外，我觉得有很多人把敏捷看作单纯对外协作的过程，这其实是很危险的。

敏捷方法可以小中见大，需求比较含糊，项目内可以由分析人员来扮演客户的角色来进行敏捷开发。

因此敏捷的作用主要还是用来改造开发组织自身。我想那些把敏捷有意无意地单纯地说成是项目组与客户进行沟通的技术的人，还是比较空洞的。

[ggokind]

冻结需求，如论CMM还是敏捷都是必要的，关键要衡量冻结的时间点。
一定时期范围内的需求冻结，有助于避免项目组内部开发和测试受到外界过多的干扰。项目经理有责任识别出何时冻结需求，何时解冻。
传统CMM受到诟病最多的就是固定在系统设计或者SRS设计完毕候，基本将大块的需求冻结，用一种较为生硬的方式保证开发可以顺利进行；
敏捷的改进主要在于，没有大块的需求，基本上都有分解为细粒度的story，并且在最长一个月的迭代周期内交付，这就给下次迭代的时候，需求变更留有了机会和余地。否则就像CMM一样，大块大块的需求统一集中设计，当用户想明白自己想要什么的时候，已经来不及变化需求了。

因此，无论是否敏捷，需求冻结都是必要的，但是敏捷有更多的机会在后面的迭代中接纳这部分变化（注意，变化不一定增加工作量）。

[以专业开发人员为伍]

假设一个有点经验的并且人不多（连手工测试人员带做饭的大妈算在内也不过15个人左右的）项目组，假设我们制定了一个15天的开发计划，然后用户需求在正式评估之后被确定为下一个15天的里程碑中实现的特性，那么对当前来说是不是“需求冻结”了呢？我想，这很可能成了语言学上的游戏。

但是我根据经验判断，用户此时并不会觉得这是冻结了，而相反是觉得这是“大师”更好地安排了开发进度。用户会看到需求总是被快速地实现，同时质量、一致性很好。

[David_Jiang]

非常感谢大家，受益良深。
看大家讨论这么热烈，我暂时先不结贴，大家继续讨论，以后再一并结贴~

再次感谢~！

[以专业开发人员为伍]

或者叫做“言不由衷”，或者说是还根本没有那个意识把测试驱动的过程重新倒置成为市场导向型的。

不要搞点行政上的噶进就号称敏捷了，只能说是在学习敏捷。

就像无数的企业学丰田学不像一样，应该说敏捷其实就是一个药引子，如果弄出一罐很名贵的药但是不知道药引子是什么这只能浪费资源。敏捷很简单，但是如果实际的技术还很差，例如你只会从市场上买、从网上抄，而自己并没有开发和掌握一点最关键的测试、版本管理、bug管理、需求评估信息系统核心技术（这样你就不能自己给自己开药方），是很难做到敏捷的。

[以专业开发人员为伍]

如果没有在技术上掌握敏捷团队所需要的自动化技术，千万不要奢谈敏捷。不要轻信那些可以随意自我解释的门槛很低、没有多少技术含量、倾向于行政手段的所谓敏捷描述。应该说，传统的方法与敏捷方法之间，没有中间状态。你不要为了给自己一个时髦的敏捷开发的称号而敏捷，你可以仅仅采用敏捷方法的一些自动化技术手段，进而带来行政管理上的不一样的改变，而此时无需成称呼自己为敏捷团队。敏捷其实很简单，但是他是很“反叛”的，甚至可以说“变态”的，但是习惯了也许就是另外一种常态。

[严于律人宽于待己]

一个project不可能无限期的持续下去，主要范围和目标达到了就该停止接纳新需求。

管理需求最难的不是项目组内部，而来源于项目组外部，每个需求提出者出于个人目的都会夸大本身需求的重要性。
瀑布是一次接纳所有需求（含变更）并试图一次性完美的交付，可能组织上要求需求按优先级排序，但这个排序仅仅是排序，需求要全部实现；
迭代可逐步完善逐步交付，在项目过程中需求管理活动相对来讲更多些，需求优先级是实际生效的，冻结可针对当次迭代或阶段发布版本，整个项目根据情况会适当少实现一些无价值需求。

[以专业开发人员为伍]

呵呵，真的，奢谈迭代真的会毁了敏捷开发团队。只要能够讲出那个关键的测试驱动技术，就以此为入门而自然而然地会敏捷起来。而迭代等等的表象，更多地是从旁观者看实践者，而不是实践者自己的角度来说的。

但是，我见过和共事过几个干过8年以上专业测试管理、负责过年人工费千万以上的项目的测试主管，不懂测试驱动只懂传统的测试（因为测试外包给他们的公司，而他们的公司更注重传统技术知识）。如果要敏捷，我们不得不自己写各个客户端平台的测试驱动程序，而他们的测试只是辅助（原本我们做测试时业余的，但是因为要实践敏捷开发，我们自己掌握的测试系统开发的核心技术而他们只是懂得买点软件来用一用）。

除此以外，需求评估技术流程也是一个关键。但是这是开发变为测试驱动以后的后话。

因此，我强调，看不到关键的技术，请不要敏捷。

[以专业开发人员为伍]

不是简单地会用、买了人家的软件，而是全面地把赌注压在敏捷方法上，大概才能很好地实现敏捷开发。当你没有自动化地采用敏捷所需要的技术，而在行政上采纳了敏捷论调，其实就是鼠目寸光、软件危机了。

快速地迭代，谁不想呢？但是不是说迭代就迭代的了得。

[zhnzzy]

学习下

[码农哈里]

个人认为记录好版本就足够了。

[以专业开发人员为伍]

我在帖子《敏捷，想说爱你不容易－－从CMM向敏捷过渡的一点体会》上回复了一段关于测试驱动观念的评论，应该说很多所谓的敏捷团队在测试驱动问题是“言不由衷”的，这就造成了他们不是以技术手段来带动敏捷，而纯粹是想用一点行政手段（仅从Scrum中抄袭来一点门槛极低、急功近利、偏重于行政管理手段而非技术手段的方法）来就敏捷。

在那个帖子中，我说测试主要是围绕ST，而UT甚至可以不做（而是写大量断言来更全面和自动化地检测功能）。实际上，使用ST这个术语也是不得已，因为许多人人受传统的测试“理论”的规则束缚很深，我只能用用一个人家可以很容易理解的启发性方法来说出我的意思，而不是一步到位地说明白。实际上，XP等敏捷技术中，从来没有把测试驱动规定为黑盒或者白盒，根本不是那种视角，而仅仅是强调它是驱动项目的具体开发过程的而不能妄图放到功能开发出来之后再写（因为那时大多数人都会人之常情地自己反悔自己信誓旦旦在以前确定的测试目标）。