Shulou(Shulou.com)06/03 Report--

When it comes to agile development, it is not agile because of agility. In recent years, agile development has been mythical by many agile consulting service providers. This thing is not an artifact, and its implementation can solve the problems of all software companies. Instead, it is necessary to combine the characteristics and problems of your own company to find out a set of models that suit you.

As we all know, at the beginning, startups need to develop a product that can make the company money, but most startups can't do it so easily, and the capital chain of many companies' unsuccessful products is broken and the company is dead. Our company is in such a situation that there is a product line that can maintain the company's expenditure and only meet the surplus. It is not enough to expand the rapid development, and there is no point in starting a business all the time. The other line is to do technological innovation in order to develop a popular product in the future, but you can't develop it hungry. How do we implement agile development according to our own characteristics? A problem, a big problem!

Our technical team is configured like this: 1 technical director, 2 senior development engineers, 1 senior development engineer, 2 potential development engineers, 1 front-end development, 1 test. The technical director needs to deal with a lot of team management and customer management work, and can participate in the project for up to 1/2 of the time per day. Two senior developers need to be responsible for mentoring other engineers and have been involved in the development of new projects for about 80% of the time. Senior engineers should set aside time for project study, which is about 90% of the time they participate in the project. Potential development engineers need some time to learn technology and projects, but they can basically devote 70% of their time to projects. Front-end development and testing are revolutionized wherever they are needed, belonging to the mobile unit.

There are now a total of six old projects under maintenance and two new projects to be developed. The maintenance of six projects requires a total of 4 man-days per week (it takes 1 person 4 days to complete a task). One of the new projects, Project 1, has an estimated development time of 120 man-days and needs to be completed within 1 month. "Project 2" is estimated to take 40 man-days of development and 2 weeks to complete. The current manpower is calculated according to the time that can be invested, and the total resources are (1 * 1 beat 2 + 2 * 8 shock 10 times 1 * 9 times 2 * 7 hand 10) 30 days = 132 person days, 6 old projects need 4 person days per week, 4 weeks a month, 4 * 4 = 16 person days. The resources that can be invested in the project are 132-16 = 116 person-days, while a total of 120 + 40 = 160 days are required, a full reduction of 44 person-days, which seems to be an impossible task.

In the end, however, we completed these two projects using agile development, which did not affect the maintenance of the old project. How do we do it? At the beginning of our two development, at this time as long as two people can work well together to develop the product, do not need any model. With the expansion of the staff, it is necessary to think carefully about how to work together between teams to complete the task on time, quality and quantity.

Try one, traditional software development model. The whole process is requirements analysis, system design, task decomposition planning, development design, coding, testing, delivery, acceptance and maintenance. This model is also the most commonly used model, but this is how we operate when applied to our company.

Traditional development process

Due to the start-up of the company, the boss has an idea, but can not well describe the requirements, so the task of requirements analysis falls on the technical director. The system design and task decomposition are initially completed by the technical director, and later the senior development engineer can bear part of it. Development and design can be completed by various development engineers, senior engineers check it, then test it to testers, and finally deliver it to users for acceptance and technical maintenance. It looks like a good model, and several products have been developed with delays and some products fall far short of users' expectations, and the confidence of those involved in the project team has been frustrated.

Why did it fail? Then I thought about these questions:

1. The technical director is not a product manager and cannot assume the responsibility of product design. The boss trusted the technical director to make the product, so he gave it to him to do it. But there is a confusion here that product managers and project managers, and technical directors should play the role of project managers and architects. The project manager controls the project schedule and plan, and the architect grasps the overall technical issues. And the technical director has no choice but to do a good job when he receives this task. In the final analysis, the mechanism does not distinguish the product design from the project manager, which does not mean that the technical implementer is the product designer. More should let the boss or other business personnel take on the work of product design.

2. The demand is unstable, and the cost of change is high. As a result of entrepreneurship, demand will often be adjusted to adapt to the market, but once adjusted, many development plans will be adjusted accordingly. If some of the functions are already under development, a lot of work will have to be restarted after adjusting the requirements, seriously affecting the enthusiasm of technical colleagues. It is impossible for the business not to adjust the demand, they are in order to meet the requirements of users, users are satisfied in order to bring value to the enterprise. However, if the adjustment is too expensive and a lot of code has to be rewritten, people will blame the technical director or project leader for not having a good grasp of the requirements.

3. The team often works overtime, but the combat effectiveness is not strong. The core team is tired of dealing with demand, technology development and old system maintenance, and does not have time to guide new colleagues to learn technology, while the skills of new colleagues have not been brought into full play yet. Work efficiency is low, tasks are often delayed, and there is no sense of achievement. The core team has a lot of things to do, there is no time to organize project documents, and new employees are not as slow as documents. People do a lot of things every day, and they need to work overtime to finish them, so they are tired. Everyone has a lot of things to do besides work, such as going home to watch TV, spending time with their families, reading and studying, and so on. If an employee is allowed to work 24 hours a day, he can agree, but his family may not necessarily agree. The development that makes everyone happy is much more efficient than the tired one.

