background
In the past, we used the contract to firmly fix the demand, and then Party B did everything possible to only act according to the contract without exerting greater creativity, and Party A did not want to spend a penny more in front of the fixed cost, but kept asking for new functions. . Then the two sides will form a contradictory situation, or even a hostile situation. How to break this situation? This is the agile development to be talked about in this issue.
Origin of agile
In the hardware field, there is Moore's Law , that is, every 18 to 24 months, the performance of the computer that can be bought for every $1 will more than double. The software industry has no corresponding rules. So if the software industry improves productivity, quality, value, etc. And how do software companies improve productivity and quality? In fact, many traditional enterprises still rely on overtime, processes and tools, contracts and documents, and communication difficulties are an important reason for bugs and delays. The communication here includes the communication between the development team and Party A, and the communication between teams. Communication between teams and managers, etc.; in the waterfall development model, we will do a lot of pre-requirement analysis and detailed design. We think that our efforts will ensure that the delivered software will be what customers expect, but this is not the case . In addition, all software developers are knowledge workers, so are the executive initiative and creativity of knowledge workers controlled by managers?
The above mentioned pain points in the software industry are not new. As early as 1987, Fred brooks mentioned in "No Silver Bullet" that there is no single technology or method that can increase the productivity of software engineering tenfold in ten years. Software development itself has complexity, invisibility, variability, and consistency , making software development difficult to manage, so it is likened to "werewolves", but there is no technology or method to solve it, that is, there is no silver bullet.
And agile development is to solve the problem of software development.
waterfall model
Before introducing agile development in detail, let's first introduce the "non-agile" development model, namely the "waterfall model". This methodology is divided into 5 stages: requirements analysis, design, coding, testing and maintenance. The requirements analysis stage usually defines the system requirements; the design stage usually determines what database the system uses, the division of system modules, and the functions of each module; the coding stage uses programming languages to implement the functions of the design stage; the testing stage mainly tests whether the functions are realized; the maintenance stage is based on The user's new requirements re-modify the system to make the system run normally and more stable.
The limitations of the waterfall model are very obvious. For example, the response to market changes and user needs is slow, the cost of change is high, and it may even fail as soon as the product is withdrawn from the market.
Agile development
We're always on the lookout for better software development methods in practice, helping others while doing it. From this we have established the following values:
- Individuals and interactions over processes and tools
- Working software over detailed documentation
- Customer cooperation is higher than cooperation negotiation
- Responding to change over following a plan
Agile Development Manifesto
- Our most important goal is to satisfy our customers by consistently delivering early and valuable software
- Embracing changes in requirements, even late in development, with an agile process that manages changes for the client's competitive advantage
- Deliver working software frequently, a few weeks or a month or two apart, tending to take shorter cycles
- Business people and developers must collaborate with each other, every day in the project is no exception
- Stimulate the fighting spirit of individuals, build projects with them as the core, provide the required environment and support, supplemented by trust, so as to achieve goals
- The most effective and efficient way to convey information, both inside and outside the team, is face-to-face conversation
- Working software is the primary measure of progress
- Agile processes advocate sustainable development. Owners, developers, and users need to be able to keep their pace steady
- Relentless pursuit of technical excellence and good design enhances agility
- It's the art of minimizing unnecessary work by focusing on simplicity
- The best architectures, requirements, and designs emerge from self-organizing teams
- Teams regularly reflect on how they can improve their effectiveness and adjust their behavior accordingly
principles of agile development
- Gather the strength of people and work closely together (cooperation). Including the relationship between business leaders, development teams, customers, and managers, all of which have been one of the reasons for project crises in the past, so, in the agile era, we need these roles to work closely together to maximize each the power of the character
- Focus on customer value and eliminate waste
- In addition to being human and valuable, we also need to continue to learn and improve , because the world is changing too fast.
agile team
The values and principles of agile development look beautiful, but how to implement them? First it requires forming an agile team. Intersecting with traditional teams, agile teams have the following characteristics:
- Teams are required to be small, usually single-digit numbers (3-9 people)
- Full-time focus, must be full-time staff
- cross-functional
- authorized to self-organize
Agile Team Operation Mechanism
- A team has its own ××× matters, and the ××× matters are divided into small ones.
- Prioritize by customer value, with product managers responsible for value prioritization
- The work of team members is not driven by the supervisor, but pulls the work themselves
- Small but stable, cross-functional team
- Multiple teams are loosely coupled (with low dependencies), aligning iteration times and strategic goals
key team roles
- Product Owner
- Scrum Master (Process Master)
- development team
Product Owner
- The only person in charge of managing the product backlog (××× matters)
- Representing clients/projects as responsible persons
- Define all the features of the product
- Responsible for product input and output
- Manage stakeholders and their interests
- Accept or reject the result of the iteration
- Maintain just enough, just-in-time feature details
- Share success with your team
- Responsible for maximizing the value of product and development team work
Scrum Master (Process Master)
- play the role of coach
- Lead the team to complete the practice of Scrum and reflect its value
- Troubleshoot the team
- Make the team work closely together, and make the team individual have the ability to work in multiple functions
- Ensuring teams are competent for their jobs and remain productive
- Protect the team from outside unwarranted influence
development team
- The team has 3-9 people
- Team members are cross-functional and generalist
- Team members all work full time
- Team self-organization and management
- Team relationships should be fixed in an iteration cycle, and individual functions can be adjusted at the beginning of a new iteration
key team activities
-
Daily stand-up meetings
The daily stand-up meetings are held every day, and the time is maintained within 15 minutes. Standing meetings are held. All relevant personnel need to participate to avoid discussions on irrelevant issues. - The review meeting
needs to be held on the last day of the iteration cycle. It takes about 1 hour. The customer needs to attend. If the customer cannot attend, the product manager needs to attend. - Iteration retrospective meeting The
iteration retrospective meeting is conducted at the end of each iteration to summarize the experience and lessons learned in the work. The time is maintained within 30-60 minutes, and the entire team needs to participate (Scrum Master, Product Owner, development team and customers). The iterative review will consist of two parts, the first part is quantitative analysis and the second part is qualitative analysis. Quantitative analysis includes whether the team has completed the iteration goals, collecting and reviewing iteration metrics (including rate, iteration burndown chart, iteration plan story and actual completion story, planned release date and actual release date, customer satisfaction, team satisfaction , production bug count, production bug resolution time, user stories, etc.). Qualitative analysis includes what is working well (should continue) and what is not doing well (should be discontinued)? What can be improved (the team chooses 1-2 to implement in the next iteration)?
Most commonly used agile methods and practices
- Scrum
- XP
Welcome to the WeChat public account: Mu Keda, all articles will be synchronized on the public account .