Quick-kill Project Management

(Source)
This is a very important article I saw today on the famous dr. Dobb development website in the United States. I happened to have used the (or similar) method mentioned in the article, and it worked well, So I translated it as a reference.

Original article: Quick-kill Project Management

Translation:

Quick-kill Project Management

Author: Andrew Stellman & Jennifer Greene Translation: tianxinet (fat monkey)-recently devoted to research and introducing some "best practices"

How can we develop agile (SMART) software, even in the face of an "impossible" schedule?

Andrew and Jennifer are the authors of "applied software project management" (O 'Reilly & Associates ). In www.stellman-greene.com you can contact them.

(Note: lead developer and lead can both be considered as team leader in this article, because these roles often overlap in small teams, but they can also be properly placed according to different situations)

If you are lead developer in a five-person group, you have been working in a project for several weeks and the group has just been on the road. Your team includes senior architects and junior programmers who have just stepped out of school. At this time, your boss calls you to the office and tells your senior supervisor to reprimand him on the phone. He wants your project to be completed yesterday. When it was finally completed, it was a long time before the promised date. The user has a job to do and the software is required. If the software cannot work, or it cannot work well, you 'd better update your resume.

This is the last time you join a group in this highly stressful situation. This project is a nightmare. The team members have been stuck in wrong ways for many days. You have to play a hero and spend 40 hours working each weekend to fix serious design problems. In a lengthy meeting with senior managers, it seems that stubborn bugs can never be solved and often work late at night. When the Group finally delivers something, the user hates it. It seems that users will have a bug when they click every button, but their desired features never appear in the delivered software.

Quick kill
Many groups find that they are in a similar situation every day, and lead developer faces severe challenges. Lead developer may not directly manage his group, but he is responsible for "sending out the software". He is respected by the Group. When he makes a decision, people are usually willing to follow him. However, lead developer's work group is not management but development. It takes most of the time to design solutions, design software, and build code.

Quick-kil project management consists of three methods that enable lead to meet the boss's expectations and user needs:
• Vision and scope document)
• Work breakdown structure (WBS)
• Code Review)

Each of these methods takes only a little time to execute and can help the team avoid some of the most common and costly project defects. Using them, leads can greatly increase the chance of delivering satisfactory software.

Vision and scope document: 6 hours
If a group cannot really understand the context of the software they build, they may make bad decisions throughout the project. These bad decisions waste the group's valuable time to correct. If they are not corrected, the project may not meet the user's needs and damage the good relationship between the Group and the user. (IF) the true scope of the project is not well understood, the only thing that the Group can foresee is being "chased after the ass" (urgency ), they are separated from the demands they try to satisfy. Programmers can see their own single program, but they are separated from the big idea. This is the biggest single cause of Project latency and failure.

Fortunately, there is a simple, direct, and easy-to-Execute experience to help the team avoid these problems-spend less than a day writing a prospect and scope document, it also helps the team avoid weeks of rewriting and incorrect start.

The first step in writing a foreground and scope document is to talk to the project stakeholders (stakeholders. Unfortunately, it is not always apparent who is a project stakeholder. Lead should find out the person most affected by the project-Either he wants to use the software, or he has trouble if the software is not developed. Stakeholders are happy to talk about their needs. This is exactly what lead developer should talk to other team members, if possible. Talk to each stakeholder for less than an hour to obtain their needs.

The foreground and scope documents should be concise and contain no more than two pages (see the table below ). All information obtained through conversations with stakeholders should be added to the problem statement section.

1. Problem Description
A. Project Background
B. Stakeholders
C. User
2. Vision)
A. Foreground statement
B. Function Specification (features) List
C. features that will not be developed (features)

(Some instructions on this document are omitted here. For details, refer to the original article)

Reference the original text of this section:
Table 1: Vision and scope document outline.

 

The project background section is a summary of the problem that the project solves. it shoshould provide a brief history of the problem and an explanation of how the Organization justified the demo-to build software to address it. this section shoshould cover the reasons why the problem exists, the organization's history with this problem, any previous projects that were undertaken to try to address it, and the way that the demo-to begin this project was reached.

The stakeholders section is a bulleted list of the stakeholders. each stakeholder may be referred to by name, title, or role ("support group manager," "scto," "senior manager "). the needs of each stakeholder are described in a few sentences. the Users section is similar, containing a bulleted list of the users. as with the stakeholders, each user can either be referred to by name or role ("support rep," "Call quality auditor," "Home Web site user"); however, if there are using users, it is usually inefficient to try to name each one. the needs of each user are described.

The needs of the users and stakeholders are the most important part of this document. unless the team understands the needs that drive the project, they may end up with a narrow focus, causing them to waste time addressing problems that are of little importance to the stakeholders. it's easy to build great software that solves the wrong problems, but the only way to build the appropriate software is for everyone in the project to understand and agree on both why and how that software will be built before the work begins. that's the purpose of project planning.

The "vision" part of the vision and scope document refers to a description of the goal of the software. all software is built to fulfill needs of certain users and stakeholders. the team must identify those needs and write down a vision statement (a general statement describing how those needs will be filled ). the goal of the Vision Statement section is to describe what the project is expected to accomplish. it shoshould explain the purpose of the projects. this shoshould be a compelling reason, a solid justification for spending time, money, and resources on the project.

The list of features and features that will not be developed sections in a concise list of exactly what will and won't be built. before writing these sections, the team shoshould write the rest of the document and have an open discussion of the needs that they are trying to fill. every single feature in each list shocould be built to address a specific need listed in the problem statement section. often the team comes up with a feature that seems obvious, but that turns out not to really address a need. features like this shocould be described in the features that will not be developed section.

 

