Agile Technical Practices Distilled
Agile Technical Practices Distilled
$19.99
Minimum price
$24.99
Suggested price
Agile Technical Practices Distilled

This book is 100% complete

Completed on 2018-12-12

About the Book

The authors of the book have been working as software developers and coaches for years, accumulating more then half a century of experience. During this period working in the trenches of teaching software design we created lots of content and shared many stories of real professional life among us. From the feedback we had, we thought it would be a good idea to organize all the information in a single place, following a logical sequence, creating a sort of learning journey. We touch all the principles we consider important to master, dropping too many details. In our profession the information are far too many to be all memorized, let alone mastered. The ability to select what to focus on is maybe more important then the ability of learning itself. We all are very excited to be able to share with you our personal selection of content and the lessons we learned the hard way. We genuinely hope that at the end of it you will find some new ideas for improving your Software Design skills, the relationship within your team and your business as well.

About the Authors

Pedro Moreira Santos
Pedro Moreira Santos

Over 25 years experience in software, from embedded systems, aviation, media, retail, to cloud-based enterprise applications. In recent years, I've focused on educating, and inspiring other developers.

I coach and mentor. I've spent hundreds of hours doing pairing sessions, coaching and tutoring developers at all levels of proficiency. I've worked with developers on everything from programming basics, to object-oriented design principles, to refactoring legacy applications, to pragmatic testing practices, to architecture decisions, to career development choices.

Marco Consolaro
Marco Consolaro

Describing himself as a software craftsman, systems thinker, Agile technical coach, entrepreneur, philosopher, restless traveler - all blended with Venetian humor - Marco learned coding in Basic on a Commodore when he was nine years old. He graduated from Venice University in 2001 with a degree in Computer Science.

Since then, Marco has worked in Italy and the UK, always looking to learn something new. When his journey led him to the Agile principles, he quickly realized the effectiveness of such an approach for both technical and organizational areas. He now strongly believes that an iterative approach based on trust, transparency, self-organization and quick feedback loops is the key to success for any team in any discipline.

His dream is to see these principles based on Systems Thinking understood and implemented at every level in businesses and public administrations.

Alessandro Di Gioia
Alessandro Di Gioia

With 20 years experience in building software, Alessandro worked within companies ranging from small start ups to large enterprises.

He helps companies embrace Agile Technical Practices in London where he currently resides, and previously in Italy and Norway.

Adopting Agile methodologies, especially eXtreme Programming reshaped the way he builds software and think about the whole life-cycle of the solutions he delivers from inception to delivery.

He likes concise, expressive, and readable code as well as pragmatically improving existing solutions.

He is passionate about developing and designing OO and functional code. Using his skills to lead digital transformation through cultural change and architectural evolution to scalable distributed asynchronous systems.

Being a continuous learner, he loves to share his experience with others through coaching, mentoring, delivering workshops and talks.

About the Contributors

Mary McCauley-Stiff
Mary McCauley-Stiff

