Agile development - self use

** If there is a mistake , Thank you for correcting **

If there is a mistake , Thank you for correcting , Please send a private message to the blogger , There is a red envelope for hard work , Worship “ one-word teacher ”.

Please find the paragraphs you need according to the table of contents

Introduction ： This blog is organized for individuals Java Learning notes , If there is a mistake , Thank you for correcting . System learning , Welcome to continue to pay attention , Follow up updates ~
Java communication qq Group 383245788. There are some resources and leaders in the group , Welcome to exchange .

This article aims to learn and communicate , Personal Agile development learning experience - Self use

Content sources ：

1. Black Book - software development
2. Hook Education
3. Related blogs and learning videos

Text

Agile theory

Agile can be described as a kind of thinking , It can also be said to be a - Methods , It aims to promote the process of the project , Help the team to be more efficient, but in addition to being agile , Lean thinking and Kanban approach can also improve efficiency .

• Lean methods are often used in business management , It is a strategy level approach oriented to the overall situation
• Agile and Kanban methods are mostly used in production research teams , It is organization oriented

Three sharp and agile swords ： sense of worth 、 Principles and practices

• Agile thinking is made up of values and principles , And reflected in agile practice . among , Values to define agile thinking patterns , Principles as a guide to action , Practice is the process of concrete application . The practical part is very important , Learning agility , Finally, it should be implemented in the actual work scenario , In the process , Pay attention to choose the most suitable practice scheme according to your own needs .

Agile Manifesto

• Individuals and interactions are higher than processes and tools ;
• Working software is higher than detailed documentation ;
• Customer cooperation is higher than contract negotiation ;
• Responding to changes is higher than following the plan .

The Agile Manifesto defines agile as a method , But based on years of agile experience , We can understand agile in this way , It is used to deal with VUCA The method and practice of the uncertain business environment of the times . The Agile Manifesto is the agile values , It tells us two points ：

1. Agile methods are not just talking about things out of thin air , It comes from the accumulation of practice , We need to grasp the core of agility , Continue to explore better methods in practice .
2. Agile methods come from practice , It should also be attributed to practice , Help us solve practical problems , Not a frame that frames our thinking , Become a cage of thought .

The twelve principles of agility

1. Our most important goal , It is through continuous and early delivery of valuable software to satisfy customers .
2. Be happy to face the changes in demand , Even in the late stages of development . For the competitive advantage of customers , Agile processes control change .
3. Deliver working software often , A few weeks or a month or two apart , Tend to take shorter periods .
4. Business people and developers must work together , Every day in the project is no exception .
5. Inspire the individual's fighting spirit , Build projects around them . Provide the environment and support needed , Supplemented by trust , To achieve the goal .
6. No matter inside or outside the team , The best and most efficient way to deliver information is to talk face to face .
7. Working software is the primary measure of progress .
8. Agile process advocates sustainable development . Those responsible 、 Developers and users should be able to maintain a stable pace together .
9. Persistent pursuit of technical excellence and good design , Agility is enhanced by this .
10. Based on simplicity , It's the art of trying to reduce unnecessary work .
11. Best architecture 、 Requirements and design come from self-organizing teams .
12. The team regularly reflects on how to improve effectiveness , And adjust your behavior accordingly .

explain ： The twelve principles are used to guide us in agile practice , It clearly lists some situations that we will encounter in promoting the project , It also explains how to do , Or how to do better . Like the second one , It tells us to be willing to face changes in demand , This is because at work , Requirements can easily change frequently , If the team is not ready for change at any time , It is easy to fall into depression and affect the progress of the project . For example, Article 6 , It tells us that face-to-face conversation is the best way to communicate , This is because many teams are used to communicating in words at work , But it is easy to be ambiguous , It needs to be confirmed over and over again , Increases the cost of communication .

Agile practice ：

Agile methods

Scrum Method ：Scrum Is now the most popular agile method , It is mainly for the development and maintenance of complex products . This structural framework is very reasonable
Explain , It can be used “3355” To sum up , intend 3 Roles 、3 Two kinds of workpieces 、 5 Kind of ritual and 5 Kind of values .

DSDM Method ：DSDM Is the dynamic system development method . Its specific implementation idea is as follows ： When the time schedule and available resources are fixed in advance , Strive to maximize the satisfaction of business needs （ The traditional method is that the demand is fixed , Time and resources are variable ）, Then deliver the required system . For delivered systems , A sufficient degree of stability must be achieved , Make sure you can run in a real environment ; For some urgent business needs , Must be able to meet in a short time , These functions will be improved in the subsequent iteration stages .
Crystal method ： A way to promote mobility , Contains core elements with commonalities , Each primary color contains a unique character 、 Process mode 、 Work products and practices . The inventor refined the crystal method into a transparent crystal methodology （Crystal Clear）、 Yellow crystal methodology （Crystal Yellow）、 Orange crystal methodology （Crystal Orange） And the red crystal methodology （CrystalRed）. These crystal methodologies are divided according to the importance of the project and the size of the participants .
Crystal method emphasizes organization , It will teach you how to transform your organization , It is also a set that can be carried out according to different organizations “ Adjust measures to local conditions ” The method of tailoring .
Feature driven approach ： Feature driven method is abbreviated as FDD, It is a model driven （model-driven）、 Short iterations （short-iteration） The process of , in other words FDD It is a development process , The process has a starting point and an ending point ,FDD The starting point is to create a global model outline , Through biweekly " Feature design - Feature implementation " Iteration , Gradually enrich the model function content .
Feature driven methods are often used in ordinary work . Its biggest feature is the need for a comprehensive architecture , This means that the design and modeling are very clear , So it is more suitable for products that do not need trial and error , That is to say, a project with a definite scope of requirements .
Adaptive software development method ：

1. Based on complex adaptive system theory , Improve software speculation 、 Collaboration and learning process , Establish new values ： Adaptation is more important than optimization ;
2. Pay attention to people （ Skill ） And communication , Put the development process second , Focus on working software, not documentation , It emphasizes collaboration with customers and adaptation to change ;
3. Define people-oriented 、 Leader - Collaborative management model . The focus of leadership is not instruction , But to create a cultural atmosphere , Make adaptation and collaboration work effectively , besides , And create a collaborative structure , Enable multiple teams to communicate effectively .

It is more suitable for changing needs 、 A software project with a short development period . It can be said that it is the prototype of agility , But it is more suitable for internal development , This is because it does not emphasize the value of delivery , Nor did they pay much attention to the changes of the market and users .

Continuous integration approach ： The continuous integration method is an engineering practice method , Specifically, whenever a developer submits a line of code , It can be compiled automatically by the machine 、 Automatic test , Then automatically publish . Development teams typically integrate once a day , A new version can be produced for the team and the user experience , The goal is to expose the problem as soon as possible through the rapidly produced version , Further improve the efficiency of development and production .

Best practices

We judge whether it is a best practice through these specific contents ：

1. A stable team ： We need stability 、 A team with tacit understanding , That is, team members are fixed for a long time .
2. Predictable rate ： We need the rate of team formation in an iteration , It's easy to know what we can do in the next iteration .
3. One piece flow ： We need to focus on doing one thing at a time , So parallel tasks are not welcome .
4. Built in quality ： We need to ensure our own quality in every link , Do not leave quality problems downstream .
5. The end of the day ： We need to split the task granularity into at most 1 God , So that we can know the progress of our work every day .
6. There is an emergency parking area ： We need to add an emergency parking lot for urgent tasks , In order to analyze the insertion of urgent tasks .
7. Rolling iteration ： We need to improve our products through iterative delivery .
8. Continuous improvement ： We need to review and summarize , Continuously strengthen our team ability .
9. Deliver as early as possible ： We hope to deliver the version as soon as possible , Get user feedback faster , So as to meet the needs of users more quickly .

