当前位置：网站首页>Read the five flow indicators of R & D efficiency insight

Many years ago , There are probably only 100 Ten thousand lines of code , For basic drive function （ Such as traction control ）; It soon grew to 1000 Wan line code , To meet more and more digitalization 、 The growth of electronic control units , And the complexity of additional control software brought by electric vehicles ; With the development of automobile interconnection and information entertainment , In a few years ago , A BMW has reached 1 One hundred million lines of code ; With the popularization of automatic driving technology , Maybe soon there will be 10 One hundred million lines of code . by comparison , How much code is there in the operating system installed on our desktop computer ？ Data shows , Microsoft Windows The operating system probably has 6000 About ten thousand lines of code .

therefore , Cars have become computers on wheels .

chart 1： Modern cars have become computers on wheels

This is just a small example , What I want to say is , We really , Has been in the key node of the digital era .

But a little ironic , In the digital age , As IT practitioners , Our R & D management , Sometimes it is still in a relatively backward state .

Many enterprises are still using the methods used in the last technological revolution , It continues the old behavior and outdated way of thinking . For example, use the method of measuring physical workers nearly a century ago , Pay too much attention to the length of work 、 Human resource saturation , Excessive demand for standardization and uniformity of work activities ; Pay too much attention to the proxy indicators of work output （ How many lines of code did the developer write 、 How much does the tester measure Bug）, Instead of maximizing business results ; Pay too much attention to local optimization （ The degree of automation of a certain research and development process 、 What is used DevOps Tools ）, Not global optimization （ End to end delivery efficiency and quality ）......

So that now , In many cases, the software development process is still a black box , Lack of end-to-end visibility , Where is the congestion 、 Where is waste 、 Where there are risks , Managers may not know , product 、 Development 、 test 、 The real pain points of operation and maintenance , It is also easy to be buried in endless needs and work , It's even scarier , After a long time, everyone is used to it .

however , We still have something to pursue , We need to find a way , Let software research and development itself be digitalized . Digitalization is from the physical world , Mining data , Rough out information , Refine knowledge , Gather wisdom , Ultimately improve productivity .

According to this logic , R & D digitalization , We can start with building an effective R & D efficiency insight system .

The topic of R & D effectiveness insight system is very big , It involves the construction of R & D infrastructure 、 Design of measurement index system 、 Construction of insight analysis model 、 Insight into the realization of tool products 、 Operation based on data-driven and experimental thinking . Limited to space , This article only expands a small part , That is, focus on the five flow indicators in the value stream management method of software delivery , Effective insight into the R & D process , And analyze the potential problems and bottlenecks .

chart 2： R & D efficiency insight system

2 Flow framework and five flow indicators

stay 2018 At the end of the year, there is a book named 《Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework》 Publication of works , The book points out that business is related to IT The disconnect between is one of the fundamental reasons for the failure of digital transformation , And further refined a called “ Flow framework ” New model of , It is used to establish the missing connection between business driven digital transformation and the technological transformation supporting them .

I remember that it was Mr. He Mian who recommended this book to me , After I saw it, I really felt sorry to meet you late , I think the contents of the book have strong guiding significance and high reference value for the whole industry , Then I decided to translate it into Chinese with my friends （ Forthcoming publication , Coming soon ）.

In this paper, we will first focus on the five flow indicators in the flow framework .

chart 3： Five liquidity indicators

You may want to ask , Why is it called “ flow ” Index ？

This is because , Lean thinking is the bottom logic of flow framework and its related flow index design , As the five principles of lean thinking emphasize , We should accurately define value according to specific products 、 Define value streams for each product 、 Make value flow continuously 、 Let customers pull value from manufacturers , And the pursuit of perfection .

therefore , Based on lean thinking , Liquidity indicators measure the flow of value , They collectively indicate the efficiency and health of an organization in the process of delivering value . There are five liquidity indicators , They are the flow rate 、 Flow time 、 Flowing load 、 Flow efficiency and flow distribution . Make comprehensive use of these five indicators , We can tell a complete story about the value stream of software development , Answer the essential question about the efficiency of R & D delivery .

