Trust Driven Development
Trust Driven Development
$15.00
Minimum
$25.00
Suggested
Trust Driven Development

This book is 75% complete

Last updated on 2017-07-24

About the Book

Trust Driven Development is about the profession of building successful software. It talks about about planning for change, about process, and above all, about trust.

Process is what we do to make sure that everybody on a project has a shared sense of state and of goals. Trust is what happens when we match that shared state and meet those goals.

At some point in your software project, something will go wrong. There will be a miscommunication or a sudden change of requirements. You might even make a mistake. What happens then depends on a lot of factors, some of which are outside your control.

One factor that is in your control is whether you’ve presented yourself as worthy of your partner’s trust so that rough spots along the project path can be approached in the sprit of collaboration and not fighting over blame.

Bad process and a lack of trust cause real difficulty in projects and make developer and customer lives more painful. It can be better. This book can help.

Table of Contents

  •  
    • A Fable About Trust
      • Trust Driven Development
      • Back to the Mechanic
      • Project Zen
      • Where to?
  • I Before You Start
    • 1. What is a Project?
      • 1.1 What is “Process”
    • 2. Who are the Players?
    • 3. What do I Need Before I Start?
      • 3.1 Sharing Knowledge
      • 3.2 What to Share?
    • 4. What prevents sharing?
    • 5. What do First Meetings Look Like?
      • 5.1 Getting the initial feature list
      • 5.2 Workflows
    • 6. Initial Estimates
      • 6.1 Let’s talk about #NoEstimates
      • 6.2 Making story lists and estimates
      • 6.3 Converting the list to something resembling an estimate
    • 7. What do Clients Need To Know?
      • 7.1 Okay, so what’s the problem…
    • 8. Iteration Zero
      • 8.1 Setting up Environments, Continuous Integration, and Continuous Deployment
      • 8.2 Team Agreements
      • 8.3 Spikes and Technology decisions
  • II Iteration Heartbeat
    • 9. Iterations
      • 9.1 What’s an iteration?
      • 9.2 Why Iterations?
      • 9.3 What happens in an iteration?
      • 9.4 How long should an iteration be?
      • 9.5 A Quick Plea About Days of the Week
      • 9.6 The Iteration Planning Meeting
      • 9.7 Iteration process smells
      • 9.8 When don’t I need iterations?
      • 9.9 When should I worry?
    • 10. Retrospectives
      • 10.1 When
      • 10.2 Who
      • 10.3 How
    • 11. Where Do Stories Come from?
      • 11.1 What makes a story?
      • 11.2 Lifecycle of a story
    • 12. Estimation and Velocity
      • 12.1 The Rules
      • 12.2 Why Estimate?
      • 12.3 What are you estimating?
      • 12.4 One Plus One Equals Three, or Point Math
      • 12.5 Validating Estimates
      • 12.6 Estimation in Context, or Estimation in Conflict
      • 12.7 Should You Estimate Bugs?
      • 12.8 Why does this work?
    • 13. Responding to Change
      • 13.1 What’s a change?
  • III Daily Heartbeat
    • 14. Daily Stand Up
      • 14.1 Build A Better Standup
      • 14.2 Date and Time
      • 14.3 Who attends?
      • 14.4 The Virtual Standup
    • 15. Doing The Work
    • 16. Pair Programming vs Code Review
      • 16.1 Effective Pairing
      • 16.2 Code Review
      • 16.3 Code standards and documentation
    • 17. Remote Work
      • 17.1 Set up communication early
      • 17.2 Conway’s Law, Remote Teams, and You
      • 17.3 Split Sites
      • 17.4 Remote Meetings
      • 17.5 When Not To Remote
    • 18. Release Management
      • 18.1 Code Freeze
      • 18.2 Release cutover
      • 18.3 Staging “plus”
      • 18.4 Feature block
      • 18.5 When to deploy?
    • 19. Testing
      • 19.1 When to Deploy to Stage
      • 19.2 When to Deploy to Production
    • 20. Bugs
      • 20.1 Building Trust Before Bugs Happen
      • 20.2 Building Trust When Bugs Happen
      • 20.3 Fixing Bugs
      • 20.4 Bug or Feature?
      • 20.5 Flavors of bugs
      • 20.6 When Bugs Get Serious
  • IV Crunch Time
    • 21. Crunch Time
      • 21.1 The End Game
      • 21.2 Attention Must Be Paid
      • 21.3 Deadlines
      • 21.4 End Game Review
      • 21.5 Code Freeze is never a freeze
      • 21.6 One More Thing
      • 21.7 Continuous Crunch
      • 21.8 Plan for the End
    • 22. Responding To Problems
    • 23. I made a mistake
    • 24. Professionalism in a Hostile Environment
      • 24.1 I think what you are doing is a bad idea
      • 24.2 The project keeps changing
      • 24.3 Scope Creep
      • 24.4 The client has unreasonable time and scope expectations
      • 24.5 I way underestimated this feature/project
      • 24.6 People on this project are not executing
      • 24.7 I don’t have agency, the team is too big
      • 24.8 I’m having personal issues with the client
      • 24.9 The client hates what they said they wanted
    • 25. End of Life
    • Colophon
    • Acknowledgements
    • Changelog
  • Notes

About the Author

Noel Rappin
Noel Rappin

Noel Rappin is the Director of Development at Table XI. Noel has authored multiple technical books, including "Rails 4 Test Prescriptions", "Trust-Driven Development", and "Take My Money: Accepting Payments on the Web". Follow Noel on Twitter @noelrap, and online at http://www.noelrappin.com.

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors and publishers use Leanpub to publish amazing in-progress and completed ebooks, just like this one. You can use Leanpub to write, publish and sell your book as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub