Trust Driven Development
Trust Driven Development
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
About the Author
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
The Leanpub 60-day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
