This is the ninth article in the agile development series. (One, two, three, four, five, six, seven, eight, nine)
It is often said that agile development is very similar to "instinctive response". For example, everything needs to be "handled", such as "not stuck in the form", such as "directly hitting the code, do not write useless documents "and so on.
So what is the difference between agile development and instinctive response?
Simply put,Agile development is an instinctive reaction without my status.
No one, no one (no one, no one, no one)
It is reasonable to say that the instinctive response is the closest to the optimal path. First-line personnel, work site, and current problems will certainly find a better way out of the pre-planned path, unless there is a word "I.
1. For example, if a tester is busy recently, several testers need to be dispatched to ensure that the test is not extended. Some developers are likely to come to help with the test, or write some manual-saving automated test code (the latter is our team's practice in, the final result is that 25 developers only need one tester to complete the test.) But if "We Are developers, they are Testers ", in particular, "every time a defect is found, they get 10 yuan, and we deduct 10 yuan.
2. For example, one person encountered difficulties at the daily meeting, and another person had a very easy solution to this problem. One sentence may help save a few hours, but if "I have my job, he has his job", especially "If I have helped him, I may not be able to finish my work.
3. for example, a document does not need to be written in this product, but "if they do not write, it will be difficult for our EPG group to perform the cmme evaluation ", so whether or not to write this document is really a problem.
These separation between me and others makes it difficult to take the best path in terms of things, and most of them will take the best path in terms of human and labor division, this is especially true for "I. In this case, the instinct is wrong.
No current me, no future me (no longer-lived Person)
A person may also have problems.
1. A design is very complicated. It depends on instinct and should be recorded. However, if "I have a clear idea in my mind that no design is required, and no one is maintaining the code in the future", it is easy to skip this document, but it will cause a lot of trouble in the future.
2. Writing a code like this may cause defects in the future, but this version is the fastest. If "I want to write in the fastest way and decide who the future is", most of the code will be bad.
If a person says, the reason why I don't write a document is "I express the design in the Code". If the code is pretty, it does. If the code is bad, it can be seen that the former is just an excuse.
To be honest, the code of most programmers who use "code as design" is very bad.
Create an environment without me
In most of my environments, the solutions proposed by everyone are different for one thing, and none of them overlap with the best solution of this matter, because every "I" takes action in its own interests.
The final result is to allow me to work together and create numerous departmental specifications, workflows, intermediate documents, plans, and intermediate document review criteria, used to constrain each of my jobs. The instinctive response is suppressed.
"How to Create an environment without me?"This question has the best answer in every specific environment. It is difficult to generalize it because it is restricted by specific people, things, and things.
However, if you do not have any precondition to answer this question, there will also be a "awesome" answer, that is, "resonance ".
The so-called resonance means to achieve some results within the controllable range, in exchange for the resonance of others and the future, so as to promote the method.All the great people in the world work in this way, and the influence can reach thousands of miles and thousands of years.
As an individual, I can first break away from the current one. As a small team (for example, three people), I can break down the division of people in a small scope and move forward and backward. As an Development Team, I can break down division and individual assessment in part; as the R & D department, you can implement a new performance appraisal system within the Department.
Although these things seem to have difficulties, compared with those "thousands of miles, thousands of years", they are insignificant. It can be said that they can basically be done without failure.
However, the principle of resonance is to find the Inherent Frequency of promotion of things and make it happen as soon as it is done. Instead, it becomes a pioneer.
I used to change my work frequently in the past 10 years. I tried to find a place where I could make a big image, but all of them failed. After three years of persistence in a company, I was shocked by the outcome. In the past, every company was easily promoted. The only question to be judged was: "Is this enterprise worth pushing?"
The resonance content will be mentioned in more than two articles in this series.
Click to download the free agile development textbook: Martian agile development manual