您最成功的是哪种敏捷软件开发方法？[已结束]

Scrum，因为它显示了懒惰者的位置。它还可以更快地识别业务部门通常不知道他们真正想要交付什么

我曾参与过不少声称以“敏捷”方式工作的组织，他们的处理通常似乎基于XP（极限编程），但他们都没有遵循几乎所有的做法。

也就是说，我可能会对一些 XP 实践发表评论

• 如果从项目一开始就完成单元测试，那么它似乎非常有用，但进入现有的代码库并开始尝试添加单元测试似乎非常困难。如果您有机会从头开始，测试驱动开发是一个真正的帮助。

• 持续集成似乎是一件好事（或者更确切地说，缺乏它真的很糟糕）。也就是说，我见过的组织通常规模很小，以至于任何其他方法都显得愚蠢。

• 用户故事卡很好，因为有一个物理对象可以扔来扔去进行优先级排序是很棒的，但它们还不够详细，除非你的开发人员真的知道这个领域，或者你有一个现场客户（我从未真正见过）。

• 站立会议对于新团队成员了解每个人以及他们的工作内容往往非常有用。老手们很快就懈怠了，只是说“我还在做X”之类的话，这是他们过去一周一直在做的事情——这需要一个强大的领导者来迫使他们深入研究细节。

• 重构现在是一个非常被误用的术语，但是当你有足够的单元测试时，从概念上将“在不改变功能的情况下改变现有代码的设计”与“添加新功能”的活动分开是非常有用的

Scrum的。

每日站立会议是确保事情保持在正轨上并取得进展的好方法。我还认为，让产品/市场人员以真实、有意义的方式参与到这一过程中是关键。它将创造一个更具协作性的环境，并消除当产品团队和开发团队是独立的“孤岛”时出现的许多对抗性垃圾。

我一直在与一个使用 XP 和 Scrum 实践的团队一起工作，并加入了一些精益。这是非常富有成效的。

每日站立 - 帮助我们全面跟踪每个人的工作内容和工作地点。

结对编程 - 改进了我们的代码库，并帮助消除了引入系统的“愚蠢”错误。

迭代开发 - 使用 1 周的迭代通过设定更直接的目标来帮助提高我们的速度，这也有助于我们确定规模要求

TDD帮助我改变了我的编程方式，现在我不写任何不能修复损坏测试的代码，我也不写任何没有明确定义需求的测试。我们也一直在使用可执行需求，这确实帮助开发人员和 BA 达成了需求理解。

看板 - 实时显示我们的位置。我们有一个用于里程碑和当前迭代的。您可以一目了然地看到还剩下什么要做，正在做什么，以及已经完成和接受什么。如果你没有在每日站立中报告一些与黑板上的内容有关的事情，你必须解释一下。

同地团队 - 每个人都能跟上速度，并了解其他人正在做的事情。沟通是及时的，非常有成效，我一点也不想念我的立方体。

定期回顾是帮助团队提高效率/敏捷性的好方法。 除了坚持特定的敏捷风格之外，这种做法还可以帮助团队确定哪些方面运作良好，并适应不断变化的环境。

只要确保主持回顾的人知道他/她在做什么，否则它可能会沦为抱怨的会议。

您可以带领团队进行许多练习，以帮助他们反思并从回顾中提取价值。我建议听听 Software Engineering Radio 对 Linda Rising 的采访，以获得很好的介绍。

在 Google 上搜索“Heartbeat retrospectives”以获取更多信息。