Table of Contents

  • Introduction
    • AGILE TECHNICAL PRACTICES
      • Is this book for me?
      • Why we wrote this book
      • Why distilled?
      • What are Agile Technical Practices?
      • Rules, principles and values
      • How this book is organized
      • How to get the most out of this book
      • Resources
  • First steps
    • PAIR PROGRAMMING
      • What is pair programming?
      • Roles
      • Driver/Navigator switch techniques
      • Breaks
      • Katas
      • When should I move to the next chapter?
      • Resources
    • CLASSIC TDD I – TEST-DRIVEN DEVELOPMENT
      • Classic TDD
      • The three laws of TDD
      • Refactoring and the Rule of Three – baby steps
      • Three methods of moving forward in TDD
      • Degrees of freedom
      • Naming tests
      • A test name pattern
      • Katas
      • More katas
      • Great habits
      • Classic TDD flow
      • Where are we in the big picture of OO software design?
      • When should I move to the next chapter?
      • Resources
    • CLASSIC TDD II
      • Writing the assertion first and working backward
      • Organizing your test in arrange, act and assert blocks
      • Unit test principles
      • Katas
      • Great habits
      • Classic TDD flow
      • Where are we in the big picture of OO software design?
      • When should I move to the next chapter?
      • Resources
    • CLASSIC TDD III – TRANSFORMATION PRIORITY PREMISE
      • Kata
      • TPP – Defining obvious implementation
      • Katas
      • Great habits
      • Classic TDD flow
      • Where are we in the big picture of OO software design?
      • When should I move to the next chapter?
      • Resources
    • DESIGN I – OBJECT CALISTHENICS
      • It’s the design…​
      • Kata
      • Object calisthenics – 10 steps for better software design
      • Heuristics
      • Katas
      • Great habits
      • Classic TDD flow
      • Where are we in the big picture of OO software design?
      • When should I move to the next chapter?
      • Resources
  • Walking
    • DESIGN II - REFACTORING
      • When to refactor (for now)
      • Main refactors
      • IDE agility (a.k.a. know your shortcuts)
      • Kata
      • Refactor 80-20 rule
      • Refactoring guidelines
      • Kata
      • Parallel change (or expand, migrate and contract)
      • Kata
      • Great habits
      • When should I move to the next chapter?
      • Resources
    • DESIGN III – CODE SMELLS
      • Design smells
      • Code smells
      • Highlighted code smells
      • Object calisthenics preventing code smells
      • When to refactor (extended for code smells)
      • Refactor code smells
      • Kata
      • Great habits
      • Classic TDD flow
      • The big picture
      • When should I move to the next chapter?
      • Resources
    • TEST DOUBLES
      • Principles
      • Different types of Test Doubles
      • Test Doubles guidelines
      • Katas
      • Great habits
      • When should I move to the next chapter?
      • Resources
    • TESTING LEGACY CODE
      • Breaking dependencies using a seam
      • Characterization tests
      • Kata
      • Golden Master
      • Kata
      • Approval Tests by Llewellyn Falco
      • Revisiting the refactoring guidelines
      • Kata
      • Conclusions
      • Great habits
      • When should I move to the next chapter?
      • Resources
    • DESIGN IV – DESIGN PATTERNS
      • Design patterns advantages
      • Design patterns pitfalls
      • Quick reference catalogue
      • Revisiting the refactoring guidelines
      • Kata
      • Great habits
      • When should I move to the next chapter?
      • Resources
  • Running
    • DESIGN V – COHESION AND COUPLING
      • Coupling
      • Cohesion
      • Katas
      • When to refactor (extended for Cohesion/Coupling)
      • Classic TDD flow
      • The big picture
      • When should I move to the next chapter?
      • Resources
    • DESIGN VI – SOLID PRINCIPLES++
      • Single Responsibility Principle
      • Open/Closed Principle
      • Liskov Substitution Principle
      • Interface Segregation Principle
      • Dependency Inversion Principle
      • Balanced Abstraction Principle
      • Principle of Least Astonishment (a.k.a. WTF principle)
      • Kata
      • When to refactor (extended for SOLID principles)
      • Classic TDD flow
      • The big picture
      • When should I move to the next chapter?
      • Resources
    • DESIGN VII - CONNASCENCE
      • Definition
      • Dimensions
      • Connascence of Name and Type (CoN and CoT)
      • Connascence of Position (CoP)
      • Connascence of Value (CoV)
      • Connascence of Meaning (or Convention) (CoM)
      • Connascence of Algorithm (CoA)
      • Connascence of Execution Order (CoEO)
      • Connascence of Timing (CoTm)
      • Connascence of Identity (CoI)
      • Connascence of Manual Task (CoMT)
      • Classic TDD flow
      • The big picture
      • When should I move to the next chapter?
      • Resources
    • DESIGN VIII – THE FOUR ELEMENTS OF SIMPLE DESIGN
      • What are the four elements of simple design?
      • What does each element mean?
      • Alternative definitions of simple design
      • Our personal definitions of simple design
      • Kata
      • Classic TDD flow
      • The big picture
      • When should I move to the next chapter?
      • Resources
    • DESIGN IX - CONCLUSION
      • Cohesion and Coupling as forces
      • The 3 Cs of design: from Cohesion and Coupling to Connascence
      • Systems Entropy
      • The big picture
      • Resources
  • Flying
    • OUTSIDE-IN DEVELOPMENT
      • Classic TDD approach
      • Acceptance tests
      • Test boundaries
      • Double loop TDD
      • The Outside-In approach
      • Outside-In TDD: London school
      • The direction of dependencies
      • Should I use classic TDD or Outside-In TDD?
      • Kata
      • The big picture
      • Great habits
      • Resources
    • BEHAVIOR-DRIVEN DEVELOPMENT (A.K.A. LOVE YOUR REQUIREMENTS)
      • Poka-yoke
      • Mistakes versus defects: feedback is the cure (again)
      • Bugs and communication
      • User stories
      • Behavior-Driven Development
      • Acceptance Tests done right
      • Boundaries
      • The walking skeleton
      • Kata
      • Resources
    • UNDERSTAND THE BUSINESS
      • Knowledge versus understanding
      • Theory of Constraints
      • Domain-Driven Design: What domain?
      • Beyond requirements: knowledge crunching
      • Value stream and domain events
      • Bounded contexts and communication
      • Business and DevOps
      • System Thinking and Sociotechnical organizations
      • Resources
    • THE STORY OF TEAM C
      • Terraforming
      • Team building
      • The backlog: crunching knowledge for breakfast
      • Cracking on
      • From forming to performing
      • Outside-In ATDD with optional unit tests
      • The green flag
      • The moral of the story
    • CONCLUSION
      • The human factor
      • Team play
      • Bounded rationality and knowledge sharing
      • Resources
  • Appendices
    • THE 12 AGILE PRINCIPLES
    • PopcornFlow by Claudio Perrone
      • The 7-steps decision cycle
      • The principles
      • Who can benefit from PopcornFlow
      • Resources
    • EventStorming by Alberto Brandolini
      • Silos and value stream
      • The importance of learning
      • The EventStorming approach
      • The workshop: a quick overview
      • Different flavors of EventStorming
      • Complex Systems and proven solutions
      • Resources
    • License: CyberDojo
      • About CyberDojo Foundation exercises
      • Web resources
    • SAMPLE SOLUTIONS
      • Sample solutions: FizzBuzz in Clojure
      • Sample solutions: Fibonacci sequence in C++
      • Sample solutions: Roman numerals in C#
      • Sample solutions: TicTacToe in Swift (partial solution)
      • Sample solutions: Connecting code smells with Cohesion/Coupling
      • Sample solutions: Connecting object calisthenics with code smells and Cohesion/Coupling
      • Sample solutions: Connecting Cohesion / Coupling and SOLID principles
    • ABOUT THE AUTHORS
      • Pedro
      • Marco
      • Alessandro
      • Personalized coaching
      • FEEDBACK PLEASE
  • Notes

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, publishers and universities use Leanpub to publish amazing in-progress and completed books and courses, just like this one. You can use Leanpub to write, publish and sell your book or course 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