Building Software Teams

Table of contents

1. Preface
   1. The Topic of This Book
   2. Why You Should Read This Book
   3. Who Should Read This Book
   4. What You Need to Know to Read This Book
   5. What This Book Is Not
   6. About the Software Improvement Group (SIG)
   7. Related Books
   8. Conventions Used in This Book
   9. O’Reilly Safari
   10. How to Contact Us
   11. Acknowledgments
2. 1. Introduction
   1. Software Development as an Observable Process
   2. Software Quality According to the ISO 25010 Standard
      1. Software Product Quality in ISO 25010
   3. The Contribution of Each Developer Matters
   4. Measuring and Benchmarking Development Process Maturity
   5. The Goal-Question-Metric Approach
   6. An Overview of the Development Best Practices in This Book
3. 2. Derive Metrics from Your Measurement Goals
   1. Motivation
   2. How to Apply the Best Practice
      1. Goal
      2. Question
      3. Metric
   3. Make Assumptions about Your Metrics Explicit
      1. Find Explanations Instead of Judgments When Metrics Deviate from Expectations
      2. Using Norms with the GQM Approach
   4. Common Objections to GQM
      1. Objection: Yes, Good Metric, but We Cannot Measure This
4. 3. Make Definition of Done Explicit
   1. Motivation
      1. With a DoD You Can Track Progress and Prove Success
      2. A DoD Focuses on Software Quality
   2. How to Apply the Best Practice
   3. Common Objections to Using Definition of Done
      1. Objection: DoD Is Too Much Overhead
      2. Objection: DoD Makes the Team Feel Less Responsible
      3. Objection: With DoD There Is No Room for Technical Maintenance
      4. Objection: Changing the DoD May Mean Extra Work
5. 4. Control Code Versions and Development Branches
   1. Motivation
      1. Tracking Changes
      2. Version Control Allows Independent Modification
      3. Version Control Allows Automatic Merging of Versions
   2. How to Apply the Best Practice
      1. Commit Specifically and Regularly
      2. Integrate Your Code Regularly
   3. Controlling Versions in Practice
   4. Common Objections to Version Control Metrics
      1. Objection: We Use Different Version Control Systems
      2. Objection: Measuring the Recommendations Is Unfeasible (for Example, Whether Commits Are Specific)
   5. Metrics Overview
6. 5. Control Development, Test, Acceptance, and Production Environments
   1. Motivation
      1. Controlled DTAP Clarifies Responsibilities Between Development Phases
      2. Controlled DTAP Allows for Good Predictions
      3. Controlled DTAP Reveals Development Bottlenecks and Explains Problems More Easily
      4. Controlled DTAP Reduces Dependence on Key Personnel
   2. How to Apply the Best Practice
   3. Measuring the DTAP Street in Practice
   4. Common Objections to DTAP Control Metrics
      1. Objection: A Controlled DTAP Street Is Slow
      2. Objection: There Is No Need to Distinguish Test and Acceptance Environments
   5. Metrics Overview
7. 6. Automate Tests
   1. Motivation
      1. Automated Testing Finds Root Causes of Bugs Earlier with Little Effort
      2. Automated Testing Reduces the Number of Bugs
   2. How to Apply the Best Practice
   3. Managing Test Automation in Practice
      1. Assumptions Regarding These Metrics
   4. Common Objections to Test Automation Metrics
      1. Objection: Failing Tests Have No Noticeable Effects
      2. Objection: Why Invest Effort in Writing Unit Tests for Code That Is Already Working?
   5. Metrics Overview
8. 7. Use Continuous Integration
   1. Motivation
      1. CI Is Efficient
      2. CI Gives Feedback Quickly and Thereby Speeds Up Bug Fixing
      3. CI Is More Reliable Than Manual Merging
      4. CI Facilitates Further Automation
   2. How to Apply the Best Practice
      1. Additions to the CI Server
      2. Important Best Practices for CI
   3. Controlling Continuous Integration
   4. Common Objections to Continuous Integration Metrics
      1. Objection: We Cannot Get Control Over Our Build Time
      2. Objection: My Colleague Broke the Build, Not Me
   5. Metrics Overview
9. 8. Automate Deployment
   1. Motivation
      1. Automated Deployment Is Reliable
      2. Automated Deployment Is Fast and Efficient
      3. Automated Deployment Is Flexible
      4. Automated Deployment Simplifies Root Cause Analysis
   2. How to Apply the Best Practice
   3. Measuring the Deployment Process
   4. Common Objections to Deployment Automation Metrics
      1. Objection: Single Platform Deployment Does Not Need Automation
      2. Objection: Time Spent on Fixing Deployment Issues Is Increasing
      3. Objection: We Are Not Allowed to Deploy in Production By Ourselves
      4. Objection: No Need to Automate Because of Infrequent Releases
      5. Objection: Automating Deployment Is Too Costly
   5. Metrics Overview
10. 9. Standardize the Development Environment
    1. Motivation
       1. Development Standards Lead to Predictable Software Development
       2. Development Standards Help Enforce Best Practices
       3. Development Standards Simplify Both the Development Process and Code
       4. Development Standards Decrease Discussion Overhead
    2. How to Apply the Best Practice
       1. Standardize Tooling and Technologies—and Document It
       2. Considerations for Combinations of Technologies
       3. Defining Process Standards
       4. Coding Style
       5. Code Quality Control
    3. Controlling Standards Using GQM
    4. Common Objections to Standardization
       1. Objection: We Cannot Work Like This!
       2. Objection: Can You Standardize on Multiple Technologies?
       3. Objection: Organization Unfit for Standardization
    5. Metrics Overview
11. 10. Manage Usage of Third-Party Code
    1. Motivation
       1. Using Third-Party Code Saves Time and Effort
       2. Third-Party Code Has at Least Base-Level Quality
       3. Managing Usage of Third-Party Code Makes a System’s Behavior More Predictable
    2. How to Apply the Best Practice
       1. Determine the Specific Maintainability Advantages of Using an External Codebase
       2. Keep Third-Party Code Up-to-Date
       3. Ensure Quick Response to Dependency Updates
       4. Do Not Let Developers Change Library Source Code
       5. Manage the Usage and Versions of Libraries and Frameworks Centrally
    3. Measuring Your Dependency Management
    4. Common Objections to Third-Party Code Metrics
       1. Objection: Safety and Dependability of Third-Party Libraries
       2. Objection: We Cannot Update a Particular Library
       3. Objection: Does Third-Party Code Actually Lead to Maintenance Benefits?
    5. Metrics Overview
12. 11. Document Just Enough
    1. Motivation
       1. Documentation Retains Knowledge and Helps to Avoid Discussion
       2. Documentation Helps You to Know Whether You Are Reaching Your Goals
    2. How to Apply the Best Practice
       1. Keep Documentation Current, Concise, and Accessible
       2. Required Elements of System Documentation
    3. Managing Your Documentation
    4. Common Objections to Documentation
       1. Objection: No Time to Write Documentation
       2. Objection: Disagreement in the Team
       3. Objection: Knowledge about System Is Scattered
    5. Metrics Overview
13. 12. Next Steps
    1. Applying the Best Practices Requires Persistence
    2. One Practice at a Time
    3. Avoid the Metric Pitfalls
    4. What Is Next?
14. Index