除了瀑布，还有什么计划驱动的软件开发方法？

Question

我刚看了平衡敏捷与纪律。撇开糟糕的标题不说，它对比了一个使用PSP/TSP的计划驱动项目团队和一个使用极端编程的敏捷团队。

当作者提供一个计划驱动方法的例子时，他们使用了个人软件过程/团队软件过程。尽管开箱即用，这些都是计划驱动的方法，但它们也被设计成作为过程框架，最终只指定要做的事情类型，而不是如何去做，即使在敏捷环境中也可能有用。它有可能是敏捷的，并且仍然坚持PSP原则，而且我对TSP还不太熟悉，不能肯定地说，但我的理解是它非常相似。

在书中的某一点上，他们列出了许多方法，并根据敏捷性对它们进行了排序。像Scrum、精益、水晶和XP这样的方法处于顶端。底层(从大多数到最不敏捷)包括、、、CMMI、Software、Personal Software和Cleanroom。

瓦茨·汉弗莱( Watts )在PSP:软件工程师的自我改进过程中专门用一章阐述了过程定义，特别是对个人软件过程的修改。共同的主题是过程是指令性的(他们说要做什么)，而不是描述性的(如何去做)。我猜想TSP也是如此。CMMI还与敏捷方法和SEI有一本书 (我还没有读到)一起使用。

特性驱动的开发经常被吹捧为项目管理的敏捷方法，但作者选择将其归类为一种不那么敏捷的方法。

RUP是一个迭代框架。虽然我对它不太熟悉，但它是一个框架这一事实使我可以将它与SW-CMM、CMMI和PSP/TSP组合在一起，因为它可以作为一种敏捷或计划驱动的方法来实现。

书中提供的唯一一个我同意的例子是洁净室软件工程。洁净室的主要组成部分是使用正式方法、统计质量控制和统计健全测试。我不明白为什么不能在敏捷(迭代/增量)方法中使用这些方法，增加了时间和成本开销。

为了澄清我想要的是什么，敏捷方法家族包括了以Scrum和Extreme形式的抽象思想的具体实现。它们实现了迭代和增量开发、响应更改、人员(个人和团队)、频繁交付工作软件、与客户协作等概念。它们明确地指定了角色、工件、会议、时间盒和其他实践，并且“做Scrum”或“做极端编程”意味着接受包。即便如此，它们也允许裁剪性和新流程的创建(但是，您并不是在“执行Scrum”或“正在执行XP")。然而，我还没有发现计划驱动方法的"do X“--大部分工作似乎都是针对那些可能是敏捷或计划驱动的框架。

那么，我的问题是:更多的计划驱动软件开发方法的例子是什么？许多过程框架(PSP/TSP、SW、CMMI、RUP)也允许计划驱动或敏捷开发，但没有一个是描述性的。但是，是否有任何真正的计划驱动的方法，例如，直接对应于Scrum和极端编程？

Answer 1

老实说，我怀疑书中提出的任何观点是否正确，因为书中的“敏捷”和“纪律”是相互对立的。在我的经验中，敏捷方法比其他类型的开发需要更多的纪律。

也就是说，如果要利用敏捷过程的好处，就必须遵循它们附带的启用实践(请参阅Martin的设计死亡文章；他主要讨论XP，但在我看来，它适用于所有敏捷)。这需要很大的纪律。

但是，为了回答你的问题，我认为所有真正的计划驱动的方法都是瀑布的变体，比如螺旋形，它在切换到瀑布方法之前通过多个层次的原型开发，和双子座SDM，它是瀑布的一个非常不同的阶段，每个阶段都在另一个开始之前结束。