Build an efficient software development process and repost the team

2. Project Plan

After a product is released and used, there must be many unsatisfactory and worthy of improvement. During the use process, customers will find some problems, put forward higher requirements, and the market is also changing. Our competitors are also developing, and new technologies are constantly emerging, these factors drive the continuous development of our products, so that their versions keep growing. These development requirements were not raised at once. During the customer's use process, they found some unsatisfactory and inconvenient places, and they would give advice to our technical support staff, technical support personnel store these requirements in the form of bugs in the bug database. The level is generally defined as the feature of the next version. Some bugs not solved in the previous version may also need to be solved in the current version. Therefore, when we develop the next version, many of its features already exist in the bug database. Of course, the features of the new version are not only obtained from bugs. The management layer may propose new features from the market perspective to lead competitors, developers themselves can also make certain requirements to be included in the new version development plan. For example, they need to refactor some code to make its structure clearer and easier to maintain, and the execution efficiency is higher.

Each person collects functional modules related to himself and estimates the time, including the document writing time, development time, and unit test time. Generally, the time must be accurate to the working day. This information is sent to the team lead, and the team lead sends the tasks and estimated time of the team members to the management, which evaluates and reviews the tasks and progress, the Management will make a selection based on the product release time, customer requirements, market factors, and other factors. Some features may be postponed to the next version due to the urgent time. If the estimated time conflicts with the expected product release time, and this function is required in the current version, the development team will be asked to re-estimate the time, accelerate development to meet this requirement.

Although the development progress time is an approximate estimated time, we should try our best to follow the development progress. Every Friday afternoon, we have a status meeting (which is generally less efficient and suitable for meetings). At this meeting, we will review our work based on the progress, whether the work of each person follows the schedule, whether someone is delayed, or whether the work of others is blocked. At this meeting, everyone should report their progress and what they did last week, what they were doing, and what they were going to do next week. Through this meeting, you will feel that someone is monitoring you, and force you to constantly urge yourself not to delay the task. If there are signs of delay, you will also find and catch up as soon as possible. If some efforts fail to catch up, there is no way to modify the original schedule because our estimation is different from the reality. We must make our schedule conform to the actual situation, this can prevent many projects from occupying 20% of the final workload or even dragging back. We used to modify the progress table. Once, when we performed the previous progress to the desired state, we suddenly received a notification asking for another major feature due to market and customer reasons, this function has a huge impact on the structure of our program, so we need to 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 postponed. Of course, we should try our best to avoid this situation, especially when new requirements are generated in the later stage of the project. If we have to, we should re-plan the progress, instead of continuing to follow the original progress, because the old progress cannot reflect the reality.

3. Development Documentation

In the project schedule, we have planned the document writing time. Although the document is written here, it is actually a design program, which sorts out the ideas and architecture, in this way, the actual code writing will be much smoother and save time. Therefore, it can be said that all the really thoughtful things are completed during the writing of documents. Of course, the document format here is not as defined in ISO. Our document format is relatively free and can be used at will, but it should be noted for several main points. The required documents can be easily understood by others. They can clearly explain the problems and reflect your design ideas. There are not many documents. There are two types of development documents: function spec and design document.

In function spec, We need to specify the tasks completed by this module, the issues to be solved, the functions to be used, and the reasons for these functions. In addition, we will add them to the scope of application and what are the shortcomings, note what it is and where it can be improved in the future. This function spec does not involve any very detailed algorithms. This document is not only for developers, but also for QA and other members and later newcomers to learn about the general functions of this module based on this document. It will also be presented to document writers, they will sort out a user manual based on these function spec to tell users what features are added in this version, what role each function module has and how to use them. Therefore, in our development process, function spec is an important document. After this document is completed, it will take some time to review this document with relevant personnel and QA, so that QA can understand the intent of the designer, at the same time, be familiar with the new functional modules and prepare for the next test. If there are any misunderstandings or misunderstandings, we will discuss them and make them correct by developers.

The design document describes the main algorithms, data structures, class hierarchies, and call relationships involved in implementing this module. The reader of this document is mainly a developer, including anyone who wants to know the code in detail to help people understand the code. In some simple programs with function modules, this document describes less information. Unlike function spec, this document does not need to be compiled before writing code. It can be added as the code is written, but it basically follows the document first principle, that is to say, to add new code or modify the code, if there is a document involved, you should first modify the document and then modify the code.

4. write code

Because we use the Java language for development, we use the JBuilder ide tool. About the code style, we basically use the automatic code format Orchestration in JBuilder, But what needs to be changed is that the indent is 4 characters, and there are two lines between the class and the class, there are two lines between the method and the method, and the complete class name is used for importing the class. When writing code, you must provide detailed comments and instructions on classes and functions. You can see the descriptions of these classes and functions and the implementation principles of the main algorithms. During the development process, unittest should be written for the main modules, and unittest should be performed first, that is, the test driver principle in the XP rules should be followed. When all unit test code passes, this function is basically complete.