1. Flow rate

chart 4： Flow rate

Index definition ：

Flow items completed in a given time （ Such demand 、 Defects or other types of work ） The number of , The flow rate can be used to measure productivity .

How to use ：

Track the flow rate , To effectively evaluate and predict how much work the team can deliver . When the flow rate is too low , The cause needs to be investigated in time , There may be a shortage of resources 、 Problems such as architecture or infrastructure , There may also be a flow stagnation caused by a large number of waiting .

Interpretation of indicators

The value increases ：

It generally indicates that value delivery is accelerating

The value decreases , And the flow time is very long ：

It generally indicates that delivery is blocked 、 rely on , Or work switching waste caused by too many WIPs

common problem

What is the difference between the concept of flow rate and agile rate ？

Flow rate is adapted from agile rate concept , The latter indicates that the team is in a period of time （ for example , Two week iteration ） How many work units have been delivered （ for example , Story points ）. But the flow rate is the number of flow items completed in a given time , Suppose a version is completed 10 Needs and 5 A flaw , Then the flow rate of this version is 15. therefore , The key difference here is , The flow rate is simpler , It does not depend on the amount of work 、 An estimate of the scope or priority of each flow item .

Why is the flow rate calculated according to the number of demands , Not by story point ？

indeed , The size of current items may vary greatly , This will make people tend to use “ Story point ” or “T T-shirt ” Estimate .

however , Using the estimation of story points will easily lead to scale impulse （ Artificially estimate more ）, On the contrary, it may be more inaccurate , It often leads to business / The game of numbers between products and R & D teams .

therefore , The flow rate tends to use the number of flow items （ Not the story point ） To estimate , According to the law of large numbers （ If there are enough tests or examples , The probability of an event is equal ）, If there are enough current items , Then in a period of time, all current items are large , In another time period, all current items are very small , It should rarely appear .

in addition , Reasonable splitting of work items （ Such as decomposing requirements into business requirements - Product needs - Technical tasks ）, To a certain extent, it will also reduce the impact of the difference in demand granularity on the accuracy of the index standard . If I'm not sure , While measuring the flow rate index , You can also scale the demand （ Such as development + The amount of testing ） Observe together as an auxiliary reference index .

The other thing to note is that , The measurement of flow rate is more suitable for tracking productivity and delivery trends within a value stream , Instead of comparing across value streams .

2. Flow time

chart 5： Flow time

Index definition ：

From the current item is accepted and enters the value stream , The time it takes until it is completed , It includes the time when the work is active and the time when it is waiting .

How to use ：

Track flow time , Make the delivery time more predictable through probability thinking , And answer a core question relatively accurately ：“ When can the work be finished ?”. According to the research , Lead time indicators generally conform to Weber distribution （Weibull Distribution）, So it is recommended to use 85% quantile （ Not the average ） To measure and predict the flow time .

Interpretation of indicators

The value is very low ：

We certainly hope that the flow time will continue to be shortened . But when you see this value is very low , Don't be happy too soon , See if the work is accurately tracked . For example, in our actual work , Often appear “ make amends ” Demand situation , For example, when the development is completed and it is time to go online , Because the online order needs to be associated with a demand order , At this time, add a demand to the Kanban , Then drag directly from the first stage to the last stage . Similar situations will lead to the distortion of indicators , The accuracy of indicators is the foundation of measurement , We need extra attention . In the process of practice , We often observe the main indicators （ Such as flow time ） At the same time , Add an auxiliary reference index about data health （ Such as the proportion of abnormal data ）, To ensure the confidence of the main index .

The value is very high , And the flow rate is very low ：

It may be the work switching caused by too many WIPs , Or work is blocked , There is a lot of waiting time , Let the flow time be prolonged . We can combine the following flow load and flow efficiency to conduct a more detailed analysis .

common problem

Lead time 、 Cycle time 、 What's the difference between flow time ？

