Help project success - day build
Keywords:
Day build, continuous integration, project management
Summary:
The daily construction is essentially a management practice, that is, through continuous integration, rapid feedback to ensure that software work products are gradually advanced, and it is expected to advance towards the goal. Constructing the basic management measures with day, which is beneficial to ensure the success of the project and improve the quality of software products.
What is Daily Build?
The so-called day building, popularity is integrated with all work products every day and allows it to test. Day Construction is a sustained construction concept to be particularly known at the smaller occurrence frequency of Daily.
Building day is the best practice in software development management in the XP method; continuous integration is also a principle that guarantees the success of software projects in agile software development. Coincidentally, 2003 China Software Technology Conference, Shanghai Mini Software Company Technology Director Cai Pei tells the software development management of Microsoft, which mentioned an important practice in Microsoft software development management, which is the day construction.
Why do I need to build a day?
There are many problems in software development management often make managers very worrying, such as:
1. Only half a year of the project cycle, I saw the original interface and some preliminary functions after two months. Demand personnel one, find that the designer is incorrect for business needs. And the designer, found that developers did not really understand their design intentions. Helpless, I have to redesign, re-coded some places, and progress is delayed. If you have an early verification, how is it!
2. The original business is good, and I didn't expect to integrate half a month. It is not the same as that. It is incorrect, but it is not exposed at that time, and the result can only be reundened.
3. Each integrated discovery requires three days to get all the compilation issues. The error is often stem from the interface change has not been notified in time, or the developer has forgot to adjust the code after the notice.
4. Although the project has been clearly stated in the project, "coding specifications" is clearly stated, but each time the code takes out, there are still many violations. I really want to have an automated tool, automatically judge the developer's code every day, and discover the problem automatically notify the project manager.
5. The developer has completed this week, but it always found that this is because this reason is not completed. How do you know how developers have a daily productivity? How many lines of code he wrote every day? What is the functional implementation? What is the quality of the realization?
6. How to ensure that the quality of the software is really a problem. The project time is tight, and testers often need to wait until the product is basically molded, and the test time cannot be very long, so it is easy to lead to a lot of potential bugs in the product. If you can take the test to develop together How good. But the product is not coming, how to test the tester, it seems that it is impossible to implement.
7. Each project milestone display and review will lead to various project managers and department managers to be tired to make their work products can work normally, and have been integrated with the brothers and downs. Can you keep our work products in a stateful state every day, is it successful?
The problem in software project development is different, far from listed above. However, carefully consider these problems, can you find a proper management method or a technical method to solve it? An answer I know is to introduce day builds in software project management, and continue to build daily builds.
Help project success
The main body of software development is a person, and it is necessary to communicate between people through people and exchanges to achieve joint understanding and understanding of work objectives and processes. However, what is often seen is to communicate and communicate missing, not in place, fail, resulting in repetitive work, invalid work, and even errors. Carefully analyze the communication and communication issues of software development, I think there are several key influencing factors:
1. Communication between the team and exchanges dependent team members and do things, how to introduce mechanisms in the project to ensure that team members have spontaneously persisted and do necessary, effective communication, exchange? 2. There is an unavoidable understanding of the objectives in communication, but feedback is required to make feedback as soon as possible through some measures so that it is notified as soon as possible. How to build a mechanism to promote this feedback?
The introduction of day builds has played a role in the influencing factors described above. Why do you say this? Explain as follows:
1. Weekly build a lot of specifications for each developer's daily development behavior, these specifications itself reduces the cost of communication and coordinates the work of team members.
2. The various outputs built in the day is actually a real and timely feedback from all aspects and levels of software projects. For example, the compilation results feedback the coordination of the interface; the code review feeds back the real compliance of the coding specification; the code line statistics feeds back the actual workload; the construction of the executable work product is fed back to the current product.
The quality assurance of the software has always been a problem. One aspect is that the quality of the software lacks perfect metrics and metrics, and another reason is because most of the quality factors affecting the quality of the software are related, human knowledge, IQ, psychological quality, and even the mentality and mood of a certain period are enough to affect the quality of the software, so the quality control of the software is a typical TQC (TOTAL Quality Control) control.
We are used to adopting tests to ensure software quality assurance, but testing on quality assurance has some unsatisfactory aspects:
1. The quality of the software is gradually formed during the software development, and the current test usually occurs substantially in our product module, or can be integrated. The test seems to be a post-quantity guarantee means, and the cost of repairing the problem is high.
2. The quality control cycle of the software is very long, which has more influential factors, and needs to obtain quality feedback in time during the development process, and test is just a later feedback.
3. The quality of the software provides users with stable, available, enough functions, in addition to runtime, also reflects the maintenanceability of the software. The current white box test can only feed back the external quality of the software, and cannot feed back the internal quality of the software (code quality, the maintenanceability and bug distribution of the software itself)
4. The quality of the software is seriously dependent on people, so it should be anti-Duju, agile monitoring, and standardization management. In the later stage, BUG's discovery not only repairs high cost and impacts the psychological impact on team members, affecting individual working conditions.
The principle of day construction is to start from everyone's work products. At the beginning, it emphasizes integration, feedback, and is committed to providing a system for testing, thus starting quality control advance (whether the results before the coding can also Incorporate the day build, this is the problem that follows. Day builds at least higher than the frequency of feedback, this high frequency feedback is easy to solve the problem, and it will help improve the normative and consistency of the team's processing, which is guaranteed software. Quality of quality. Day build directly handles everyone's work products, we can join many of the audit and monitoring of work products, in fact, this gives us a means of controlling internal quality. This means is combined with white box testing to control the software quality.
An important part of software project management is how fair, fair metrics, and evaluates and encourages members to members. There may be many differences in the work of everyone, such as work difficulty, workload, working attitude. We originally evaluate each member of each member may have more subjective colors, which is not a mature project management method. Really fairness, justice should be based on quantification. Day build directly handles everyone's work products, add statistics in handling, audit, very considerable metrics, every person's workload and a certain degree of work attitude. For example, by row code statistics, metadata statistics we can analyze absolute workloads in a project group, and a person's absolute workload. Through the code specification audit, we can objectively feedback from individuals to standardized compliance and implementation, which can be used as an objective evaluation indicator of work. The help of day buildings may be much more than these helps, because day builds are essentially combined with some range and to some extent, thus giving us more better Management control capability. The development process of concluding software is an empirical process, rather than a deterministic process, i.e., software development is not well described, predictable. Therefore, in the Scrum software methodology, it is believed that the concepts in industrial process control can be applied to software development, and software development is treated as a black box. Based on the conversion of the black box input and output At the end, the combination of experience is determined to regulate the black box, so that it does not overcome the set boundary, resulting in a satisfactory output. So how do you do this metrics and feedback? I think, I build a answer!
Cloudward
2004-8-16
