Dominando rapidamente gerenciamento de projetos
Quick-Kill Project Management
How to do smart software development even when facing impossible schedules.
By Andrew Stellman and Jennifer Greene, Dr. Dobb's Journal
Jun 30, 2006
URL:http://www.ddj.com/architect/189401902
Andrew and Jennifer are the authors of Applied Software Project Management (O'Reilly & Associates). They can be contacted at www.stellman-greene.com.
--------------------------------------------------------------------------------
Say you're the lead developer on a small, five-person team. You've been working for weeks on a project, and the team is just starting to jell. Your team members range in experience from a senior architect to a junior programmer just out of school. Then your boss calls you in and tells you the senior vice president was just on the phone chewing him out, and he wants your project done yesterday. As it turns out, this project is highly visible and had been promised for a long time. The users have a job to do, and this software is vital. If it doesn't work, and work well, then you'd better update your résumé.
The last time you were on a team in this kind of high-pressure situation, the project was a nightmare. Team members went down false paths for days at a time and you had to play the hero, jumping in and working 40-hour weekends to fix serious design problems. There were interminable meetings with senior managers, stubborn bugs that never seemed to go away, and too many late nights of coffee and pizza. And when the team finally delivered something, users hated it. It seemed like every button they pressed had a bug, and entire features that they were expecting never materialized in the software.
The Quick Kill
Many teams find themselves in situations like this every day, and a lead developer faces serious challenges. He doesn't necessarily directly manage his team, but he's responsible for getting the software out the door. He does have the team's respect, and when he makes a decision, people will generally follow him. But the lead developer's job isn't management—it's development. He needs to spend most of his time designing the solution, designing the software, and building the code.
Ideally, project management takes either a dedicated project manager or a lot of the project lead's time. But what do you do if you're leading a team, and you have neither the time nor the budget to do project management "right"? It's difficult for someone in this position to even know where to start. That's the idea behind "quick kill"—a highly directed system aimed at "killing" only the most pressing project problems. In other words, these practices give project leads a good trade-off that yields the most gain for the least effort.
Quick-kill project management consists of three techniques that leads can use to help their project produce what the boss expects and users need:
Vision and scope document
Work breakdown structure
Code review
Each of these techniques takes little time to implement, and helps the team avoid some of the most common and costly project pitfalls. Using them, leads can vastly improve the odds of delivering acceptable software.
Vision and Scope Document: Up To 6 Hours
If a team doesn't really understand the context in which the software is being built, they're more likely to make bad decisions over the course of the project. These bad decisions cost the team valuable time to correct—or, if left uncorrected, cost the team goodwill with users when the project doesn't meet their needs. Without a good understanding of the real scope of the project, the only thing that the team sees is the urgency, and they lose track of the needs they're trying to fill. Programmers can see the individual problems that they are working to solve, but lose track of the big picture. And this is the single biggest source of delays and project failure.
Luckily, there is a straightforward and easy-to-implement practice that can help the team avoid these problems. Writing a vision and scope document takes less than a day, and helps the team avoid weeks of rework and false starts.
The first step in writing a vision and scope document is to talk to project stakeholders. Unfortunately, it's not always immediately obvious who those stakeholders are. The lead should find the people who will be most impacted by the project, either because he plans on using it or because he is somehow responsible for it being developed. In other words, the lead needs to find the people who will be in trouble if the software is not developed. Stakeholders are generally happy to talk about what they need. This is exactly what the lead developer—and other team members, if possible—should do with them. Gathering those needs should take less than an hour per stakeholder.
The vision and scope document (see Table 1) should be brief, no more than a couple of pages. All of the information the team gathers by talking to the stakeholders should be added to the Problem Statement section.
1. Problem Statement
a. Project Background
b. Stakeholders
c. Users
2. Vision of the Solution
a. Vision Statement
b. List of Features
c. Features That Will Not Be Developed
Table 1: Vision and scope document outline.
The Project Background section is a summary of the problem that the project solves. It should provide a brief history of the problem and an explanation of how the organization justified the decision to build software to address it. This section should 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 decision 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 many 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 should explain the purpose of the projects. This should 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 contain a concise list of exactly what will and won't be built. Before writing these sections, the team should 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 should 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 should be described in the Features That Will Not Be Developed section.
Work Breakdown Structure: 2 Hours
Before working on the features that will be built, the lead should work with the team to come up with a list of estimates for each feature. Many developers have a lot of trouble with estimation. Luckily, there are a few guidelines that can make the estimation process much more straightforward and reliable.
Estimation is important because it requires that the team members think through every aspect of the project. Most programmers recognize the sinking feeling that comes with the realization that a task they'd assumed would be simple turns out to be much more involved. If other team members are depending on that work, it can throw the entire project into disarray. Good estimation practices help the team avoid that sort of all-too-common disaster. Estimating a project requires the team to figure out in advance the steps required to complete it, and to come up with a number of days (or weeks, months, hours, and so on) that each step requires. The only way to find those numbers is to sit down as a team and think through many of the details that would otherwise be left unaddressed until later in the project.
The first step in generating estimates is to break the project down into a list of tasks that will produce the final product. This list is called a "work breakdown structure" (WBS). There are many ways to break a project down into a WBS; the lead developer should gather the team together for a meeting to brainstorm this list of tasks.
A useful rule of thumb is that any project can be broken down into between 10 and 20 tasks. For large projects (for example, a space shuttle), those tasks will be very large ("Test the guidance system"); for small projects (like writing a simple calculator program), the tasks are small ("Build the arithmetic object that adds, multiplies, or divides two numbers"). It should take less than an hour for the team to brainstorm this list of tasks.
Once the team members have agreed on a WBS, they can begin to discuss each task so they can come up with an estimate for each one. At the outset of the project, team members do not have all of the information they need to produce estimates; nevertheless, they need to come up with numbers. To deal with incomplete information, they must make assumptions about the work to be done. By making assumptions, team members can leave placeholders for information that can be added later, to make the estimate more accurate.
Assumptions are an important key to estimation. If two people disagree on how long a task takes, it's likely that the source of their disagreement is that each person made different assumptions about details of the work product or about the strategy for producing it. In other words, any disagreement is generally about what is required to perform the task itself, not about the effort required to complete it. For example, given the same vision and scope document for a tool that sets the computer clock, two different developers might come up with wildly different estimates. But it might turn out that one developer assumed that the implementation would have a simple command-line interface, while the other assumed that there would be a complete UI that had to integrate tightly with the operating system's control panel.
By helping the other programmers discuss these assumptions and come to a temporary resolution about their differences, the lead can help them agree on a single estimate for the task. The lead should bring up each task one by one, and for each task the team should decide how long it will take. Each time they encounter a disagreement, that means that there are missing assumptions. The lead should work with the rest of the team to figure out exactly what those assumptions are. As these are discovered, they should be written down. As the discussion progresses and more assumptions are written, team members learn more about the project—and they will start to make decisions about how the software will be built. This helps the team converge on estimates for each task.
The final WBS should consist of a list of tasks, an estimate for each task, and a list of assumptions for that task. It should take about an hour for the team to come up with the assumptions and estimates for the 10 to 20 tasks in the WBS. The total time for creating the WBS and then doing the estimate will typically be about two hours. That should be sufficient for a basic estimate for a typical five-person project. However, if the project is large, the team may need to divide it into pieces and run the two-hour estimation session for each piece.
Code Reviews: 2.5 Hours Per Review
In a code review, the team examines a sample of code and fixes any defects in it. A defect is a block of code that does not function as the programmer intended, or that is not incorrect but could be improved (for example, it could be made more readable or its performance could be improved).
Implementing code reviews is an effective way to help the team build better software. In addition to helping teams find and fix bugs, code reviews are useful for cross-training programmers on the code being reviewed and helping junior developers learn new programming techniques. Most importantly, developers tend to write better code when they know someone else will read it later.
The first task in a code review is to select the sample of code to be inspected. It's impossible to review every line of code, so the programmers need to be selective about which portion of the code gets reviewed. If the right code samples are selected for review, then code reviews can be effective. It turns out that in most projects, a large number of defects tend to be concentrated in relatively small pockets of code. If the code is selected well, then the review easily saves the team far more time than it costs by helping the team catch defects that, if left in the software, would have required much more time to track down and fix later on.
It's not hard for the lead developer to select the right code samples for review. Code that's a good candidate for review may implement a tricky algorithm, use a difficult API or object interface, require specific expertise to maintain, or may employ a new programming technique. It is especially helpful to select a code sample in a high-risk part of the software in which any defects will be especially catastrophic—this is useful not just because that code is likely to have more defects, but also because more people will be able to maintain it down the line. When there is a large repair that requires extensive changes to many areas of the software, there is a high risk of introducing defects—this code makes a good candidate as well.
To prepare for the review, the lead distributes a printed copy of the selected code (with line numbers) to each team member. The team members each spend half an hour individually reading through (and, if possible, executing) the code sample. They do their best to figure out whether the code really does what the author intended it to do. They should look for problems with accuracy, maintainability, reliability, robustness, security, scalability, reusability, or efficiency. Any of these problems should be considered a defect. Each team member tries to spot as many defects as possible, marking them down on the printed copy.
After the individual preparation, the team leader gathers everyone for the review meeting. The code review session starts with the lead developer reading the first small block in the code sample aloud. He doesn't literally read the commands in the code; he simply gives a brief description (about one sentence) of the purpose of that block. If anyone (including the lead) does not understand what the code does or disagrees with the interpretation, the author of the code explains what it is the code is supposed to accomplish. Sometimes a team member can suggest a better, more self-explanatory way to accomplish the same thing; often it is simply a matter of explaining the purpose of the code to the person who raised the issue.
Team members should then discuss any defects found in that block of code. This is where the lead must act as a meeting moderator. If anyone found a defect, the lead should decide whether or not the team can come up with a way to fix it on the spot. If he decides they can, they do that. If not, he notes it as an open issue for the programmer to fix later. In either case, the lead adds a row to a spreadsheet that contains the review log. This spreadsheet should have one row per defect found, where each row lists the line number that contains the defect, the person who identified it, and a description of how to resolve it (or an indication that the issue was left open). At the top of the log, the moderator should note when the meeting took place and identify which block of code was reviewed.
The meeting should take no more than two hours. If it lasts longer than that, then a shorter code sample should be selected for future code reviews. Once the meeting is over, the lead should e-mail the log to the rest of the team and assign defect repairs to whoever is responsible for that block of code. Once the defects are repaired, he should review the updated code to make sure that it was repaired properly.
How to do smart software development even when facing impossible schedules.
By Andrew Stellman and Jennifer Greene, Dr. Dobb's Journal
Jun 30, 2006
URL:http://www.ddj.com/architect/189401902
Andrew and Jennifer are the authors of Applied Software Project Management (O'Reilly & Associates). They can be contacted at www.stellman-greene.com.
--------------------------------------------------------------------------------
Say you're the lead developer on a small, five-person team. You've been working for weeks on a project, and the team is just starting to jell. Your team members range in experience from a senior architect to a junior programmer just out of school. Then your boss calls you in and tells you the senior vice president was just on the phone chewing him out, and he wants your project done yesterday. As it turns out, this project is highly visible and had been promised for a long time. The users have a job to do, and this software is vital. If it doesn't work, and work well, then you'd better update your résumé.
The last time you were on a team in this kind of high-pressure situation, the project was a nightmare. Team members went down false paths for days at a time and you had to play the hero, jumping in and working 40-hour weekends to fix serious design problems. There were interminable meetings with senior managers, stubborn bugs that never seemed to go away, and too many late nights of coffee and pizza. And when the team finally delivered something, users hated it. It seemed like every button they pressed had a bug, and entire features that they were expecting never materialized in the software.
The Quick Kill
Many teams find themselves in situations like this every day, and a lead developer faces serious challenges. He doesn't necessarily directly manage his team, but he's responsible for getting the software out the door. He does have the team's respect, and when he makes a decision, people will generally follow him. But the lead developer's job isn't management—it's development. He needs to spend most of his time designing the solution, designing the software, and building the code.
Ideally, project management takes either a dedicated project manager or a lot of the project lead's time. But what do you do if you're leading a team, and you have neither the time nor the budget to do project management "right"? It's difficult for someone in this position to even know where to start. That's the idea behind "quick kill"—a highly directed system aimed at "killing" only the most pressing project problems. In other words, these practices give project leads a good trade-off that yields the most gain for the least effort.
Quick-kill project management consists of three techniques that leads can use to help their project produce what the boss expects and users need:
Vision and scope document
Work breakdown structure
Code review
Each of these techniques takes little time to implement, and helps the team avoid some of the most common and costly project pitfalls. Using them, leads can vastly improve the odds of delivering acceptable software.
Vision and Scope Document: Up To 6 Hours
If a team doesn't really understand the context in which the software is being built, they're more likely to make bad decisions over the course of the project. These bad decisions cost the team valuable time to correct—or, if left uncorrected, cost the team goodwill with users when the project doesn't meet their needs. Without a good understanding of the real scope of the project, the only thing that the team sees is the urgency, and they lose track of the needs they're trying to fill. Programmers can see the individual problems that they are working to solve, but lose track of the big picture. And this is the single biggest source of delays and project failure.
Luckily, there is a straightforward and easy-to-implement practice that can help the team avoid these problems. Writing a vision and scope document takes less than a day, and helps the team avoid weeks of rework and false starts.
The first step in writing a vision and scope document is to talk to project stakeholders. Unfortunately, it's not always immediately obvious who those stakeholders are. The lead should find the people who will be most impacted by the project, either because he plans on using it or because he is somehow responsible for it being developed. In other words, the lead needs to find the people who will be in trouble if the software is not developed. Stakeholders are generally happy to talk about what they need. This is exactly what the lead developer—and other team members, if possible—should do with them. Gathering those needs should take less than an hour per stakeholder.
The vision and scope document (see Table 1) should be brief, no more than a couple of pages. All of the information the team gathers by talking to the stakeholders should be added to the Problem Statement section.
1. Problem Statement
a. Project Background
b. Stakeholders
c. Users
2. Vision of the Solution
a. Vision Statement
b. List of Features
c. Features That Will Not Be Developed
Table 1: Vision and scope document outline.
The Project Background section is a summary of the problem that the project solves. It should provide a brief history of the problem and an explanation of how the organization justified the decision to build software to address it. This section should 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 decision 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 many 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 should explain the purpose of the projects. This should 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 contain a concise list of exactly what will and won't be built. Before writing these sections, the team should 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 should 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 should be described in the Features That Will Not Be Developed section.
Work Breakdown Structure: 2 Hours
Before working on the features that will be built, the lead should work with the team to come up with a list of estimates for each feature. Many developers have a lot of trouble with estimation. Luckily, there are a few guidelines that can make the estimation process much more straightforward and reliable.
Estimation is important because it requires that the team members think through every aspect of the project. Most programmers recognize the sinking feeling that comes with the realization that a task they'd assumed would be simple turns out to be much more involved. If other team members are depending on that work, it can throw the entire project into disarray. Good estimation practices help the team avoid that sort of all-too-common disaster. Estimating a project requires the team to figure out in advance the steps required to complete it, and to come up with a number of days (or weeks, months, hours, and so on) that each step requires. The only way to find those numbers is to sit down as a team and think through many of the details that would otherwise be left unaddressed until later in the project.
The first step in generating estimates is to break the project down into a list of tasks that will produce the final product. This list is called a "work breakdown structure" (WBS). There are many ways to break a project down into a WBS; the lead developer should gather the team together for a meeting to brainstorm this list of tasks.
A useful rule of thumb is that any project can be broken down into between 10 and 20 tasks. For large projects (for example, a space shuttle), those tasks will be very large ("Test the guidance system"); for small projects (like writing a simple calculator program), the tasks are small ("Build the arithmetic object that adds, multiplies, or divides two numbers"). It should take less than an hour for the team to brainstorm this list of tasks.
Once the team members have agreed on a WBS, they can begin to discuss each task so they can come up with an estimate for each one. At the outset of the project, team members do not have all of the information they need to produce estimates; nevertheless, they need to come up with numbers. To deal with incomplete information, they must make assumptions about the work to be done. By making assumptions, team members can leave placeholders for information that can be added later, to make the estimate more accurate.
Assumptions are an important key to estimation. If two people disagree on how long a task takes, it's likely that the source of their disagreement is that each person made different assumptions about details of the work product or about the strategy for producing it. In other words, any disagreement is generally about what is required to perform the task itself, not about the effort required to complete it. For example, given the same vision and scope document for a tool that sets the computer clock, two different developers might come up with wildly different estimates. But it might turn out that one developer assumed that the implementation would have a simple command-line interface, while the other assumed that there would be a complete UI that had to integrate tightly with the operating system's control panel.
By helping the other programmers discuss these assumptions and come to a temporary resolution about their differences, the lead can help them agree on a single estimate for the task. The lead should bring up each task one by one, and for each task the team should decide how long it will take. Each time they encounter a disagreement, that means that there are missing assumptions. The lead should work with the rest of the team to figure out exactly what those assumptions are. As these are discovered, they should be written down. As the discussion progresses and more assumptions are written, team members learn more about the project—and they will start to make decisions about how the software will be built. This helps the team converge on estimates for each task.
The final WBS should consist of a list of tasks, an estimate for each task, and a list of assumptions for that task. It should take about an hour for the team to come up with the assumptions and estimates for the 10 to 20 tasks in the WBS. The total time for creating the WBS and then doing the estimate will typically be about two hours. That should be sufficient for a basic estimate for a typical five-person project. However, if the project is large, the team may need to divide it into pieces and run the two-hour estimation session for each piece.
Code Reviews: 2.5 Hours Per Review
In a code review, the team examines a sample of code and fixes any defects in it. A defect is a block of code that does not function as the programmer intended, or that is not incorrect but could be improved (for example, it could be made more readable or its performance could be improved).
Implementing code reviews is an effective way to help the team build better software. In addition to helping teams find and fix bugs, code reviews are useful for cross-training programmers on the code being reviewed and helping junior developers learn new programming techniques. Most importantly, developers tend to write better code when they know someone else will read it later.
The first task in a code review is to select the sample of code to be inspected. It's impossible to review every line of code, so the programmers need to be selective about which portion of the code gets reviewed. If the right code samples are selected for review, then code reviews can be effective. It turns out that in most projects, a large number of defects tend to be concentrated in relatively small pockets of code. If the code is selected well, then the review easily saves the team far more time than it costs by helping the team catch defects that, if left in the software, would have required much more time to track down and fix later on.
It's not hard for the lead developer to select the right code samples for review. Code that's a good candidate for review may implement a tricky algorithm, use a difficult API or object interface, require specific expertise to maintain, or may employ a new programming technique. It is especially helpful to select a code sample in a high-risk part of the software in which any defects will be especially catastrophic—this is useful not just because that code is likely to have more defects, but also because more people will be able to maintain it down the line. When there is a large repair that requires extensive changes to many areas of the software, there is a high risk of introducing defects—this code makes a good candidate as well.
To prepare for the review, the lead distributes a printed copy of the selected code (with line numbers) to each team member. The team members each spend half an hour individually reading through (and, if possible, executing) the code sample. They do their best to figure out whether the code really does what the author intended it to do. They should look for problems with accuracy, maintainability, reliability, robustness, security, scalability, reusability, or efficiency. Any of these problems should be considered a defect. Each team member tries to spot as many defects as possible, marking them down on the printed copy.
After the individual preparation, the team leader gathers everyone for the review meeting. The code review session starts with the lead developer reading the first small block in the code sample aloud. He doesn't literally read the commands in the code; he simply gives a brief description (about one sentence) of the purpose of that block. If anyone (including the lead) does not understand what the code does or disagrees with the interpretation, the author of the code explains what it is the code is supposed to accomplish. Sometimes a team member can suggest a better, more self-explanatory way to accomplish the same thing; often it is simply a matter of explaining the purpose of the code to the person who raised the issue.
Team members should then discuss any defects found in that block of code. This is where the lead must act as a meeting moderator. If anyone found a defect, the lead should decide whether or not the team can come up with a way to fix it on the spot. If he decides they can, they do that. If not, he notes it as an open issue for the programmer to fix later. In either case, the lead adds a row to a spreadsheet that contains the review log. This spreadsheet should have one row per defect found, where each row lists the line number that contains the defect, the person who identified it, and a description of how to resolve it (or an indication that the issue was left open). At the top of the log, the moderator should note when the meeting took place and identify which block of code was reviewed.
The meeting should take no more than two hours. If it lasts longer than that, then a shorter code sample should be selected for future code reviews. Once the meeting is over, the lead should e-mail the log to the rest of the team and assign defect repairs to whoever is responsible for that block of code. Once the defects are repaired, he should review the updated code to make sure that it was repaired properly.
postado por TodoMusica às
06:23
0 Comentários
