I collect nuggets of wisdom on various topics. Recently I have been going over the topic of Agile software development; what really matters? Below is a list of 26 key principles to guide an agile software development team.

• Get case 1 fully working before starting case 2. Another way of saying this to use a kitchen metaphor is: “Serve the current meal before starting to cook the next“. The biggest problem with software development is to start a bunch of things in parallel, because inevitably work will include something that is later discarded, meaning wasted work. Work on one case; get it fully functional; get the tests running; write the documentation; check it all in as a finished piece of work, before you start on the next case.
• Never break the build. Pretty obvious, but must be included in any list of software development advice. A programmer who is taking all the proper precautions to test before checking in will never break the build. If the build is broken, it is always because someone took a shortcut.
• Never implement a routine before it is needed in a use case. When implementing a particular class, you should have a particular use case in mind, and you should implement only the methods required for that use case. You might think about the potential for other capabilities on a class, and you might document this in a comment, but implementation should wait until it is actually needed in a use case.
• Never add a data member before it is needed in a use case. Exactly like above except with regard to class data members. It may seem obvious that a “customer” record will need a “ship to address”, but that ship to address should not be implemented until you have a use case which specifically needs it.
• Don’t be afraid to make a decision; don’t be afraid to change an earlier decision. Agile development is about responding to uncertainty and quickly responding. Early in development you do not have complete information. You should delay decisions as long as possible, but there comes a time that a decision is needed to move forward. You can not hold up decision until that information comes in. Instead, make the best decision you can on the available information. Later, when new information arrives, don’t be afraid to change that decision. (Some dinosaurs call this flip-flopping, but I call it reacting to a changing environment.)
• Continually learn how to improve quality. This job never ends, so you should expect to be constantly on the look out for things that could be improved, and collect examples of ways that quality problems were identified and addressed.
• Measure, measure, measure. Agile development is help address the problem of uncertainty about the future, but there should be no uncertainty about the past. Tests should be continually running. Performance of every run should be measured and recorded.
• Design around people, not systems. Too often developers get sidetracked into designing for technical opportunities. You should never lose sight of the ultimate purpose of the software, and that is to help people get work done.
• Tests are part of the product. Many developers and managers consider the product to be what you ship to the customer, and everything else less important. The tests should be considered an actual part of the product, worthy of full consideration during design, and even, in many cases, delivered with the product to the customer. (This latter part is controversial, but a built-in self-test as part of a software delivery takes inconsequential space, and yet provide tremendous benefit when needed. Such an approach should be considered.)
• Write the test before the code. The test itself can be used to clarify the design for exactly what is needed. Many times there are flaws in the design approach which are discovered when working through the test cases. Think how much time would be saved to work through those cases before coding. But: write the test for case1, and code for case 1, before starting case 2.
• Eliminate Waste. Frankly, another ubiquitous platitude which must be included in any list of development principles because it is so important. There is no end to the job of looking for waste where it exists and eliminating it. Eliminate anything that does not add value to the actual customer. If you can not identify the value to the customer, then you probably don’t need it.
• Build a culture of immediate response to build breakage. Understand that when the build is broken, it effect everyone in the project, and so there is nothing more important than making sure that the central core code is building and testing properly. I have seen teams that allowed broken tests to persist for months because is was someone else’s job. Everyone suffered, but nobody acted. Instead, there needs to be widespread recognition that a little work will pay back in a big way over the team.
• Every team member needs to understand the needs of the customer.Large complex projects must be broken into separate teams and further divided for handing out to developers, but this should never be done to the extent that people lose sight of the desires and goals of the actual users of the final product.
• Keep related definitions together. Structure the code so that highly related things are located together, possibly within one class. This is a standard OO design principle of encapsulation. Ideally, all the code outside the class will not need to know the details of the internal workings. Some developers delight in spreading details across multiple files in order to organize in different way: such as to keep all the same data types together, or to organize alphabetically. Fro example, putting all the constants in one class in a different package from where they are being used adds unnecessarily to the complexity of the program. The guiding rule should be to group by relatedness with the result being to hide complexity.
• Always run the tests before checking in. This guideline will help you satisfy the “never break the build” guideline.
• Premature optimization is the root of all evil. A quote from Don Knuth which rings true today. Code should be written well to avoid needless waste at the micro level, but optimization beyond the individual method level should wait until testing within the entire program with a stress test bases on an actual end user use case. Intuition of what is important for overall performance is almost always wrong when based only on a static understanding of the code. Instead, measure the behavior of the complete system, to identify the 1% of the code that really makes a different in performance, and focus on that.
• Minimize backlog of uncompleted coding tasks. When a developer starts to work on a use case, there is a cost associated with all the code that has been modified, but not completed and tested. Holding uncompleted changes for days or weeks adds up to a significant risk of waste due to rework. Consider three tasks estimated to take 1 day each. Starting all three at one time, and working in parallel for three days involves an accumulation of 9 “units” of cost. But doing each task sequentially, completing each task before starting the next, involves only 3 “units” of cost. This is not intuitive. Our intuition tells us that while we are in there, we might as well do three things at once, before buttoning the work up. But software is not like physical construction. Short, quick, and complete jobs not only cause less cognitive load, but also reduce the chance that uncompleted work will conflict with another person’s uncompleted work.
• Never overgeneralize functionality. This is also know as “YAGNI – You Aren’t Going to Need It” . While coding a particular class, programmers like to think with a small tweak this class might be used for several other purposes. This is fine if those purposes are required by the current use case, but usually the programmer is thinking about uses which have not been invented yet, and which may in fact never be needed. (This subject always reminds me of the classic Saturday Night Live skit about the product which was both a floor wax, and a dessert topping.)
• Never use 3 lines when 2 lines would do. Succinctness in code pays every time someone else has to read it. But don’t shrink the code to the point of being difficult to read. Smaller, well written code can easier to maintain and easier to spot errors in, than verbose, ornately written code. Always simplify as much as possible, but no more.
• Never ever measure code by counting lines. The number of lines needed to do a particular task varies greatly from programmer to programmer, and from style to style. The number of lines of code does not tell you much of anything about the completeness or the quality of the code. Code quality can vary by a factor of 200, and this overwhelms any usefulness of the count of the lines. Count instead functioning use cases.
• Continually re-design and re-factor. Apply this cautiously because some code is brittle and difficult to change, but in general you should not be afraid to change the code to match the real use case. A data member may have been an integer in the past, but when a use case requires it to be a floating point don’t be afraid to change it.
• Delete dead code. There is a tendency to let “sleeping dogs lie” when it comes to large blocks of code that is not well understood. One example is adding a new method to a class to replace another, quite often the developer will leave the old method there “just in case”. Some effort should be expended to check to see if that method is needed, and delete it if there is no evidence that it is needed. The worst offense is commenting out blocks of code, and leaving that commented code around. Commented code should be deleted as soon as you know that the tests run, and certainly before checking it in. It is easy to add code at any time, it is hard to delete code at any time. Therefor, at a particular time that you have a good idea that something might not be needed, and small extra effort to verify this and eliminate the code will make the codebase more maintainable.
• Don’t invent new languages. Programmers love to make text files that drive functionality in way configurable at run-time. There are no end of configuration files to be able to change the behavior of the program without recompiling. The advent of XML is driving an unending chain of specialized custom “scripting languages” that allow functionality to be “programmed” by the end user without having to compile. The flaw in this reasoning is that the precise definition of the behavior of the operations almost never well defined outside of the context of a particular implementation, and these types of scripting languages are mainly useful only to people who have an intimate knowledge of the internal working of the code body in question. Thus, real end users without detailed internal knowledge can never possibly know what is necessary to anticipate the effect of complex combinations of commands. Scripting languages have a use, and can not be eliminated, but the designer must take a very very conservative approach and use existing languages as far as possible, and avoid inventing new ones.
• Do not create a design until you are ready to implement and test the implementation. You should have some overall idea of where you are going, and a overview of the system architecture that will be aimed for, but no detailed design, no detailed description of functional implementation should be written down until the development iteration that will allow that design to be implemented and tests. The detailed design should cover only as much as is needed to handle the current use case. The biggest cause of waste in software development is time spend designing things that are not needed or need to be redesigned because of some mistaken assumptions that the design is based on.
• Software is Plastic. Unlike physical manufacturing, software can be changed in significant ways very easily. In fact there is plenty of evidence that software is easier to change than the design specifications that describe the software. Furthermore, software communicates the design more effectively than the specification. Therefor, you should spend the time to implement the design directly, so that customers can see the details of the design. If you miss and have the change the design, it is easier to change the software than it would be to change the spec. But most important, your information about what the customers wants is far better after they have seen the code running.
• Take the time to code a complete description of the problem in the code that detects and reports exceptional situations. Programmers are often very lazy and throw exceptions with superficial descriptions of what is wrong. Thinking that they are the only people who will ever see the problem, and they will remember the meaning of the problem from the vague description included. But in fact more time is wasted in customer support situations because of inaccurate or incomplete error reports than any other cause. Write every error message is if you are explaining the situation to someone who just walked into the room and has no experience with the code. The customer, and the customer support team, after all, have no experience with the code.

