Applied Software Project Management

Applied Software Project Management

by Andrew Stellman, Jennifer Greene
Released November 2005
Publisher(s): O'Reilly Media, Inc.
ISBN: 9780596553821

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Book description

"If you're looking for solid, easy-to-follow advice on estimation, requirements gathering, managing change, and more, you can stop now: this is the book for you."--Scott Berkun, Author of The Art of Project Management

What makes software projects succeed? It takes more than a good idea and a team of talented programmers. A project manager needs to know how to guide the team through the entire software project. There are common pitfalls that plague all software projects and rookie mistakes that are made repeatedly--sometimes by the same people! Avoiding these pitfalls is not hard, but it is not necessarily intuitive. Luckily, there are tried and true techniques that can help any project manager.

In Applied Software Project Management, Andrew Stellman and Jennifer Greene provide you with tools, techniques, and practices that you can use on your own projects right away. This book supplies you with the information you need to diagnose your team's situation and presents practical advice to help you achieve your goal of building better software.

Topics include:

  • Planning a software project
  • Helping a team estimate its workload
  • Building a schedule
  • Gathering software requirements and creating use cases
  • Improving programming with refactoring, unit testing, and version control
  • Managing an outsourced project
  • Testing software

Jennifer Greene and Andrew Stellman have been building software together since 1998. Andrew comes from a programming background and has managed teams of requirements analysts, designers, and developers. Jennifer has a testing background and has managed teams of architects, developers, and testers. She has led multiple large-scale outsourced projects. Between the two of them, they have managed every aspect of software development. They have worked in a wide range of industries, including finance, telecommunications, media, nonprofit, entertainment, natural-language processing, science, and academia. For more information about them and this book, visit stellman-greene.com

Table of contents

  1. Applied Software Project Management
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. About the Author
    3. Praise for Applied Software Project Management
    4. Preface
      1. Goals of the Book
      2. Who Should Read This Book
      3. Comments and Questions
      4. Safari Enabled
      5. Acknowledgments
    5. 1. Introduction
      1. 1.1. Tell Everyone the Truth All the Time
      2. 1.2. Trust Your Team
      3. 1.3. Review Everything, Test Everything
      4. 1.4. All Software Engineers Are Created Equal
      5. 1.5. Doing the Project Right Is Most Efficient
      6. 1.6. Part I: Tools and Techniques
      7. 1.7. Part II: Using Project Management Effectively
    6. I. Tools and Techniques
      1. 2. Software Project Planning
        1. 2.1. Understand the Project Needs
          1. 2.1.1. Drive the Scope of the Project
          2. 2.1.2. Talk to the Main Stakeholder
          3. 2.1.3. Write the Vision and Scope Document
            1. 2.1.3.1. Review the vision and scope document
        2. 2.2. Create the Project Plan
          1. 2.2.1. Statement of Work
          2. 2.2.2. Resource List
          3. 2.2.3. Estimates and Project Schedule
          4. 2.2.4. Risk Plan
            1. 2.2.4.1. Brainstorm potential risks
            2. 2.2.4.2. Estimate the impact of each risk
            3. 2.2.4.3. Make a mitigation plan
          5. 2.2.5. Project Plan Inspection Checklist
        3. 2.3. Diagnosing Project Planning Problems
          1. 2.3.1. Lack of Leadership
          2. 2.3.2. The Mid-Course Correction
          3. 2.3.3. The Detached Engineering Team
      2. 3. Estimation
        1. 3.1. Elements of a Successful Estimate
          1. 3.1.1. Assumptions Make Estimates More Accurate
          2. 3.1.2. Distrust Can Undermine Estimates
        2. 3.2. Wideband Delphi Estimation
          1. 3.2.1. The Delphi Process
            1. 3.2.1.1. Choosing the team
            2. 3.2.1.2. Kickoff meeting
            3. 3.2.1.3. Individual preparation
            4. 3.2.1.4. Estimation session
            5. 3.2.1.5. Assemble tasks
            6. 3.2.1.6. Review results
        3. 3.3. Other Estimation Techniques
          1. 3.3.1. PROBE
          2. 3.3.2. COCOMO II
          3. 3.3.3. The Planning Game
        4. 3.4. Diagnosing Estimation Problems
          1. 3.4.1. Padded Estimates Generate Distrust
          2. 3.4.2. Self-Fulfilling Prophecy
      3. 4. Project Schedules
        1. 4.1. Building the Project Schedule
          1. 4.1.1. Allocate Resources to the Tasks
          2. 4.1.2. Identify Dependencies
          3. 4.1.3. Create the Schedule
          4. 4.1.4. Reconcile the Schedule with the Organization's Needs
          5. 4.1.5. Add Review Meetings to the Schedule
          6. 4.1.6. Optimize the Schedule
          7. 4.1.7. Don't Abuse Buffers
          8. 4.1.8. Track the Performance of the Project
        2. 4.2. Managing Multiple Projects
          1. 4.2.1. Understand Dependencies Between Projects
          2. 4.2.2. Prioritize Projects Realistically
        3. 4.3. Use the Schedule to Manage Commitments
        4. 4.4. Diagnosing Scheduling Problems
          1. 4.4.1. Working Backward From a Deadline
          2. 4.4.2. Misunderstood Predecessors
      4. 5. Reviews
        1. 5.1. Inspections
          1. 5.1.1. Choose the Inspection Team
          2. 5.1.2. Select a Moderator
          3. 5.1.3. Inspect the Work Product
          4. 5.1.4. Manage the Author's Expectations
          5. 5.1.5. Help Others in the Organization Accept Inspections
            1. 5.1.5.1. "Inspections take too long."
            2. 5.1.5.2. "I don't like people criticizing my work."
            3. 5.1.5.3. "I built it, and only I can say when it's done."
        2. 5.2. Deskchecks
        3. 5.3. Walkthroughs
        4. 5.4. Code Reviews
          1. 5.4.1. Select the Code Sample
          2. 5.4.2. Hold the Review Session
          3. 5.4.3. Code Review Checklist
        5. 5.5. Pair Programming
        6. 5.6. Use Inspections to Manage Commitments
        7. 5.7. Diagnosing Review Problems
          1. 5.7.1. Problems Are Found Too Late
          2. 5.7.2. Big, Useless Meetings
          3. 5.7.3. The Indispensable "Hero"
      5. 6. Software Requirements
        1. 6.1. Requirements Elicitation
          1. 6.1.1. Conduct Interviews
          2. 6.1.2. Observe Users at Work
          3. 6.1.3. Use a Discussion Summary
        2. 6.2. Use Cases
          1. 6.2.1. Name, Summary, Rationale, and Users
          2. 6.2.2. Preconditions and Postconditions
          3. 6.2.3. Basic Course of Events
          4. 6.2.4. Alternative Paths
          5. 6.2.5. Develop Use Cases Iteratively
        3. 6.3. Software Requirements Specification
          1. 6.3.1. SRS Template
            1. 6.3.1.1. Functional requirements
            2. 6.3.1.2. Nonfunctional requirements
          2. 6.3.2. Develop the SRS Iteratively
          3. 6.3.3. Requirements Differ from Design
          4. 6.3.4. SRS Inspection Checklist
        4. 6.4. Change Control
          1. 6.4.1. Establish a Change Control Board
          2. 6.4.2. Change Control Process
          3. 6.4.3. Evaluate Changes in the CCB Meeting
          4. 6.4.4. Analyze the Impact of Each Change
        5. 6.5. Introduce Software Requirements Carefully
          1. 6.5.1. Sell the Designers and Programmers First
          2. 6.5.2. Speak the Managers' Language
        6. 6.6. Diagnosing Software Requirements Problems
          1. 6.6.1. Iteration Abuse
          2. 6.6.2. Scope Creep
      6. 7. Design and Programming
        1. 7.1. Review the Design
        2. 7.2. Version Control with Subversion
          1. 7.2.1. Multiple People Can Work on One File
          2. 7.2.2. Understanding Subversion
          3. 7.2.3. Check Out Code into a Working Copy
          4. 7.2.4. Access the Subversion Repository Using a URL
          5. 7.2.5. Create a Repository
          6. 7.2.6. Share the Repository
          7. 7.2.7. The Subversion Basic Work Cycle
            1. 7.2.7.1. Update the working copy of the code
            2. 7.2.7.2. Make changes to the code
            3. 7.2.7.3. Examine all changes
            4. 7.2.7.4. Merge any changes made since the working copy was checked out
            5. 7.2.7.5. Commit the changes
        3. 7.3. Refactoring
          1. 7.3.1. Refactoring Example
          2. 7.3.2. Refactoring Pays for Itself
        4. 7.4. Unit Testing
          1. 7.4.1. Test All of the Code, Test All of the Possibilities
          2. 7.4.2. JUnit
          3. 7.4.3. Unit Testing Example
          4. 7.4.4. Test-Driven Development
          5. 7.4.5. Everyone Is Responsible for Quality
          6. 7.4.6. Unit Testing Saves Programming Time and Effort
        5. 7.5. Use Automation
        6. 7.6. Be Careful with Existing Projects
        7. 7.7. Diagnosing Design and Programming Problems
          1. 7.7.1. Haunted by Ghosts of Old Problems
          2. 7.7.2. Broken Builds
          3. 7.7.3. Spaghetti Code
      7. 8. Software Testing
        1. 8.1. Test Plans and Test Cases
          1. 8.1.1. Inspection Checklist
        2. 8.2. Test Execution
        3. 8.3. Defect Tracking and Triage
        4. 8.4. Test Environment and Performance Testing
        5. 8.5. Smoke Tests
        6. 8.6. Test Automation
        7. 8.7. Postmortem Reports
        8. 8.8. Using Software Testing Effectively
          1. 8.8.1. Understand What Testers Do
          2. 8.8.2. Divide Quality Tasks Efficiently
          3. 8.8.3. Manage Time Pressure
          4. 8.8.4. Gather Metrics
        9. 8.9. Diagnosing Software Testing Problems
          1. 8.9.1. Requirements Haven't Been Implemented
          2. 8.9.2. Obvious Bugs Slip Through
          3. 8.9.3. "But It Worked For Us!"
    7. II. Using Project Management Effectively
      1. 9. Understanding Change
        1. 9.1. Why Change Fails
          1. 9.1.1. Change Is Uncomfortable
          2. 9.1.2. We Already Build Software Well
          3. 9.1.3. "Not Invented Here" Syndrome
          4. 9.1.4. It's "Too Theoretical"
          5. 9.1.5. It Just Adds More Bureaucracy
          6. 9.1.6. You Can't Give Me More Work!
          7. 9.1.7. It's Too Risky
        2. 9.2. How to Make Change Succeed
          1. 9.2.1. Prepare Your Organization
            1. 9.2.1.1. "We've always done it like this"
            2. 9.2.1.2. Be positive about the work that's already being done
            3. 9.2.1.3. Take credit for the changes
            4. 9.2.1.4. Make the changes seem straightforward
            5. 9.2.1.5. Build support from the team
            6. 9.2.1.6. Show that the changes will save time and effort
            7. 9.2.1.7. Work around stragglers
            8. 9.2.1.8. Stick to the facts
          2. 9.2.2. Plan for Change
            1. 9.2.2.1. Create a vision and scope document
            2. 9.2.2.2. Inspect the vision and scope document
            3. 9.2.2.3. Schedule the changes
          3. 9.2.3. Push for Consensus
          4. 9.2.4. Use a Pilot Project to Build a Track Record
          5. 9.2.5. Measure Your Progress
            1. 9.2.5.1. Measuring cost
            2. 9.2.5.2. Measuring quality
          6. 9.2.6. Bring In an Expert
      2. 10. Management and Leadership
        1. 10.1. Take Responsibility
          1. 10.1.1. Ensure That You Have Authority to Do the Project
          2. 10.1.2. You Are Accountable for the Project's Success
          3. 10.1.3. Grant Authority and Accountability to Team Members
          4. 10.1.4. Defend Your Project Against Challenges to Your Authority
        2. 10.2. Do Everything Out in the Open
          1. 10.2.1. Publish Your Work Products
          2. 10.2.2. Make Decisions Based on Known Guidelines
        3. 10.3. Manage the Organization
          1. 10.3.1. Senior Managers See Software Projects as a Cost Burden
          2. 10.3.2. Show Senior Managers the Impact of Their Decisions
          3. 10.3.3. Don't Confuse Flexibility with Always Saying Yes
            1. 10.3.3.1. Don't agree to an unrealistic schedule
            2. 10.3.3.2. Change your approach when necessary
            3. 10.3.3.3. Don't confuse "easy to describe" with "easy to implement"
        4. 10.4. Manage Your Team
          1. 10.4.1. Avoid Common Management Pitfalls
            1. 10.4.1.1. Don't manage from your gut
            2. 10.4.1.2. Don't second-guess estimates
            3. 10.4.1.3. Don't expect consensus all of the time
            4. 10.4.1.4. Avoid micromanagement
            5. 10.4.1.5. Make your mistakes public
            6. 10.4.1.6. Avoid lists
          2. 10.4.2. Accept Criticism
          3. 10.4.3. Understand What Motivates Your Team Members
          4. 10.4.4. Don't Be Thrown by Dishonesty
          5. 10.4.5. Address Performance Problems Early
      3. 11. Managing an Outsourced Project
        1. 11.1. Prevent Major Sources of Project Failure
          1. 11.1.1. Get Involved
          2. 11.1.2. Constantly Communicate Project Goals
          3. 11.1.3. Make Sure the Project Is Estimated Well
        2. 11.2. Management Issues in Outsourced Projects
          1. 11.2.1. Actively Manage Your Project
          2. 11.2.2. Share Information with Your Management
          3. 11.2.3. Build a Relationship with the Vendor's Management
          4. 11.2.4. Build a Relationship with Your Team
        3. 11.3. Collaborate with the Vendor
          1. 11.3.1. Plan and Manage the Project Scope
          2. 11.3.2. Do Your Own Estimation
          3. 11.3.3. Maintain Your Own Project Schedule
          4. 11.3.4. Hold Reviews and Inspections
          5. 11.3.5. Maintain Control of Design and Programming
          6. 11.3.6. Take Responsibility for Quality
      4. 12. Process Improvement
        1. 12.1. Life Without a Software Process
          1. 12.1.1. Teams Can Be Effective Without a Formal Process
          2. 12.1.2. Lack of Process Maturity Is Not "Immature"
          3. 12.1.3. If Things Are So Great, Why Change?
        2. 12.2. Software Process Improvement
          1. 12.2.1. Models and Certifications
            1. 12.2.1.1. The Capability Maturity Model
            2. 12.2.1.2. ISO 9000
            3. 12.2.1.3. Six Sigma
          2. 12.2.2. Processes and Methodologies
            1. 12.2.2.1. Extreme Programming
            2. 12.2.2.2. Rational Unified Process
        3. 12.3. Moving Forward
      5. A. Bibliography
        1. Chapter 2. Software Project Planning
        2. Chapter 3. Estimation
        3. Chapter 4. Project Schedules
        4. Chapter 5. Reviews
        5. Chapter 6. Software Requirements
        6. Chapter 7. Design and Programming
        7. Chapter 8. Software Testing
        8. Chapter 9. Understanding Change
        9. Chapter 10. Management and Leadership
        10. Chapter 11. Managing an Outsourced Project
        11. Chapter 12. Process Improvement
    8. Index
    9. About the Authors
    10. Colophon
    11. SPECIAL OFFER: Upgrade this ebook with O’Reilly

Product information

  • Title: Applied Software Project Management
  • Author(s): Andrew Stellman, Jennifer Greene
  • Release date: November 2005
  • Publisher(s): O'Reilly Media, Inc.
  • ISBN: 9780596553821