DevUI is a team with both design and engineering perspectives, serving Huawei cloud
DevCloudPlatform and huawei internal several background systems, service designers and front-end engineers.
Official website:
devui.design
Ng Component library:
ng-devui(Welcome Star)
The introduction
In DevOps, there is a popular saying that XX measures the success of DevOps. Determine whether a project has completed the DevOps transition by measuring key data at each stage of the r&d process.
That’s a good idea, because if you want to improve it, you have to measure it.
For most front-end projects, some DevOps measurement indexes can also be applied. Based on my own project practice and combined with the particularity and differences of front-end project R&D process, I sorted out more suitable measurement indexes to judge whether front-end projects are efficient and high-quality. Most of the metrics can be captured automatically by tools, making it easy to create deliverable kanban tailored to the team for daily project management improvements.
This article is suitable for front-end project leaders and engineers who try front-end engineering practice.
Front-end R&D process
I divided the front-end research and development process into five stages: design, development, personal verification, version verification and online verification. Let me explain the meanings and differences of these stages.
Design: The most special stage of the front-end development process. Due to the characteristics of the front-end business, the front-end engineer will inevitably work with the designer and the product as much as possible. Whether it is a technical feasibility assessment of product design or a discussion of product experience, the product design phase will determine how the business will be implemented, which is the source of all requirements. The more efficient the synergy with designers and product managers is, the more efficient the front-end team will deliver.
Development: the core coding output stage of the front-end engineer. The code quality, development efficiency and collaborative coordination efficiency in this stage will determine the quality and rework cost of subsequent versions. There are many automation tools or CLI tools available at this stage to help developers improve efficiency and code quality. But this is also the most difficult phase to control, as it relates to the individual development environment and individual skill levels and habits.
Personal verification: After front-end engineer development is completed, there is always a personal verification phase before formal submission. That is, after self-verification to ensure no problems, and then commit to the library, start the version verification phase. While every development engineer does self-validation, it’s often the most overlooked part of the process because of the developer mindset. We need to add a lot of automated validation capabilities to this process to help developers achieve quality improvement during the personal development phase. The more problems are found earlier in the development process, the lower the cost of fixing them.
Version verification: In the front end team, after each developer completes self-verification and submits to the version branch, the version verification phase starts. At this stage, an excellent front-end team will complete a series of automatic version verification actions such as compilation and packaging, static inspection, quality control, and use case testing through an automated assembly line to ensure the quality and safety of the version. This stage should be the most automated part of the whole r&d process. High efficiency, high automation, fast execution of the pipeline, will greatly improve the quality and efficiency of front-end projects.
Online validation: The first four phases are from the development team’s perspective, and the last phase is from the user’s perspective. That is, when you have a release, how well your product actually performs, whether users are using it the way they expect, whether there are missed tests, whether there are quality bugs that were overlooked during the development phase, whether problems can be found before users, and whether problems can be quickly located. These require monitoring and interception during the online verification phase, where front-end monitoring and the use of various tools such as alarms and dials are good practices.
So up to this point, the whole front-end research and development process is complete closed loop.
measure
That’s the front-end development process. So, what are the measurable metrics we use to determine whether we are doing our best at each stage of the process and whether there is room for improvement? The establishment of the measurement index system not only helps you understand the current baseline of the project, but also has the greater value of guiding the team to reach the target according to objective measurement data. The direction is clear and the effect is obvious.
design
In the design phase, we need to consider how to improve the efficiency of the front end personnel. At this stage, if designers and product managers are professional in many teams, they can achieve high efficiency through the cooperation of design platforms. However, if the confusion between designers and products in the design stage, it may lead to unclear requirements, repeated design and one-sentence requirements. Therefore, at this stage, it is more important to measure product managers and designers, and reverse constraints through indicators to avoid transferring design costs to front-end developers. Project management tools make it easy for front-end developers to label and fill in requirements to measure metrics.
Lead time
Lead time is a term used in supply chain management, also used in Agile and DevOPS. In supply chain management, lead time is the time between the time a buyer places an order and the time a supplier delivers. In agile and DevOps, this is usually the time between a user request and a release. Under normal circumstances, the delivery efficiency is constant when the delivery manpower is stable, so the reduction of lead time should focus on the efficiency of the design stage. That is to say, from the user requirements to the final design of the time is there room for optimization.
Frequency of requirement modification
Because front-end deliverables are so closely tied to the interactive experience, there are frequent changes in the design drafts and prototypes. Demand modification frequency can record The Times of front-end product requirements being modified, thus reflecting the standardization degree and cooperation efficiency of product managers and designers in product design.
Degree of requirement specification
Whether the submitted requirements meet the agreed specifications. For example, complex features require detailed, high-fidelity annotation diagrams, one-sentence requirements, and unclear descriptions. Upon receipt of a requirement that does not meet the specification, the developer has the right to call back the requirement to avoid further development costs. On the other hand, teams with poor compliance should examine whether there are optimization points in the collaboration of the corresponding roles.
The development of
The development stage is the engineer core code output stage, in this stage, we mainly focus on delivery efficiency and quality.
Number of delivery requirements per iteration
The number of requirements per developer that can be completed per unit iteration. Since the team has the habit of dividing the granularity of requirements continuously, there may be some inconsistency between the granularity of requirements of different developers in individual iterations, but the correlation error is basically controllable in a long period of time. Therefore, teams with higher average iterative delivery requirements and an upward trend can be interpreted as teams with high delivery efficiency.
Number of problems per iteration
Correspondingly, the more live network problems occur in unit iteration, the lower quality of the delivered version. If the index does not converge for a long time, it is necessary to examine whether there is room for optimization in the corresponding quality assurance system.
Personal verification
In the stage of personal verification, it is mainly the self-verification of developers on the code written by themselves before incorporating the version. It mainly includes a series of quality activities such as functional testing and code review. Of course, in some good practices, a number of automated tools and plug-ins are introduced to help developers detect quality problems ahead of time.
Code checks compliance
Good code specification and basic static checking can avoid many low-level problems, and with tools such as ESLint, it’s easy to set up code checking requirements. Compliance metrics require developers to meet our code inspection requirements, such as zero clearance for critical issues or zero clearance for 100% issues.
Automate use case coverage
Whether it is a unit test case or an E2E test case, during the individual validation phase, developers should write corresponding test cases and run related automation cases based on the scope of impact of this code submission to ensure the quality of new and historical features. Especially for large front-end business systems, an automated use case system must be established to ensure the quality of a large number of features accumulated over a long period of time. At this stage, the higher the coverage of automated use cases, the better the quality of the release.
Automated use case success rate
Use case coverage, on the other hand, is its own success rate. Frequent failures of test cases either reflect the imperfection of business functions or the imrigor of test cases, thus affecting the acceptance of version quality, should be avoided.
conclusion
After the personal verification, we will move into the version verification phase.
Version verification stage will be the most objective measurement index, the highest degree of automation, is the most core part of the measurement system. Most of the overall metrics will be presented through automated practices during this phase to assess the quality and efficiency of the front-end release. Drive project improvements, mostly based on metrics collected during the release validation phase, drive overall project improvements.
I will elaborate on the corresponding content in the second chapter.
To be continued, stay tuned.
Join us
We are DevUI team, welcome to come here and build elegant and efficient human-computer design/research and development system with us. Email: [email protected].
The text/DevUI Monkey
Previous articles are recommended
Agile Design, Efficient Collaboration, Highlighting the Collaborative Value of the Design End cloud
Modularity In Modern Rich Text Editor Quill