These are presented in no particular order. I welcome comments on principles that I have left out, or (if this is the case) principles that you disagree with.

 

 译文（来源网络）： 

我经常收集各种各样的至理名言，最近我重温敏捷开发；真正的问题是什么？下面是一份26条关键原则的清单，以指引敏捷软件开发团队。

1、完整地干完一件事后在开始另一件事：用厨房比喻来说就是：“先上这道菜，再开始做下一道”。软件开发的最大问题就是同时开始几件事情，这将不可避免的造成某些工作被废弃，从而造成浪费。专注于一件事；完整地实现其功能；运行测试；编写文档；签入所有，把这当做一项工作完成，然后再开始下一件事。

2、不要破坏构建：非常明显，但必须被包含在任何软件开发建议清单中。程序员在签入之前采取所有合适的预防措施进行测试，则永远不会破坏构建。如果构建被破坏，通常是因为有人偷懒了。

3、在用例需要之前，不要实现程序：当你实现一个特定的类，你应该在脑海中有一个特定的用例，同时应该只实现用例需要的方法。你可以考虑该类潜在的功能，写入注释之中，但直到用例真正需要时，才应去实现它。

4、在用例需要之前，不要添加数据成员：同上一条，不过这是从类的数据成员角度考虑的。似乎显而易见地，“客户”记录需要“送货地址”，但直到有用例明确需要送货地址，才应该实现它。

