Training
Certifications
Books
Special Offers
Community




 
Under Pressure and On Time
Author Ed Sullivan
Pages 304
Disk N/A
Level Intermediate
Published 04/04/2001
ISBN 9780735611849
ISBN-10 0-7356-1184-X
Price(USD) $29.99
To see this book's discounted price, select a reseller below.
 

More Information

About the Book
Table of Contents
Sample Chapter
Index
Related Series
Related Books
About the Author

Support: Book & CD

Rate this book
Barnes Noble Amazon Quantum Books

 


Chapter 11: Scheduling continued


Building a Great Schedule

Now that I’ve covered the basic scheduling concepts, let’s focus on the details of building a great software schedule. The process has three basic steps: defining the tasks, grouping them into base levels, and grouping the base levels into project milestones.

Later in this chapter I’ll provide an example of a typical schedule that describes the basic project structure you need to manage. As you will see, however, the goal is not to micromanage every detail of the project. You can’t possibly know what someone will be doing on a specific date six months from now. Instead, you want a schedule that enumerates a set of well-defined deliverables that occur regularly throughout the development cycle. With this in place, you can manage the team toward each deliverable and mark and measure your progress with certainty.

Tasks

Your first step is to define all the tasks required to implement a specific feature. The total time it takes to complete these tasks is the time it will take to complete the feature. Schedule the features from the list of must-have requirements first and then move to the should-haves and could-haves. This method will help you achieve a viable release as soon as possible.

After that, schedule the QA, user education, UI, and release engineering teams’ tasks. Each team will have their own set of work items based on their own project deliverables, and those tasks should be organized so they integrate with or follow closely behind the implementation of the features by the software engineers.

Base Levels

Base levels define the delivery date for a group of related features. They should occur every two to three weeks. Remember, these features must be both available through the installation procedure and usable by the development team. Base levels are important short-term objectives to focus the team’s attention and effort. To a large extent, nothing matters more than completing the next base level on time. If you don’t hit the next base level, your project is officially behind schedule and you need to take corrective action immediately. The following are some sample base levels (from NuMega’s error detection product, BoundsChecker):

  • A source code library and nightly build are established, and a bare bones installation procedure is completed.
  • The product hooks and logs basic memory functions.
  • The product displays first memory error message using the UI prototype.
  • The product successfully detects memory leak types 1 and 2.
  • The product successfully detects memory leak types 3 and 4.
  • The product successfully detects memory leak types 5 and 6.
  • The product’s real UI appears, but without print, sort, and filter support.
  • Print, sort, and filter support is complete.
  • The product integrates with other products in the suite.

Intermediate Milestones

A milestone is a group of base levels that represent the completion of a significant portion of the product. They should be evenly divided across the duration of the project. For example, if you defined four milestones for your project, each one would represent 25 percent completion. Obviously, the more complex the project, the more frequent your milestones.

Each milestone should have a stabilization and integration period, as discussed in Chapter 6. To review, this is a period of time, usually one to two weeks, during which the entire team focuses on addressing issues that have surfaced in the features that have already been implemented. These periods —during which testing is done, bugs are fixed, design and integration issues are addressed, and performance is evaluated—are critical to the project because they allow the software to stabilize. Do not move forward into new feature development until you’re certain that the current features are functioning well. In addition, stabilization periods are also a great time to catch up on any work that has been delayed. This period offers the team a time for individuals or sub-teams to catch up with the rest of the team and get back in sync.

External Milestones

External milestones involve people or teams outside the project and mark critical points in the project. The most common external milestones include:

  • Alpha release  This is a release with only a few critical features implemented. Alpha releases are not widely used, but they can be beneficial if you need to show progress or get feedback on critical features externally.
  • Beta release  This is a release with most, if not all, of the features implemented. Beta releases are given to customers for testing and evaluation.
  • Release candidate (RC)  This is a release you intend to send to manufacturing if testing is completed successfully. Release candidates are a signal that the project is nearly done and its release is imminent.
  • Release to manufacturing date (RTM)  This is the date on which the production release will be sent to manufacturing (or posted to the Web, whatever the case might be).

Each external milestone requires the software to be distributed to people outside the team and even outside the company. Because of the importance of these events, you should have a stabilization period before each milestone. This allows your team to focus on quality, integration, and important fit and finish issues before the product is released. The beta release and release candidate are critically important and will be discussed in detail in Chapters 13 and 14.

An Example

To make sure you’ve understood the basics, let’s walk through a detailed example, shown in Table 11-1 on page 184. Although I’ve simplified the project and eliminated information that would normally be included, this example should be detailed enough to show you how everything fits together. The following are the basic scheduling assumptions for this example.

  • Scheduling principles
    • Each feature has a list of engineering tasks associated with it. They are not shown in the example but could be easily listed in the document. A single task can’t be any longer than two weeks; most should be one week or less. Must-have features are done first, based on requirement prioritization, and the less important features are done later.
    • QA tests the features as soon as they are delivered by development. Some features will have automation, but all other features will be manually tested. The details of testing activities are described in a QA plan.
    • User education documents features as soon as they are delivered. The documentation effort follows the features delivery as much as possible. The details of this effort are described in a user education plan.
    • Human factors evaluates each UI feature implementation as soon as it’s completed, consults on changes, and reviews the product experience as the project is developed. The details of this effort are described in the human factors plan.
    • Release engineering will create a simple build and installation procedure immediately, and then increase the features and robustness of the build and installation procedure regularly over the course of the release. They also support the inclusion of a new feature when it is ready. These specific feature and capability improvements will be described in the release- engineering plan.

  • Personnel
    • Matt: dev lead and full time developer
    • John: software engineer
    • Jim: QA lead; also writes automation
    • Frank: QA specialist; executes the automation and manual tests features
    • Sarah: user education lead
    • Kenny: human factors lead
    • Bob: release engineering lead

  • Milestones, internal and external
    • There will be four bi-monthly base levels, two major milestones, two betas, one RC period, and one RTM.
    • Every two base levels will form a milestone. Milestone 1 will represent half the project’s completion; Milestone 2 will represent the other half.
    • Table 11-1   A Sample Schedule

      DateGoalDev Team QA Team 
        MattJohnJimFrank
      Jan 01 (White space indicates work has started on next task.)   
      Jan 08Base level 1F1F2A1T2
      Jan 15     
      Jan 22Base level 2F3F4A3T4
      Jan 29 F5   
      Feb 05Milestone 1Integration and stabilization period   
      Feb 12  F6 T6
      Feb 19Base level 3F7 A7 
      Feb 26     
      Mar 05Base level 4F8F9A8T9
      Mar 12     
      Mar 19Milestone 2Integration and stabilization period   
      Mar 26     
      Apr 02Base level 5F10F11A10T11
      Apr 09 F12F13A12T13
      Apr 16Beta 1 prepTest for beta 1 readiness.   
      Apr 23
      May 21
      Beta 1F14, F15. Fix, tune, and make minor enhancements. A14, A15. Improve automation and test according to QA plan. 
      May 21Beta 2 prepTest for beta 2 readiness.    
      May 28
      to Jun 25
      Beta 2Bug fix. Tune. Make minor enhancements. Improve automation and test according to QA test plan. 
      Jul 02RCExecute release candidate process.   
      Jul 16RTMProject closure   

      # (Number) = Feature identification number

      F = Feature is coded and unit tested, all engineering tasks associated with it are complete.

      A = Feature has test automation

      User Ed TeamUsability TeamRelease Engineering Team
      SarahKennyBob
        Complete simple builds and install
      D1U1 
      D2U2 
      D3U3, U4 
      D4, D5U5Better build and install according to release engineering plan
         
      D6  
       U7 
      D7  
      D8, D9U8, U9 
      Vacation Great build and install according to release engineering plan
         
         
      D10, D11U10, U11  
      D12, D13U12, U13Full featured install
         
      Document activities according to doc planFinal review: external testing, OOTB evaluation 
         
      Document activities according to doc planVisual freezeFinal install
         
         

      T = Feature has been maually tested

      D = Feature has been documented

      U = Feature has had its usability review

    • Beta 1 will be one month long. Features F14 and F15 will be added during beta 1, but the rest of the time will be spent on testing, tuning, and fixing bugs. Each team member has a specific list of activities during the beta 1 time period.
    • Beta 2 will have no new features. No major feature changes are allowed—just testing, tuning, and bug fixing. There is a specific list of activities for each team member during this time period.

  • Release candidate
    • A release candidate will be built at the end of beta 2 if testing has been completed without major problems.

  • Status meetings
    • A meeting will be scheduled every Monday to review progress. If a base level is not completed on time (or it appears that it won’t be), changes required to get the project back on schedule will be made.

Beta Testing Additions

In the example, you’ll notice that two tasks are scheduled for delivery during the first beta period. Although you want to refrain from adding features—particularly important or complex features—during any beta period, it sometimes makes sense to schedule a set of low-cost and relatively low-risk features for the first beta. The longer you delay putting your product in the hands of your beta customers, the longer it will take to receive feedback on the quality and the implementation of your features. The benefits of sending your product through a beta cycle earlier can often outweigh the risks of adding minor features after the beta program has started.

Although adding a few features into the first beta period is sometimes acceptable, no new features should be scheduled for the last beta period. The final beta period is a time in which features are locked down and the team focuses on quality, performance, and fit and finish problems. Beta testing will be covered in detail in Chapter 13.

Unexpected Problems

If you have created a schedule using the principles in this chapter, you probably have planned your project as well as anyone could. However, software development is an imperfect science and problems are always nearby. You’ll need to check your project’s progress against your schedule regularly and compare your actual progress against each base level and milestone to see if you’re on track. If you’re off schedule you’ll need to identify the problem, update the schedule, and hit your next base level or milestone. Sound simple? It’s not—and this is where the project manager and the leads need to be on top of their game. Due to the complexity of keeping a project on schedule, I’ve devoted most of Part III to the subject.


Previous   |  Table of Contents   |   Next




Top of Page


Last Updated: Saturday, July 7, 2001