题目

英语翻译
From Nothing,to Monumental,to Agile
Most software development is a chaotic activity,often characterized by the phrase "code and fix".The software is written without much of an underlying plan,and the design of the system is cobbled together from many short term decisions.This actually works pretty well as the system is small,but as the system grows it becomes increasingly difficult to add new features to the system.Furthermore bugs become increasingly prevalent and increasingly difficult to fix.A typical sign of such a system is a long test phase after the system is "feature complete".Such a long test phase plays havoc with schedules as testing and debugging is impossible to schedule.
We've lived with this style of development for a long time,but we've also had an alternative for a long time:Methodology.Methodologies impose a disciplined process upon software development with the aim of making software development more predictable and more efficient.They do this by developing a detailed process with a strong emphasis on planning inspired by other engineering disciplines - which is why I tend to refer to them as engineering methodologies.
Engineering methodologies have been around for a long time.They've not been noticeable for being terribly successful.They are even less noted for being popular.The most frequent criticism of these methodologies is that they are bureaucratic.There's so much stuff to do to follow the methodology that the whole pace of development slows down.
As a reaction to these methodologies,a new group of methodologies have appeared in the last few years.For a while these were known a lightweight methodologies,but now the accepted term is agile methodologies.For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the monumental methodologies.These new methods attempt a useful compromise between no process and too much process,providing just enough process to gain a reasonable payoff.
The result of all of this is that agile methods have some significant changes in emphasis from engineering methods.The most immediate difference is that they are less document-oriented,usually emphasizing a smaller amount of documentation for a given task.In many ways they are rather code-oriented:following a route that says that the key part of documentation is source code.

提问时间：2020-12-14

答案

从无到有,以不朽的,以敏捷
大多数的软件开发是一个混乱的活动,其特点常常是一句"代码和解决办法" .该软件是写,没有多大的一个潜在的计划书,以及系统的设计是鹅卵石汇聚了来自许多短期决定.其实,这是工程相当好,因为这一制度是小,但由于该系统的增长变得越来越困难,以增加新的功能使用该系统.此外臭虫日趋普遍,并越来越难以解决.一个典型的迹象,这样的制度是一个长期的测试阶段后,该系统"功能完整" .这么长的测试阶段起着破坏与明细表的测试和调试工作,是不可能如期进行.
我们已经生活在这个风格的发展在相当长的时间,但是我们应该也有另一种在相当长的时间：方法论.方法强加给一个有纪律的过程后,软件开发委员会,目的是使软件开发更可预见,更有效率.他们这样做,通过制定详细的进程,以高度重视,对规划的鼓舞其他工程学科-这就是为什么我倾向于统称他们为工程的方法.
工程方法已经围绕在相当长的时间.这一举措并没有得到明显的为极度成功的.他们更指出,为受市民欢迎.最常见的批评,这些方法是,他们是官僚.有这么多的东西,以做后续的方法,因为整个的发展步伐放慢.
作为反应,以这些方法,一群新的方法已经出现,在过去数年.有一阵子,这些被称为轻量级方法,但现在接受的任期是敏捷方法.对许多人呼吁这些敏捷方法是,他们的反应,以官僚的气壮山河的方法.这些新方法的尝试一个有益的妥协过程中,没有太多的过程中,只提供足够的过程中得到一个合理的回报.
结果,而这一切,是敏捷方法有一些显着的变化,逐步从侧重工程方法.最直接的区别在于它们是那么的文件为主,通常是强调了少量的文件,为特定的任务.在许多方面,他们都是比较代号为导向：经过的路线说,关键的部分文件源代码.