It should be noted that , We need to recognize the gap between ourselves and best practices , It can't be done overnight . Be specific to your actual situation , Tailoring to requirements , Avoid formalism , Don't be agile for the sake of agility .

Agile transformation - Project life cycle

The life cycle of a project is to describe the whole process from concept to completion . The whole project life cycle includes five process groups .

1. Start the process group ： Is one that includes getting Authorization , And define a new project or a new phase of an existing project , Then the process of formally starting the project or phase . such as , Before we started to do the first mobile game version of fighting landlords , Will demonstrate the market first 、 Competitive products and user business models , Then form a conclusion and output the project charter . In the process , We will invest less resources , Only the producers 、 Product owner and project manager , And several R & D leaders ;
2. Planning process team ： By defining the project scope and optimization objectives , A set of processes for developing action plans to achieve goals , Make the team work develop orderly . For example, our project is usually divided into four stages ：Demo Stage 、 Basic function realization 、 Grayscale release and official release , Each stage has its scope 、 Resource input, etc ;
3. Execution process group ： It is a group of processes to achieve project objectives by completing the work determined in the project management plan . In the process , We mainly need to pay attention to information communication and project progress ;
4. Monitoring process group ： Means by tracking 、 Review and adjust project progress and performance , A set of processes to identify necessary plan changes and initiate corresponding changes , Make the project progress towards the goal . We mainly control four aspects in this process ： Scope change 、 The quality control 、 Status report and risk response ;
5. Closing process group ： It refers to a group of processes implemented to complete all activities of all process groups and formally end the project or phase . The main value of this process group is that it can summarize the lessons learned during the project , And continuously improve it , Help us to accomplish better in future projects .

In real work , We have encountered a variety of projects , The demand situation is different , So people have summarized them according to the characteristics of different projects , Four project life cycles are summarized ： Predictive 、 Iterative type 、 Incremental 、 Agile . We can choose the appropriate type according to the characteristics of our own projects , Help us better advance , In other words, we can judge whether the project is suitable for agile methods .

Predictive life cycle

The first is the predictive life cycle , Generally, the project life cycle we refer to refers to the predictive life cycle . Predictive life cycle is based on analysis 、 Design 、 structure 、 Testing and delivery are performed in a sequential manner , This requires us to make a detailed plan , When to start the project , When to finish the project . In the process , We try to limit changes , So we need to set up such a complex organization as the change committee to handle the approval of each change . Because this project reduces the cost of handling changes as much as possible , It helps to deliver products at a minimum cost .
At the beginning of the project, when the plan was made , The team must consider various project constraints , And add these constraints to the risk and cost plan . So when we are implementing the plan , The impact on these plans can be strictly controlled , Minimize project changes .
Because predictive projects emphasize sequential execution , Therefore, products or services are not usually delivered during the project , This will create a greater risk , Once the customer needs are not understood enough , Or disagree about the needs , A lot of work done before will be burnt down .

Iterative lifecycle

Most of the early Internet projects belong to the iterative life cycle . It will produce delivery in the course of the project , We can get feedback in the process , Then collect the feedback and summarize it 、 refine , Then new requirements are formed , Then put these requirements in the next iteration . In this way, we can help us improve our work results through prototype verification or proof of concept . The advantage of this is that it can reduce the uncertainty of the project .
The whole process of iterative life cycle includes requirements analysis 、 Analysis design 、 Build testing and value delivery , Its characteristics focus on the process of analysis, design and test construction , At this time, we need to constantly and quickly polish to improve our products . In this way, the problem can be fixed as early as possible through rapid iteration , And the cost of repair will become smaller . If the requirements in the project change frequently , Or when we think the customer's needs are not very certain , An iterative lifecycle is appropriate , Because the iterative lifecycle focuses more on building prototypes and optimizing improvements , Not to speed up delivery .

Incremental lifecycle

Incremental lifecycle , It can provide the customer with the completed deliverables , Enable customers to use... Immediately . Many companies or customers prefer teams to deliver during the project , Instead of waiting for all the requirements to be completed . When we deliver part of the solution , Customers can already use , We call this kind of life cycle with a small number of deliverables an incremental life cycle .
The project team will plan every time we want to deliver before starting , After starting, they will complete the first delivery as soon as possible , In real work , It is possible that the first delivery time is one week , The second delivery time is two or three weeks . As the project continues , The team may find , The final deliverables may deviate greatly from the initial plan . But the team doesn't have to care about the result , Because we pay more attention to faster delivery of value to collect user feedback , Compared with meeting the planned requirements on schedule , We pay more attention to the customer's view on the deliverables and the delivery value . therefore , As long as the result is to create value for customers , We don't have to worry too much about whether all the requirements of the original plan have been completed .

Agile life cycle

Agile life cycle , It has both iterative and incremental properties , But with the gene of agility , So it is in line with the agile declaration ⾔ A kind of life cycle , It can better cope with more frequent changes and deliverables ⽬ value . say concretely , It adds incremental analysis of user value on the basis of iteration , In other words, customer satisfaction will continue to improve with the early delivery and continuous delivery of valuable products .
So in this type of life cycle , We will deliver products incrementally , Iterating the deliverables rhythmically , In this way, customers can see our deliverables in a fixed cycle , And give feedback , This will make our team more confident about whether it can meet the needs of customers , The project can also be rewarded as soon as possible .

Life cycle characteristics comparison
When you start a project , We must first define the needs of the project 、 Way of execution 、 Delivery methods and final objectives

• If the requirements are very clear , That is to say, the customer's requirements have been determined at the beginning of the project , And will not change with the progress of the project , So at this point we can be sure , The project uses a predictive life cycle to advance .
• But if our project requirements are dynamic , And the demand is complex and full of uncertainty , Internal improvement is needed to achieve the final delivery , At this point, we will choose an iterative life cycle .
• If our customers want to adjust their initial needs according to some of the results , That is to say, we should pay attention to the customer's feedback during the whole promotion process , At this point, we will choose the incremental life cycle .
• But in real life , The situation is often not so simple , We may need to iterate frequently , Considering the feedback from customers , At this point, we have to choose the agile life cycle , Here, please pay attention to , Because the agile lifecycle focuses on frequent delivery , So the requirements for the team are very high , But if you encounter a large project , It will be very difficult and impractical , The incremental life cycle is to complete partial delivery in a fixed cycle , It will be more suitable for .

Agile methods focus on delivering results , Therefore, combined with the above analysis , We can know , When your work scenarios are predictive and iterative , Then you don't have to adopt agile methods at all ; When your work scenario is incremental and agile , You can partially or completely transform agile .

Agile practices ： Iteration based and process based

Process based agile practices

Process based agility , Agile practices based on processes , At the beginning of the project , The team will prioritize customer value , Extract several functions with high priority from the to-do list to start development . Its biggest characteristic is ： Every iteration must complete all functions . In this practice , The team needs to evaluate the total workload for this iteration , Because the functions selected each time are different , And the total workload is also different , So the iteration time is also different . If such a project needs to be delivered frequently , We can only do this before each iteration , Choose as few features as possible to develop . More Than This , If there is a change during the iteration , The changed workload will be added to the total workload , The iteration time will be extended accordingly . So the team should make an appropriate schedule , The iteration time should not be prolonged by adding too many functions , Make the project inflexible

