A few software development team management of small problems

In a recent communication with a general manager, he talked about their company's software development Management, said: "Our company's biggest problem is that the project can not be completed on time, always have to drag." He asked me what I could do to change the situation. Starting with such a question, in the ensuing conversation, he introduces a series of problems in software development management, including:

The existing code quality is not high, the new developers would rather rewrite when taking over, also do not want to see others left the "rotten" code, how to do?

refactoring can cause fallback, how to avoid it?

some developers are relatively low-level, how to ensure their code quality?

Do you need documentation for software development?

What if the code Review is required to be submitted before the developer does not do or muddle through?

When a developer encounters a problem in the development process, the work cannot continue, thus delaying the progress, how to solve?

. How can you improve the developer's motivation?

In fact, every software development team managers are faced with or have faced these problems, but also have their own management "routines" to deal with these problems. I put my "routines" on the rambling.

1. The project can not be completed on time, always drag and drop, how to change?

Before finding a solution, of course, you should know why the problem arises. The general manager said: "There will always be a need to change and new needs to bring forward, so that the original development plans have to be extended." I see Knowing the root cause, of course, there is the solution, that is, "agile." Agile development is adapted to the ideas and practices of iterative (iterative) and incremental (Incremental) projects and products that are "constantly changing and increasing demand". After I talked about some of the agile concepts, especially the scrum framework, the general manager also expressed the recognition of "agility".

In fact, think about it, there is a very common problem. For product delivery time or project completion time, often by the senior management in accordance with the market situation decision and determination. In many software companies, these decision-makers often overlook an important parameter in decision-making, which is the team's productivity (Velocity). Productivity needs to be quantified, not "patted forehead" to feel. There are ways to estimate productivity in agile development. So the use of agility is relatively accurate when estimating product delivery times or project completion times. Jeff Sutherland, one of the founders of scrum, said that when he worked as an agile coach in a venture-capital team, senior Partners in the team asked the same question to all the investment companies: "Do you know the productivity of the team?" "And it's hard for these companies to make a definitive response. To set a more realistic delivery date for a product, software companies first have to figure out their software productivity.

2. The existing code quality is not high, the new developers would rather rewrite when taking over, do not want to see others left "rotten" code, how to do?

This may be the experience of many software development engineers, in the hands of other people's code, do not understand, do not add new features, read code read the headache. What does that mean? Exclude the factors that take the personal level of the person, which indicates that the old code readability, scalability is poor. What to do? At this point, perhaps refactoring is a way of both worlds. By refactoring code, you can improve the readability and extensibility of your old code without the time-consuming risk of rewriting your code.

From the perspective of taking over people's psychology, the reconstruction has a good side effect, that is, after the code refactoring, the person who takes the original "rotten" code is changed to become proud of their new achievements. Mike Cohn, author of Scrum Agile Software Development, wrote: "After my daughters drew a particularly impressive masterpiece, they took it home from school and wanted to show it in a clear position, the refrigerator." One day, at work, I used C + + code to implement a program that is particularly useful in policy mode. Because I decided that the refrigerator door was suitable for displaying anything we were proud of, so I put it up. Wouldn't it be nice if we were always so proud of the quality of our work that we could proudly show it to the refrigerator as a child's artwork? "So this positive boost will make the code for the person who feels the change is their own, and expect to find more things to refactor."

3. Refactoring will cause fallback, how to avoid?

Refactoring is really easy to cause fallback (Regression). At this point, the refactoring will play the opposite purpose. So we should add as many unit tests as we can. Some old products, old code, probably no or not so many unit tests. But at least we need to add unit tests to refactor part of the code before refactoring. Unit testing based on refactoring should be guided by the following principles (see "Refactoring", chapter 4th: Building a test system):

-Writing imperfect tests and actually running them is better than waiting for the perfect test. Testing should be a risk-driven behavior, so do not test access functions that read and write only a single range, which is too simple for them, and is less likely to go wrong.

-Focus on where the test firepower is by considering possible error boundary conditions. Play the "Public Enemy of the program" and pamper the part of your mind that is more cramped and actively think about how to break the code.

-When things are supposed to go wrong, do not forget to check if there are any exceptions that are thrown as expected.

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

