Читать книгу Beginning Software Engineering - Stephens Rod - Страница 35

A project manager is generally the highest-ranking member of the project team. Ideally, this person works with the team through all stages of development, starting with requirements gathering, moving through development and testing, and continuing until application rollout (and sometimes even beyond into future versions).

The project manager monitors the project’s progress to ensure that work is heading in the right direction at an acceptable pace and meets with customers and other stakeholders to verify that the finished product meets their requirements. If the development model allows changes, the project manager ensures that changes are made and tracked in an organized manner so that they don’t get lost and don’t overwhelm the rest of the team.

A project manager doesn’t necessarily need to be an expert in the users’ field or in programming. However, both of those skills can be extremely helpful because the project manager is often the main interface between the customers and the rest of the project team.

Project manager duties include:

● Helping define the project requirements

● Tracking project tasks

● Responding to unexpected problems

● Managing risk

● Keeping users (and the executive champion) up-to-date on the project’s progress

● Providing an interface between customers and developers

● Managing resources such as time, people, budget, hardware, and software tools

● Managing delivery

MYRIAD MANAGERS

There are a lot of kinds of project managers in addition to software project managers. Construction, architecture, engineering, and other fields have project managers. Just about any activity that involves more than a few people needs someone to perform project management duties, even if that person isn’t called a project manager.

This book even has a project manager extraordinaire, Adaobi Obi Tulton; although her title is project editor. She makes sure I’m turning chapters in on time, passes chapters to various technical and copy editors, and generally guides the book during its development.

In practice, some project managers are promoted from the developer ranks, so they often have good development skills but weak project management skills. They can give useful advice to other programmers about how a particular piece of code should be written or how one subsystem should interact with another. They can provide technical leadership, but they’re not always good at recognizing and handling scheduling problems when something goes wrong.

For that reason, some larger projects divide the project manager’s duties among two or more people. One project I worked on had a person dedicated to task tracking and making sure we kept to the schedule. She had training in project management but no programming experience. If something started to slip, she immediately jumped all over the issue, figured out how much delay was required, asked about contingencies in case the task couldn’t be finished, determined whether the delay would affect other tasks, and did all the nontechnical things a project manager must handle.

That person was called the “project manager,” in contrast with the other project manager who was called the “project manager.” It got a little confusing at times. Perhaps we should have called the task-tracking person the “developer babysitter” or the “border collie” because she gently guided us toward our goals by nipping at our heels. Often people call the other manager the “technical project manager”; although, that person may also handle nontechnical tasks such as interaction with customers and executives.

Meanwhile the “main” project manager was freed up to attack the problem from the development side. He could work with the developers to figure out what was wrong and how to fix it.

When I first encountered this set up, I thought it was kind of silly. Couldn’t a single project manager handle both technical and tracking tasks? In our project, the separation actually made things easier. This may not be the right approach for every project, particularly small ones, but it was useful in our case.

If you are a project manager or want to become one, you should do a lot more reading about specific tools and techniques that are useful for keeping a project on track.

Before moving on to other topics, however, I want to cover a few more project management issues in greater detail. The next three sections describe PERT charts, the critical path method (CPM), and Gantt charts. PERT charts and CPM are generally used together but are separated here so that you can digest them in smaller pieces. Together these three tools can help you study the project’s total duration, look for potential bottlenecks, and schedule the project’s tasks.

However, you can’t understand how tasks fit into a schedule unless you know how long those tasks will take, so the last sections about project management deal with predicting task lengths and with risk management.

PERT Charts

A PERT chart (PERT stands for Program Evaluation and Review Technique) is a graph that uses nodes (circles or boxes) and links (arrows) to show the precedence relationships among the tasks in a project. For example, if you’re building a bunker for use during the upcoming zombie apocalypse, you need to build the outer defense walls before you can top them with razor wire.

PERT charts were invented in the 1950s by the United States Navy. They come in two flavors: activity on arrow (AOA), where arrows represent tasks and nodes represent milestones and activity on node (AON), where nodes represent tasks and arrows represent precedence relations. Activity on node diagrams are usually easier to build and interpret, so that’s the kind described here.

To build an AON PERT chart, start by listing the tasks that must be performed, the tasks they must follow (their predecessors), and the time you expect each task to take. (You can also add best-case and worst-case times to each task if you want to perform more extensive analysis of the tasks and what happens when things go wrong.)

Note that you don’t need to include every possible combination of predecessors. For example, suppose task C must come after task B, which must come after task A. In that case, task C must come after task A, but you don’t need to include that relationship in the table if you don’t want to. The fact that task C must come after task B is enough to represent that relationship. However, you also don’t need to remove every unnecessary relationship. Those extra relationships won’t hurt anything.

If you like, you can add a Start task as a predecessor for any other tasks that don’t have predecessors. Similarly, you can add a Finish task for any other tasks that don’t have successors.

To make rearranging tasks easy, make an index card or sticky note for each task. (You can draw the chart on a piece of paper or with a drawing tool, but index cards and sticky notes make it easy to shuffle tasks around if necessary.) Include each task’s name, predecessors, and expected time.

Then to build the chart, follow these steps:

1. Place the Start task in a Ready pile. Place the other tasks in a Pending pile.

