Several small issues of software R & D team management

When talking to a general manager recently, he talked about the software R & D management of their company and said, "the biggest problem in our company is that the project cannot be completed on time, so it is always time-consuming ." He asked me how I could change the situation. Starting from such a problem, in subsequent conversations, he introduced a series of problems he encountered in software development management, including:

 

. ExistingCodeThe quality is not high. When new developers take over, they would rather rewrite the code than view the "bad" code left by others. What should they do?

. Refactoring will cause rollback. How can we avoid this?

Some developers are relatively low in level. How can they ensure their code quality?

Does software development require documents?

. Code review is required before code submission, but developers do not, or perfunctory. What should I do?

When a developer encounters a problem in the development process and the work cannot be continued, the progress is delayed. How can this problem be solved?

. How can we improve developers' initiative?

 

In fact, the managers of each software R & D team are faced with or once faced with these problems, and they also have their own management "routines" to deal with these problems. I will repeat my "routine" here.

 

1. If the project cannot be completed on time, it must be delayed. How can this problem be changed?

 

Before finding a solution, you must first know why the problem occurs. The general manager said: "There will always be demands for changes and new demands, so that the original development plan has to be extended ." It turns out that. Knowing the root cause, of course there will be a solution, that is, "agile ". Agile development is suitable for projects and products with frequent changes and increases in requirements due to its iterative and incremental ideas and practices. After I talked about some agile concepts, especially the scrum framework, the general manager also recognized "agile.

 

In fact, there is still a very common problem. The product delivery time or project completion time is often determined by the senior management based on market conditions. In many software enterprises, these decision makers often ignore an important parameter in decision-making, that is, the team's productivity (velocity ). Productivity needs to be quantified, rather than being perceived by the brain. Agile development involves how to estimate productivity. Therefore, agility is relatively accurate when estimating the product delivery time or project completion time. Jeff Sutherland, one of the founders of scrum, said that when he is an agile coach in a venture capital team, senior partners in the team will ask all companies waiting for investment the same question: "Do you know the team's productivity?" However, it is difficult for these enterprises to make clear replies. Software Enterprises must first determine their software productivity if they want to set a more practical delivery date for their products.

 

2. The quality of the existing code is not high. When new developers take over the code, they would rather rewrite it than view the "bad" code left by others. What should they do?

 

This may be an experience that many software development engineers have experienced. When taking over others' code, they cannot understand and can't add new functions. This is a headache for reading code. What does this mean? Excluding the personal level of the successor, this shows that the old code is less readable and scalable. What should I do? At this time, reconstruction may be a perfect solution. The successor restructured the code, which not only improves the readability and scalability of the old Code, but also avoids the time risk caused by code rewriting.

 

From the perspective of the owner's psychology, there is also a good side effect of refactoring, that is, after code refactoring, the owner feels that the original "bad" code has been modified into a new achievement that he is proud. Mike Cohn, author of scrum agile software development, wrote: "My daughters will take it home from school after drawing a really amazing masterpiece, and want to display it in an obvious position, that is, the refrigerator. One day, at work, I used C ++ code to implement a particularly useful policy pattern.Program. I decided that the refrigerator door was suitable for displaying anything we were proud of, so I put it on. If we are always very proud of the quality of our work and can proudly show it on the refrigerator like the child's art, isn't that good ?" So this positive promotion will make the successor feel that the modified Code is his own, and expect to find more refactoring.

 

3. Reconstruction may result in rollback. How can we avoid this?

 

Refactoring can easily result in a regression ). At this time, refactoring will play the opposite role as it was originally intended. So we should add as many unit tests as possible. Some old products and old code may have no or no unit tests. However, we should at least add a unit test for the code to be restructured before refactoring. Unit Tests based on reconstruction goals should follow the following principles (see Chapter 4th of reconstruction: Building a testing system ):

-Write incomplete tests and run them in real time, so you can never wait for a perfect test. The test should be a risk-driven behavior, so do not test access functions that read and write only one value field. It should be too simple and unlikely to make an error.

-Consider the possible boundary conditions for errors and set the test firepower. Play the role of "public program enemy", indulge in the narrow part of your mind, and actively think about how to destroy code.

-When an error is accepted, do not forget to check whether any exception is thrown as scheduled.