5. Code Management

We use VSS + sourceoffsite for version control, which stores all the source code, library files, documents of this product and the installation programs for release. Each part is stored in different directories. Every morning, developers are required to get the source code of latest version from VSS, then compile and start the day's work. In theory, employees are required to check all the code modified on the current day before leaving work. before checking in, ensure that the compilation is successful. If someone checks in code and causes the daily build to fail, some punitive actions or warnings are required, such as Microsoft taking care of the daily build of the day. Sometimes the code we write involves multiple files, and this change is complicated and takes many days to work. If you check in now, it may cause BVT (build verify test) the test is successful, because some code is not completely completed, and the previous code can pass the BVT test, and the code basically does not involve others. In this case, you can not check in, check in again after all the code is complete and the BVT test can be submitted.

Every day, we build daily, usually at a.m.. At that time, a program will automatically pull the latest code from VSS and compile it. Because we conduct synchronous development with the United States, if we want to enter the modified Code into this build, we need to check the corresponding code before a.m. If someone checks in the code to make the compilation fail, it will be found in this step. After the compilation is complete, the installation package is automatically generated. The test department will perform BVT tests on the Code and label the development library in VSS, if any bug is found, you can determine the time when the bug occurs based on the label. BVT refers to build verify test, which is used to test basic functions of components. This test is performed every day to check whether the newly added code or modifications affect the basic functions of the system, so that errors can be detected as soon as possible.

6. Test

After the developer completes the function spec, the test department starts the test plan to determine what needs to be tested and how to test and schedule it. Testers need to write a lot of test code. Some test code needs to be integrated into BVT for testing, and some may need to be tested separately to ensure that the product meets the requirements, this makes it easy for developers to locate and correct the problem. Whether the product functions meet the requirements and whether the product can be released is determined by the testers. Therefore, the testers are also hard-working and have great responsibilities. After passing the daily BVT test, some performance tests, compatibility tests, and disaster tests need to be carried out before the product is released. After completing these tests, the tester determines whether the product can be release. If there is no problem, the tester will perform beta testing for some users with good relationships, and then finally release the product.

7. Bug Management

Because we perform tests every day, bugs are often discovered by the testing department. Once new bugs are found, they are added to the bug tracking system. Currently, the most popular bug tracking systems include testtrack, ClearQuest, and Bugzilla. Bug Tracking System is the bond between developers and QA. Developers and QA are linked through BUG Tracking System. Each bug has its type and level. The predefined types include crash-data loss, crash-No data loss, incorrect functionality, cosmetic, and feature request. The levels include P1, P2, and P6, they represent the importance and urgency, and P1 bugs need to be fixed quickly. Bugs earlier than P5 must be fixed before the current version of release, if it is really unavailable or unimportant, it is determined by QA and the priority is reduced to go to the next version to fix it. After a bug is found, QA adds a bug to the bug track, fills in the relevant information, and assigns the assign to the corresponding developer. After receiving the Bug Analysis and fixing, the developer sends the assign to QA to verify, enter the analysis results and detailed instructions on how to solve them. If QA passes verify on this bug, close the bug; otherwise, verify failed and re-assign the bug to the developer and wait for its fix. Every week, status meeting reports the bug status. The QA Team Lead reports the bug status, including the number of new bugs, the number of fixed bugs, and the number of open bugs, you can learn about the development and testing status based on the number of pending verify conditions. Sometimes we conduct bug review on status meeting and bug review in a separate group, its main function is to re-identify bugs on each person's head and understand the status of each bug, such as how developers will handle this bug, in this way, you can see if there are any thorny problems during development, which increases the risk of product release. In a game where QA adds bugs and developers fix bugs, the number curve of bugs fluctuates up and down like the stock market curve. However, the general trend is that bugs are rising in the early stage, and bugs are falling in the later stages, if the number of new open bugs continues to rise in the future, the risk is increasing and may not be controlled. That is to say, fixing a bug leads to multiple new bugs. You can also use a line chart of the number of codes to roughly present the quantitative development progress. When a large number of new functions are added, the amount of code may increase quickly. When the bug fix stage is used, the code is modified a lot, so the increase in the number of codes will decrease, based on the amount of code, you can see the development status at what stage.

It should be pointed out that we have a wide range of definitions of bugs, and some new features can also be proposed as bugs, but these bugs are relatively low, so that they can be implemented in the next version. Therefore, the creator of a bug can also be a technical support staff, marketing staff, or even developers themselves. The developer may find some bugs, some of which are from other developers, and some may be from the developer, adding this bug to the bug library can help developers learn from each other when they encounter new problems or similar bugs in the future, however, verify of this bug must be verify by the tester who tests this module.

