【发布时间】：2010-03-28 18:21:59
【问题描述】：
我长期以来一直提倡敏捷，但困扰我的一件事是敏捷从业者，尤其是年轻的从业者，已经抛弃或错过了很多好的（非 Scrum，非 XP ) 做法。 Alistair Cockburn 的用例写作风格浮现在脑海中。正交数组（成对测试）是另一个。
我主要阅读与敏捷相关的书籍和文章，并且主要与敏捷人员一起工作......我有什么遗漏吗？
【问题讨论】：
标签： agile
【发布时间】：2010-03-28 18:21:59
【问题描述】：
在没有人写下做出特定决定的原因并且所有相关人员都离开时，看看这些系统的可维护性可能会很有趣。
【讨论】：
-
这是什么神话？敏捷！= 没有文档。写的及时，够用。
-
教科书上的敏捷和实践中的敏捷有很大的不同——首先要放弃的是任何不是代码的东西。
-
这就是测试与敏捷齐头并进的原因，因为您的测试在很大程度上应该是您的文档。
-
被谁丢了？如果产品负责人想要文档，他会得到。这是一个管理问题。
-
大多数文档从来没有被任何人阅读过，并且在一两年内就会变得陈旧，因为没有人更新它，要么是因为他们不再记得它在那里，要么是因为他们根本无法被打扰。这就是现实。
我有什么遗漏吗？
是的，我想了很多，但前提是您对软件开发流程感兴趣。
我喜欢这个解释：
每个项目都应该尽可能敏捷，但不能更加敏捷。
并非每个项目都可以敏捷...但我认为 80%+ 可以。
我将敏捷视为“car of the year”。它非常适合大多数人，但如果您需要/想要一些特别的东西，例如能够以 300 公里/小时的速度行驶的汽车或能够运载 20 吨货物的汽车，您需要其他东西。
还有很多情况下，人们可能想要的不是“年度汽车”，而是需要一本书来写下来:-)我推荐你Agility and Discipline Made Easy: Practices from OpenUP and RUP。在这本书中，你会发现很多“缺失的部分”都得到了很好的说明。理解的关键是敏捷性只是软件开发过程的（要求的）属性，有时无法实现。这本书描述了几个关键的开发原则（它们是 RUP 的基础），并解释了在不同的采用水平上使用它们所遵循的“仪式”和“迭代”级别。
一个例子
实践：自动化变更管理和变更传播
在您的项目中，您可能需要非常先进和严格的变更管理，并决定通过实施自定义或重新配置现有工具以及使用变更和控制板来“自动化变更管理和变更传播”。
效果：这很可能会增加您项目中的“仪式”级别。
【讨论】：
(...) 已经抛弃或遗漏了很多好的（非 Scrum、非 XP）实践。
Scrum 不是规定性的，您可以选择如何做事。换句话说，没有什么会强迫您使用用户故事（即使用户故事适用于许多团队，也没有达成共识），所以如果您认为它们更适合您的上下文，请随意使用（轻量级）用例.为了说明这一点，Jeff Sutherland 报告说他再也不会将用户故事用于 PDA 设备项目（他们在他目前的公司中使用某种“轻量级规范”）。这同样适用于测试，使用适合你的任何东西。总而言之，如果您发现 XP 不够灵活，请使用其他东西……并检查和调整。
【讨论】：
迭代开发。
在实践中，敏捷团队可能会进行迭代（或其他任何事情，敏捷是一种“真正的苏格兰人”），但敏捷过程并不充分要求或定义迭代开发。
以 RUP 为例 - 笨拙而臃肿，它确实编译了一些敏捷错过的长期开发的好方法。
总体而言，敏捷是一种避免问题的方法：如何避免长期计划、如何保持团队规模小、任务短、客户参与等等。它经常起作用，但有时你有面对和解决问题：如何达到严格的期限，使大团队合作，实现遥远而复杂的目标，使客户细化要求。这时候就需要超越敏捷。
【讨论】：