chart 6： Flow time vs Lead time

In lean production , There are two key indicators for process improvement , Namely “ Lead time ” and “ Cycle time ”. Lead time focuses on measuring the time of the whole process （ Work from “ newly build ” The state begins to “ complete ” Time difference between States ）, Cycle time focuses on the time it takes to complete a step in the process （ Such as “ Development ” Cycle time of the phase ）. The lead time can tell us the time spent in running the end-to-end process , Cycle time can help identify bottlenecks （ The step with the longest cycle time is usually the bottleneck ）.

But to avoid confusion , The flow framework uses the name “ Flow time ” New indicators of . Flow time begins when work is explicitly accepted （ For example, the new requirements review passed and entered the scheduling ） Or implicitly accept （ For example, events that are automatically upgraded ） The moment of , This is completely different from the lead time when the work is put forward . The flow time can be used as an observation index of the delivery efficiency of the product R & D team , That is, the time from determining to do a certain work to completing ; The lead time is more observed from the perspective of the demand side , That is, the time required from the request to completion .

Why not use DevOps The change lead time commonly used in the community ？

From year to year DevOps Global survey report and DevOps In the community , Often use the name “ Change lead time ” The measurement of , English is Lead time for changes, That is, the lead time from code submission to deployment . Although we often use this indicator for efficiency measurement and analysis , But it has not been adopted by the flow framework .

chart 7： Change lead time change

Lead time is more a developer centric perspective , Instead of designing from a customer-centric or value stream centric perspective , So it is not enough to encapsulate business value , Although it is one of the important indicators of team engineering ability , But in essence, it is more partial 、 More procedural indicators . And the vision of flowing time is broader , What we observe is the end-to-end flow of work items in the software delivery pipeline , Is more partial to the overall situation 、 More consequential indicators .

Is the flow time calculated according to natural days or working days ？

As mentioned above , Flow time is a customer-centered design indicator , So it is based on “ natural ” Time, not “ Working day ” To calculate and measure .

3. Flowing load

chart 8： Flowing load

Index definition ：

The number of work in process in the value stream （ Started 、 Hang in the air , That is, the work in progress ）, Contains the number of flow items with active or waiting status .

How to use ：

Current load is a leading indicator , It can be used to find the impact of too much WIP on speed indicators and team satisfaction . We can adjust and experiment constantly , Find the optimal flow load of the product value stream , At this time, the flow rate is high , And the flow time is short . The floating load can make the production research team better cooperate with the business demander , Find a balance between demand and capacity .

Interpretation of indicators

The value is low ：

There may be only a small amount of work being done , There may be idle .

Higher value ：

Excessive flowing load （ In the products ） It is likely to cause delivery delay 、 Cost increase 、 Quality decline 、 Employees complain , Arranging work beyond the capacity of the team for a long time will lead to job burnout . It can be further decomposed into the following two cases .

Higher value , And the flow time is very short ：

There may be a lot of work neglected or shelved , There are many “ Zombies need ”, Has been stuck in the delivery pipeline, but because of the priority, there has been no time to deal with . At this time, it is necessary to clean up WIP , Evaluate what really needs to be done . If it is really important, let the work continue to advance in time , If it's not important, just move the work out of the delivery pipeline .

Higher value , And the flow time is very long ：

Work switching caused by too many WIPs may be the culprit , Excessive flow load directly affects the delivery efficiency . At this time, lean practice can be adopted , Limit WIP and adopt pull model （ Such as using lean Kanban ）. It may also be the role of insufficient resources / Increase capacity of Posts , Or improve the level of Automation .

chart 9： Flow time prediction based on little's law

One thing in particular to note , According to little's law , Flow time = Flowing load / Flow rate , When the current value of the current load is higher than （ Flow rate * Flow time ） The predicted value of , It indicates that there will be work that cannot be completed on schedule in the future . At this time, the risks of future delivery plans and cycles have been found , The prediction of flow time needs to be corrected , To achieve more accurate commitments / Decision making , This is the value of leading indicators .