2. Position the tasks in the Ready pile in a column to the right of any previously positioned tasks. (The first time through, the Ready pile only contains the Start task, so position it on the left side of your desk.)

3. Look through the tasks in the Pending pile and cross out the predecessors that you just positioned. (Initially that means you’ll be crossing out the Start task.) If you cross out a card’s last predecessor, move it to the Ready pile.

4. Return to step 2 and repeat until you have positioned the Finish task.

PUZZLING PREDECESSORS

If you don’t move any tasks into the Ready pile during step 3, that means the tasks have a predecessor loop. For example, task A is task B’s predecessor and task B is task A’s predecessor.

For example, at my college, you needed to pay registration fees before you could get your student ID; you needed a student ID to get financial aid checks; and you needed financial aid checks to pay registration fees. (At least, you probably do if you need financial aid.) You needed to fill out extra paperwork to break out of the predecessor loop.

After you finish positioning all of the cards, draw arrows representing the predecessor relationships. (You may want to use a dry-erase marker so that you can get the arrows off your desk later.)

At this point, you have a chart showing the possible paths of execution for the tasks in the project.

EXAMPLE Building a PERT Chart

The steps for building a PERT chart are a bit confusing, so let’s walk through an example that creates a PERT chart for a project that builds a bunker to protect you and your video games in case of a zombie apocalypse. (The U.S. Strategic Command actually developed a plan for fighting off a zombie apocalypse as part of a training exercise. You can read it at i2.cdn.turner.com/cnn/2014/images/05/16/dod.zombie.apocalypse.plan.pdf.)

Start by building a table that lists the tasks, their predecessors, and the times you expect them to take. Table 3.1 shows some of the tasks you would need to perform to build the bunker. To keep things simple, I’ve omitted a lot of details such as installing sewer lines, building forms for pouring concrete, and obtaining permits (assuming the planning officials haven’t been eaten yet).

Table 3.1 Tasks for a Zombie Apocalypse Bunker

After you’ve built the task table, create index cards for the tasks (or be prepared to draw them with a drawing tool). Figure 3.1 shows what the card for task I might look like.

Figure 3.1 Each task’s card should hold its name, duration, and predecessors. You’ll fill in the total time later.

Next, start working through the four steps described earlier to arrange the cards. This is a lot easier to understand if you go to the trouble of creating index cards or sticky notes instead of trying to imagine what they would look like. Trust me. If you found the steps confusing, make the cards.

1. Place the Start task in a Ready pile. Place the other tasks in a Pending pile.

Figure 3.2 shows the initial positions of the cards. (I’ve omitted the task names and abbreviated a bit to save space.)

Figure 3.2 Initially only the Start task is in the Ready pile.

2. Position the tasks in the Ready pile in a column to the right of any previously positioned tasks. (The first time through, the Ready pile contains only the Start task. Just position it on the left side of your desk.)

3. Look through the tasks in the Pending pile and cross out the predecessors that you just positioned. (Initially, that means you’ll be crossing out the Start task.) If you cross out a card’s last predecessor, move it to the Ready pile.

Referring to Figure 3.2, you see that tasks A, F, and H have the Start task as predecessors. In fact, the Start task is the only predecessor for those tasks, so when you cross out the Start task, you move tasks A, F, and H into the Ready pile. Figure 3.3 shows the new arrangement.

Figure 3.3 After one round, the Start task is positioned and tasks A, F, and H are in the Ready pile.

4. Return to step 2 and repeat until you have positioned the Finish task.

To do that, position tasks A, F, and H because they’re in the Ready pile. Then cross them out for any tasks that are still in the Pending pile. When you cross out those tasks, task B loses its last predecessor so move it into the Ready pile. Figure 3.4 shows the new arrangement.

Figure 3.4 After two rounds, the Start task and tasks A, F, and H are positioned. Task B is in the Ready pile.

5. Return to step 2 and repeat until you have positioned the Finish task.

This time position task B and remove it from the remaining tasks’ predecessor lists. After you cross task B off, tasks C and I have no more predecessors so move them to the Ready pile. Figure 3.5 shows the new arrangement.

Figure 3.5 After three rounds, the Start task and tasks A, F, H, and B are positioned. Tasks C and I are in the Ready pile.

By now you probably have the hang of it. Position tasks C and I, and remove them from the Pending tasks’ predecessor lists. That removes the last predecessors from tasks D, E, and G, so move them to the ready pile, as shown in Figure 3.6.

Figure 3.6 After four rounds, only the Finish task is still in the Pending pile.

In the next round, position tasks D, E, and G, and move the Finish task to the Ready pile. Then one final round positions the Finish task.

Now draw arrows showing the predecessor relationships between the tasks. You may need to adjust the spacing and vertical alignment of the tasks to make the arrows look nice. Figure 3.7 shows the final result.

Figure 3.7 This PERT chart shows the paths of execution of the project’s tasks.

To check your work, you can verify that each task has one arrow entering it for each of its predecessors. For example, task G has two predecessors, so it should have two arrows entering it.

Critical Path Methods

PERT charts are often used with the critical path method, which was also invented in the 1950s. That method lets you find critical paths through the network formed by a PERT chart.