Work Breakdown schedule (WBS): 2 hours
After configuring the Feature Specification (features), lead should work with the team to propose an estimate list for each Feature Specification. Many developers may encounter a lot of trouble during evaluation. Fortunately, some guidelines can make the evaluation process simple and reliable.

Evaluation is important because it requires team members to consider every aspect of the project from start to end. Most programmers admit that they feel this uneasy: with the implementation of their (original) hypothetical tasks, the original (seemingly) simple problems will become increasingly tricky. If the members of other groups rely on the work, it may drag the entire project into chaos. Good evaluation experience can avoid frequent disasters. Evaluating a project requires the team to provide the steps to complete the project in advance and propose that each step takes days (Weeks, or hours ), the only way to figure out these numbers is to sit down and consider many details that may be missed in the project later.

The first step in the evaluation is to split the project into a list of tasks to complete the final product. This list is called "work breakdown structure (WBS )". There are many ways to break down a project into a WBS. Lead developer should organize group members to join a meeting to discuss the task list.

A useful principle is that any project can be broken down into 10 ~ 20 tasks. For large projects (such as space shuttle), tasks are very large; for small projects (such as simple calculator programs), these tasks are very small.

Once the team members reach an agreement on WBS, they can start to discuss each task so that they can evaluate each task. At the beginning of the project, the team members did not have all the information required for the evaluation; however, they needed numbers. To process these incomplete information, they must make some assumptions about the work to be processed (assumption ). By making assumptions, the team members can reserve positions for the information that may be added later to make the evaluation more accurate.

Hypothesis is the key to evaluation. If two people have disputes over how long it takes to complete a task, they may make different assumptions about the product and production product strategies. In other words, any dispute is usually about what is needed to execute the task, rather than the effort to complete the task. For example, a tool for setting the computer clock provides the same vision and scope document, but a developer may assume that a command line interface is used, another developer assumes a graphical interface combining the system control panel.

By helping another programmer discuss these assumptions and reach an interim resolution on their differences, lead can help them reach a consensus assessment on the task. Lead should propose each task one by one, and the Team should decide how long each task will take. Every time a dispute arises, it means that there are missing assumptions. Lead should work with other team members to accurately identify the missing assumptions. Note these assumptions when they are discovered. When the discussion process and more assumptions are written down, the team members will learn more about the project and will begin to make decisions on how the software is built. This helps the team reach an agreement on the evaluation of each task.

The final WBS should be composed of the task list, evaluation of each task, and assumptions of the task. Propose 10 ~ The assumption of the 20 tasks will take about one hour for the group. The total time for WBS creation and evaluation is about 2 hours. This should be sufficient for a basic assessment of a five-person group. However, if it is a large project, you need to divide the project into multiple parts, and then evaluate each piece in two hours.

Code reviews: 2.5 hours for each review
In a code review, the Team checks a code sample and fixes any of its defects (defect ). A defect is a code block that cannot run as the programmer wants, or that can be improved (for example, making it easier to read or improve its performance ).

Executing code review is an effective way to help the team build better software. In addition to helping the team discover and correct bugs, code review is helpful for programmers to perform cross-training for reviewed code and to help novice developers learn new programming technologies. Most importantly, developers tend to write better code when they know that someone is going to read it later.

The first task of code review is to select the sample code for the check. It is impossible to review each line of code. Therefore, the programmer must review the part of the Code to be selected. If the selected code is correct, the code review will be valid. In most projects, a large number of defects are concentrated in a relatively small part of the code. If the code is well selected, the review can help the team identify the defects and easily save much time than the review. If these defects are left in the software, it will take more time to track and correct the changes later.

It is not difficult for lead developer to select the correct code sample. A good review of candidate code may implement a tricky algorithm, use a difficult API or object interface, require special technologies for maintenance, or may use a new programming technology. This is especially useful for Selecting code samples for high-risk components where any defect in a software would result in a disaster-not just because the code may have more defects, it is also because more people will maintain the software along this clue. When there is a large scope of repair, it is highly risky to introduce defects.

When preparing for review, lead delivers a printed copy of the Code (with a line label) to each group member. The group members spent half an hour reading (if possible and executing) the code sample once, and they tried to point out whether the code was actually doing what the author wanted it to do. They should look for problems such as accuracy, maintainability, reliability, controllability, security, scalability, reusability, and efficiency. Any one of these problems should be seen as a defect. Each team member should discover as many defects as possible and mark them on the print.

After the preparation is complete, the Team Leader puts everyone together for a review meeting. At the beginning of code review, lead developer reads a piece of code sample. Instead of simply reading the code, he makes a concise description of the code block. If no one (including lead) can understand what the code is doing or does not agree with the elaboration, the Code author wants to explain what the code should do, sometimes a group member can come up with a better and clearer way to accomplish the same thing; it generally just shows the purpose of the code.

Then the team members should discuss any defects found in the code, and lead must act as the arbitration of the meeting. If anyone finds a defect, lead should determine whether the team can propose a way to correct it. If the judgment is correct, the team should propose a solution. If the judgment is not, use it as a pending issue for subsequent amendment. In addition, lead adds a row to the table that contains the Review Record (log). Each detected defect has a corresponding row in this table, each line lists the code lines containing defects, the validators, and descriptions of how to resolve the defects (or mark the problem as pending ). At the top of the record (log), lead should record the time of the meeting and the code to be reviewed.

The review meeting should not exceed 2 hours. If the duration exceeds 2 hours, you should select a shorter sample code for review in the future. After the meeting, lead should mail the records to the team members and designate the code owner to correct the defects. Once the defect is corrected, lead should review the updated code and confirm that the code is correctly corrected.