Iteration based agile practices

At the beginning of the project , As with process based agile , The team will prioritize customer value , Extract several functions with high priority from the to-do list to start development . Its biggest feature is ： The end of each iteration is strictly time boxed , in other words , Iterations for the team , We should according to the ability of the team , Given a fixed available time . In agile, this strict time node is called a time box . We want to deliver complete functionality within the time cycle , This requires us to separate requirements relatively independently , And in strict order of value , Because in this way, we can flexibly respond to changes , Once a change occurs and is inserted into the current sort , We can eliminate the low priority requirements from the iteration , To ensure a fixed iteration period . The advantage of this is , No matter when , What the team is doing in the current iteration must be the most valuable function .

The biggest difference between these two methods is , Iteration based agile is what we usually call a typical agile development , It specifies a clear delivery time , That is, the delivery time is fixed . It's like riding a high-speed train , If you miss the time, you can only sign in the next column , If this release date cannot be delivered, you can only wait until the next release date . And process based agility , Its scope is fixed , In other words, the scheduled functions must be completed each time before delivery .

Hybrid agile practices

The actual work scenario is very complex , Each project has its own unique background . We are unlikely to use a single agile approach “ A move , Eat all over the sky ”. We can combine the two agile practices mentioned above , Put together a plan that suits the team , This behavior is “ tailoring ”, This practice is a hybrid agile practice . Agile is what helps us solve problems , So don't be agile for the sake of agility , Only when you can solve the problems of the team , We need to introduce agile .
tailoring , It's not just about agile practices , The same is true for agile methods , We should use agile methods flexibly for team problems , That is, specific analysis of specific problems , An antidote against the disease , such as ：

• Scrum by PO（Product Owner）、SM（Scrum Master） as well as Team（ Cross functional team ） The emissary of ⽤ Provide guidance , Include Sprint plan 、 Every time ⽇ Morning meeting 、Sprint Review And review meeting .
• Kanban helps the team to ⼀ ButI ⾼ efficiency ,⽅ Law is to ⼯ Workflow Visualization , Make project bottlenecks easier to detect , And by adjusting WIP（ Work in progress restrictions ） To realize process management .
• Extreme programming (xp) XP, Application ⼯ Process practice such as ⽤ User story cards 、 Continuous integration 、 restructure 、⾃ Automation test and TDD（ Test-driven development ）, Aiming at the development process can improve the development efficiency .

Tailor for applicable scenarios
Crop according to the applicable scene , Mainly these two scenarios ： Forecast first, agile second and agile first, forecast second .
First of all, let's look at the prediction based and agile supplemented . For example, JD shopping , Like all e-commerce platforms , It has a home page inside 、 Category pages 、 Details page 、 Single page 、 Standard pages such as payment page and settlement page , When we are doing basic functions, we can make these pages first , This part of the page is very mature , There is no need for users to verify , Therefore, JD shopping only needs to focus on its special functions “ Spell it for ” and “ Share ” Work hard , Just try and make mistakes with these pages . This is typical of forecasting with agile as a supplement .
And the cases with agile as the main method and prediction as the auxiliary method , This model is mainly used in some work environments that need to integrate components . For example, the recommendation algorithm of Tencent advertising , It is a mature recommendation system , It is usually embedded in various browsers 、 Journalism 、 Small video 、 Games and other platforms , For the algorithm itself , Its functional requirements and framework are predictable , But after integration , It needs to be optimized in an agile way according to specific business scenarios .

Agile is a top-down approach , When landing, you must get the support of the leaders , But some leaders may simply understand the benefits of agile , Let the team explore and implement by itself without receiving professional guidance , On the contrary, it will make people feel that some practical links of agility have been increased （ Such as daily morning meeting ）, It has become an extra burden for the team , It is necessary to introduce professional agile coaches , Help people understand the real purpose of implementing agile .
To avoid team members' resistance to agile transformation , We can solve the problems faced by the team first , At the wrap up and review meeting , Tell the team what happens when the problem is solved . When the team recognizes the effect , We then tell the team what agile practices have been adopted , Let people gradually accept and recognize agile methods .

Starting point of transformation agility - Agile thinking

The characteristics of agile thinking can be summarized in three words ：

1. Fast , Carry out with drive and sweep , Only when you run faster than others can you maintain your advantage ;
2. Efficient , Only the organization can cooperate effectively , To continuously deliver value ;
3. Trial and error , Through constant trial and error at low cost , Meet the real needs of customers , Is the way to win .

These are the three characteristics of agile thinking . As we have said before , The ultimate goal of agile practice is to introduce agile process
in , Help the team build agile thinking .

Change your mind , Embrace agility

First , We need to think about how to make the team agile ？ This requires a change of mind , Keep pace with the times , Always be ready to accept new things . Whether you are the leader of the team or not , As long as you want to be agile , Then you must first form an agile thinking habit , Use systematic learning to master and understand it , This can better guide the team , So here I have the following suggestions .

1. Keep a curiosity , Be curious about things .
2. Systematically learn agile knowledge .

With this consciousness of changing thinking , With the support of theoretical knowledge , You can guide or help people to be agile in the team . You can do it from these three aspects ：

1. The perspective-taking , In the team, we need to think from the perspective of others , Instead of just focusing on our own ideas , Thinking from the other side's perspective can make communication more efficient ;
2. Common experience , It means that we need to experience things outside of work with team members . such as ： Hold group building activities regularly , Such as mountaineering or hiking , Let us not only exercise our bodies but also increase our understanding of each other after busy work , Cultivate the tacit understanding of the team ;
3. Build common goals , We all hope to improve our team and ourselves in our work , With this common goal , Working together in daily work can be more efficient , It is the so-called "people's minds move with one another" .

Use agile thinking to divide the work of the team

Build agility awareness , Start with the division of labor . Practice agility , It must be divided according to agile thinking , The most popular of agile SCRUM Method , There are three characters

• PO（Product Owner） Product owner , Generally, the product manager is responsible for . As the first person in charge of the project , He is mainly responsible for guiding the direction of the product , And be responsible for the final delivered products . He needs to sort the needs in his to-do list by customer value , Also get product feedback from customers and tell the team how to improve . The product owner carries out daily cooperation with the team , Attend the iteration planning meeting 、 Every morning meeting 、 Review meeting, review meeting, etc , And set the direction for the next version to be developed or delivered .
  It is worth noting that in Agile Development , The product owner has the greatest function , He can decide whether the version meets the publishing requirements .
• SM（Scrum Master） Agile coach , Also known as Scrum executive director 、 Team coach or team facilitator , In general , By the project manager 、 R & D Manager or quality manager to serve as , We need this role in all agile teams .
  Agile coaches should have these abilities ：
  1 Agile experts , Have rich knowledge and practical experience , Be able to lead the team to successfully complete the agile transformation .
  2. Obstacle remover , In agile practice , Can help the team clear some obstacles , Let the project be delivered on time .
  3. Servant leadership , Be able to change leadership from command to service , Help the team grow quickly .
  4. The leader of change , Infectious , Be able to take the lead , Lead the team to embrace change .
  The agile coach is more like a political commissar of an army , Not only have rich personal experience, but also be able to lead the team through difficulties , Continuously deliver value .
