About Agile Software Development

Today and tomorrow, the company contacted experts from the foreign special authority to train us for agile development. Both experts have been working abroad for about 20 years, communicate with them to gain a deeper understanding of agility.

I got into touch with agile thinking at the end of 03, and I was passionate about promoting it in the development team in 04 years. Later I basically failed, and I didn't deliberately stick to any terms in the next few years, keep the core idea of Agility: communication and quality, and use your own methods to promote development based on your situation. In terms of methodology, there are basically four differences, or my management methods are agile.

I attended lectures by two experts and made some group discussions and communication. I think it is worth remembering:

1. Agility does not apply to all projects.
For example, traditional software development is a shell, and agile development is a cruise missile.
For fixed targets, the cost of using shells is low and the hit rate is high.
If it is targeted at a mobile target, the hit rate of traditional shells is very low, and the total cost of hit is very high, the cruise missile will continue to track the target and adjust the direction.

Agile development and traditional software development are just two different tricks. Different tricks are used to deal with different projects. After several years of development, the mutual integration of the two methods is becoming more and more obvious.

2. The industry has misunderstandings about agility. The most typical representative of agile development is XP. At the beginning of its appearance, because of its rebellion against the traditional software development ideas, its fans were somewhat enthusiastic, it is not especially rational. When adopting agile or XP, some people do not have full understanding of it, and tend to take the lead. For example, agility says "the software that can work is more important than the document ", but it is understood by many people that documents can be avoided. Some people may even be eager to submit documents when practicing XP.

Both agile and XP RequireAppropriateBut XP does not have very strict style requirements on the document. It can be used to draw a sketch on paper or a picture taken on a whiteboard.

3. The most common cause of agile development failure is to partially adopt its best practices.
Some people only see the fast, simple, and free aspects of agile claims, but ignore the rigorous and complex aspects. Many practices of agile development, such as refactoring, suchCodeCommon, such as continuous integration, all have the most important premise: completeAutomatic Test. This is exactly the most complex and difficult to implement in Agile development, but it is the core.

If you cannot do it, and claim that you are in Agile development, it is easy to evolve into a disordered state. Because there is no way to ensure that there is no problem in the restructured code, as codebase continues to grow, there will be more and more situations that require fire fighting.

4. Agile development is a culture with high requirements on organizers.
In traditional software development and management processes, we are committed to ensuring that what we do is not biased through restrictions and clear regulations. Agile development advocates a culture that allows everyonePositiveTo create better results.

 

I personally like agile development very much, mainly because it is too attractive to describe the agile development team's work scenario in the book. After years, I still have an impression on my mind:
On the walls of the developer's room, a whiteboard is mounted as long as there is no space. Do not erase the results discussed on the whiteboard. Everyone can raise their own questions about the design drawings on the white panel and discuss them at any time. In Pair programming, two people write code while communicating. One person knocks on the Code and one person reminds them of possible errors, which are exchanged at intervals. Keeping code refined makes people think it is a piece of work of art. Use CRC cards to discuss the assignment of story scenarios and tasks like making movies.

These are wonderful, and I am very much looking forward to my team working like this one day. This requires the right company, the right team, and the need to solve the problem of automatic testing.