5、不要害怕做决定，不要害怕改变先前的决定：敏捷开发是关于相应变化和快速相应的。开发初期，你没有完整的信息。你应该尽可能的推迟决策，直到你必须做出决策的时候。没有信息，无法支持你的决定，相反，在有效信息的基础上做出最佳决定。有了新的信息，不要害怕改变先前的决定。（某些“恐龙”称之为摇摆不定，但我称之为响应变化的环境）

6、持续学习如何改善质量：这项工作永不会结束，因此你应经常留意可以改善的事情，并收集质量问题被确认和处理的案例。

7、度量、度量、度量：敏捷开发帮助处理未来不确定性问题，但对于过去应没有不确定性。测试应持续运行，每次运行的性能表现应被度量和记录。

8、为人而设计，而不是系统：开发者常常因技术而使设计误入歧途。绝不要忘记设计的最终目标，那就是帮助人们完成工作。

9、测试是产品的一部分：很多开发者和经理认为产品就是交付给客户的东西，而其它所有东西都不那么重要。测试应被认为是产品实实在在的一个部分，值得在设计时仔细考虑，甚至，在很多情况下，和产品一起交付给客户。（后半部分有争议，但是内建测试作为软件交付的一部分仅仅占用无关紧要的空间，却在必要时提供显而易见的好处，这种方式应该被考虑。）

10、在代码之前编写测试：测试本身可以用来阐释真正需要的设计。设计的缺陷常常是通过测试用例被发现的。想想看，编码之前，通过这些用例，可以节约多少时间。但是，为用例1编写测试，然后编码，然后再开始用例2。

11、消除浪费：坦率的说，这是另一个必须包含在任何开发原则清单中的陈词滥调，因为它太重要了。发现浪费并消除它，这项工作没有尽头。消除任何不能增加客户价值的东西。如果你不能确认客户价值，那很可能你并不需要它。

12、建立对构建破坏立即响应的文化：要明白当构建被破坏，会影响项目中的每一个人，因此，最重要的是确认核心代码被构建并合理测试。我曾见过有些团队放任失败测试持续数月，因为那是其它人的工作。每个人都痛苦，但没人采取行动。想反，必须形成共识，那就是小工作能为团队获得大的回报。

13、所有团队成员应理解客户需要：大型的复杂项目定然被分解为独立的团队，进而被分派给开发人员。但是，不应在此范围内做的是，失去关注最终项目真正用户的期望和目标。

14、把相关定义放在一起：组织代码以使高度相关的事情在一起，或在一个类中。这是标准面向对象设计封装原则。理想情况下，所有的类外的代码不需要知道内部工作细节。一些开发者乐于将细节扩散到多个文件中以便按不同方式组织，如所有相同的数据类型放在一起，或者按字母顺序组织。例如，在他们要用的不同包中，将所有常量放在一个类里，这增加了不必要的程序复杂性。指导原则应该是按相关性分组从而隐藏复杂性。

15、始终在签入之前运行测试：这条准则帮助你满足“不要破坏构建”准则。

16、过早的优化时万恶之源：引用高德纳被证实的话：代码应编写良好以避免微观层面的浪费，但独立方法层次以外的优化应等待整个程序基于真实的最终用户使用情景的压力测试的进行。仅仅基于对代码的静态理解，直觉地判断对整体性能什么是重要的，结论几乎总是错误的。相反，度量整个系统的行为，辨别1%真正影响性能的代码，并专注于此。