• Team The team . Teams in agile usually refer to cross functional teams , This is an important part of agile practice . Cross functional team refers to breaking functional boundaries , All the roles in the team that are needed to continuously deliver the product , Gather together spatially according to the project , Everyone is jointly responsible for the project KPI, For example, designers 、 Developer 、 Testers and other required roles . Cross functional teams tend to be able to , Deliver high quality products independently , So we should pay attention to the establishment of cross functional teams .

If agile practice is compared to Dragon Boat Racing , Then the person in charge of the product is the helmsman , An agile coach is a drummer , And the team is like a rower . Each role has its own role , Everyone recognizes their responsibilities , Agility can be more popular .

In the process of agile Introduction , It is the critical period for agile thinking to take root in the team , At this point, we not only need to help you better practice agile , And we should pay attention to cultivating the consciousness of agility in our actions , Let everyone know both why and why , It is suggested to pay attention to the following aspects .

• Create a clean and transparent environment
  In the process of agile practice , The team needs a clean and transparent environment , It means that information and rules should be transparent , Because in agile practice , Because complex hierarchies can lead to inefficient execution , So agile encourages us to let the team make its own decisions , The team needs to be clear about the current information and rules to make judgments . As a leader , It is necessary to intentionally create such an environment .
  Try to divide the team into small teams to operate . This is because small teams communicate more easily , Lower management costs .
  We'd better use centralized office , It means that cross functional teams try to combine according to the project , Try to sit together in a physical position .
• The person in charge plays the role of lighthouse
  Focus can improve efficiency , It's obvious , What agile focuses on most is efficiency , So if you are in charge of agile transformation , You have to shoulder the responsibility of the lighthouse , Point out the way forward for everyone in the dark .
  First, carry out training and exchange activities , On the one hand, training in the agile direction can enable the team to establish a consistent language , Have systematic knowledge , Help the team understand why and how to implement agile ; On the other hand, for the professional skills of the team , It can help members improve their professional knowledge , Make the whole team more professional .
  The second is to encourage the team , Celebrate the success of the team . When the team fails to make achievements in a short time , We should encourage them , It shows that this is the pain that normal transformation will encounter ; After some achievements , We should encourage the team to gain confidence , Let team members have confidence to take on more responsibilities , And make great contributions to the organization . The important thing is that we need to fully recognize the team and give rewards . This creates a positive atmosphere , Our morale will be high , So as to make the team more efficient .
  The most important thing is to make the team appropriate “ Bruises ”, It's just that we don't give a solution to some small problems right away , And let them try to solve it by themselves , Exercise the team's ability to solve problems independently .

Get early feedback from rapid delivery
Agile focuses on delivering value frequently , We can get timely feedback through frequent delivery , Correct the direction in time , Make the products develop in the direction that most meets the requirements , This mindset is very important in agile . A quick feedback mechanism can be established , Let everyone be familiar with and finally proficient in this mode ：

1. The whole team builds a product to-do list based on all tasks （Product Backlog）;
2. The product manager selects high-value requirements from the product to-do list and lists them in the iteration to-do list （Sprint Backlog）;
3. For R & D personnel 1—2 Weeks of fast iterations ;
4. Release after test ;
5. The product manager collects the user feedback and sorts it into requirements , And repeat the second step 1 Step .

Self organizing teams

Self organizing teams are also called self managing teams or authorized teams . The management authorizes the team to manage its own work process and progress , And the team completes the work in its own way . in other words , Self organizing teams are not completely self-organizing , Self organization is also self-organization under certain restrictions , Leaving this limitation , Self - organization is out of the question .
For self-organizing teams , What they need to do is ：

1. Assign tasks by yourself , Instead of waiting for management to assign tasks to them ;
2. The team will consider how to use the product scheme and technical means to achieve the goal ;
3. The team sets its own code of conduct to be followed . For example, our team only has 3 Rules ： Automatically hand in your mobile phone in a meeting , Red packets for being late , Try not to give to others “ Add to the trouble ”（ That is, document or code self checking ）;
4. The team needs to keep management informed of progress and problems ;
5. Team members manage their own work , Circulation work status .

How does the management form a self-organizing team

Self organizing teams do not represent complete freedom , But under the management's strategy , Freedom with constraints . When building a self-organizing team , The management mainly needs to do the following things .

1. Define team goals and vision , Let the team fully understand the purpose and significance of what we want to do ,
2. Determine the team context , Organizational structure 、 Team structure 、 Team composition , The organizational structure serves the business , Only good organizational structure and performance methods , To keep the self-organizing team efficient .
3. Provide environment and support , Mainly the sense of security 、 Good team space 、 Atmosphere and skill coaching .
4. Appropriate decentralization , Give team autonomy , Let the team manage itself , For example, each person determines his / her own work task 、 The team negotiates the iteration cycle, etc . The management generally does not interfere in the team's implementation process , Only when team members need help , It needs to be fed back to the management , Ask them to help .
5. Training collaboration , The management needs to make the team “ Training ”. Make some for the team “ accident ”, Let the team handle and summarize the experience by itself , So as to train the team to deal with “ accident ” The ability of .

Self organizing team practice

Based on the premise of self-organization , What do we need to do next ？ That's the to-do list , That is, summarize the tasks that have not been scheduled , Created and maintained by a self-organizing team .
Create a to-do list ：
The to-do list allows us to control the progress of the project . When creating a , We should start from the perspective of the team , Measured by the team . The list should show the tasks in detail , So it should include task details , Its value and the estimated amount of work required . besides , The list is used to help us advance the project , So the specific execution steps should be clearly written in the list . All of these considerations , A to-do list should contain ID 、 type 、 name 、 value 、 priority 、 Workload and execution plan .
The type is divided according to its source , Usually these three types ：

1. A user story , That is, the requirements written from the perspective of users , Usually written by the product manager ;
2. Extranet BUG, That is, exposed by the Internet BUG, Usually from data or user feedback , It needs to be confirmed by the tester ;
3. Development tasks , That is, the task written by the developer , Such as database design 、 System reconfiguration tasks, etc .

Classification can help us according to the current main tasks , Select the appropriate to-do items faster to accomplish the objectives of the iteration . For example, the goal of this iteration is to solve the complaints of a large number of Internet users , Then we will be on the Internet BUG Select to-do items in the type .
Team discussion , Define the context of the requirements 、 value , And whether there are ready-made solutions , Then determine whether it needs to be included in the to-do list . Then include the to-do list
Sort by priority , The to-do proposer adds a priority to the to-do .
By increasing demand 、 Delete 、 Break down or merge for integration . If the requirements are complex , We need to pay attention to its integrity , Try to cover multiple user scenarios with one requirement . If you can split , Just break down the requirements into smaller units , To facilitate more flexible scheduling .
Self organizing teams work together to estimate the amount of work required for the requirements , That is, everyone has to make an estimate and give an opinion . Agility is generally estimated by estimating poker , When the difference between the given estimates is greater than the acceptable range , The person with a large estimate and the person with a small estimate should state their opinions respectively , Explain what motivates you to make appropriate estimates . In this way , can To give everyone a chance to speak , Share your thoughts , Then we can summarize the results that everyone agrees with
Finally, we will publish this list , Ensure information synchronization inside and outside the team .

---

