极限编程和瀑布编程
对我来说,极限编程的思想可以归纳为以下几点:如果我们采取我们所知道的工作,并且在某种程度上乍看起来似乎是不合理的,那将会发生什么?
您会很快注意到,如果您进行较早的测试,则测试会更加有效。 不合理的早期是什么:在我们要进行测试之前先进行测试。 因此,测试驱动开发的思想诞生了。
您会很快注意到,代码审查是提高质量和在团队中传播知识的有效形式。 不合理的代码审查量是多少:所有代码应由两个人编写。 即,成对编程。
类似地,用户故事的想法来自以下观察:用户与开发人员之间的通信是有效开发用户友好系统的关键。
极限编程的一些想法不再那么极端了。 但是精神应该继续下去。 今天所知道的事情在不合理的程度上起作用意味着什么?
以持续集成为例。 大多数团队在签入代码时都使用持续集成来运行测试。 如果每当发生变化时我们运行测试会怎样? 如今,大多数语言都支持连续测试或自动测试,并且团队现在开始采用这种方法。
对于当今的许多组织而言,频繁发布可能意味着每1-3个月发布一次。 如果您将频率从几个月增加到几周,或者从几周增加到几天,将会发生什么。 还是几天到几小时? 实际上,一些极端的组织在成功完成一系列自动化测试后,便会自动将更改推入生产。
短迭代工作和减少并行工作可帮助当今的许多组织。 如果我们完全放弃了迭代,而开发人员在准备就绪时选择了下一个故事,该怎么办? 如果我们将所有有关用户故事的讨论推迟到开发人员准备开始对其进行编程时,该怎么办? 许多组织正在使用看板的变体来增加流量并减少浪费。
极限编程意味着将工作推向更高的高度。 您想以合理的价格做些什么好主意?
参考: 极限编程有多极端? 我们的JCG合作伙伴 Johannes Brodwall在大盒子里的思考
翻译自: https://www.javacodegeeks.com/2011/10/how-extreme-is-extreme-programming.html
极限编程和瀑布编程