The coding pipeline

The pragmatic view of mid-game work focuses on programmers writing code. The only way the project moves forward is with each line of code written that brings the project closer to completion (pet features, unneeded optimizations, etc., do not move the project forward). All of the planning and design effort that takes place before programmers write code, whether done by them or by others, is done to create an efficient sequence of work for them to do while the clock is ticking. This is called the coding pipeline.

It's the PM's job to make sure the coding pipeline is running smoothly. While programmers might own the management of the pipeline and decide who works on what, (3) it's still the PM's responsibility to make sure that the programming team has as much support as necessary to make it work. This may involve gopher tasks, organizing meetings, nagging various people to finalize decisions, or, in some cases, resolving the remaining design issues (4) (see Figure 14-4). The PM may have to work a few days in front of the programmer, finalizing designs and feeding the pipeline. If a PM is responsible for the work of several developers, she will have to carefully prioritize her time to ensure she can juggle the competing demands of multiple pipelines (another reason why the lead programmer should be doing some or more of this work).

Figure 14-4. The final details of a spec/design can be verified or finalized in parallel by the PM or designer. This contributes to the value of the coding pipeline.

Figure 14-4. The final details of a spec/design can be verified or finalized in parallel by the PM or designer. This contributes to the value of the coding pipeline.

In Web Project Management: Delivering Successful Commercial Web Sites (Morgan Kaufmann, 2001), author Ashley Friedlein calls this process briefing the team, and the details for the next piece of work they are to do is called a brief. As Friedlein writes, "To maximize efficiency and speed of development, your briefs need to be created so that they are always ahead of where the work is at the moment. As soon as a piece of work is finished, you have the brief for the next section of work ready." These briefs are derived from the specs (if still relevant), but include anything new or changed that the programmer might need to know. Without actively briefing programmers during mid-game, there can be any number of things that block a work item and slow down the pipeline: usability issues, visual design work, work items done by other programmers, marketing issues, technical problems, or external dependencies. Because PMs often have the most diverse set of skills, they're the best people to run point for the coding pipeline, flagging or resolving issues, and smoothing things out before the programmer starts on them. (This includes seeking out frustrated programmers who are blocked, but either won't admit it or haven't realized it yet.)

Four questions define how to do this well:

• What work items are actively being coded? Are there any issues blocking programmers from completing their currently active work items? If so, eliminate them (the blocking issues, not the work items). This is a red-alert state for a project. If a programmer is blocked from actively writing code, the project is stalled. Nothing is more important than resolving an issue that blocks a programmer. Simply ask them, "How can I help you resolve this?" They'll let you know if you can help. If the blocking issue is a dependency (e.g., Fred has to finish work item 6 before Bob can start on work item 7), consider what other work a programmer can do until that block is removed.

• Does the programmer know and understand everything needed to implement the current work item to specification? There are always questions and gaps that arise only at the moment of implementation. Some programmers are more proactive than others about resolving these gaps in a mature fashion. The PM or designer needs to be available and involved enough to help identify and close these gaps. Sometimes, they can be anticipatedfor example, were all the issues raised in the spec review for this work item resolved?

• What is the next set of items that will be coded? This is where real pipeline management begins: staying one step ahead of programmers (see Figure 14-4). If the currently active work items are in good shape, the focus moves to the next items up the pipeline. The next items should tend to be the next most important piece of work for the project. Always try to do the most critical work first, even if it's the hardest. For each item in the pipeline, consider what open issues they have that might slow or stall the programmer when the item arrives on his plate. Find and resolve them.

• Was the last work item that was completed, really completed? It's the output of the coding pipeline that matters. Someone has to be looking at the effect of check-ins on the build and make sure it does what it's supposed to do from the customer perspective. Did the completion of that last work item truly add the functionality and behavior required? Does the test team agree? Did all unit tests pass? Did someone at least open bugs to track what's missing? Daily builds (described in the next chapter) are an easy way to track this because you can always experience the current state of the projectand find gaps in what was completedto what is needed. The bigger the work item, the more important this is.

Some programmers take more responsibility for their coding pipelines than others. Many programmers will more aggressively seek out certain kinds of issues (technical) and tend to ignore or delay on others (business, political). Part of your relationship with each programmer is knowing how much involvement you need to take on in managing their pipeline. It doesn't matter so much who does it, as long as it's done, and someone is actively verifying and protecting the quality of those work items. (This is a role discussion, as described in Chapter 9.)

Understanding SEO Help People Find Your Business

Understanding SEO Help People Find Your Business

So what does SEO stand for and what does it do for your offline business? Search Engine Optimization is the official title and you can see why it is commonly abbreviated. If you are wondering about SEO then you either have a new website or are considering setting one up. SEO comes in to play once your site is live on the web. After all you now have to get visitors to actually see your site. In SEO terms attracting visitors is known as generating traffic and this can be achieved by using search engine optimization tactics.

Get My Free Ebook


Post a comment