In the process of making tables, we need to pay attention to the following points ：
Detailed Appropriate , The appropriate level of detail . The description of each to-do item is clear and concise , Make clear what kind of users this issue is to solve 、 What we need to do and the value we can do .
Estimated , Estimate . The to-do list should have an approximate workload estimate . It is worth noting that , What is different from the estimation of iteration plan is , The estimate here is only the preliminary estimate of the person in charge ;
Emergent , That is, to emerge , It means allowing new requirements to be inserted at any time , Self organizing teams can actively respond to change ;
Prioritized , That is, consider the priority , It means that each to-do item needs to be prioritized , So when there is a new demand , It can be compared according to priority , To determine where in the table .
This is also called DEEP Model , After completing the list , We can also measure whether the list of to-do items is reasonable .

---

Maintain a to-do list
We're going to insert a new to-do item

1. analysis ： Product managers analyze new requirements , Determine whether to place in the to-do list . If yes, add a new row in the table
2. Sort ： After putting it in , The product manager needs to evaluate the value of the requirements , And prioritize
3. understand ： The team understands the description of the requirements .
4. Estimate ： The team estimates the workload for this requirement
5. Update release plan

Iteration plan

Agile is the same as all project management , We need action plans to guide us to achieve our future goals , Planning can help us move forward in an orderly way , But agile planning is more frequent than traditional development , Agile planning is more flexible , We call it iteration planning .
In agility , We will add the user feedback from the previous iteration to this iteration , That is to say, agile landing is a closed loop , From the initial stage of evolution , Select the task with the highest priority according to the to-do list , Then the implementation phase completes the task , Then the feedback stage collects the user experience to get their most real ideas , In the final optimization stage, the optimization is carried out according to the previous feedback , These four stages help our products go to the best , Continuously improve user satisfaction . In the whole process , Iteration planning is used to help us move forward more efficiently .
Time box is a management method , That is, in the budget time to complete the function of the deletion or delay , Instead of procrastinating on the budget . A good iteration plan should be to schedule the highest value to do items in the time box as much as possible .

Make an iteration plan

1. Determine the iteration period , This is usually at the discretion of the team , Generally in 1~4 Between weeks . The iteration cycle mainly depends on two factors ： Agile maturity （ Refers to the team's ability to practice agile ） And the degree of Automation , The higher the degree of these two factors , The shorter the iteration period , On the contrary, the longer .
2. Identify key work items within an iteration ,
3. Fix the occurrence time of key work items , For example, we use two weeks of iteration , Then conduct the requirements review on Monday of the second week , The test starts on Tuesday . We usually use tables to list the occurrence time of fixed key work items , Put it where the team can see it , We all need to abide by .
4. Cultivate the team's sense of work rhythm , We will arrange regular weekly meetings according to the above table , Such as requirements review meeting 、 Iteration review meeting 、 The iteration plan will , wait .
5. If the urgency of the to-do is not consistent , You can set multiple publishing nodes in a time box , But generally no more than 2 individual . If there is an urgent need , It needs to be released within the iteration , We can also flexibly adjust , Let it publish , In principle, no more than 2 individual , Because there are too many releases in the iteration , The whole rhythm will be out of order , Then the iteration rhythm is meaningless .

Iteration planning meeting

First, determine the purpose of the meeting , That is, through the meeting, we should clarify the work to be carried out , Discuss and clarify information about your to-do list ; The second is to determine the participants of the meeting , commonly Scrum Master It's the organizer ,PO and Cross organizational functional teams should be involved ;
Then there is the agenda , This process is relatively complicated , We will elaborate later ; The third is to determine the iteration objectives through meetings , We can put this goal in a prominent place of the team to synchronize ;
Finally, the output , Make the results into an iterative to-do list , This is actually a subset of the to-do list , Because it is the highest priority selected from the to-do list .

The agenda of the meeting
Let's start with the first part , Be clear about what to do . In this part, we need to think in an alternate position , From the user's point of view , Use the product as a user , Put yourself in the situation and extract the pain points of users from the scene , This process is also called storytelling .
In the to-do list ,PO Will use MoSCoW Rule to prioritize tasks based on customer value . At this point, we will start from the to-do list , Select the pain points that can satisfy the users , User stories with higher priority , Then support user scenario landing , That is to realize this function .

MoSCoW The laws of ：
Must： What must be done — Feature set or Feature（ characteristic ） Is the foundation of the system , Without them , The system will not be able to work Or no value .
Should： What should be done — What we should have , In this way, the subsystem can be used normally , Without them , The system will be very, very difficult to use .
Could： What can be done — The added value of the product , Bonus highlights .
Would not： Don't do it – Features not required by this product .
The to-do list is awarded as Must、Should We need to ensure that we can complete ,Could The priority we strive for is not completed , When important changes occur , Our sacrifice priority is Could Even Should Things that guarantee change .

The second is to clarify what we do , In this section, we need to estimate the workload of the selected user stories , We can use story points and ideal man days to estimate the workload ; Then break down the task , Traverse all user stories , Break it down into tasks that team members can perform , For example, it is divided into front-end tasks 、 Back end task 、 Joint commissioning task 、 Test tasks, etc , User story decomposition follows the principle of "who claims who decomposes" ; Finally, the team promises , When a task is assigned to a member , Each time, members should promise to guarantee quality and quantity , Try not to delay the completion of the task .

Two estimation methods

• Estimation of ideal man days This is an individual estimate .
  Specifically, it refers to the ideal situation in which there is no emergency , The amount of work required by a developer to complete the story . This method is relatively simple to implement , It takes less time to complete a round of estimation , Because everyone is familiar with their work efficiency , So this estimation method is more mainstream .
• Agile recommends using story point estimation , This is a collective estimate .

1. Establish an estimate benchmark that the team agrees with , That is, the team should have a consistent understanding of the same requirement . This benchmark can be the number of pages to complete a requirement , It can also be the number of additions, deletions, changes and queries to the database , It can also be a step to complete the operation , The benchmark value of general completion unit function is 1;
2. For the same need , Each member should give his or her own evaluation value , Then by estimating the poker method at the same time , Because it's a relative estimate , We are based on the Fibonacci sequence , Set the story points to 0,1,2,3,5,8,13,20,40,60.
3. The member who estimates the lowest and highest gives reasons for his estimation . such as A Think the demand points are 60, because Many algorithms are involved in the requirements , The team has not done any algorithmic work before . and B Think the demand points are 5, Because he knows that a third-party algorithm tool can directly reference . Combine these factors , The team considers B The feasibility of the idea , The final decision to assess this need is 5 A story point ;
4. The same requirement 2 To 3 Round estimate , Usually use 5 The estimate of the demand can be finalized in about minutes ;
5. Repeat the first 2、 3 Step , Until the workload of all requirements in this iteration is estimated .

Agile execution and monitoring

Clarify the responsibilities of the team and members outside the team

Want to make agile team progress transparent , First of all, we should make members inside and outside the team clear about their responsibilities .
Key agile team members Product Owner、Scrum Master and Team.
It is necessary to distinguish the responsibilities of internal and external personnel of the team . People outside the team are , People who have no direct output to the team , Like management 、 Investors and customers . For outsiders , We just need to refer to their opinions , Just deliver the value they want , There is no need to involve him in the whole thing .

Daily station will

During the execution of the project , This is a very important tool . Because the information of our team can flow in the daily station meeting , So it can help us synchronize progress , At the same time, problems are exposed in time , And can correct problems in time .