4. The quality of the delivered software is poor, and there is a big gap between the delivery software and the users' expectations. When starting a business, everyone's ideas are good, do a lot of work, and make a product that everyone loves to use. The reality is cruel, everyone worked hard to work out things, the boss is not satisfied, users do not pay the bill, no one recognizes the efforts made. The delivered software does not have time for self-testing, or self-testing is insufficient, and handing it over to testing is a lot of problems. Some companies haven't tested it yet, so it's dangerous to go out and give it to users. The company handed over in this way affects not only the use of users, but also the word-of-mouth of the whole company.

It's not that the traditional software development model is bad, but it's just not suitable for startups like us. Start to try other models, if you don't have a good system, you can't give full play to your maximum productivity.

Try two, agile development model. Agile development is a human-centered, iterative, step-by-step development method. Agile methods emphasize people-oriented and focus on delivering software that is valuable to customers. In a highly collaborative open environment, incremental development is carried out in an iterative way, often using feedback for reflection, reflection and summary, and constantly self-adjustment and improvement.

The gist of agile development:

One: individuals and interactions are more valuable than processes and tools

Second: available software is more valuable than lengthy documents.

Third: collaboration with customers is more valuable than contract negotiation

Four: responding to change is more valuable than following the plan

And our previous problems, delivery software customer dissatisfaction, delay, requirements change cost seems to be able to solve. If you want to try such a good model, first take a look at a flow chart of agile development.

Agile process of agile development in start-ups

Simple process for agile development:

1. The product owner designs the whole product into a product backlog. The product backlog is a list of requirements. (backlog can be understood as a requirement or something to be done.)

2. Hold a product backlog planning meeting to estimate the time of each backlog and determine which backlog needs to be completed in the first sprint, that is, the backlog of sprint. (sprint can be understood as a collection of tasks developed by a team.)

3. Write the backlog of sprint on the note and paste it on the task wall so that everyone can claim and distribute it. (the task wall is to paste the status of unfinished, ongoing, or completed work on a wall so that everyone can see the status of the task.)

4. Hold a daily standing meeting for everyone to summarize what they did yesterday, what difficulties they encountered and what tasks they will carry out today. (the daily standing meeting is to stand up and discuss with everyone in front of the task wall at a fixed time every morning. The time is limited to 15 minutes.)

5. Draw a burnout diagram to ensure that the overview of the task can be seen clearly. (the burnout map draws the total number of current tasks together with the date, and records each day to see how many tasks are left each day until the number of tasks is 0, and the sprint is completed.)

6. The sprint review meeting is held when the sprint is completed, and the completed software product is demonstrated to the customer.

7. Finally, there is the sprint summary meeting, which takes turns to speak. Everyone has to speak, summarize the problems encountered in the last sprint, improve and share the discussion with you.

How do we combine agile development to solve the problems of existing projects? we should remember that any measure is to ensure that the software is delivered to users on time and according to quality and quantity. Do not implement Agile for Agile's sake. The company cannot produce business value. Any advanced ideas or technologies are meaningless. We have taken these measures:

1. Promote the concept of agile development. The effect of imposing a system on both large and small companies is generally not very good. Anything that can be carried out must be accepted by everyone before it can be recognized.

First of all, train and test × × to learn agile development, and then let her assume the role of part of the product responsibility and agile instructor for the following reasons:

A, testing to accept the function, you must understand the business requirements.

B, testing is also a part of QA quality system, learn to have a deeper understanding of software quality.

C, most of the team are boys, and the promotion of girls is more affinity.

Call all technical teams to a meeting to prepare for promotion. Start to have a good discussion with the test, how to tell everyone how to be more effective and more acceptable. If she wants to explain, she must be very clear about agile development and prepare sufficient knowledge. At the meeting, we first point out our present problem and let us see if we have any ideas to solve the problem. Now we make products, customers do not recognize, the boss is not satisfied, they are very tired without a sense of achievement, is there any way to solve it. After discussion, we will generally recognize the advantages of agile development. You may ask how to implement and land on the ground, you can try to find a pilot project, if the implementation is successful, it will allow everyone to promote it in an all-round way, and failure will only affect some projects.

2. Build an agile development environment. If we want to implement agile development, we need better basic conditions to ensure the smooth progress of agile development. There are several key softwares: nexus build warehouse dependency center, maven management project dependency, jenkins continuous integration and automatic compilation and release, svn centralized code management, jira record requirements and status. Refer to "Agile Development Environment Building" for details.

3. Agile project implementation. The whole company establishes a business goal-oriented atmosphere. In the case of "Project 1", the goal is to complete the project, which requires the following steps:

First gather a group of warriors to achieve this goal according to their respective abilities and intentions, regardless of technical or non-technical. If there are not enough people gathered, the technical director can adjust resources to support according to the input of the overall project, but gather according to everyone's wishes if conditions permit. In the end, "Project 1" summoned a technical director, a senior developer, two potential developers, a front-end, and a test, which can be counted as four people, excluding the time everyone spent doing other things.