-Do not write the test code because "the test cannot capture all bugs", because the test can indeed capture most bugs.

-It is better to "catch all bugs in a lifetime" to "catch most bugs in a reasonable time ". When the number of tests reaches a certain level, the test benefits will decrease, rather than continue to increase.

Speaking of refactoring, there is actually a "mechanism" section in every refactoring method. It is safer to follow the steps described above in refactoring practices, at the same time, it can also avoid a lot of casual manufacturing rollback.

 

4. Code review is required before code submission, but developers do not, or are perfunctory. What should I do?

 

If every developer is proactive, the role of code review can be implemented. But what if not? Team Managers need some means to make code review effective. First, we adopt two forms of code review: one is over-the-shoulder, that is, two people are seated together, one is talking, and the other is reviewing. Second, use the tool code collaborator. In either form, information about the review must be indicated when code is submitted, for example, the name or review Number of the reviewer (Review ID, code collaborator automatically generated ), every day, a full-time employee checks every entry in the checklist to see if someone has missed this information. If this information is found, the submitter will be reminded to make up the information. In addition, if a piece of submitted code has a problem, both the submitter and the reviewer should work together to solve the problem, so as to prevent the review process from being perfunctory to the maximum extent.

 

Inovy, a blogger, said in a comment: "There is a penalty system for wood (NO), that is, the newspaper that is taken to the toilet. After reading it, you can wipe your ass ." There is no reward and punishment system to guarantee the effectiveness of the above requirements. Therefore, when a person submits a review without review, or is not responsible for the review, the performance rating will be lower, and the performance score is linked to the annual wage fluctuations. To put it bluntly, someone may submit the code because it has been detected multiple times without code review. By the end of the year, the salary increase will be 500 Yuan less than that of others.

 

5. Do I need documents for software development?

 

There may be two types of documents required for software R & D. One is relatively primitive. The document is required to ensure that after a developer leaves the company, the person to take over the enterprise can learn the code or module design that the enterprise takes over according to the document. Second, enterprises must comply with the ISO9001 quality management system or cmme.

 

For the first type, the root cause may come from two aspects:

-The original developer's design code level is not high, and the code readability is poor.

-Only one person knows the design idea and code. Once a person leaves the company, no one knows the details.

Writing some simple design documents before coding helps clarify ideas, especially with some UML diagrams, which is also beneficial for communication. But at the same time, we should also improve the coding level of developers to increase the readability of their code, for example, to enhance the readability of its variable naming, to replace the Code Compiled according to some of your own unique ideas with some well-known design patterns, and to add and improve comments, to reduce unnecessary documents. In addition, the collective ownership of code (collective ownership) can be implemented to prevent some code from being understood by only one person. This can reduce the number of documents written for this purpose.

 

The second case is complicated. People who have been familiar with agile development know that "software that can work better than all-inclusive documents" in the agile declaration ". People who have been familiar with cmme development or the ISO9001 Quality Management System know how high their requirements for documents are. They seem incompatible. However, their purposes are the same: to build high-quality products.

 

For agility, the use of hand-written user stories to record requirements and priorities, and the informal Design of drawing on the whiteboard cannot pass the ISO9001 review, however, after copying, taking photos, adding serial numbers, and saving them, they can pass the review. Every successful daily build and auto test reports cannot prove whether they are actually executed and successful, so they cannot pass the ISO9001 review. However, you can pass the review after you add an Assert (assert (false)-like assert) test.

 

Cmme and agility are complementary. The former tells organizations what to do on the general terms, but does not say how to do it. The latter is a set of best practices. Agile methods such as scrum have also been introduced to organizations that have passed the cmmi5 level evaluation. Many enterprises forget that the ultimate goal is to improve their way of building software and submitting products. On the contrary, they focus on filling in hypothetical defects as described in the cmme document, but they do not care whether these changes can improve the process or product.

 

Therefore, agile development only requires sufficient documents in the process, and there is no conflict with the requirements of quality system documents with "information communication, conformity evidence and knowledge sharing" as the main objective. In practice, we can follow the methods below to meet the review and evaluation requirements while implementing scrum:

 

-Create a well-formatted, refined, saved, and traceable backlog. Copies and photos are equally valid.

-Add the required documents to the backlog. In addition to ensuring that they are not forgotten, the cost of regulatory requirements is visible.