• Daily station meeting process
  This is the general process of daily station meeting , The team stands in a circle around the information source such as the whiteboard , Then everyone takes turns speaking . There are two speaking formats , It mainly depends on which agile approach our team uses .
  If it's iteration based agile , So what we mainly do is synchronize progress and throw problems , Focus on the commitment of the self-organizing team . The format of the speech is ： What did I do yesterday ？ What are you going to do today ？ What's the problem , Who will help me ？
  If it is process based agile , So we focus on the completion of the team , What we mainly do is the collaboration between the upper and lower classes . The format of the speech is ： We still need to do something to advance this ⼀⼯ do ？ Yes ⼈ Are you doing something that isn't on the Kanban ？ As ⼀ A team , What we need to accomplish ？⼯ Whether there are bottlenecks or obstacles in the process ？
• The specific rules of the daily standing meeting

1. The team size shall not exceed 10 name . Because the path of communication is N*(N-1)/2, That means more people , The less effective communication is , So we should try to keep 10 A small group of people .
2. It needs to be done every day . The core of agility is the small step and fast run , So we split the task granularity into 1 Days. , Everyone can finish at least 1 A mission , In this way, the team makes new progress every day , But there will also be new problems , Therefore, it is necessary to carry out station synchronization every day
3. A fixed period of time and no more than each time 15 minute . I suggest going to work every morning 15 It's going to start in minutes , Team members can use 15
   Minutes to sort out the work done yesterday .Scrum Master Control meeting time to ensure efficiency .
4. A fixed place . The team can gather at the designated place at a fixed time , Faster 、 direct .
5. Standing required , It's easy to concentrate , Subconsciously, it is easy for people to want to finish the meeting quickly , So it will improve efficiency .
6. Don't solve the problem . If the problem is solved during the station meeting , It will spread the theme of the meeting , Let's throw the problem out , After the station meeting Scrum Master Special meetings can be arranged to solve problems .
7. All relevant personnel shall be present , All project related personnel are required to attend the meeting .
8. People outside the team cannot speak , In order to avoid outsiders who are not familiar with the team interfering with the normal work process of the team .
9. have access to “ Speaking token ”, Such as tennis , Plush toys, etc , Randomly throw to team members , Get “ Speaking token ” Only members of the group may speak . This makes team members ready to speak next , People will be more focused .

Be good at using information synchronization tools

Agile focuses on efficiency , In the team , Fast information synchronization is very important to improve efficiency , So it is very important to be good at using information synchronization tools

• Iteration version calendar
• Whiteboard

Changes in the way people communicate will have an impact on how people understand each other , When we communicate remotely, we need new conference processes and behavior patterns

1. The clarity of the topic and the consistency of the meeting are the key to the success of the video conference , We need to agree the meeting rules in advance to avoid confusion . The rules include speaking time 、 Which unified communication platform is used .
2. The clearer the rules are, the better , Unless the team has already defined , Otherwise, use less English abbreviations or proper nouns .
3. Don't send too much information to the team , Before sending , Think carefully about what you want to say , Avoid ambiguity .
4. Pay attention to the introverts in the team , These people are good at written communication , In fact, remote communication is to provide a fairer competitive environment for those who do not like to speak in the group
5. Last , Find ways to celebrate and socialize remotely , For example, send wechat red envelopes 、 Hold remote birthday party, etc , Enhance the cohesion and cooperation ability of the team .

Close it up

Show

Show （Sprint Review）, Also called iterative review . At the exhibition ,Product Owner Will accept the results of this iteration , And make a decision whether to accept or reject , In this way, we can know whether this iteration will succeed or fail .
Why do we have a presentation ？ This is because with the help of the exhibition, we can check and accept the results before they are released , This helps us know as early as possible whether the results can be accepted , And we can find any problems in time , You can make optimization actions faster , Prevent the team from making directional mistakes , It can also make customers more satisfied ; At the same time, this short-term outcome , It can ensure that the product development objectives are more clear , And be consistent .

• Presentation process
  First ,Scrum Master Invite people to the meeting , Our team includes developers 、 Testers and ProductOwner Must participate in , If there are conditions , It's best to invite management and customers to participate , This will help enhance the confidence of the management and customers in the product . It is worth noting that , If important roles are invited , We need to do the internal acceptance and test well in advance , avoid “ Rollover ”.
  Before the meeting ,Scrum Master The review environment should be set up , For example, the operating environment of the product 、 Conference room and projection for presentation 、 Whiteboard these tools . Throughout the meeting ,Scrum Master Not only be responsible for reading out and showing the meeting process , And maintain the normal progress of the meeting process .
  After the meeting , The developer is responsible for demonstrating the output, i.e. the content of this iteration , Start the demonstration from the perspective of user scenarios , During this process, other participants can express their own views on the presentation , The developer has an obligation to answer the proposer's questions , Until we have no more questions . in the meantime , The tester needs to evaluate the quality of this presentation .
  After answering questions ,Product Owner A decision needs to be made to accept or reject this iteration , If you refuse, give reasons , And require the team to make corresponding rectification . after ,Product Owner Will lead the team to discuss the content of the next iteration , So that everyone has a preliminary expectation for the next iteration , If necessary, you can talk about the user scenarios for the next iteration , such as , We have completed the docking of payment functions in this iteration , In the next iteration, we need to focus on user activity , New task function , It is expected that the daily life will be improved 10%

matters needing attention

1. The presentation meeting should control the time , Generally not more than 2 Hours ;
2. In order to make the speech go smoothly , Relevant personnel are required to prepare the speech content in advance ;
3. Scrum Master It is necessary to have Plan B, In order to deal with other emergencies such as problems of equipment in the on-site demonstration environment .

Review meeting

stay 《 Agile Manifesto 》 The review meeting is described in the principle of ：“ The team should regularly reflect on how it can be more effective , And adjust the team accordingly ⾏ by ”. So the retrospective is not about blaming , Instead, learn from your previous work experience , Help the team learn to improve continuously .
Generally, a review meeting is held under the following circumstances

1. When the team completes ⼀ Publish or add ⼊⼀ Some functions . here , No matter the length of the iteration period , Or more or less functions to be completed , We all need to review .
2. When the team realizes there is a problem , And when teamwork is not smooth . here , We can have a review meeting , Help us adjust our existing working mode . Through the review meeting , We can collect the process data of problems , Then analyze the data to find the root cause , And then discuss new ways to solve the problem .
3. When the team reaches any other milestone . We can better continue the follow-up work through review .
4. When there is an Internet failure , We need to reproduce the fault scenario through the review meeting , Analyze the problem at that time , The team discussed the solution , then Scrum Master Follow up and solve .

• Review meeting process
  The review meeting is divided into quantitative review and qualitative review . We need to do quantitative analysis first , At this time, two kinds of data need to be displayed .
  One is the result data , The team can see what they have achieved through the result data , This can enhance the confidence and cohesion of the team , Specifically, we need to pay attention to the following data .

1. Technical data
2. Process data , Include BUG Situation and team speed
   The other is process data , This makes the team more aware of the process , Specifically, attention should be paid to ：
3. Revenue data
4. Active data
5. Keep data

After the quantitative review , We have to do qualitative analysis . Qualitative analysis is to find out the improvement points in the team process , The specific steps are ：

