有许多敏捷软件开发方法。在实践中，我们使用了哪些方法来交付成功的项目，以及该方法如何为成功做出了贡献？

解决方案

回答

Scrum，因为它显示了懒人在哪里。它还可以更快地确定业务部门通常不知道他们真正想要交付什么的线索。

回答

我参与了许多声称以"敏捷"方式工作的组织，它们的处理通常似乎基于XP(极限编程)，但是没有一个遵循所有实践。

就是说，我可能会评论一些XP实践

• 如果从项目开始就完成单元测试，似乎证明非常有用，但是进入现有的代码库并开始尝试添加单元测试似乎非常困难。如果我们有机会从头开始，那么测试驱动的开发将是真正的帮助。
• 持续集成似乎确实是一件好事(或者，缺少集成真的很不好)。就是说，我见过的组织通常很小，以至于使任何其他方法显得愚蠢。
• 用户故事卡非常好，因为可以放置一个物理对象进行优先级排序，但这很好，但是除非开发人员真正了解该域或者我们有一个现场客户(我从来没有这样做过)，否则它们还不够详细。实际看到)。
• 站立会议对于新的团队成员了解每个人及其工作原理非常有用。老手很快就松懈了，只说了"我仍在研究X"之类的东西，他们在过去一周中一直在这样做-需要强大的领导才能迫使他们深入研究细节。
• 重构现在是一个真正被滥用的术语，但是当我们具有足够的单元测试时，从概念上将"更改现有代码的设计而不更改功能"的活动与"添加新功能"的活动分开非常有用。

回答

混乱。

每日站立会议是确保一切都按计划进行并取得进展的好方法。我还认为，以一种真实，有意义的方式让产品/市场人员参与此过程是关键。这将创建一个更具协作性的环境，并消除当产品团队和开发团队是单独的"孤岛"时出现的许多对抗性垃圾。

回答

我一直在与使用XP和Scrum实践的团队合作，这些实践中撒了些精益。这非常有生产力。

每日站立帮助我们全面跟踪每个人在做什么和在哪里工作。

Pair Programming已改进了我们的代码库，并帮助消除了系统中引入的"愚蠢"错误。

使用1周的迭代进行迭代开发通过设置更直接的目标来帮助提高我们的速度，这也帮助我们确定了需求

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

看板实时显示我们的位置。对于里程碑和当前迭代，我们有一个。一目了然，我们可以看到剩下要做的事情，正在做的事情以及已完成和被接受的事情。如果我们没有在日常站立情况中报告问题，则与我们要做的事情有关。

在同一地点的团队每个人都可以跟上其他人在做什么并与他们保持同步。交流是及时的，非常有效率，我一点也不会错过我的魔方。

回答

定期进行回顾是帮助团队提高效率/敏捷度的好方法。
这种做法不仅仅遵循特定的敏捷风格，还可以帮助团队确定有效的方法并适应不断变化的环境。

只要确保进行回顾的人知道他/她在做什么，否则它会演变成抱怨的会话。

我们可以带领团队进行许多练习，以帮助他们反思并从回顾中获取价值。我建议听一下有关软件工程电台Linda Rising的采访，以作一个很好的介绍。

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