This course is introduction to R & D tool chain. We will mainly learn three tools. Project management tool icafe, code management tool icode, delivery platform ipipe.
In addition, we know that management practice has the following three characteristics: ① guiding product planning with “lean”; ② Accelerate iterative development with “agile”; ③ Drive continuous improvement with “data”. The three tools learned in this course are the perfect coverage of the three characteristics of management practice.
Project management tool – icafe
01 demand management
Requirements management is the cornerstone of a project. In the Internet industry, because of the rapid iteration of product requirements, requirements management has always been a headache. Therefore, how to better manage the demand and make better product planning is an important issue for the projects in the Internet industry.
Traditional requirements management methods include the following:
① Write the requirements directly on the document,
② The requirements are made into demand cards, so that the R & D personnel and the demand personnel can keep the information consistent in this way.
③ Use Excel for requirements management and sorting.
These three methods have many disadvantages, such as long-time document writing, more manpower required for document writing, high document maintenance cost, poor communication in the process of document use, and so on. Because of its reading characteristics, text is not convenient for intuitive display of tasks. Therefore, in the development process of many projects, there are often problems that the developed products are inconsistent with the document design after the documents are handed over to the R & D personnel.
The demand management of the Internet needs to have the characteristics of demand integrity, communication efficiency, expression accuracy, communication convenience and so on.
Research shows that different communication methods produce different communication effects. Among all communication methods, document communication is the most inefficient communication method, and face-to-face whiteboard communication is the most efficient communication method. Combined with a variety of efficient communication methods, the user story map is a novel way of demand management and sorting.
User story map is an important management method in agile project management.
First, use the card to list all the requirements on the whiteboard, which helps to show the overall picture of the product, and turn the requirements into visual cards, which can better sort the task requirements according to user feedback;
The cards are then layered using different colors. Blue cards are the first layer, yellow cards are the second layer, and white cards are the third layer. Put the requirements with the smallest granularity on the white card layer, and the requirements with low granularity are easier to be accepted by R & D personnel.
Finally, through horizontal grouping, the requirements of each version of each phase of the iteration plan are classified and grouped. This helps to get through the product view and R & D plan view.
Through the above steps, you can get a more complete user story map.
User story map is a very efficient demand management method. At present, all R & D teams can directly use it for demand management and tracking on the efficiency cloud without being limited by physical conditions.
02 iteration plan
After completing the product version planning, the R & D team needs to formulate corresponding iteration plans. Agile, rapid and reasonable iteration planning can promote the iteration of the project more efficiently.
Based on the user story map, you can directly drag the requirements up and down, modify the priority, and drag left and right to change the plan in the process of formulating the iteration plan. In this way, the iteration plan can be displayed more clearly, so that the development team can better locate the milestone and improve the whole iteration plan.
03 progress tracking
There are three magic weapons for progress tracking: station meeting, card wall and burnout chart.
The station is combined with the card wall. During the station meeting, the project progress and project problems can be shared directly through the electronic Kanban, so as to improve the communication efficiency of the station meeting.
Through burnout chart and statistical data, the team can directly know the development progress and problems encountered.
04 continuous improvement
For continuous improvement, we provide two tools: scatter chart of card status duration and cumulative flow chart of card status.
The scatter chart of card status duration can accurately show the team’s work rate, the single cycle duration and average cycle duration from demand proposal to demand launch, and accurately show the team’s work rate and changes in work rate in each state.
The card status cumulative flow chart can macroscopically display the efficiency trend of each process of the project. The color block width indicates that there are many overstocked needs and tasks in the process, and the color bar narrowing indicates that the team status flow rate is improved.
Based on these two graph tools, the R & D team can conduct self inspection periodically, self-examine the work in the past period, and then continue to improve.
Code management tool – icode
Icode is a code management tool. Around it, we mainly explain two practice sets: workflow and review.
Disorderly operation and development is a problem perplexing many teams, which seriously affects the delivery of products. Typical problems are: random code processing, repeated bugs, imperfect testing, chaotic release versions, etc.
Facing various problems, we support two standard workflows at the same time to ensure the orderly cooperation of the team.
(1) Backbone Based Workflow
In a backbone based workflow, the entire team maintains a backbone branch. In order to ensure the quality of trunk branches, a strict access mechanism is required. The change points need to be double reviewed by machine and labor before they can be integrated into the trunk.
When publishing is needed, the publishing branch will be pulled based on the trunk. In fact, this branch is a snapshot of a specific point of the trunk and is only used for publishing. If a problem is found in the process of publishing, go back to the trunk to repair the bug or enhance the function. If necessary, submit and pick the trunk to the corresponding publishing branch.
Branch publishing goes hand in hand with the trunk. There is no need to worry that the functions under development will be brought online. After publishing, it will return to the concise mode of a trunk.
The advantages of backbone based workflow are:
① The backbone is of high quality and can be released at any time.
② The model is simple and has only one trunk, which saves the cost of branch merging.
However, the workflow also has some disadvantages. When developing high-quality engineering projects, the team needs to build complete test cases. In the submission link, the submitter is required to maintain atomic submission, that is, the function corresponds to the submission one by one.
(2) Branch Based Workflow
In the branch based workflow, the trunk is used to store online code. When changes are needed, branches are opened based on the latest code of the trunk to complete the development, testing and release of functions; Before branch publishing, you need to synchronize the updates of the trunk; After going online, you need to merge the branches back to the trunk.
The advantages of branch based workflow are:
① Branches are parallel and developed independently, and branches will not affect each other;
② For the team, the use threshold is low, and the branch runs through the whole process of independent function development, testing and release, giving the team sufficient time to improve test cases and complete manual testing;
③ Easy to use, the system will guide developers to complete all operations such as new branch, synchronization trunk and union trunk.
However, branch based workflow also has some disadvantages, such as the cost of branch merging and the need to constantly synchronize the trunk to find the branch conflict risk points and solve them in advance.
Review is an important process to ensure the project quality of the team. If the code is submitted directly without review, it may pollute the code history, increase the later maintenance cost, and even cause code quality problems in serious cases.
In the process of project development, the code running normally locally may suddenly crash in the test environment or online environment. In view of such problems, quality protection nets can be used. The quality protection network includes three levels: code scanning, continuous integration and manual review.
Code scanning can find out the places that do not meet the code specifications, insert code comments in the line spacing, and issue a style report to facilitate engineers to modify the code style problems.
Continuous integration will configure a cloud build, which can quickly detect the initial bugs of the code and help developers repair them in advance.
After the first two steps are completed, senior members of the team can conduct in-depth review on architecture, logic, design and other issues.
Through these three steps, the double review of machine and labor is realized, and the progress is made layer by layer to ensure the project quality of the team.
Delivery platform – ipipe
Ipipe is a delivery platform. Around it, we mainly explain three practice sets.
01 curing end-to-end delivery process
The standard software delivery process includes the following points:
First, there will be a clear input of the release version,
Then, based on this release, the code will be submitted.
After the code is submitted, it will be compiled and tested. The testing phase may include module level testing and system level testing.
Finally, release. The process of release and launch may be divided into pre launch, production gray level and full production volume.
In order to standardize the code change process, we need to use the delivery pipeline. Achieve a reliable and repeatable role by standardizing the delivery process. The delivery pipeline is executed serially. After the successful execution of the previous stage, the next stage will be triggered. The execution phase consists of tasks, which can be traversal or parallel. The execution status of a task determines the execution status of a phase.
The ipipe tool currently includes a standard delivery pipeline. Users can see the construction of the pipeline in the ipipe. In the process of using the delivery pipeline, if the current stage fails, the subsequent stage will not continue, which can save resources, quickly find problems and repair problems in time.
02 plug in existing tools and services
When performing various tasks in the delivery pipeline, we need to rely on many tools and services, such as maven, docker, Jenkins, GIT and so on.
We integrate these tools and services into the pipeline through a set of standard plug-in development specifications. Users can easily use these plug-ins and services in the process of using the pipeline. If there are no plug-ins, services or tools you want to use in the pipeline, you can expand them to meet the project requirements according to the plug-in specifications provided by the efficiency cloud.
03 data measurement driven process improvement
Through the delivery pipeline, you can quickly obtain all the data and information of the project, such as the cycle from code submission to delivery on-line of a version, or the number of defects found in each stage of a project, etc.
Users can measure data by calling API to obtain data, so as to promote the improvement of delivery process. In the subsequent development, the platform will identify the key data indicators in the project and automatically form more distinctive data reports. In this way, we can continuously measure the data and provide a platform with rich dimensions for individuals and teams.