common problem

Where should the current load be calculated ？ Do you want to calculate the work that has not yet started ？

If you think of the value stream as a pipeline , All the flow items that have not been started or completed are at both ends of the pipe , The flow load is the number of work units in progress in the pipeline , Include all partially completed current items . When the flow load is too large , Because the queue time is too long , The overutilization of value stream will greatly affect the delivery speed .

Is there an absolute figure for the current load to indicate whether it is good or bad ？

It is difficult for the industry to have an absolute figure to explain the current load , Different business types 、 Teams at different stages of development , There are great differences in the bearing capacity of flowing load . therefore , It is suggested to adopt experimental thinking , Pay attention to the level of current load , It leads to the change of flow rate and flow time , So as to find a proper balance . Pursuing high resource saturation is not good for product development . 100% resource utilization has the same problem for both manufacturing and software delivery , Will have a great negative impact on the flow rate and flow time .

How to effectively RIH the flowing load to find specific problems ？

It can be reported through stagnant work , Show what unfinished work is in the delivery pipeline , And how long they have stagnated in the current stage .

chart 10： Stagnant work report

By viewing the number of days specified in the system （ Such as 10 God ） Work without progress , You can find problems and bottlenecks in the system , On the one hand, find and eliminate low value “ Zombies need ”, Reduce the amount of work on hold ; On the other hand, identify the blocked work , Through the current stage and the collaborative optimization of upstream and downstream , Promote their resumption of flow as soon as possible . About the common bottlenecks in the R & D process , I will discuss it in the next section .

4. Flow efficiency

chart 11： Flow efficiency

Index definition ：

The proportion of the time when the current item is in the active working state in the total time consumed .

How to use ：

Measure flow efficiency , It can help the team visualize the waiting time from the bottleneck , In order to find out the problem that leads to the stagnation of flow . The lower the flow efficiency , The longer the work stays waiting . This indicator can be used in combination with other liquidity indicators , Focus on reducing waiting time .

Interpretation of indicators

Higher value ：

The higher the flow efficiency , Generally speaking, it indicates that the intersection , It covers the waiting time of upstream and downstream development . If the development team is waiting for user interface design , The designers were assigned to other jobs , Then the flow efficiency will decrease , Because the relevant requirements are waiting , The reason is that neither team has dealt with them . therefore , The bottleneck of value flow can be identified by tracking the reasons for the reduction of flow efficiency . The smoother the payment process 、 The less blocking . But we should also be alert to the situation of too high indicators （ For example, over 40%）, This may mean that the state mapping is incorrect or inaccurate , For example, the phase that is actually waiting is mapped into an active state , This will lead to the false high of this index .

The value is low ：

It generally indicates that there is a bottleneck 、 Inefficient processes 、 Too many dependencies 、 Lack of resources, etc , These problems will lead to an increase in the current load , Longer queues , And longer flow time .

common problem

Flow efficiency is calculated based on flow time or cycle time ？

Flow efficiency is based on flow time rather than cycle time. Flow efficiency is based on flow time rather than cycle time , It covers the waiting time of upstream and downstream development . If the development team is waiting for user interface design , The designers were assigned to other jobs , Then the flow efficiency will decrease , Because the relevant requirements are waiting , The reason is that neither team has dealt with them . therefore , The bottleneck of value flow can be identified by tracking the reasons for the reduction of flow efficiency .

The normal value of flow efficiency should be appropriate ？

I often see some statistical data in the industry , The actual flow efficiency of many enterprises is much lower than expected , Some adopt the traditional R & D mode 、 Large scale 、 Teams with complex processes , The flow efficiency is not even 10%. When accurate statistics can be made （ The index is not falsely high ）, For many businesses , If the flow efficiency reaches 30-40%, It is already a good level .

5. Flow distribution

chart 12： Flow distribution

Index definition ：

By showing the flow items completed in a given time （ characteristic 、 defects 、 Risks and liabilities ） The proportion of , To measure the actual investment in different value creation categories .