17、减少积压未完成的编码任务：当开发人员开始一个用例，会发生成本，跟已修改却未完成和测试的代码相关联。留着未完成的变化几天或几个星期会累积成巨大的重做风险。考虑每个估算需要一天的三个任务，同时开始这三个任务，并在3天内同时进行，意味着9个单位的累计成本。但是顺序进行每个任务，完成一个再开始下一个，意味着只有3个单位的成本。这个不是直觉，直觉告诉我们，在工作完成之前，我们不妨同时做三件事情。但软件不像物理构造。短小，快速和完整的工作不仅减少认知的负担，而且减少未完成工作与他人未完成工作之间冲突的可能。

18、不要过度强调代码的通用性：这就是著名的“YAGNI-你不会需要它”。当编写一个特定类的时候，程序员总喜欢认为该类可能用于其它用途。如果现在的用例需要这些用途，这很好，但是，程序员经常考虑未被提及的用途，或者那些实际上永远不需要的。（这常常让我联想到经典的周六现场滑稽短剧，关于某产品既是地板蜡，也是糕点上的甜食。）

19、两行代码能行，就不要用三行：有人阅读时，简洁的代码总能获得回报。但不要将代码压缩到难以阅读。更小的，编写良好的代码比之冗长的，编写华丽的代码更容易维护，也更容易发现错误。始终尽可能简化，但别过分。

20、不要用行数来度量代码：完成特定任务所需的代码行数，不同的程序员之间和编码风格之间差异很大。代码行数不能告诉你代码完成和质量的些许东西。代码质量可以相差200倍，这足以抵消代码行数的作用。应该统计功能用例的数目。

21、持续地重新设计和重构：谨慎地使用这条准则，因为有些代码脆弱而难以改变，但通常你不应害怕更改代码以符合实际使用情况。一个数据成员过去可能是整数，但是当一个用例要求它是一个浮点数时不要害怕去改变它。

22、删除死代码：涉及到大量不能很好理解的代码是，有个倾向是不自找麻烦。一个例子就是往类中增加新的方法去替换另一个，开发人员常常会留下旧的方法以防万一。必须努力检查方法是否必须，如果没有证据表明它是必须的，那就删除它。最糟糕的就是注释掉大量的代码，并把它留在那儿。注释掉的代码应在测试通过后尽快删除，当然应在签入之前。因此，某个时候你发现一些东西可能并不需要，付出小小的努力去验证并消除此代码能让代码基线更易维护。

23、不要发明新语言：程序员喜爱使用文本文件配置在运行时驱动功能。没有配置文件能够不编译而改变程序的行为。XML的出现推动了无休止的专门定制“脚本语言”的浪潮，以使功能能被最终用户定制而不需要编译。这种推理的缺陷在于，离开某个特定实施的环境，操作行为几乎从来没能很好地精确定义，同时，那些脚本语言只对那些对问题领域代码的内部运行有深入了解的人有用。因此，不具备详尽内部知识的真实最终用户永远不可能知道预料复杂的命令组合的效果需要什么。脚本语言有用，也不能被消除，但是设计者必须采取非常非常保守的态度，尽可能使用现有的语言，避免新的发明。

24、在你准备实现并测试前，别做设计：你应该有行进的总体思路和对系统架构的概览，但是，直到开发迭代允许设计被实现和测试前，不要做详细设计，不要编写功能实现的详细说明。详细设计应当只涉及到处理目前的用例。软件开发中最大的浪费源于将时间花在设计那些不需要，或者因为某些错误的设计假定而需要重新设计的事情之上。

25、设计是可塑的：不像物理制造，软件可以很容易地获得显著改变。事实上，有大量证据证明软件本身比描述软件的设计说明书更容易改变。此外，软件比说明书更有效地传达设计。因此，你应该把时间用于直接实现设计，让客户能看见设计的细节。如果你犯错并改变设计，改变软件比改变规格更容易。但最重要的是，客户看到代码运行后，你关于客户想要什么的信息大为完善。

26、花时间编写发现和报告异常情况的代码中的问题的完整描述：程序员往往很懒惰，抛出粗浅描述错误的异常。认为他们永远是唯一会看到这个问题的人，并且他们从含糊的描述会记得这个问题的意思。但实际上，在客户支持环境，不准确或者不完整的错误报告比其它原因浪费更多的时间。编写每个错误消息，就好像你正向某个正好走进房间并且没有此代码经验的人解释状况。客户和客户支持团队毕竟没有此代码的经验。

这些介绍没有特定的顺序，欢迎讨论我忽略的原则，或者（如果是这种情况）你不认同的敏捷开发原则。