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.
License
Table of Contents
-
-
A Fable About Trust
- Trust Driven Development
- Back to the Mechanic
- Project Zen
- Where to?
-
A Fable About Trust
-
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
-
1. What is a Project?
-
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?
-
9. Iterations
-
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
-
14. Daily Stand Up
-
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
-
21. Crunch Time
- Notes
About the Author
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...
