Applied Software Project Management

Spis treści książki

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

pokaż cały spis treści

ukryj recenzje