In the second R&D Performance Carnival 2018, Zhang Liaoyuan from Alibaba Group r&d performance brought the audience a wonderful sharing of “Across the Agile — Idle fish R&D performance Upgrade Road”. In the sharing, he elaborated the road of Xiyu’s agile transformation from four aspects: business-oriented cross-functional collaboration, collaboration and flow according to demand, making functional services related to goals, and measuring data service transformation and improving efficiency.
Among the limited-time discounts of dozens of Aliyun products,Click here, get coupons and start practicing on the cloud!
Highlight video review click here
Share PPT download click here
Here are the highlights:
Disadvantages of waterfall development in the VUCA era
Now known as the Era of VUCA, more and more enterprises and organizations are facing the transformation of software development. According to Moore’s Law and anti-Moore’s Law, companies should reduce product development cycles as much as possible.
However, in the vast majority of software development process, the traditional software development strategy adopts the waterfall development mode, especially some traditional enterprises, usually reserved a few months to do requirements analysis, and then several months to do design, development, testing, to the final release, the overall cycle may be very long. The earliest decision on what to do is made in the demand analysis stage of the product, that is, the decision is made when the knowledge of the product project is least. This is a paradox, that is, when the knowledge accumulation is least, the decision is made for the future of the product and determines the future development direction of the product.
Therefore, in this environment, we can no longer adopt the traditional way of software development, but need to update the development strategy: In the early stages of the initial decision, after an iterative cycle, according to user feedback, the cognition of product and technology environment and the change of market environment for knowledge accumulation, at this time again according to the accumulated knowledge gradually incremental decision making and adjustment, that is to say, the iteration after delivery out features of the product can help us to verify the market and users, to help us continue to adjust, This in turn allows us to test the waters again during the next iteration, and this constant feedback allows us to constantly adjust to change, known as agility.
Obviously, the vast majority of Internet products should be developed in an agile manner. According to agile thinking, xianyu team transforms and improves the existing software development mode.
Idle fish transformation efficiency improvement strategy
The efficiency improvement strategy of Idle Fish transformation firstly defines 211 goals, namely 2 weeks delivery cycle, 2 weeks development cycle and 1 hour release time. For identified goals, they are broken down and measured using process metrics such as delivery scatter points, cumulative flow charts, defect trends, release efficiency, etc. For its grip, mainly from three aspects:
· Demand side: clear objectives, methods and functions, determine product demand organization, split demand, and communicate accordingly;
· Delivery collaboration: ensure smooth business value stream, sort out work flow and organize collaboration around business;
· Feedback adjustment side: In the whole development process, feedback adjustment needs to be carried out continuously, which can be adjusted through performance measurement and business operation data.
Let’s analyze it in detail. Let’s start with teamwork:
Business-oriented cross-functional collaboration
In the process of Internet development, there are often some things that make people laugh: for example, I have already designed the product design, the rest is for you, or I have written all the code, the rest is for you and so on. This is how our silos work together in software development. In the traditional software development process, there are often functional units to cooperate with each other.
As shown in the figure above, product design and development are carried out in its silos. Development, testing and operation and maintenance are also corresponding to their own functional silos. Collaboration between each other is completed by “ladder”, which can be imagined that the efficiency is extremely low in the process of transmission. In order to improve efficiency, organizations and collaborators usually make a large number of product requirements to be delivered to the development, and then the development of this batch of requirements to the test after the completion of development, testing and then… Batches are produced in the whole process. The vast majority of the collaboration time is spent waiting, and from the user’s point of view, there is very little time to actually process things (as shown by the green line above), making the overall efficiency quite low.
There is also a game between different job functions. For example, product managers want to develop as many features as possible and the time needed is as short as possible, while developers want to reduce development requirements as much as possible and increase development time to achieve functional perfection. So how can this problem be solved?
The solution adopted by us is to change the tossing between functions into business-oriented cross-functional cooperation, and to divide the personnel involved in the project by business. For example, business A includes its own PD, UED, front-end, back-end and testing. In this business-oriented organization, the goals of the people involved change from completing the corresponding tasks to delivering specific business requirements as soon as possible; In addition, this organization makes the communication between development, testing, front end, etc., become smooth, and everyone discusses based on the same context, which improves the communication efficiency. The reason for maintaining functional teams is to promote individual skill development. Therefore, from the perspective of business delivery, the cross-functional team should be established based on business capability orientation. Starting from the direction of personnel skill training, the functional team is set up with the function orientation. In addition, we also advocate that team members should be fixed in a certain business team and serve a specific business within a relatively fixed period of time. In this way, each business has a relatively fixed personnel allocation and resource allocation is less prone to bottlenecks. ; At the same time, it also supports certain cross-business mobility to ensure the breadth of business knowledge accumulation of personnel.
This is business-oriented cross-functional cooperation from the perspective of the organization of personnel. Next, we will analyze the efficiency improvement strategy from the perspective of collaboration.
Collaborate and flow as needed
In the collaborative process of software development, there are so many details and collaborations that it is difficult to distinguish key points in the overall process. Therefore, visualization is especially necessary.
In the transition process of idle fish efficiency improvement, we designed and manufactured many boards like the one shown above. On the whiteboard shown in the figure above, the collaboration workflow, such as the stages experienced in the process of requirements development and the relationship between upstream and downstream, is first identified. Another point is that all steps are coordinated on a requirements basis. The blue box on the board represents the overall workflow, and the red five-pointed star is the flow rule that determines each requirement.
Why collaboration and flow in terms of requirements? First, we deliver business value, features, capabilities to our customers. The task board method was adopted at the earliest, and I found that everyone was busy and did a lot of things every day, but when I looked back, I found that the requirements were not completed. Therefore, focusing on the task board is not as good as focusing on the value board. Therefore, we made the demand value plate as shown in the figure above, focusing on the flow of value and making value flow out faster. The value board consists of many phases. The red box in the figure above includes five horizontal corridors, which indicate that the development team can only support concurrent development of up to five requirements during development. The reason for limiting the amount of parallelism is to improve the development cycle and make requirements flow more quickly.
The orange box shows the release rhythm on the value board, covering both web and mobile; The green box in the figure shows the visual resource pool. Each person in the resource pool has two points, indicating that he/she participates in two requirements, which clearly shows the configuration of personnel on requirements. Through the value board, we can clearly see where requirements are accumulating, as shown above in the selection phase and when there is a visual break, making it easy to visualize all problems and locate them. In addition, the value board can also pay attention to the rhythm of the released version, communicate from right to left when standing every day, whether there is demand release, gray level, test, walk check, development, forming a pull process (priority from top to bottom). The bottom left corner is the products and requirements that may be developed in the future. The goals and methods are determined in advance, and the organization and communication are carried out in advance.
What happens when you have a value board?
Above is a comparison of the morning meeting before and now. Before, the project manager synchronized the progress and status of the project, and most people were doing their own things; Now, business-oriented teams do morning meetings at a board, with everyone on the team coordinating the flow of requirements.
Kanban view from cloud effect public cloud (www.aliyun.com/product/yun)…
When team members are working in remote locations, it’s not practical to have morning meetings at a physical board. To solve this problem, we upgraded the physical board to a cloud effect electronic board with similar content to the physical board, making remote synchronization much simpler. By means of value board, we visualized the workflow and controlled the value flow by means of morning meeting, limiting the number of parallelism on board, etc.
So what is the relationship between value board requirements and business goals? What are the relationships between requirements? What is the relationship between business goals and requirements? These questions are answered in terms of functional service association goals.
Make functional services associated with goals
As is shown in the picture above, different people use different ways to cross the river. Crossing the river is the goal, crossing the river is to build a bridge, and crossing the river is to dig a tunnel. If the methods of crossing the river are not consistent, it will obviously be inconsistent.
In software development, we face a similar problem, because the language of business function is different from that of development function. Business function is domain concept, while development is a certain design model, algorithm, etc. At this time, how to break the barrier of understanding, communication and collaboration between business function and development function is particularly important; Another challenge is the ambiguous and inconsistent relationship between business goals and product functionality. For example, if the business goal is to increase the conversion rate by 30%, what should the corresponding product feature be added? What are they related to each other?
We can use the golden Circle method to represent everything from business goals to product features. As shown in the figure, the innermost layer of the golden circle is Why, the middle layer is How, and the outermost layer is What. Why refers to business objectives, and How refers to business methods or business scenarios. What indicates product functions. By sorting out Why, How and What, we can determine the business objectives of product functions developed and the development sequence of functional requirements.
The figure above shows a specific case based on the Golden Circle rule. Determine the product path from the business map, decompose the product path into several key indicators according to the business objectives, identify key functions, to achieve key indicators such as How many times to improve the search relevance, for different ways, adopt different ways, here are listed respectively Why, How and What. This path map is usually pasted next to the value board and regularly aligns the business teams with the business goals, practices, and functions they are currently working on.
The first three parts are more about business teams, collaboration, and feature identification, and finally how to achieve continuous improvement.
Measure data service transformation performance
Without measuring insight, management is nothing more than a blind man touching an elephant. So we need complete metrics or data that can provide insight to help us identify the objects under management.
More data measurement dimensions reference [Cloud performance measurement features](help.aliyun.com/document_de…)
Going back to the delivery response cycle/development response cycle, it is easy to determine the lead time of a requirement, and how long it will take at a given stage, by looking at the requirements as they flow through the different phases. Since the requirements take a long time (blue for requirements time, green for development time) and the requirements phase is 1:1 on the right, we need to think about why it takes so long on the requirements side.
Another measure is delivery frequency, defect, and cumulative distribution.
Delivery frequency, defect and cumulative distribution
More data measurement dimensions reference [Cloud performance measurement features](help.aliyun.com/document_de…)
The figure above shows delivery frequency, defect, and cumulative flow respectively. Each point in the requirement delivery scatter chart represents a requirement release. The vertical axis represents the cumulative length of time when the requirement is released, and the horizontal axis represents the point in time when the requirement is released. The demand accumulation diagram on the left represents the quantity accumulated in different stages of demand, the height represents the quantity of backlog wIS, and the lead time in a certain stage can be determined horizontally. In the defect trend chart, the red column represents the number of newly discovered defects, while the green column represents the number of defects repaired on the day, which is accumulated over time.
There are two sides to metrics or indicators. Sometimes, if the indicators are not good enough, they will do great damage to the team as a whole. Therefore, good metrics or indicators should be selected. So how do you identify good metrics or indicators?
More data measurement dimensions reference [Cloud performance measurement features](help.aliyun.com/document_de…)
A good metric is that it should be simple, not complicated; The second best metric is to express a complete “story,” not a single point of information; The third best metric should trigger an action. As demand present in an electronic bulletin board, in cloud effect, can also be measured data visualization, pictured above, average cumulative flow diagrams can show demand, effective defect the shut down time, defect trend diagram, demand development data such as average stay length, through these data can help us in r&d efficiency was improved.
Future Development Plan
Establish functional business loop
We are still working on the feedback mechanism after the product is delivered. The next step is to establish a functional business closed loop, first determine the product stage objectives and methods; Fast delivery of functional requirements; After that, according to the feedback and analysis of operation data, the product objectives and methods of the next stage will be determined to form a functional business closed loop.
Continuous integration publishing system
Another focus of the future work is to establish the continuous integration release system, which mainly includes the following work:
· Establishment of defect review analysis mechanism (RCA/EDA);
· Combed and improved continuous integration/release pipeline;
· Continuously test layering
Automation,
Through the above mechanism guarantee, the efficiency of product release can be significantly improved.
The original link