-"It's better to take a reasonable time to catch most bugs" than to "get all the bugs out of your life". Because when the number of tests reaches a certain level, the test benefit will be reduced, rather than continuously increasing.

Speaking of "refactoring" this book, in fact, in each refactoring method has "practice (mechanics)" section, in the reconstruction of the practice in accordance with the above steps are more secure, but also to avoid a lot of inadvertently produced by the return of the appearance.

4. What do I do if I ask you to do code Review and developers do not do, or muddle through, before committing?

If each developer is proactive, the role of Code review can be implemented. But what if it's not? The team manager needs some means to make it effective in code Review. First of all, we used the code review in 2 forms, one is over-the-shoulder, that is, 2 people together, one person speaking, another person review. The second is to use the tool code collaborator. In either case, the submission of the code must include information about the review, such as: The name of the reviewer (Reviewer) or the review number (Review Id,code collaborator Auto-generated), each day by a full-time person to check every one of the checklist, See if someone misses the message and if it does, it will remind the person who submitted it to fill it out. In addition, there is a problem with the code being submitted, and both the submitter and the reviewer have to resolve the issue together to minimize the review process.

Bo Master Inovy in a comment said very image: "Wood (No) has the system of reward and punishment, is to bring to the toilet newspaper, after reading can be used to wipe the buttocks." "There is no reward and punishment system for guarantee, of course, the above requirements are not effective." Therefore, when a person often does not review the submission, or the review is irresponsible, its performance evaluation will be lower, and performance score is linked to the annual wage fluctuations. To put it bluntly, someone might have been able to commit the code because they had been found out many times, and by the end of the year the salary increase was 500 yuan less than others. Review

5. Do you need documentation for software development?

Software development requires documentation of the original 2, one is relatively original, the need for documentation in order to be a developer after leaving, the enterprise needs to take over the person can be based on the document to understand the design of the code or module he took over. Second, the higher level, enterprises comply with ISO9001 quality Management system or CMMI.

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

-The original developer design coding level is not high, its code readability is poor.

-Design ideas and code only one person understands that once the person leaves, no one knows the details.

Writing a few simple design documents before coding helps to clarify the idea, especially with some UML diagrams, which is also beneficial in communication. But at the same time, we should also increase the developer's coding level to increase the readability of their code, such as enhancing the readability of their variable names, using some of the design patterns that are known to replace their own unique ideas to write code, add and improve comments, and so on to reduce unnecessary documentation. In addition to implementing the collective ownership of the Code (collective Ownership), avoid some code that is only understood by one person, thus reducing the documentation written for that purpose.

For the second, the situation is somewhat complicated. People who have been exposed to agile development know that "working software is better than exhaustive documentation" in the Agile Manifesto. People who have approached CMMI development or ISO9001 Quality management systems know how high their requirements are for documents. They look incompatible. However, their purpose is consistent, namely: to build high-quality products.

For agile, the method of using handwritten user stories to record requirements and priorities, and the informal design of writing on a whiteboard, cannot be audited by ISO9001, but when copied, photographed, added to the serial number, saved, it can be audited. The daily build and auto test reports fail each time to prove that they are truly executed and truly successful, so they cannot be audited by ISO9001. However, after you add a test that asserts that the assertion failed (like assert (false)), you can pass the audit.

CMMI and Agile are complementary, the former tells the organization 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 into organizations that have passed the CMMI5 level assessment. Many companies forget that the ultimate goal is to improve the way they build software and deliver products, instead they focus on the hypothetical flaws described in the CMMI documentation, but don't care whether the changes will improve the process or product.

Therefore, agile development in the process of writing only enough documents, and the "Communication of information, evidence of conformity and knowledge sharing" as the main goal of the quality system documentation requirements are not contradictory. In practice, we can do this by following the implementation of scrum and meeting the requirements of auditing and evaluation:

-Make well-formed, refined, saved, and traceable backlog. Copy and photo are also valid.

-Put the documentation work for the regulatory needs into the backlog as well. In addition to ensuring that they are not forgotten, the cost of regulatory requirements can be made visible.

-Use a checklist to prove to the auditor or assessor that the activity has been performed. The team's definition of completion (definition of "done") can easily be transformed into a checklist.

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