1. Scrum Master Give team members a few simple signs ;
2. Team Each member of the is at 10 Write at least two in minutes , Write respectively “ Well done ” and “ Something to be improved ”, And write only one comment on each piece of paper for combined analysis ;
3. Scrum Master Collect notes , Then paste the well done ones on the left wall , Put what needs to be improved on the right wall ;
4. Scrum Master First comment on the well done part , This kind of affirmation can enhance the confidence of the team ;
5. For notes that need to be improved ,Scrum Master You can ask the person who filled in the form to explain , Then categorize them according to the type of problem , It can be divided into demand problems 、 Test questions 、 Development issues 、 Team issues or other issues ;
6. Scrum Master Ask the team to vote on the classified questions Top3 The problem of , Because the team can not solve all the problems at once , So we should solve the main problems , Then each iteration makes improvements ;
7. Scrum Master Guide the team to Top3 Discuss solutions to problems , And determine the person in charge of the scheme and the solution time ;
8. Scrum Master Put the plan 、 The person in charge and the settlement time shall be recorded as meeting minutes , And synchronize with relevant personnel , Follow up in later iterations , Until the problem is closed .

The performance of

How to measure agile team performance scientifically and effectively ？ This is mainly from the speed 、 Quality and value are three dimensions

Speed

Let's start with speed , It includes demand response capability and release capability . Agile focuses on efficiency , Literally, it's speed , Here we mainly measure whether the team has the ability to execute quickly .
among , Requirement responsiveness refers to the ability of agile teams to process and deliver user requirements , It is mainly reflected in the lead cycle of business requirements and the delivery cycle of user stories , The former is made up of Product Owner be responsible for , It refers to the time from when the user's demand is proposed to when it is scheduled ; The latter is caused by Scrum Master be responsible for , It refers to the time when the user story is scheduled to be released . The shorter these two cycles , Then it shows that the team has stronger demand response ability
The release capability is mainly reflected in the integration test cycle 、 The release frequency and the average time to solve the release problems are higher ：

1. Integration test cycle refers to the time from development to test to completion of integration test , The shorter the cycle , The stronger the testing ability of the team ;
2. Release frequency refers to the interval between two releases of the team , The shorter the interval, the stronger the team's engineering ability .
3. The average time to resolve a release issue is , After product launch , The average time from the appearance of an Internet problem to each problem solved , This tests the team's ability to respond and solve problems when they are released and there are problems on the Internet .

• This data can usually be found in project management tools , The calculation formula is as follows ：
• • Integration test time = Test completion time - Transfer time ;
• • Frequency of release = Release time of this iteration - Release time of the last iteration ;
• • Length of time to resolve release issues = Problem solving time - Problem discovery time .

quality

Quality is the core of a product , The higher the score of this dimension, the more likely the team is to create high-quality products .
Quality is divided into internal quality and external network quality . Internal quality refers to the quality of products during testing （ Including unit tests 、 Integration testing 、 Pre launch test and online test ） Quality produced in , It is reflected in the number of defects left in a unit cycle and the number of defects in a single user story , Defect is Bug.
Here, the number of defects left per unit period refers to , The remaining number of defects generated in an iteration cycle at the completion of the iteration ; The number of defects in a single user story is , The number of defects that developers generate in implementing a user story .
We calculate the number of defects by weighting . For example, defects are classified into fatal defects according to their severity 、 Serious defects 、 General defects 、 Minor defects and suggested defects , Usually their weights are 5、4、3、2、1, Here the severity measure is given by the tester , Due to the limited space, there is no expansion here . We count the number of defects of the same degree according to this standard , The lower the number of defects , Then the internal quality of the team will be better .
Internet quality refers to the quality of products after they are released , The quality it presents on the Internet , This involves the feedback of external network problems and the annual average failure rate of the system . Internet problem feedback refers to users' roast about product quality , These are difficult to quantify , Usually we will be in the product forum 、 tieba 、 Apple App Store Or other application markets , As well as customer service calls and App Collect users' roast through their own feedback channels . Once something goes wrong with the application itself , One user may use multiple accounts to feed back this problem in different channels , Therefore, it is difficult for us to explain the decline of evaluation quality by user feedback , And it's hard to assess the severity of the problem from roast , So we generally measure the annual mean failure rate of the system .
The annual mean failure rate of the system refers to , The sum of the system failure time in one year divided by the total system service time in one year , The lower the number is , It shows that the system developed by the team is more stable , The higher the quality .

value

The core of agile is value driven , The value dimension can help us measure whether the team has mastered the core of agile , And how to master it .
Value is measured by demand throughput and delivery effectiveness , say concretely , Throughput refers to the number of business requirements delivered per unit time , For example, in an iteration , How many business requirements have our team delivered . Delivery effectiveness is the demand value of the business . Demand will have value , Some requirements have direct value , For example, how much revenue has been increased or how many users will be increased , Or the user activity rate has been improved , There are also some requirements that have no direct value , For example, it improves the user experience . Direct value can be quantified , But there is no way to quantify the indirect value . So when the team makes a vertical validity measurement with itself , It is more suitable to use value .
After that, let's take a look at the specific measures , That is, performance management . Performance management refers to the management and employees at all levels in order to achieve organizational goals , Participate in the formulation of performance plan 、 Performance coaching communication 、 Performance evaluation 、 Application of performance results 、 The continuous cycle process of performance target promotion .

Misunderstanding of performance management

first , Equate performance measurement with performance management , In fact, performance management is a management process that managers at all levels must pay attention to , It includes a performance plan 、 Performance implementation 、 Performance measurement and performance improvement . Performance measurement is only a part of performance management , Is an effective management tool .
The second thing we need to pay attention to is , Some teams only use the results of performance measurement mainly for bonus and salary adjustment . Although through performance management , We can make the salary distribution from experience management to scientific management , But performance management is more important to organizations , Through performance management, we can make employees' efforts towards the strategic objectives of the organization . say concretely , Performance management can let every employee know their own growth direction . For businesses , Successful performance management can improve the performance of enterprises , Let all members share the fruits of success .
If only for bonus and salary adjustment , Employees can show what you want to see according to your standards . For example, you want to reduce the number of thousand lines of code Bug rate , Then employees can start from two aspects ： One is to write dozens of lines of code for tasks that can be completed with dozens of lines of code , Or ask the tester privately Bug, Not put Bug Recorded in the project management system .
The third thing to note is , Don't go overboard with comprehensive metrics . In addition to the indicators we listed earlier , There are also many indicators that can measure performance , For example, the number of defects per page , test Bug Response period, etc . however , Measuring indicators is not the more the better , This is because ：

1. Too many indicators increase the difficulty of data collection , The workload of data collection is greatly increased ;
2. Faced with so many indicators , Team members may not be able to take care of every indicator , That is, it is unable to achieve good performance in all indicators . In the event that it cannot be fully completed , Team members are likely to abandon oneortwo indicators that are difficult to achieve , These indicators may be key performance indicators .

The last thing to note is , Never ignore the real goal of performance management , That is to help managers make continuous improvement 、 Improve performance . Some managers prefer to measure the performance of different teams directly , To compare the level of team performance . however , A team is a complex system , What you do 、 The ability of team members , And the team running in time is different , So we can not use a unified standard to measure , So we should focus on the goal of performance management .

How to go from 0 To 1 Introducing agility

Transformation management drivers