-Use the check list to prove to the reviewer or evaluator that the activity has been performed. The team's definition of "done" can be easily converted into a check list.

-Use agile project management tools. It is actually an electronic presentation of development programs and records.

 

All in all, software development requires documents (but documents can be in a variety of forms, text files written in Word are documents, and UML diagrams drawn in Visio are also documents, the test cases stored in the Quality Center are also documents. At the same time, we only need to write enough documents.

 

6. When a developer encounters a problem in the development process and the work cannot be continued, the progress is delayed. How can this problem be solved?

 

This is also a common problem. If the manager provides guidance on the specific problems of an engineer, the engineer may experience excessive micro-management. We need to find a macro solution. I. Based on the scrum rule "teams share common goals", we use the collective ownership mentioned above to address these problems, use all the power available in the team to help them get rid of their troubles, rather than letting others stand. Of course, performance evaluation problems will be involved here. For example, the person who provides help will feel that his help does not help his or her performance evaluation and why does he need help. This requires the human resources department to eliminate personal-Disposition factors and team collaboration factors in the Performance Evaluation of teams using scrum development, so as to listen extensively to opinions from various aspects, evaluate performance more frequently.

 

2. Even if you use all the available power, if a problem is insurmountable, in order to reduce the risk of delivery failure on time, the product owner should come up and make a difference. Either re-evaluate the priority of the backlog to make it unable to continue delivery a little later. First, do some backlogs with a relatively low priority to ensure that the overall delivery time is not extended; or reduce some functions, more time is provided to overcome difficulties. In short, exceeding technical difficulties will reduce the team's productivity, and the product owner must make a choice.

 

7. How can we ensure the quality of code when some developers are relatively low?

 

Of course, first let more experienced people review the code to be submitted. This is almost what all managers will do. In addition, managers have the responsibility to help these people (including high-level people) improve their levels. They can read books, read documents online, read others' code, and so on. But the question is how you can determine whether it is actually rewarding. Our experience is to set annual goals for every engineer in about March each year. Each person's goals include product and technical goals, in terms of personal abilities, there are four to five items. After half a year and one year, the Performance Review will be performed twice. Whether or not the target is achieved will also be linked to performance evaluation. When setting goals, we follow the SMART principle:

 

Specpacific (clear): The goal should be clearly stated based on the results and results.

Measurable: the completion of the target should be measurable and verified.

Aligned: the goal should be consistent with the company's business strategy.

Realistic (realistic): Although the goal should be challenging, it should be able to be achieved under given conditions and environments.

Time-bound (with a time limit): The target should include a specific implementation time.

 

For example, if a person sets a goal of "preliminary understanding of localization technology", he must determine the implementation time and describe the learning methods and steps, by applying technology to the company's existing products, we need to make some exploration for the localization, internationalization, and globalization of the company's products, and make presentation to demonstrate his achievements to the team, you are prepared to answer questions raised by others. The Team also organizes Tech Talk activities to help them achieve their goals, so that everyone can share their learning results. By using these methods, developers are more interested in self-learning and their technical skills are gradually improved.

 

8. How can we improve developers' initiative?

 

The incentive mechanism is indispensable to improve developers' initiative. Developers cannot feel that they will not make any progress over the past five years. You need to make him feel that he is engaged in a career, not just a job ). Otherwise, they will not take the initiative to work. Our experience is to provide a framework for career development. The framework develops two types of development paths: managerial path and technical path, and six career levels (Entry/associate, intermediate, senior. Level 4 Management class is Manager/senior manager, and the technology is Principal/Senior Principal. Level 5 management class is Director/senior director, and the technology class is fellow/effecect. Level 6 is executive management ). Each level has 13 specific requirements, including scope, cross functional, level, knowledge, and guidance) problem solving, delivering result, Responsbility, mentoring, communication, and self-learning ), operational oversight and customer response ). There are two opportunities to raise the level every year. Once a developer meets the upgrade conditions, his supervisor will apply. Once approved, his title will be increased accordingly, the salary will also be greatly improved. So that every developer feels that there is a rush, and naturally their subjective initiative is improved.

 

The above "routine" involves the R & D process, technical practices, document management, and incentive mechanisms in software R & D team management. However, there are still a lot of content covered by R & D team management, and managers need to learn and master it on the road of continuous exploration and practice.