All in all, software development requires documentation (but the document can be in a variety of forms, word-written text files are documents, UML diagrams in Visio are also documents, test cases saved in Quality center are documents), and we only need to write enough documents.

6. When a developer encounters a problem in the development process, the work cannot continue, thus delaying the progress, how to solve?

This is also a problem that is often encountered. If the manager to the specific problem of an engineer to guide, will fall into the situation of excessive micro-management. We need to find a macro solution. One, our scrum-based "team has a common goal" rule, using the collective ownership mentioned earlier, when these problems arise, use all the forces in the team to help them out of their plight, rather than letting others sit idly by. Of course, there are issues of performance appraisal, such as: The person who provides help will feel that his help is not conducive to the improvement of his performance evaluation, why to provide help. This requires the Human resources department in the performance evaluation of the team using scrum development, to eliminate those who tend to personal factors, but also to include the factors of teamwork, widely listen to the views of a wide range of opinions, more frequent evaluation of performance and so on.

Second, even if the use of all the power can be used, if a problem is really insurmountable, in order to reduce the risk of failure to deliver on time, the product owner should stand up and make a difference. Either re-evaluate the backlog priority so that the backlog can be delivered late, with a relatively low priority backlog, to ensure that the overall delivery time is not extended, or to reduce some of the functionality and give more time to overcome the problem. In short, overcoming technical difficulties will make the team productivity decline, product owners must make a choice.

7. Some developers are relatively low-level, how to ensure their code quality?

Of course, first let the more experienced people review the code they want to submit, which is almost what all managers do. In addition, managers have the responsibility to help these people (also including the higher level of people) to improve the level, they can read some books, the Internet to read information, reading other people's code, etc., through a lot. But the question is how do you measure whether or not it really gains something? Our experience is that every year around March for each engineer to set the entire annual goal, everyone's goals include product, technical, personal ability, such as 4 to 5 items. Six months later and a year later, to do two times performance Review, whether the goal is achieved, will also be linked to performance evaluation. We follow the smart principle when setting goals, namely:

Specific (Clear): Goals should be expressed in terms of clear results and outcomes.

Measurable (measurable): the completion of a goal should be measurable and verifiable.

Aligned (Allied): goals should be aligned with the company's business strategy.

Realistic (realistic): Although the target should be challenging, it should be implemented in a given condition and environment.

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

For example, a person has a "preliminary mastery of localization technology" goal, he wants to determine the implementation of time, to describe the way and steps of learning, by applying technology to the company's existing products, for the localization/internationalization/globalization of the company's products to explore, and make presentation to the team to demonstrate his results And ready to answer questions from others. The team also organizes tech talk activities to meet their goals and to share everyone's learning outcomes. Through these means, to improve the development of self-learning interests, and gradually improve the level of development of developers.

8. How to improve developer's initiative?

To improve the initiative of developers, there is no incentive mechanism. It is not possible for developers to feel that 5 years later he and now will not make much progress. You have to make him feel that he is engaged in a career (career), not just a job (job). Otherwise, they will not be actively involved in the work. Our experience is to provide a framework for career development. The framework has developed 2 types of development paths, management classes (managerial path) and technical classes (Technical path), and 6 career levels (level 1-3 is entry/associate,intermediate,senior. Level 4 Management class is Manager/senior Manager, Technical class is Principal/senior Principal. Level 5 Management class is Director/senior Director, technical class is fellow/architect. Level 6 is executive Management). There are 13 specific requirements for each level, including scope (scope), cross-functional, hierarchy (level), knowledge (knowledge), guidance (Guidance), problem resolution (problem solving), Submit results (delivering result), sense of responsibility (responsbility), mentor (mentoring), communication (communication), self-study (self-learning), operational supervision (operational Oversight), client response (customer responsiveness). Every year there are 2 opportunities to improve the level, once the developer has the conditions for the upgrade, his supervisor will apply, once approved, his title increases, salary will also have a relatively large increase. So that each developer feel "have Bentou", naturally their initiative also increased.

The above "routines" involved in software development team management of the development process, technical practice, document management, incentive mechanisms and other aspects. But just bucket, research and development team management covers a lot of content, but also need managers in the continuous exploration and practice on the road to learn and master.

A few software development team management of small problems