著名的敏捷12原则更加详细阐述了敏捷的宣言的内涵，在拙作“知行合一：价值驱动的敏捷和精益开发”.一书第二章，我花了很大精力讲了我的理解。
敏捷12原则
其中第十条敏捷原则是我最喜爱的，这一条最容易被误解，需要时间逐步领悟。原文是：Simplicity – the art of maximizing the amountof work not done – is essential。 我的翻译是：简于形——是最大化的减少不必要工作的艺术——这是敏捷精髓。其实这句话的翻译让我花了很多精力推敲，虽然最后呈现的也并不十分满意，但也只能姑且这样了。敏捷是一种在有限范围内尽量求全的艺术，而并不是追求完美的艺术。如开发团队不可能预期后面需求会如何变化，所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件，而会把注意力放在如何用最简单的方法完成现在需要解决的问题。如果你已经预计到了肯定存在的需求扩展点，是否一开始就考虑呢？团队可以需要根据自己的最好理解去决定是否考虑，如果深信在明天发生了这个问题也可以很容易处理的话，那么就最好先不考虑。尽量只做刚刚够的东西（just enough）以及在恰当时刻（just in time）做决策是敏捷的核心实践之一。
这学期，我教授软件工程一门在线研究生课程：敏捷和精益的软件项目管理。每周我们会有一个在线讨论题目，上周的问题是“用实际例子说明如何运用敏捷第十原则”，由于MSE学生基本都是有比较丰富经验的在职软件从业人员，在教课过程中，我也能从他们身上学到不少有意思的实践。
今天刚刚看完了所有讨论，随机选了4个和大家分享下。 也许这些例子可以帮助大家从做僵化的敏捷（doing agile）转成灵活运用敏捷理念（being agile）。实在没有时间把这些讨论翻成中文，委屈大家了，不过可以把这当作英文阅读理解练习了。
学生甲：
“I would like to start with a quote by Brian Kernighan that resonates with mydevelopment mindset: “Everyone knows that debugging is twice as hard aswriting a program in the first place. So if you're as clever as you can be whenyou write it, how will you ever debug it?”
I believe that on onehand this message serves both a powerful illustration of a need for simplicityin software modern development. However, on the other hand, it illustrates thegreat deal of damage that uncontrolled programmer’s ego and search for illusory perfection of code can cause. People are bad at understanding complex and abstract ideas. People are even worse at explaining these ideas. One of the fundamental challenges of modern software construction is the sheer complexityof problems it attempts to address. The only reasonable way to constructively deal with these challenges is to generalize, abstract, and decompose complexity into its building blocks and simpler forms; in my opinion, it is best to keep decomposition until no further logical interpretations are possible. Nature strives for simplicity in its every form, so why are we so against being and seeming simple? I believe that programming is a natural extension of human intellect. In this lies its wonder and also dangers.
Naturally, people attempt to generalize and simplify things that they do not understand or agree. Effectively, complexity opens a door to multiple unforeseen interpretations -100 people, 100 ideas. This in a good thing when we talk about abstract concepts of art, music, love, and perhaps a meaning of life. However, this is avery bad thing when we deal with mission and life critical code. Software development and developers must never attempt to focus on produce “beautiful”or creative code. Our professional duty is to design and construct code that is functional, reliable, and maintainable. Simplicity of code play a fundamental role in each of these 3 elements. Functionality of code is being able to perform a fixed task. Functionality is simple by definition as long as it follows single responsibility - This code does this and nothing extra. Everything extra is an unnecessary obstruction to its level of simplicity. One may ask how reliable code can even be “unsophisticated” to address all possible problems thrown at it. First of all, one really should never attempt constructing such code. It is hard if not impossible and promotes complexity. Secondly, reliable code is one that works every time (within any design margin). It is arbitrarily challenging to determine if complex code works every time forit is just as challenging (if not more so) to test. The only way to systematically produce reliable code is to make its composition individually simple and testable. When it comes to code maintenance, one dirty truth of software development is that majority of the work we do has to do with legacy code. Every developer’s nightmare is to deal with undocumented yet sophisticated and arguably painting-worthy algorithm someone wrote 5 years agoon a napkin and transcribed into enterprise level banking infrastructure software. As I discussed above, people are bad at translating abstract ideas. If you truly want your legacy code to become your legacy, keep in mind that maintainable code is simple for it can be understood and improved by other people when you are no longer around. We might think that we write code to communicate with machines, but we really write code to communicate with fellow developers. Machines are stupid and will digest everything thrown at them without looking twice - garbage in, garbage out. People won’t.
Simplicity of code promotes healthy lean development without excess waste in the form of added“features”. “Features” are only features when customers openly recognize and desire added value. Otherwise “features” are simply wasting development time,complicate code, and consume valuable development resources. Agile is built around adapting to changes versus following an established plan. Simplicity of code development is to construct just enough to address the specific functionality and stop right there. When change happens, adapt and add thenow-missing functionality, and stop again. As developers, including myself, weare guilty in our attempts to predict the “what-if”s and foresee the larger plan when things are unknown. However, the things are often do remain unknown until they are not. Very likely your predictions are false yet you already built in all the possible features that the customer might ever want into your God-module with 32 input parameters. When tempted with in advance answering questions that no one yet asked (or ever will), just remember there is a big chance that you ain't gonna need it.
I have a fellow colleague at work. He is a senior software developer and has been working on his toy idea for a few years - an ultimate automated test generatorthat would be able to fully generate hardware specific test sequences.Seemingly great idea - potentially significantly simply development effort of new test products and produce uniformity of software approach to many products. The bad news is that the management actually bought into this idea of solo rogue-like development not understanding the magnitude of this project. Perhaps the developer’s ego prevented from conveying this magnitude to the managementand fellow developers. Who would ever want to share code ownership, right? Wrong. Few years and millions dollars later, long time after many other developers moved on with their working software test products and much simpler implementations, the project grew to be so complicated it had to be abandoned without any chance of resurrection. The implementation grew out to be soobscure and cumbersome, no one could understand how to use the framework. The morale of this example is not to be ambitious in trying to solve everything atonce and alone. Don’t waste in the name of creativity. Be simple and be humble.”
学生乙：
“ One example relates to decision makers choosing how to set up their departmental web pages within their division. Basically, our public facing websites consists of sites that were either created from scratch, outsourced and professionally built, or created from our campus template. Although choosing to use the campus template keeps things simple, there are many thatprefer to create their sites from scratch or outsource, which is fine as longas they have someone who can maintain it and keep up with campus standards. In reality, most people have it set up and leave before being held accountable for failing compliancy. Sites that were professionally done usually end up getting scraped because no one understands the back-end code because the web designer got paid and is long gone. As a result, the decision maker is back to square one.
While I spend a good portion of my work time helping people troubleshoot web related problems, I believe that by using the campus templates, one is truly maximizing the amount of work not done. First of all, the templates meet campus standards so anyone can take advantage of the features offered and know that it’s been tested and officially approved. Secondly, it’s easy to use and is managed by IT so there’s no need to hire someone with a specific technical background. Departments save money while the web team maintains and upgrades the templates and offers training, support and resources to those who need it. Finally, it’s completely accessible out of the box so it will pass compliancy. One less thing toworry about.
As more and more departments end upgoing with the campus templates after experiencing the headache of building from scratch or outsourcing, it ultimately becomes a slow but steady reductionin time and money wasted.”
学生丙：
“One story immediately comes to mind when discussing simplicity and software development. It all started in the early 90s when a class-action lawsuit wasfiled against the Los Angeles Unified School District (LAUSD) on behalf of students with disabilities. The allegation was that the district’s special education practices were in violation of the requirements of the Individuals with Disabilities Education Act (IDEA).
Specifically, the violations were in the “areas of child find, identification, tracking of student records, and placement. The LAUSD promised to create a computer database system, which they called MISIS (My Integrated Student Information System) –originally called only ISIS, to track comprehensive information on every student in the district.
LAUSD contracted acompany to build the system in 2003, and the system was supposed to be finished in 2007 Fast-forward to 2014 and the project had had many false starts and delays. The district had spent several millions of dollars but it was found that the system was “plagued with major defects or bugs”.
Due to the large numberof defects, back in 2010, LAUSD put the project on hold and stopped paying the contractor they had hired. The district looked for other ways to complete the project, including using software that had been developed by Microsoft for the Fresno School District. However, the Microsoft-developed system was not any better (succeeded at 20% of tasks) than MISIS (which succeeded at 82% of tasks).
The LAUSD went as far assuing the software vendor for the faulty and late software. However, the vendor was able to prove in court that the software they delivered was “as required” and that the problem was caused by mismanagement in the part of the district, including “frequent turnover in administrators and staff”, which led to"constantly changing requirements". The district, not only lostthe lawsuit, but they were also ordered to pay the vendor $10 million. After a settlement LAUSD was only required to pay $3.75 million.
When the system was rolled out in the 2014-15 school year, several things went wrong: schedules for high school students were not accurate, some students were stuck in their auditoriums for days. There were also issues saving newly-enrolled student’s information. Attendance records were also not saved accurately.
I can only wonder how differently things would have turned out if the LAUSD had focused first onsolving their original problem regarding special education students,instead of trying to come up with a solution that affects every student in the district. After solving the original problem with a small set of students, they could have scaled the solution forthe entire student body.
This example illustrates how simplicity can be hard to miss sometimes, when the amount of work not done is not maximized, there is potential forproducing a lot of waste.”
学生丁：
“From my experience, the 10th Agile principle Simplicity is something that teams try to follow but is most times influencedby higher management.
One of the examples that come to mind is at my current work place when we tried to introduce an array of workflows and issue types to our sprint boards so that the management could micro manage and keep track of individual tasks and workflows. Even though the idea seemed great on paper, the implementation of the workflows and these issue types caused a lot of restriction for the teams such as the following,
1. Each issue type had a specific workflow and some of the issue types had certain restrictions moving between swim lanes onthe sprint board.
2. Restriction on moving Issue types on the board was also made based on user groups where certain user groups were unable to move certain issue types which caused a lot of confusion among the team.
3. The various issue types and workflows were prone to human error and we noticed most times where teams members used the wrong issue types which did not reflect correctly on the management metrics.
After using this detailed structure for a couple of Sprints we noticed that the teams were spending too much time figuring out what goes where in the sense and it was disrupting the productivity of the team when it came to the real work of developing a functional solution at the end of each sprint.
Finally the management team was convinced and it was decided to get rid of this detailed issue type and workflow management and a simple solution was introduced which reduced the number of issue types toonly the high priority issue types and the workflows were minimized and simplified to include fewer swim lanes so that the tasks can move much smoother through out the sprint. This new approach also reduced confusion within the team and also improved the productivity and efficiency of the scrum team ineach sprint.
Overall simplicity is a key factor when it comes to Agile, where over engineering certain processes and activities could be avoided and a more focused product can be built which results in delivering value to the customer.”
