敏捷开发 敏捷个人_11个敏捷神话和2个真理

敏捷开发 敏捷个人

我提供了很多敏捷培训课程，并且我还做了很多有关敏捷的演讲（ 今晚BCS Bristol ）。 有些问题一而再再而三地出现，这是人们开始相信敏捷的神话的结果。 因此，我花了我的时间一次又一次地揭穿这些神话。

我一直在列出一些清单，有11个重复出现的神话。 还有两个事实，对于团队和公司来说很难接受。

敏捷神话

1. 敏捷是新事物 ：不，敏捷宣言于2001年发布，Scrum Pattern
   该语言是PLoP 1998所希望的作品，Episments模式语言（XP的前身）是PLoP 1995的工作坊， Tom Gilb的Evo方法可以追溯到1976年，有些人可以追溯到更远的地方。
2. 敏捷意味着没有文档：您可以在敏捷中拥有尽可能多的文档。 文档只是另一个可交付成果 ，如果它能为您带来价值，则可以像其他任何东西一样安排和生产它。 请注意：文档通常是未读的，经常无法通信，被用作防御工具，通常是大型软件项目（返工后）上第二昂贵的想法。
3. 敏捷意味着没有设计 ：不，敏捷可能意味着更多的设计。 在开发，每次计划会议等等中，设计都是固有的。 敏捷确实意味着结束了大前期设计，该设计在有人开始编码后五分钟就失效了。
4. 敏捷意味着没有计划 ：不，再次，敏捷可能还有更多计划。 同样，计划是在整个开发过程中而不是在前端进行，这是每个人的工作，而不是一两个受膏者。
5. 开发人员可以做自己喜欢的事情 ：不，如果对您来说这是对的，那么您做错了，请给我打电话。 敏捷需要团队更多的纪律，完成的工作应由通常指定为客户或产品负责人，通常由产品经理或业务分析师担任的特定角色领导。 如果开发人员正在做他们喜欢的事情，那么这个角色就会失败。
6. 用户故事的 大小合适：用户故事的大小合适 。 每个团队都是不同的，克服它。
7. 工作必须适合Sprint：如果您要进行Hard Scrum，则可以。 如果您按照我的方式（现在称为Xanpan ）玩敏捷游戏，那么不可以 。事实上，我建议让故事跨越冲刺，以改善流程。 您可以拥有跨越冲刺的故事，但我们不会让它们永远持续下去，我们将尝试将其分解为较小的部分。
8. Scrum和看板是发誓的敌人 ：不，但是通过这种方式，他们背后的营销努力可以吸引很多眼球。 Xanpan是看板/ XP的混合体，XP与Scrum没什么不同，因此您可以使用。
9. 敏捷不适用于固定期限项目 ：不，敏捷在固定期限项目环境中效果最佳。
10. 敏捷不适用于Brownfield项目 ：不，敏捷在Brownfield环境中效果最佳。 授予改造自动化单元测试的难度更大，但远非不可克服。
11. 敏捷在Greenfield项目上不起​​作用 ：否，但是您的首要目标是使自己进入一个稳定的状态，在该状态下您可以像Brownfield项目一样思考。

在我看来，启动敏捷计划的理想项目是棕地系统，在大约3到6个月内有固定的期限，开发已经开始，但需求尚不明确。 现在有关敏捷的两个事实：

1. 敏捷对我们不起作用，因为…… （请自己完成这句话）
2. 敏捷是一个好主意，但是…我们应该等到完成X，让Y买入，购买Z并得到（新）教皇的祝福后，

您总是可以说服自己，或者找到今天不这样做的充分理由。

参考：来自我们的JCG合作伙伴 Allan Kelly的11个敏捷神话和2个真相在allan的博客上–敏捷，精益，模式博客。

翻译自: https://www.javacodegeeks.com/2013/03/11-agile-myths-and-2-truths.html

敏捷开发 敏捷个人