Often companies choose to introduce agile for some reason , We call this motive Transformation management drivers . According to my years of project management experience , There are two main motivations for transformation .
The first is Related to accelerated delivery The transformation of the . Enterprises often start from small teams with less than 100 people , As you grow, the number will increase , The way I used to work is becoming more and more inappropriate , Organizational efficiency will be lower and lower , Especially when the number of people exceeds 1000 , Managers are aware of the need to improve delivery efficiency , Accelerate the delivery process , Agile can help enterprises achieve this goal , So they want to introduce agile . This situation often occurs in the Internet industry or traditional software industry , They usually measure the output of agile introduction in terms of performance results .
The second is Related to agile methods The transformation of the . Agile has been popularized in China for more than ten years , Many companies have introduced agile and achieved good results , Tencent, for example . This has attracted the attention of other large enterprises , If agile can make the company better , Then why don't I try ？ So they also want to introduce agile , And it usually takes changing the cooperation mode as the cut-off point , Because they want agile to help their teams and other departments 、 More frequent communication and collaboration between suppliers . They pay more attention to the measurement of agile process , For example, whether the efficiency of some links has been improved , How far is it from the best in the industry . This situation is common in the banking industry .
Motivation for different businesses , We should also have different ways of transformation . If it is a transformation related to accelerated delivery , We need to pay more attention to the results of agile import , For example, after agile introduction , Whether the delivery of value is optimized , Whether the income has increased compared with the original , Whether the number of users has increased , Users are full It means Whether the degree is enhanced . If it is a transformation related to agile methods , We need to measure the maturity of the enterprise , Set an industry benchmark for yourself , Coach the team to make process improvement , Strive to reach or approach the level of the industry benchmark

Influencing factors of agile transformation

First, let's understand the negative factors that are not conducive to transformation agility , Mainly related to these situations ：

1. Work is broken down into departmental silos , from ⽽ Create dependencies that hinder accelerated delivery , Not built on the ability to ⼒ in ⼼ Cross functional team under the guidance , in other words , The thicker the Department wall, the less conducive to agile transformation ;
2. Short term delivery projects are not suitable for agile . For example, we undertake Party A's demand development , The products required to be delivered by Party A are particularly clear , Changes arising during this period will also be described in the supplementary contract , The delivery time will also be clearly written in the contract , Because there are no frequent changes in this project , So there is no need for agility ;
3. Team optimization is based on partial efficiency rather than end-to-end project delivery flow or overall optimization , Because if you only want to improve R & D efficiency , So the effect of agile transformation is limited , What agile can bring is all-round optimization , So during the import process , We should focus on the overall situation ;
4. Employees belong to specific fields , The tools or incentives to diversify skills are limited , Do not pay attention to training T Type experts ⼈ only . Because agile is a cross functional team , Everyone except their own field , It's better to have expertise in other fields , For example, development engineers have product thinking . Agility encourages T Professional talents , namely Have expertise in a certain field , At the same time, people who have certain experience and opinions in many other fields . If the team only emphasizes cultivating talents in specific fields , This is just cultivating screws , It doesn't bring a lot of benefits to cross functional teams ;
5. Decentralized project portfolio even if employees are assigned too many projects at the same time , Instead of focusing on a single project . The Agile Manifesto mentions “ Working software is better than comprehensive documentation ”, Explain that agile teams advocate simplifying documentation . That's why , So we need to keep the team stable , The main thing is that the team members are relatively fixed , If the employee is assigned too many items , Will break this stable team structure , Agile transformation is difficult to succeed .

secondly , Let's look at the positive factors that can drive agile transformation , It mainly involves these aspects ：

1. The management has a strong desire for transformation . Any transformation is top-down , Agile transformation is no exception , The stronger the management's willingness to transform , Enterprises' agile transformation is also easier to succeed ;
2. Employees' awareness and willingness to change . If employees recognize agile , Think Agile transformation can solve their current problems , And willing to make changes in the way they work . For example, start to build cross functional teams 、 Carry out morning meeting and review meeting , The stronger the awareness and willingness to change , The easier it is to succeed ;
3. Build cross functional teams . If the leaders are willing to adjust the original organizational structure to a cross functional team , Provide natural soil suitable for growth for agility , Then the team is more likely to succeed in transformation . For example, tencent , It is a typical cross functional organization , product 、 Development 、 Test and operation are organized on a project by project basis , Everyone bears the performance together KPI, Set common goals . besides , The salary increase of employees is not directly evaluated by their functional leaders , Instead, the channel committee decides the rank of the employees ,HR Then the salary will be adjusted according to the rank . Such a team only serves to achieve the product objectives , Very agile ;
4. Focus on short-term goals instead of ⻓ Period objectives . Agile teams need constant trial and error to gain short-term benefits , So agile teams pay more attention to the achievement of short-term goals , If the team belongs to this feature , Then it is more suitable for agile transformation ;
5. ⼈ To manage maturity and competence . Agile has high requirements for teams , One is that agile encourages self-organizing teams , So the team must have the ability to manage itself , This requires a lot of team members ; Second, agile requires the team to have strong automation ability , For example, automated testing 、 Automated build and automated deployment . The stronger the team's self-management ability , The more automated the team is , Agile transformation is also easier to succeed .

If the team's positive factors outweigh the negative factors , The higher the success rate of agile transformation , On the contrary, the lower the success rate , So we are These factors should be identified as far as possible before transformation , In order to promote agile Introduction , We can follow the above concerns , Avoid negative factors , Develop positive factors .

Selection of pilot projects

Agility is not achieved overnight , We will choose the pilot project to cut into .

• First of all The importance of the project .
  Select the next most important project for transformation , The impact of this is relatively good , And it is controllable .
• The second is The cycle of the project .
  It's best to continue Time for intra enterprise projects is usually Of Projects that last about half the time , This cycle is about threeorfour months . This gives the team enough time to Sprint I work very well in , Realize Scrum Benefits . And this project cycle can fully prove Scrum Similar success can be achieved in longer cycle projects
• Also need to consider Scale of the project .
  There is only one team project to start with , And have the team members sit together , Even if the pilot project will be expanded to multiple teams in the future , We should also start with a team , This is because ：

1. It can save the cost of communication between multiple teams ;
2. The first pilot team needs an agile coach to focus on where to go The reason is There are a lot of problems ;
3. The results of a team are easier to quantify , Facilitate the display of the final transformation effect .

• Also need to consider Business or customer support and participation

In the process of transformation , We need to train people to output documents , Prepare for the subsequent agile transformation of the whole company , So we need to train at least one Scrum Master, This role requires a professional agile coach , And it can implement appropriate agile practices in combination with the actual situation of the company . in addition , You also need to output “ So and so company Scrum Master Instruction manual ”, To guide the company's Scrum Master Agile transformation .
Last , We also need someone to regularly promote the effectiveness of agile practices and outputs , If the company has PMO （ ProjectManagement Office ） The team , The responsibility will fall on them ; If there is HRBP（ HR Business Partner）, Then he is obliged to do it . If we don't have these two roles , Then at least one person should be selected from the pilot team to take charge of this matter , Only by constantly letting others know the tangible benefits agile brings to the team , Will stimulate the transformation willingness of other teams in the company .

---

Here are some personal thoughts

No company involvement in agile practices , To be added …

---

At the end of the article

Give us a brain teaser . We all know why Hou Yi only used three arrows to shoot the ninth day ？
Because he shot three times [ Manual doge]​！
You can see it here , If it helps you , Please also help me make some comments , Pay attention ~
Last ： Here's a message . Low starting point , Current net , It's dirty , It's normal ！