8. Code freeze

When bugs earlier than P5 are fixed, the release date of the product is not far away. Generally, the release product can be released two weeks later. In this case, the code in VSS should be freeze, to ensure the stability of the code library. In the Code freeze stage, check in and check out permissions of developers are generally disabled, if a bug report is reported at this time and it is determined that it is significant and must be fixed in this version, the permission must be granted with the consent of the management, after the modification is completed, the modifier should report the modified files, affected documents, and other information to various departments, such as QA, build personnel, and document writers. In the Code freeze phase, the test Department is conducting various tests to obtain various data and determine whether the current version can be release.

9. Tech Talk

Computer knowledge is updated very quickly. There are often new terms, new terms, new ideas, and new technologies, if we leave this industry for a few months and return again, we will not be able to understand these new things, and we may have forgotten what happened to the world around us for our own projects. Tech Talk provides an opportunity for us to understand new knowledge and the latest development trends, so that we can share and improve our knowledge. Tech Talk is generally carried out when the project is not too busy. The host will designate a person to prepare tech talk one week in advance. Generally, this person may be interested in some aspects, then, he will take some time to understand this situation, write a document such as Powerpoint, upload it to the LAN, and notify everyone to browse it first. The content of tech talk is very extensive and not necessarily closely related to our projects. Any new ideas and new knowledge (of course, generally limited to the computer field) all of them can be used as the content of tech talk. After the keynote speech, you may have some questions to discuss and answer questions about this topic. Of course, tech talk can also be related to our projects, such as researching the product technologies of competitors and the architecture of our products. Studying the product architecture of the company enables everyone to have a global concept of the company's products. From the overall perspective, let's sort out the product architecture to make it clearer and more organized. In normal times, everyone only pays attention to a small part of what they are responsible for. In tech talk, they can jump out of their own box to understand the global situation, this is also a good opportunity for new employees to understand the overall framework of the company's core technologies. The owner of each module needs to elaborate on all aspects of this module, so that everyone can understand and answer questions.

10. Code Review

Code review will be performed when work is handed over, and code review will be performed when a tricky bug is encountered. Code review is a good opportunity for everyone to understand its detailed implementation. Code review will generate a sense of intimacy rather than strangeness and fear for this code. I believe many people will experience a very painful experience when reading other people's code. Code review is a good prescription to reduce this feeling of suffering. Prior to code review, the speaker will send a notification in advance to inform relevant personnel of the Code to be reviewed, so that participants can take time to learn about the code in advance, take a note of what you don't understand so that you can raise questions in code review. When we encounter a tough bug that has no idea or is confusing, we can find a few people or people familiar with the code to review the Code. At this time, the format is relatively casual, you can ask questions on a temporary basis and ask the speaker to answer them. In this process, the speaker may not be able to hear the detailed process very quickly, however, the speaker re-examined the code in this process and may find a solution to the problem. Sometimes there are a lot of code in code review, but a function module can be implemented in a progressive way from the overall to the local. The review time of a code review should not be too long, but can be performed multiple times. In the code review, you will raise questions and suggestions, brainstorm ideas, and come up with multiple people. Some questions you may not think of will be discovered, learned from each other, and made progress together.

11. Communication and communication

Most employees spend most of their time in the company, so the company's life has become a major component of everyone. The relationship between employees is harmonious, and communication is very important. At the same time, everyone does not want their own life to be boring and has been dealing with machines. Communication is everywhere and communication occurs at any time. Many relationships are established outside of work. In a software company, there are various conflicts, because they are determined by the nature of your work. For example, when QA or users are dissatisfied with your implementation and put forward various requirements, I believe that you may complain sometimes, and there is a confrontation in the invisible, which will lead to resistance in the future. I believe most people will feel this way. This is not your fault. It is mainly determined by the nature of our work. If your job is to bring wealth to the other party, the other party will welcome you and treat you as a god of wealth. The relationship with you will be very harmonious and friendly. Therefore, we need to eliminate such conflicts outside of work and establish a harmonious working atmosphere. We chat and communicate with each other at the dinner table. We have created a happy email list, where we will send emails such as humorous jokes, which gives us a relaxed atmosphere for our intense work. After work, you can organize activities to increase the company's cohesion. After a product is released, we will organize a tour to relax and better meet the next challenge.

12. Postscript

Different companies have different practices. I just present the processes and management methods that I think are better, so that everyone can learn from them. Of course, they are not perfect, and they are not perfect, if you think that some areas are helpful or worthy of promotion, this is the best result of this article. I am very grateful to company I for giving me such a wonderful experience and to my colleagues who have helped me a lot. I sincerely hope that company I will continue to grow and succeed! I sincerely wish my colleagues happiness and happiness!