How to use ：

Use flow distribution to bring visibility to different types of work in the value stream , In this way, we can see the focus of current investment from the perspective of priority . If the statistical flow distribution （ Equivalent to the allocation of resources ） Inconsistent with business priorities , You need to adjust . Flow distribution makes the allocation of resources visible , Promote the production research team and the business demander to weigh various work priorities , The trade-off here is a zero sum game . in addition , Flow distribution over time , According to the stage of the product , It needs continuous adjustment and evolution .

Interpretation of indicators

Defects account for a high proportion ：

It generally indicates that defects and unplanned work reduce the ability to deliver requirements , Investment in technology debt may need to be strengthened .

Lack of technical debt and risk ：

Relevant work is neglected or delayed , Although there seems to be more demand for delivery in the short term , But there may be a debt crisis in the future .

common problem

How to set the flow distribution of each value stream ？

The flow distribution will change over time , Constantly evolving . The value stream of new products is usually adjusted to maximize the proportion of demand delivery . Once the product is launched and has stable users , It is necessary to build additional capabilities to handle possible support work orders and failures , And there is still some work to be done to reduce the accumulated technical debt in the subsequent release cycle .

The above respectively introduces the definitions and interpretation methods of the five liquidity indicators , I believe you have some feelings about how to use them . But one more thing to note is , These indicators remain at the level of software delivery , We should also map R & D work to business results . Associate R & D performance metrics with business results , Real data can be used to determine correlation , And constantly learn and adjust .

Common business outcome indicators include value （ Such as income 、 Annual contract value 、 Number of active users ）、 cost （ Such as labor costs 、 Operation and infrastructure costs ）、 Satisfaction degree （ Such as net recommended value 、 Employee net recommendation ） etc. , Considering the limited space , Methods and cases on how to map the five flow indicators to business indicators , This article will not be expanded , I'll introduce you later .

3 Common bottlenecks and solutions in the R & D process

Through the five flow indicators , We can effectively measure and analyze the software delivery process , And see through the potential problems and bottlenecks . below , Let's briefly discuss the common bottlenecks in the R & D process and their solutions .

1. Scarce experts or resources , Cause the flow to be blocked

chart 13： The bottleneck causes the flow to be blocked

The phenomenon ：

Some active state stage （ Such as “ Development ”） There are bottlenecks , The waiting state stage before this （ Such as “ To be developed ”）, There is a lot of stacking work （ High WIP 、 Cycle is long ）.

Solutions ：

In the active phase with bottlenecks , Increase skilled resources （ But temporary addition may lead to additional burden , Instead, it reduces productivity ）; Train team members in professional skills , Or cross professional horizontal training ; Through automation 、 Self service 、 Process optimization or specification simplification .

2. Lack of automation or backward engineering ability , It leads to inefficiency

chart 13： Inefficiency due to lack of Automation

The phenomenon ：

Manual processes or interactions that are mainly done manually , Become the bottleneck of flow ; For example, the code needs to be tested in the pre delivery environment , But testing resources are scarce , And the resource application is not self-service , There is a lot of demand piled up in " Waiting for the test " Stage .

Solutions ：

Automate the process , Introduce self-service mechanism , Enhance engineering capability ; Improve throughput through automation , Do not rely on resources or expert readiness , So as to improve efficiency ; Do not rely on a centralized team to complete the work according to priority , Such as issuing approval 、 Environmental application, etc .

3. A tedious process , Lead to waiting and long time consuming

chart 14： Cumbersome process leads to waiting

The phenomenon ：

Change Approval Committee （ Such as holding an approval meeting every two weeks , No matter how fast the front delivery is, we have to wait ）、 Safety approval 、 Fund approval, etc ; Work is waiting , Such as “ Waiting for approval ”, There are many products in these States , Reach the high water mark in the selected time range , Then it decreases periodically .

Solutions ：

