Var*_*una 31 agile scrum extreme-programming
敏捷有哪些神话或误解？
有一些与敏捷有关的误解可能会导致普通新人陷入困境.敏捷世界有什么误解,你如何证明这是一种误解呢？
更新:敏捷神话总结
阅读以下答案,了解有关上述神话和更多神话的更多信息.
kiw*_*pom 21
"通过综合文档工作软件"意味着您不需要功能规范......
错误!!!它只是意味着您可以与用户一起反复消除皱纹 - 作为供应商说话,您仍然需要良好的文档来协助QA和签核阶段......
Daf*_*ees 20
"我们正在做Scrum - 所以我们不需要(配对|做TDD | ......)"实际上Scrum的创始人--Ken和Jeff一直在说所有高效率的scrum团队都在实施全系列极端编程实践.
测试驱动开发不会发现所有错误/不容易应用于所有 - 所以我们不会尝试! - 学习TDD并不是"全有或全无"的交易,你可以更好地判断测试内容以及如何有效地进行测试.我已经做了十年了,而且我仍然在寻找更好的方法来做这件事和新的事情.
我可以从书中学到所有我需要应用敏捷方法的知识. - 您需要通过实践来学习,这通常意味着指导和会见可以提供帮助的其他人.当人们试图从书中学习时,很多事情都会出错.
歇斯底里(并且非常真实)"候选人必须接受指导,并支持scrum大师"(根据我上周发送的工作规范......) - scrum master 不应该告诉别人该怎么做.他/她在那里提供便利 - 即帮助团队学会自己解决问题.这是一个巨大的失败模式 - 拥有一个"命令"人的scrum大师!
谈论"敏捷方法论" - 大无能指标.首先,谈论"敏捷"就像是一个特定的事情,而对于许多不同的事情来说,这是一个非常模糊的总括性术语.其次,使用"敏捷"方法 - 有大量的方法,以及大量不同的方法来完成其中的许多方法!第三,敏捷社区中的很多人都反对九十年代大型,重型的UML方法.这些人不倾向于使用"方法论"这个词......
你需要特别有才能的人才能以敏捷的方式开发软件.Jeff Sutherland表示,他们考虑使用"首席程序员团队"模式来管理银行团队 - 但发现他们没有足够的"酋长".Scrum旨在从许多中等能力的程序员中获得最佳生产力.实际上,移除一个不想帮助其他人的不成比例的高效团队成员可以"解锁"平庸的团队成员,并将他们的综合生产力提高到超过补偿超级高效的前团队成员......那就是杰夫无论如何说...
有不少其他XP相关的人,我们在一个开放的空间研讨会,我最近导致想出了:http://xpday-london.editme.com/WhereHasXpGone
Ric*_*kNZ 15
神话:测试优先开发迫使您的项目进行充分的单元测试.
事实:许多开发人员变得懒惰,他们在代码之前编写的单元测试通常很弱且不充分.
神话:结对编程总能产生更好的代码.
事实:程序员往往具有轻微的反社会性,并且彼此之间存在明显不同的思维过程.在编码时让某人呼吸到颈部非常不愉快,结果往往是紧张的工作氛围,同时降低了代码质量和数量.
Pas*_*ent 10
神话:敏捷意味着没有文档
事实:敏捷价值工作软件不仅仅是全面的文档,但这并不意味着根本没有文档.文档应该及时编写,并且足够.不,敏捷并没有说应该总是使用用户故事.如果且仅在适当的情况下使用它们!
神话:敏捷意味着没有计划
事实:如果没有计划,敏捷不支持开发.敏捷使用持续的计划和估算来最大化ROI.实际上,敏捷是关于范围管理的.
神话:敏捷意味着没有纪律
事实:敏捷开发人员必须更加自律,才能获得成功.
神话:敏捷只适用于琐碎的项目
事实:敏捷(实际上是Scrum)已被用于
神话:敏捷不会扩展
事实:Sutherland在500多人的团体中使用了Scrum,Cohn在100多人的团体中使用了Scrum
神话:"没有大设计前线"意味着没有设计.