Fully mobilize customers (bosses and business colleagues) to participate in the project, their participation directly determines the success of the project. Combined with previous experience, if they are not involved enough, the final product is not what they want, or a big gap from what they want. When they first joined, they were very confused and sometimes showed resistance. At this time, we must patiently insist on the success of the first sprint development, so that we can taste the benefits. Allowing them to participate in the project also means that we embrace change. If there is a change in demand, add tasks to the task wall, so that you can have a comprehensive understanding of the time of all tasks. If you exceed the end time of sprint, you need to decide which functions are not added in this sprint cycle.

The technical director arranges to communicate with the customer, which refers to the boss and the business. Test * * is responsible for communicating records with customers, assisted by Technical Director. After many times of communication, try to let the test draw the requirement prototype with the simplest tool, and the technical director communicates with the customer after passing the review, and iterates over and over again until there is no objection to the whole requirement. Many companies have a special product owner to carry out this demand, but according to our current manpower, it is impossible to do so. The main reason why the technical director is not asked to do this is to avoid the previous problems and excessive technical design of the product.

After the product is designed, the project members are convened to decompose the tasks and determine the time of each task, which can be estimated using agile playing cards. Task decomposition should be controlled at a granularity of 1-2 days as much as possible, so that we can make a prototype that can be tested in 1-2 days, and integrate testing to find problems as soon as possible. Try to limit the task set of a sprint to 1-2 weeks, not too long or too short. Too long will lead to fatigue, too short sprint will make people feel that there is too much work and finish one after another. "Project 1" estimated that 120 person-days, a total of 4 people, need 30 days and 4 weeks, we cut into 4 sprint, almost one month to complete, to meet the time requirements of the business.

Implement sprint in stages, draw task wall, divide unstarted, planned, in progress, completed, burnout diagrams. Put the sprint task to be done on the wall and post it where it hasn't started.

Agile development task wall for startups

Stand up every day for a meeting to claim the task. Including business tasks, development and design, development and coding, front-end design and development, testing and so on are all tasks, unified management. The emphasis is on a group. If a colleague asks for leave, other colleagues can finish the task on top. The standing meeting summarizes whether there is a problem with yesterday's task, and if you have any suggestions for the current task, try to limit it to 15 minutes and hold an effective meeting. Unlike in the past, the business or project manager is not chasing everyone for results, but team-driven. What everyone does every day is reflected on the wall, and everyone will help him figure out a way to ensure the success of the whole project. When each task is completed, the project executor pastes the task from the progress to the completion area. Never assign an area to claim a new task and post it to an ongoing area.

Software development process. After claiming the task, how to ensure that everyone develops quality code? The team has more experienced engineers who do not need much guidance and can directly participate in the development of the project. On the other hand, learning engineers need guidance and help to do use cases and system analysis step by step. The technical director does not recommend claiming too many development tasks, he is responsible for the summary design review of the development team, the unapproved design cannot be developed, and guides everyone to analyze and design the system. As we all know, with the idea of the system, the rest is the process of technical realization, as long as it is not difficult to master the skills. You may ask, doesn't agile development emphasize that the product of software development is software, not documentation? We here are not like the traditional development software for documentation, just let everyone write down their own design ideas, only after their own careful design can be clearly written down. We do not need to write a long speech, such documents are not welcome, popular documents only need to write use case analysis, table design, complex logic needs to draw process sequence diagrams.

Pair programming. This programming model has been ridiculed by countless people before, but it is impossible for every project to be programmed in pairs. This is unrealistic and a waste of resources. Our pairing is that when you develop a difficult module, you will add a task to the pair to cooperate with other developers to complete this task. In fact, when we are developing, we often pair up, such as mentoring new colleagues and discussing design modules, which are not included in our development workload before.

Agile development pair programming for startups

Project demonstration and summary meeting. At the end of the project, let all the members involved in the project participate, demonstrate to the customer, and answer the customer's questions, so that everyone can fully feel the harvest. The summary meeting is mainly to share the problems and experiences encountered in this sprint, and to prepare for the next sprint.

After agile implementation, our productivity has improved a lot, the enthusiasm of employees has increased, business participation makes the overall demand control is also very good, we communicate more, and the 30-day task is completed 5 days ahead of schedule. We have extra time for people to study their areas of interest one or half a day a week, but these studies must eventually reflect the results. For example, backstage developers want to study a new technology, and finally need to write a ppt to share with you. It not only allows people to do what they want to do, but also creates an atmosphere for everyone to learn from each other.

Ps: all models should not be dogmatic. Advanced models are not good ones. What suits you is the best. To paraphrase an old saying: no matter the black cat and the white cat can catch the mouse, it is a good cat.

Also expose the members of Project 1:

Project 1 Agile team

Original article, reproduced, please indicate: reproduced from LANCEYAN.COM

Link to this article: how startups implement Agile Development

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.