Review of agile development process

Since learning and trying agile, it is currently the third team.

The first team, in a small company, is responsible for one of the two development teams of the company. It was the first time that I took the lead in development and did not have any project management experience. Under the strong development pressure, I had some time to make myself overwhelmed: The team members were relatively idle, because they are not able to solve complex problems, I am busy every day. After studying project management, I tried some traditional management methods, which were not very powerful. Then I came into contact with extreme programming and agile development.

The first agile attempt surprised me a lot. We have made major upgrades to an old system (a noodle program that has been built up for several years can be imagined as bad)

In this development process, we attempted to deal with some agile methods such as programming, test-driven, presentation, review and summary.

This is a very beneficial attempt. We successfully completed the upgrade, reducing the workload of the customer service department by 90% (data provided by the customer Department) (solving customer errors ), the methods recommended by agile are very beneficial, but some problems have also been found in the attempt.

1. test-driven development requires developers, and test-driven development requires developers. A complete test-driven development is a disruption to the conventional development process, when the children's shoes who have just graduated from school (the company has limited funds and have to become a programmer's cradle) are not familiar with programming languages, it is almost impossible to ask them to be test-driven. The test is required to give priority, almost pausing the project progress.

2. the effect of pairing programming on the progress. The long-term persistence advantage is obvious, but the development team is strong and weak (the composition structure of many project teams was such a structure at that time) there are also many problems. First, the strong and weak pairs may cause pessimism or dependency on the weak side, at the same time, it also delays the progress of the strong Party (when the project progress is highly dependent on 1, the delay is serious ). The effect of pairing two weak people is weak. It takes a long time to see the effect (at least three months to six months ).

3. the effect of the Opening Ceremony gradually decreases. When the freshness of the early stage of the Conference passes and the project progress is under pressure, the effect of the project is obviously weakened. the establishment will become a simple and payable statement for the participants to present their work, they do not care about each other's work.

 

Some variations:

1. the test driver is adjusted to enhance the test and mutual test, and 1 is strong in the release test. You can also write test cases by a strong developer, or use code reviews to replace tests to reduce requirements for junior developers.

2. Loose Pair Programming (I saw related articles some time ago and used nouns) to enhance the discussion of program design and reduce the code pairing. However, weak and weak pairs are still under unforced advocacy.

3. organize and hold meetings in turn, exchange and discuss the work of the other party, and rotate the work content

The second team, I went to a large company. The development of large companies is systematic and compiled. For example, to upload files, you need to write (or copy) the upload function for the first team, but in the second team, we need to find the interface required by the team responsible for uploading files. For example, for processing big data tables, the first team needs to split tables and database shards. The second team can find a more core R & D team to solve the problem of large data volumes.

The second team is a very unhappy experience (although the leaders and colleagues are both good, although the year-end experience is also generous). When the second team was established, agility has not yet been born. After years, the company where the second team is located has formed its own development culture (influenced by the company culture ), simple, fast, and product-oriented development (I don't know if this is an accurate description, but it's just my own feeling ).

This is our development process. In this process, I am in charge of a development group, but I cannot promote agility for many reasons:

1. for simple products, the personal abilities of the members of the second team are much better than those of the first team, while the product difficulty does not increase or decrease. For most projects or functions, we only need to design several tables, then it is displayed in the form of web. In such a situation, pairing and testing will only waste time and then let the leaders roar (speed is one of the principles highly respected by the company, so it is a common task to pick up the lights at night ). The meeting also becomes dispensable. The development pressure of the second team is relatively high, not because of the difficulty of the product, but because of a large number of simple products and the continuous revision of these products, A large number of simple products can only make us skilled.

2. Simple architecture. The company has a general design framework and a simple three-tier architecture. In view of the simplicity and complexity of the product architecture

3. A loose team, although I am in charge of an Development Team, I have no full control over the team members. The Senior Technical Manager above me will lead and arrange the work of the team members, team members are often sent to support the development of other groups (of course, sometimes other groups also need to send someone to help us develop the Group)

Wait. There are other reasons. I cannot list them one by one. There are two core reasons:

1. The development process of the team has been fixed. It is difficult to make changes and to challenge the inherent and inert culture.

2. Agile development requires high-level support. The loose development team gives me no chance to try agile in my own group.

Currently, I am in my third team, which was not often established. I have promoted some Agile Methods internally and released three beta programs, in the future, we will gradually summarize the agile attempts in this team.

Summarize some of your agile feelings:

Agile Efficiency:

Agile development requires long-term persistence, and early implementation of agility may not immediately see obvious results

Applicability of agility:

I remember that when agile development emerged, one of the cases was that the team gave up or rarely used junior developers, and took full advantage of the Efficiency of senior developers to complete the project. In discussions with friends and colleagues, it can be basically confirmed that agile is more suitable for teams composed of middle and senior developers. Some agile principles are the extraction of the development process of senior developers.

For teams that mainly include many junior developers, it is best to make some changes in implementing agility (unless the boss allows you to perform agile training for the team for 3-6 months without asking about the progress)

Agile periodic promotion

1. Presentations, reviews, product design discussions, simple implementation principles, etc. This is a simple, quick, and obvious agile method.

2. Pair programming. Long-term Pair programming has a significant effect on improving the overall strength of the team. If the agile development environment is not ideal, you cannot fully Pair programming, and you have a better choice for loose programming. For Pair programming, you can also use a pair when necessary instead of a complete pair.

3. User stories and iterative development allow us to better understand products, and allow us to quickly respond to changes in product requirements. My practical results show that the project progress is faster. If users and product personnel cannot be involved in development, timely feedback on the project progress is beneficial to the development of the project.

4. test-driven, refactoring, and better design patterns. These methods have high requirements for team members. It is not a good idea to enforce them if the team members are unable to develop such products, the combination of strengths and weaknesses, enhanced training, and enhanced code review and restructuring gradually formed a development atmosphere, slowly affecting team members.

Without formal agile training, I found myself agile in practice. I have been stumbling for several years. There are many mistakes. You are welcome to comment on them.