3

有许多敏捷软件开发方法。您在实践中使用了哪些方法来交付成功的项目,该方法对成功有何贡献?

4

5 回答 5

7

我曾参与过不少声称以“敏捷”方式工作的组织,它们的处理通常似乎基于 XP(极限编程),但它们都没有遵循所有实践。

也就是说,我可能可以评论一些 XP 实践

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

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

  • 用户故事卡很好,因为有一个物理对象可以用来确定优先级,但它们不够详细,除非您的开发人员真正了解该领域,或者您有现场客户(我从来没有实际见过)。

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

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

于 2008-08-09T03:39:44.600 回答
6

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

于 2008-08-09T03:21:59.923 回答
4

Scrum。

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

于 2008-08-09T04:52:54.610 回答
2

定期回顾是帮助团队变得更加有效/敏捷的好方法。这种做法不仅可以坚持特定的敏捷风格,还可以帮助团队确定哪些方面运作良好并适应不断变化的环境。

只要确保进行回顾的人知道他/她在做什么,否则它可能会退化为抱怨会议。

您可以带领团队进行许多练习,以帮助他们从回顾中反思和提取价值。我建议收听软件工程电台对Linda Rising的采访,以获得很好的介绍。

在 Google 上搜索“心跳回顾”以获取更多信息。

于 2008-09-24T21:59:07.153 回答
1

我一直在与一个使用 XP 和 Scrum 实践并带有一些精益的团队合作。这是非常有成效的。

Daily Standup - 帮助我们完整跟踪每个人的工作内容和位置。

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

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

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

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

同一地点的团队——每个人都跟上其他人正在做的事情。沟通及时,效率很高,我一点也不想念我的立方体。

于 2008-08-28T23:08:40.450 回答