Build an efficient software development process and team
1. Preface ... 2
2. Project plan 2
3. Development Document 3
4. Write code 4
5. Code Management 4
6. Test ... 4
7. BUG Management 5
8. Code Freeze .. 6
9. Tech Talk 6
10. Code Review ... 6
11. Communication and Communication 7
12. Postscript ... 7
1 Introduction
I have worked in a number of companies, but I left me the most impressive, and the company's most standardized company is i company. The company is headquartered in the US Silicon Valley, which has been developed by PC Magazine's highest five-star excellent praise. Now I am writing according to the experience and some of the experience you feel in this company, I hope to have a referee and other companies.
2. Project plan
After a product is published and used, there is certainly a place where many places are not as good as improved. Customers will find some problems during the use, put forward higher demand, the market is also changing, our competitors are also developing, new technologies are constantly producing, these factors have driven our products continue to develop forward. Make it to grow up. The demand for these developments is not proposed. In the process of customer use, some areas that are not intentionally inconvenient, they will advise our technical support, and technical support will save these needs in the form of bugs. In the bug database, the level is generally defined as the next version of Feature. Some of the previous version unresolved BUG may also need to solve this release. Therefore, when we come to develop the next version, many of its features already exist in the bug database. Of course, the nature of the new version is not only available from the bug, the management may raise new features from the perspective of the market to seek leading competitors, and the developers themselves can also propose certain requirements to incorporate new version of the development plan, such as request. Reconstructing a certain part of the code to make its structure more easier and easier to maintain, and more efficient is more efficient.
Everyone collects the function modules related to their own, and the time, which mainly includes the time, development time, and unit test of the write document, generally requiring accurate to the working day. This information is sent to the team leader, and the team leader is sent to the management layer, and the management is evaluated by the management, and the management will be based on product issuance time and customer needs. Waiting for the choice, some functions may be postponed to the next version due to time emergency. If the estimated time has a more conflict with the expected product release time, this feature is required in this release, and the development team will be re-estimated, accelerate the development speed to achieve this requirement.
Although this development schedule is a probably estimated time, we have to do our best to perform according to this development schedule. Every Friday afternoon, we have a Status Meeting (generally low work efficiency, suitable for meeting), at this meeting we will come to REVIEW according to this progress, whether the work in everyone is going on this progress, Has anyone delayed, whether Block lives in someone else. Everyone in this meeting has to report their progress, but also to report what is done last week, what is doing, and what is going to do next week. Through this meeting, you will make you feel that someone is supervising you, forcing you to continue to urge yourself not to delay the task, if there is a delay, there will be as soon as possible to catch up. If some efforts can't catch up, there is no way to modify the original schedule, because that is a deviation in our estimate, we must make our schedule in accordance with the actual situation, which avoids many projects The final 20% of the work will occupy 80% or even the situation. The situation of modifying the schedule has happened, once in accordance with the original progress to the status of the original progress, the notification is suddenly notified due to the market and customer reasons to join another major feature, this feature is the structure of our program There is a very big impact, so we will re-develop a progress to meet the needs. In this case, the original development progress of the product is disrupted, and the release time is also delayed. Of course, this situation should be tried to avoid, especially in the later stage of the project, if it should be re-planned, not still in accordance with the original progress, because the progress of the old progress cannot reflect the reality. 3. Development documentation
In the project schedule, we have also planned to write the time of writing documents. Although it is written document, it is a design program, organizes ideas and architectures, and the sharpener is not mistaken, so it will be smooth when you actually write code. A lot, saving time, so it can be said that there is a thoughtful thing to write in this time. Of course, our document format is not like ISO, and our document format is relatively free, basically able to play freely, but for several main points, it is necessary to explain. The document that requires written can make others easier to understand, can clear the problem, reflect your design ideas. There are not many documents, there are two types of development documents, and one is Function Spec, and the other is Design Document.
The task of this module is required in the Function SPEC. What is the problem, what is the effect, why do you want these functions, and we will add applicable scope, what is insufficient, what is it? Improvements can be made later. Any very detailed algorithm is not involved in this Function SPEC. This document does not light to developers, but also let QA and other members and later newcomers can understand the general features of this module according to this document, and will also give document writers, they will sort out a user according to these Function SPEC Manual, telling users What functions have been added in this release, what is the role of each function module, how to use information. So in our development process, the Function Spec is a very important document. After this document, you will take a time with relevant personnel and QA REVIEW, let QA understand the designer's intentions, and familiarize with new function modules, The test is prepared. If you have misunderstandings or unknown, you will come out to discuss and correctly modified by developers.
The main algorithm, data structure, hierarchical structure and call relationship related to the implementation involved in this module are mainly described. The readers of this document are mainly developers, including anyone who wants to understand the code in detail, helping people understand the code. In some simple programs, the information described in this document is relatively small. This document is not written before the FUNCTION SPEC is to be written before starting writing code, but it can basically follow the principle of documentation, that is, if there is a new code or modify the code, if there is access to the code The document should be modified first, then modify the code. 4. Write code
Since we developed in Java language, we have a JBuilder IDE tool. Regarding the code style, we basically set up the auto code format in JBuilder, but there is a change in the indentation of 4 characters, between 2 lines between classes and classes, between 2 lines, the Import class Use a complete class name. When writing code, you must provide detailed annotations and instructions for classes and functions. Basically, you can know the features of this class or function and the principle of the main algorithm. In the development process, the main module should be written in UnitTest, and the unittest is in advance, that is, follow the test driver principles in the XP rule, which is basically completed when all unit test code passes.
5. Code management
We use VSS SourceOffSite to version control, where all source code, library files, documents, and release of this product are stored, and each part is stored in different directories. Developers asked developers from the source code of Get Latest version in VSS and then compile and start a day. Before working, the code to be modified on all the day before get off work, to ensure that compilation can be passed before Check IN. If any Nock IN code causes Daily Build fail, it will be asked to request some punitive measures or warnings, like Microsoft to be responsible for seeing daily construction on the day. Sometimes our code involves multiple files, and this change is complicated to spend more workload. If Check I in goes can cause the BVT (Build Verify Test) test, because some code is not completely completed. The previous code can pass the BVT test, and these code will basically not involve others, in this case, in this case, it can be in this case until all code is completed to submit the BVT test together Check IN.
Every day we will do Daily Build, usually in the morning at 4 o'clock, then there is a program automatically pulled the latest code from VSS and compile. Because we have developed synchronously with the United States, if you want to enter the modified code into this build, you need to pick IN in the morning before 4 am. If anyone pick IN, the code is compiled, but it will be discovered in this step. When the compilation is completed, the installation package will be automatically generated, and the test department will perform BVT testing of these code, and the development library in VSS is played with Label. If you find what bug, you can get this bug according to this Label. BVT refers to the Build Verify Test, which is a test of basic functions in the component. This test will be done every day, see if the newly added code or modification will affect the basic functions of the system, which is easy to discover errors early.
6. Test
After the developer completed the Function SPEC, the test department began testing planning, determining which aspects of you need to test, how to test and schedule. Test staff need to write a lot of test code, some test code need to integrate into BVT tests, and some may need to perform separate tests, to make the product meet the requirements, so that developers are easy to find out and correct. Whether the product feature meets the requirements, whether it can be published is determined by the tester, so the testers are also relatively hard, responsible. Through the daily BVT test, there are some performance testing, compatibility testing, disaster testing, etc. need to be carried out before product release. After completing these tests, it determines whether this product can be removed. If there is no problem, it will give a beta test to some of the best relationships, and then finally Release out. 7. BUG management
Since we have tested a test every day, there is often a bug being tested. Once a new bug is found, it will be added to the bug tracking system. Currently popular bug tracking system has TestTrack, ClearQuest, Bugzilla, etc. Bug Tracking System is a bond between developers and QAs, developers and QA links through bug tracking system. Each bug has its type and level, the predetermined type has Crash-Data Loss, Crash-no Data Loss, IncorRect FunctionA, Cosmetic, Feature Request, etc., P1, P2 has been to P6, which represent importance and emergency Experience, P1 BUG requires fast Fix, P5 BUG must be fixed before this version Release, if you really can't or not, it is determined by QA and reduces priority to enter the next version to go to FIX. QA finds a bug adds a bug in bug track, and fill in the relevant information and assign gives the corresponding developer. The developer receives the BUG analysis and FIX. ASSIGN will go to Verify, where is the result of the analysis and how to fill the results of the analysis Detailed illustration. If Qa is passed by CLOSE BUG, Verify Failed is re-Assign to wait for FIX. BUG status report on Status Meeting is reported in Status Meet, mainly by the QA team leader, mainly new bugs, how much FIX is falling, how much is in Open state, how much is waiting for Verify, accordingly You can learn about development and testing. Sometimes we will also conduct bug review, bug review is sometimes in a separate group, which is to re-clear the BUG on each human head and understand the situation of each bug, such as the developer will make How to deal with it, to learn about whether there is a tricky problem in the development, increasing the risk of product issuance. In the game of QA increases bug and developer FIX bug, the number of bugs will fluctuate like the stock market curve, but the overall trend is generally the mass transfer, and the late shock falls. If the number of BUGs in the later new Open have been rising The risk is increasing, it may not be controlled, that is, the FIX has a bug that causes multiple new BUG generation. A curve map of the code can be used in a quantization development scheme. The increase in the amount of code will be faster when there is a large number of new features, when in the FIX bug phase, the code has more modifications, so the increase in code is reduced, and the situation can be seen in the development of the code.
What needs to be pointed out is that we have a wide definition of bugs, and some new features can also be proposed as bugs, but these bug levels are relatively low, allowing them to enter the next release. Therefore, BUG's creator can also be technical support staff, market personnel, even developers itself. About the developer itself, because he may find some bugs, some of the other developers, some may be this developer itself, and add this bug to the bug library to help developers will generate new problems in the future or similar The bug has a reference and ideas, but this bug's Verify must let the test person of this module come to Verify. 8. Code Freeze
When the BUG before P5 is fixed, it is not far from the product release date. It is generally a release product after 2 weeks. At this time, the code in the VSS is to ensure the stability of the code base. Sex. The Code Freeze phase generally turns off the permissions of each developer's Check IN and Check Out. If there is still a bug report and discussed it is significant and must be fixed in this release, you need to agreed by management. And specially granted permissions, and the modifier has to modify which files have been modified, and the modifies will be reported to various departments such as QA, Build personnel, document writer, etc. In the Code Freeze phase, the test department has conducted various tests in tight, and has made various data and determine if this version can be release.
9. Tech Talk
Computer knowledge updates are very fast, often have some new terms, new nouns, new ideas, new technologies, if you leave this industry a few months later, you will neglect these new things, and We usually bury their heads in their own projects and may have forgotten what happened around. Tech Talk provides a chance to let us know new knowledge and the latest development trends, let everyone share knowledge and improve together. Tech Talk generally performs when the project is not too busy, the host will designate someone to prepare a TECH Talk one week in advance, and the people may be more interested in someone, and then he will spend some time to understand this. The situation is written as a document such as PowerPoint and uploads to the LAN, and notify you that you can go to browse. Tech Talk is very wide, not necessarily close to our project, any new idea, new knowledge (of course, is usually limited to computer sectors) can be used as Tech Talk content, and after the speaker is finished Some time to ask questions and discuss this topic, answer questions. Of course, Tech Talk can also be related to our project, such as studying the product technology of competitors, the architecture of the company's products. Studying the company's product architecture allows you to have a global concept of the company. From the whole, look at your own products, and by the way, the architecture of the product makes it clearer and more clear. Usually, everyone only pays attention to a small piece of it being responsible. You can jump out your own small frame box in Tech Talk, and this is also a good opportunity for new employees to understand the company's core technology overall framework. The person in charge of each module needs to explain all aspects of this module, let everyone understand and answer questions.
10. Code Review
When working is handled, we will perform Code Review, and Code Review will be made when you encounter a tricky bug. Code Review is a good opportunity to understand the detailed implementation. After Code Review, it will generate intimacy rather than strange fear, I believe that many people have a very painful experience when reading others code, and Code Review is a good prescription that reduces this pain. Before making Code Review, the speaker will issue a notice to tell the relevant personnel to tell which code is to be review, so that the participant can take the time to know the relevant code in advance, do a notes to the place that does not understand to make questions in Code Review. When we encounter a more tricky bug, there is no idea or more confused. At this time, a few related person or a person who is familiar with this code is a Code Review. At this time, you can temporarily ask questions. Let the speaker answer, people who may listen in this process will not learn from the detailed process very quickly, but people who have repeatedly resemble their ideas in this process, and they have been forced to re-examine the code. It may find a solution to the problem. There is a lot of code when Code Review, but it can be made from the overall to a functional module in a functional module. The time of the Code Review is not too long, but it can be done multiple times. In Code Review, you will ask questions and suggestions, brainstorming, and more people together, some may have discovered, mutual learning, and progress by everyone. 11. Communication and communication
Most of the employees have spent the company, so the company's life has become the main components. The meaning of the relationship between employees is very important, and everyone doesn't want their own life to be boring, and I have been dealing with the machine. Communication is everywhere, the exchange occurs at any time, and there are many relationships that are established outside of work. Software companies are very easy to produce a variety of contradictions, because this is determined by your job nature, such as QA or users will not satisfy your realization, put forward various requirements, I believe you sometimes complain In invisible, it produces opposition, and it will have to contradict the psychology later. I believe that most people will have this feeling, this is not your fault, which is mainly determined by our work. If your work brings wealth to each other, the other party will welcome you very much, treat you as a God of Wealth, and your relationship will be very harmonious. Therefore, we need to eliminate this relationship between this contradiction outside of work and establish a harmonious working atmosphere. We chatted with each other at the time when we eat. We have established a list of HAPPY mail, which will send some humorous jokes, giving us a nervous work to increase your own atmosphere. After get off work, you can organize activities and increase the company's cohesiveness. After a product released, organize the tour, let the tight neurons relax, and better meet the next challenge.
12. Postscript
Different companies have different practices, I just presented me more than the process and management, let everyone have a reference, of course, it is not perfect, nor is it four seas, if you think some The place is helpful or worth promoting, this is the most important thing that this article is most. I am very grateful to i company to give me such a wonderful experience. I also thank my company's colleagues who have given me great help. I sincerely bless my company more and more growing, gradually moved! I also sincerely wish my colleagues happier!
