For the agility of the top five misconceptions

Myth: agile people demanding

Many people try to implement agile: agile requirements too high, we do not have such conditions, we do not have the people, so we can not agile. However, agile requirements really that high?

Software in the final analysis, is also a creative activity, developed the skill level and personal capacity plays a decisive role in the quality of the software or just a variety of processes and methods to help developers, testers and other roles to better cooperation, resulting in higher productivity. Regardless of the method, the developer level is always a major factor.

From another point of view: the process and methods of what help developers how big favor? Is about the same for the lower level of technology developers, agile methods and traditional methods to help him, so to see a less than significant effect, even when there are opposite effect; With the improvement of the technical level of the developer, agile methods be able to unlock the shackles, encourage innovation, and the effect will be more significant.

Agile requirements, and will help you develop the necessary capacity, of course, if you are in really agile environment.

Myth: agile design document, nor do

This misunderstanding from the XP start did not stop, XP encourage non to be necessary and of great significance not write the document. There mentioned "necessary and of great significance" is a criterion, not all documents are not written. For example, the user manual is not necessary and significant "? This depends on the requirements of the customer, if the customer does not need, then they do not need to write, if the customer needs, you must write; Another example, the architecture design document or else write? Complicated to write complex do not write. Architecture design usually only need a relatively simple document, for some projects, a simple UML diagrams is enough. Therefore, write, do not write, how to write, how much significance should be the basis of this document in the end, the decision of the proportion of outputs and inputs, as well as the specific circumstances of the project. Actual operation allows all project team personnel to vote, to be avoided by an individual (such as lead).

As for the design, XP pursuing sustainable design, and not without design. This is actually the design work allocated to day-to-day work, constant design improvements (reconstruction), the design has been kept flexible and reliable. As for the pre-design before coding, Kent Beck et al really practiced without any pre-designed development, but for those of us non-guru "level developers, the necessary pre-designed or need, just not too much, not too fine, there must be the will to overturn ready.

Misunderstanding number three: good agility, and other methods is not good

Some people mention dexterity shouted agile practice anything mentioned CMMI methods such shouted bad, no matter what as long as the stained side on where not good, seems agile and other methods is completely opposite. Newton said that, I am standing on the shoulders of giants. Agility also draw other methodological advantages, but also standing on the shoulders of giants, agile remains many historic practices and principles just different manifestations Bale.

From another perspective, the present do not have a good ring, good or bad depends on whether it is suitable to solve your problem. Each method has the most good at solving problems and the best play environment, demand is stable, and the era of software complexity is relatively high, the waterfall model can also work well, while Min Jieqia good applies to the risk of changes quickly The project - which is precisely the many projects in common.

Therefore choose a method or process, and not according to whether it is agile, but should be based on whether it is suitable. Learned a thing suitability, or want to try to understand things are not proven untrustworthy.

Misunderstanding: Agile XP, Scrum

XP and Scrum are just two of the many agile methods, as well as many other agile methods. The different dragon have nine sons, agile methods look is a big difference, but the reason they are called agile methods, because their underlying philosophy and principles are the same, this principle is "Agile Manifesto". Learning agile not only to study and practice, but also to understand the principle in practice, not only to understand how to do it, but also to understand why they do, and when not to do so.

XP or Scrum full application of your project, but also might not be able to successfully, for others may not be suitable for you. These practices and methodologies agile gave us a starting point, but certainly not the end, the best way for you, but also your own explore and find practical work.

Myth five: agility well, so I want to develop a standard, all projects must follow the standard

Which two projects are the same, the customer is not the same, the staff is not the same, the demand is not the same, not even what may be the same. Not the same environment and problems solved, using the same method, is good is impossible to solve. By serving others, you should find the most suitable method for the project team to determine the method and not let the team to adapt this method. Therefore there was no uniform for all items. Any attempt to unify all the project process methods are incorrect.

The same time, for the same team as the project progresses, needs to understand the depth, the depth of technical understanding, the beginning of the process and methods will gradually not suitable. At this time also timely adjustment process requires a team to ensure the quality and efficiency of the project. Agility is dynamic, rather than static, because this world is change, change the world use the same method, it is unrealistic. Silver bullet never had, and would not exist in the limited future.