With high water mark （ Maximum number of products ） For clues , Find the bottleneck problem , Even if the current value has fallen . Automate the change approval process , Criteria for identifying high-risk changes , What must be approved , What are low-risk changes that can be verified automatically 、 Direct deployment .

4. Too much dependence , Cause work flow to stop

chart 15： Too much dependence leads to stagnation of flow

The phenomenon ： Wait for something or someone to finish , To keep working .

Architecture dependency （ Software or hardware ）： The change of one part causes the function of another part to be destroyed （ for example DB The function call of the other party cannot work due to the change ）

Professional knowledge or expert dependence ： Experts who need specific expertise （ Such as business experts 、 Security experts ） The input of , Can continue to complete the set work

Activity dependency or event dependency ： You need to wait for other activities to complete , Otherwise, the process cannot proceed . For example, the dependencies between several predecessors in the Gantt chart

Solutions ：

chart 16： Three kinds of dependence and their solutions

Modeling dependencies （ Such as using dependency matrix ）, Communicate with the relying party , Explore solutions ; Long term plan ： Take time to remove dependencies , Not just managing them . At the architecture level ： Find the fracture surface of the system , Decouple the architecture ; Organizational level ： Build a cross functional team , Conduct organizational decoupling . Activity level ： Improve self-service and autonomy , Decouple activities .

The last thing to say is this , For the bottleneck in the R & D process , We should think systematically , Take the flow index as the traction to observe the whole value stream , Think about constraints in a holistic way . After finding the bottleneck and clarifying the solution , When implementing improvements , Pay attention to solving only one problem at a time , But not greedy 、 The pursuit of large and complete , In this way, we can independently observe the effect and impact of each measure .

chart 17： Based on data-driven and experimental thinking , One problem at a time

4 summary

The core points of this paper are as follows ：

Digital age , Software development itself should also be digitalized .
R & D digitalization , We can start from building an effective R & D efficiency insight system .
Based on lean thinking , Liquidity indicators measure the flow of value , It indicates the efficiency and health of an organization in the process of delivering value .
There are five liquidity indicators ： Flow rate 、 Flow time 、 Flowing load 、 Flow efficiency and flow distribution .
Make comprehensive use of these five indicators , We can tell a complete story about the value stream of software development , Answer the essential question about the efficiency of R & D delivery .
Common bottlenecks in the R & D process include scarce experts or resources 、 Lack of automation or backward engineering ability 、 A tedious process 、 Too much dependence, etc , These bottlenecks will lead to blocked flow 、 Let the work stagnate , Lead to waiting and long time consuming .
For the bottleneck in the R & D process , We should think systematically , Take the flow index as the traction to observe the whole value stream , Think about constraints in a holistic way .
When implementing improvements , One problem at a time , In this way, the effect and impact of each measure can be observed independently .

5 The authors introduce

Zhang Le

Tencent Technology Engineering Group DevOps And senior technical experts in R & D effectiveness , Former Baidu engineering efficiency expert 、 Former Jingdong DevOps Platform product director and chief architect , Once worked as Accenture 、 HP and other global top 500 enterprise consultants 、 Senior technical expert . Long term work in a front-line Internet company with tens of thousands of R & D personnel , Focus on R & D efficiency improvement 、 Agility and DevOps Practice landing 、DevOps Tool platform design 、 R & D effectiveness measurement system construction and other directions , yes DevOpsDays The core organizer of the international conference in China , There are many in China DevOps、 Engineering productivity 、 Co chair of the technical conference in the field of R & D effectiveness 、DevOps/ Special producer of R & D Efficiency , yes 《 R & D effectiveness declaration 》 Initiator and drafter of main contents ,EXIN DevOps A full range of internationally certified authorized lecturers 、 Authorized coach of Phoenix Project sand table . Work ：《 Practice of improving software R & D efficiency 》、 Translated works ：《 Unicorn project ： Development legend in the era of digital transformation 》

原网站

版权声明
本文为[JackieZhengChina]所创，转载请带上原文链接，感谢
https://yzsam.com/2022/204/202207232005290025.html