敏捷开发 敏捷个人
我提供了很多敏捷培训课程,并且我还做了很多有关敏捷的演讲( 今晚BCS Bristol )。 有些问题一而再再而三地出现,这是人们开始相信敏捷的神话的结果。 因此,我花了我的时间一次又一次地揭穿这些神话。
我一直在列出一些清单,有11个重复出现的神话。 还有两个事实,对于团队和公司来说很难接受。
敏捷神话
- 敏捷是新事物 :不,敏捷宣言于2001年发布,Scrum Pattern
该语言是PLoP 1998所希望的作品,Episments模式语言(XP的前身)是PLoP 1995的工作坊, Tom Gilb的Evo方法可以追溯到1976年,有些人可以追溯到更远的地方。 - 敏捷意味着没有文档:您可以在敏捷中拥有尽可能多的文档。 文档只是另一个可交付成果 ,如果它能为您带来价值,则可以像其他任何东西一样安排和生产它。 请注意:文档通常是未读的,经常无法通信,被用作防御工具,通常是大型软件项目(返工后)上第二昂贵的想法。
- 敏捷意味着没有设计 :不,敏捷可能意味着更多的设计。 在开发,每次计划会议等等中,设计都是固有的。 敏捷确实意味着结束了大前期设计,该设计在有人开始编码后五分钟就失效了。
- 敏捷意味着没有计划 :不,再次,敏捷可能还有更多计划。 同样,计划是在整个开发过程中而不是在前端进行,这是每个人的工作,而不是一两个受膏者。
- 开发人员可以做自己喜欢的事情 :不,如果对您来说这是对的,那么您做错了,请给我打电话。 敏捷需要团队更多的纪律,完成的工作应由通常指定为客户或产品负责人,通常由产品经理或业务分析师担任的特定角色领导。 如果开发人员正在做他们喜欢的事情,那么这个角色就会失败。
- 用户故事的 大小合适:用户故事的大小合适 。 每个团队都是不同的,克服它。
- 工作必须适合Sprint:如果您要进行Hard Scrum,则可以。 如果您按照我的方式(现在称为Xanpan )玩敏捷游戏,那么不可以 。事实上,我建议让故事跨越冲刺,以改善流程。 您可以拥有跨越冲刺的故事,但我们不会让它们永远持续下去,我们将尝试将其分解为较小的部分。
- Scrum和看板是发誓的敌人 :不,但是通过这种方式,他们背后的营销努力可以吸引很多眼球。 Xanpan是看板/ XP的混合体,XP与Scrum没什么不同,因此您可以使用。
- 敏捷不适用于固定期限项目 :不,敏捷在固定期限项目环境中效果最佳。
- 敏捷不适用于Brownfield项目 :不,敏捷在Brownfield环境中效果最佳。 授予改造自动化单元测试的难度更大,但远非不可克服。
- 敏捷在Greenfield项目上不起作用 :否,但是您的首要目标是使自己进入一个稳定的状态,在该状态下您可以像Brownfield项目一样思考。
在我看来,启动敏捷计划的理想项目是棕地系统,在大约3到6个月内有固定的期限,开发已经开始,但需求尚不明确。 现在有关敏捷的两个事实:
- 敏捷对我们不起作用,因为…… (请自己完成这句话)
- 敏捷是一个好主意,但是…我们应该等到完成X,让Y买入,购买Z并得到(新)教皇的祝福后,
您总是可以说服自己,或者找到今天不这样做的充分理由。
参考:来自我们的JCG合作伙伴 Allan Kelly的11个敏捷神话和2个真相在allan的博客上–敏捷,精益,模式博客。
翻译自: https://www.javacodegeeks.com/2013/03/11-agile-myths-and-2-truths.html
敏捷开发 敏捷个人