Extreme Programming (XP): Revisted
Download as PPTX, PDF1 like103 views
The document is a presentation by Mike Harris discussing extreme programming (XP) and its importance in software development. It outlines the principles and practices of XP, compares XP with other methodologies like Agile, Scrum, and Kanban, and emphasizes the benefits of adopting XP to improve code quality and team dynamics. Harris shares personal experiences and examples from projects to highlight the effectiveness of XP practices in overcoming legacy code challenges and enhancing team collaboration.
Extreme Programming (XP): Revisted
- 2. My Plan • Introduce myself • Give the background to why I think this is important • Introduce eXtreme Programming • Look at how XP works alongside other methodologies • Outline some XP-like practices I use and think are helpful • Sum up
- 3. Me • Developed The Fractal Engine for Atari ST in GFA BASIC and 68000 assembler • Degree in Computing for Real-Time Systems • On and off software engineer since then • Developed CMS systems through the nineties and noughties in ColdFusion, Perl, and PHP • Heard about XP first in 2005; dismissed it! • Finally started to pay attention to XP in 2013 • Have since evangelised it wherever I’ve worked in software development teams • Recently I’ve been working in ColdFusion again! FOR a&=line_start& TO line_end& ' temp%=real%(a&) reg%(0)=temp% temp=temp% temp_2%=temp*temp/jul_div% ! x2 reg%(4)=temp_2% ! 16 BIT ONLY reg%(8)=temp_2% ! 32 BIT ONLY temp%=imag%(line_pos&) reg%(1)=temp% temp=temp% temp_2%=temp*temp/jul_div% ! x2 reg%(5)=temp_2% ! 16 BIT ONLY. reg%(9)=temp_2% ! 32 BIT ONLY. reg%(7)=max_it& reg%(10)=c_re% reg%(11)=c_im% RCALL address%,reg%() ' it%=reg%(7) IF NOT it%=65535 it%=(2+max_it&-it%) DIV spread| PSET a&,line_pos&,col_index|(it% MOD 14+2) ENDIF ' NEXT a&
- 4. Why this talk? If you’re not practising XP, you’re probably not writing your best software.
- 5. Project X – From the Outside • Experienced crew on same platform for years • Huge backlog of unprioritized work • Unavailable in the mornings • Customer had no faith in team’s ability to deliver • Strong lead developer with clear vision • Delivery unpredictable • Large spreadsheet of backlog representing “The Grand Scheme” • Plan to stop all other work and deliver TGS
- 6. Project X – From the Inside • Almost all code is legacy code (no tests at all) • Complex tightly-coupled system (hard to change) • Dragon infested areas of the code (can’t be changed) • Priorities based on biggest manager ego • Master developer telling everyone what to do • Other developers unable to make decisions for themselves • No version control • Single shared dev environment • Dev was never equal to Prod
- 7. Project Y – From the Outside • A high performing delivery team • Experienced crew on same platform for years • Great relations with customer • Excellent inter-personal relations in team • Perception of delivery fast and on time • Well managed customer relations and expectations • Lovely cycle-time graphs produced • Nice burn-up charts delivered • Excellent Scrum ceremony management
- 8. Project Y – From the Inside • Almost all code was legacy code (not tested) • Complex tightly-coupled system (hard to change) • Dragon infested areas of the code (can’t be changed) • BDD test suite was retro fitted and took a long time to run, often failing unpredictably (and therefore was not run often) • Large overhead of story writing, development, QA hand-offs • Deployment took up to a day to arrange • And several hours to do • Production version of code did not exist in version control • Lots of siloed knowledge amongst developers • SysOps and Devs siloed; not shared understanding of full tech stack
- 9. My Conclusion We’re totally flying
- 10. So, what is XP? A brief recap of eXtreme Programming
- 11. Hang on, but what is Agile? Agile is not about going fast, it’s about knowing, as early as possible, just how screwed we are. - Robert C. Martin
- 12. Agile Values • Individuals and Interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
- 13. So, what is XP? A brief recap of eXtreme Programming
- 14. What is XP? • Coined by Kent Beck approx. 1996-03-06 • Who had worked previously with Ward Cunningham at Tektronix in the 1980s • Refined methodology he’d used on the payroll project Chrysler Comprehensive Compensation System (C3) • Into his book ”Extreme Programming Explained” • Which was published way back in October 1999 • (The 2nd Edition of the book was published in 2004) • He didn’t invent all the practices (such as TDD) • He codified them into an umbrella methodology: XP
- 15. XP Values • Communication • Simplicity • Feedback • Courage • Respect
- 16. XP Principles • Humanity Safe space for collaboration and growth • Economics Must be affordable, must meet business values • Mutual Benefit What we do we do for the benefit of everyone • Self-Similarity Reuse solutions even at different scales • Improvement Perfect your process; not a perfect process • Diversity Team members have a variety of skills, celebrate this • Reflexion Think about how and why we’re working in the way we are • Flow Deliver a steady flow of valuable software • Opportunity Problems are opportunities for change and improvement • Redundancy Solve critical difficult to solve problems in several different ways • Failure Don’t be afraid of it • Quality Do not accept lower quality to make products go faster • Baby Steps Do things a little bit at a time • Accepted Responsibility You decide if you are responsible or if you’re not
- 17. XP Practices Planning Game Acceptance Tests Small Releases Whole Team Consistent Metaphor Sustainable Pace Collective Ownership Continuous Integration TDD Refactoring Simple Design Pairing Business Facing Team Facing Technical The XP Circle of Life – Ron Jeffries
- 18. Returning to My Conclusion
- 19. XP Practices Planning Game Acceptance Tests Small Releases Whole Team Consistent Metaphor Sustainable Pace Collective Ownership Continuous Integration TDD Refactoring Simple Design Pairing Business Facing Team Facing Technical The XP Circle of Life – Ron Jeffries
- 20. How does XP fit? In comparison with Agile, Scrum, Kanban and Waterfall
- 21. Comparison of methodologies Project Management Software Development SAFe Scrum Kanban Lean Software Development Waterfall Lean XP PRINCE2
- 22. XP and the Agile Manifesto • Individuals and Interactions over processes and tools • Whole Team, Metaphor, Collective Ownership, Pairing, Sustainable Pace • Working software over comprehensive documentation • Acceptance Tests, TDD, Simple Design, Refactoring, Continuous Integration • Customer collaboration over contract negotiation • Small Releases, Planning Game, Acceptance Tests, Consistent Metaphor • Responding to change over following a plan • Small Releases, Planning Game, Sustainable Pace, TDD, Refactoring, Acceptance Tests
- 23. Kanban with XP • Whole Team • Consistent Metaphor • Collective Ownership • Pairing • Sustainable Pace • Acceptance Tests • TDD • Simple Design • Refactoring • Continuous Integration • Small Releases • Planning Game 看 板
- 24. Scrum with XP • Whole Team • Consistent Metaphor • Collective Ownership • Pairing • Sustainable Pace • Acceptance Tests • TDD • Simple Design • Refactoring • Continuous Integration • Small Releases • Planning Games Delivery
- 25. Waterfall with XP • Whole Team • Consistent Metaphor • Collective Ownership • Pairing • Sustainable Pace • Acceptance Tests • TDD • Simple Design • Refactoring • Continuous Integration • Small Releases • Planning Game
- 26. But hang on one minute…. Winston W. Royce's final model illustrated that feedback could (should, and often would) lead from code testing to design and from design back to requirements. In the same paper Royce also advocated large quantities of documentation, doing the job "twice if possible" (a sentiment similar to that of Fred Brooks, famous for writing the Mythical Man Month, an influential book in software project management, who advocated planning to "throw one away"), and involving the customer as much as possible (a sentiment similar to that of Extreme Programming).
- 27. Royce: Revisited
- 28. Managing the Development of Large Software Systems Dr Winston W. Royce. Proceedings, IEEE WESCON, August 1970, pages 1-0 © IEEE
- 29. Royce’s Final Model Dr Winston W. Royce. Proceedings, IEEE WESCON, August 1970, pages 1-0 © IEEE
- 30. Royce’s Five Practices 1. Design Comes First - Customer should know roughly what they want. - Stories should be minimally scoped 2. Document the Design - Document architecture and integration points - Code should be self-documenting 3. Do It Twice - Spikes, MVPs, Prototypes - Cross-functional teams 4. Plan, Control, Monitor Testing - This is most changed, due to CI/CB and move away from siloed QA 5. Involve the Customer - Customer collaboration over contract negotiation
- 31. XP’s Technical & Team Practices Filling in the Software Project Hole
- 32. Simple Design • Keep your design as simple as possible (KISS) • Only implement what you need • Practise YAGNI (You Ain’t Gonna Need It) • Practise the Rule of Three • Domain Driven approaches will help you • Test Driven Development will make your code simpler • Don’t write code unless you really need to
- 33. Do TDD. Like really do it. • Write your test first • Make it pass • Refactor • Write another test • Repeat
- 34. Test driven developers are not skilled at operating a debugger. - Robert C. Martin
- 35. Refactor • Do it all the time • Do it constantly • Do it as soon as possible • Don’t ask for permission • Don’t make it a story • Don’t leave doing it • Your code will rot if you don’t!
- 36. Write Self-Documenting Code • Our code should be self-explanatory • Comments should document whys not whats or hows • Classes, methods, variables, etc, should have meaningful names. • When starting out, call something a foo; until you know what it does • Use your IDE to help improve your code’s readability • Spend time refactoring every bit of code you touch • Even the code that isn’t yours • In fact all code is yours if you’re working with it
- 37. Continuous Integration • Learn how to use Git • Like, really learn how to use the different Git commands • Regularly merge/rebase master if using feature branch • But, aim for trunk-based development • Regularly merge back to master and push • Like regularly, measured in minutes, not hours, nor days
- 38. Continuous Integration only works if you integrate continuously - Robert C. Martin
- 39. Pair Programming • Reduces need for code reviews, QA checks, etc • Helps share knowledge in the team • Helps eliminate silos • Two heads really are better than one • Just do it! • But it is a practice • Make sure you do it right • And don’t do it all the time
- 40. Tiny Tasking • Great technique to use with pair programming • Break a small story into baby steps • Agree first with your pairing partner • Put the critical path on sticky notes and place them on the desk in front • Go into a correct level of detail • Too many tiny tasks indicate: • Too much up front planning • A story that’s too big • Tiny tasks are too small • A new person rolling on to a story can catch up on the tasks left to do • This gives you both a way of transferring knowledge and establishing context
- 41. Mob Programming • Great for on-boarding new team members • Great for new project/work inception • Take breaks regularly • Avoid ‘mob Googling’ • Hold daily retros • Have a mob programming charter
- 42. Collective Ownership • You may have wrote it, but it’s not your code • The team owns the code • Not you • Be prepared to work on other code • Be prepared for someone to change, or even delete, your code • Be prepared to jump onto a story when someone is away
- 43. Technical Debt Wall • It’s about knowing what the risks are • Keep a Tech Debt Wall (Trello is a good tool for this) • Note down any technical debt you accrue as you develop • Consider the risk of postponing resolution vs the cost of sorting now • Don’t engineer the future: resolve in the next iteration • Regularly review the Tech Debt Wall • Categorise the debt on the wall • Take highest risk technical debt into backlog and resolve • Delete technical debt that no longer is, or is no longer relevant
- 44. Outcomes What I found when we applied the practices
- 45. Project Z – Where we were • We were doing pretty much all of the XP and other practices outlined • Our Tech Lead and founding architect left for a Start Up • Two other contracted developers moved on at the same time • We took on two new developers shortly afterwards • We were a small team with lots of risk • Loosing critical mass on our dev practices was a possibility • There was potentially a lot of overhead onboarding new folks • And this would slow us down
- 46. Project Z – The Results • The fact we’d done pair programming meant • All developers had some knowledge of every part of the software • Within weeks we were able to do a complete hand-over • And made a smooth transition to a new tech lead • Pairing and mobbing meant that new developers could do valuable work from day one • Our code was self-documenting and covered by descriptive tests • Helped with onboarding new members • No balls were dropped
- 47. In Summary • Adopting Scrum, Kanban, or a hybrid, on it’s own is not enough • They won’t lead you to do Agile Software Development • As they are primarily methods for managing software projects • XP helps you write better software • XP helps you to mitigate against legacy code • You may not be able to do everything • But at least do some of the things • It can be hard to change • But keep at it; you will get there • XP will even work with Waterfall methodologies • The Fractal Engine was the best software project I’ve been involved in • ColdFusion is still a thing
- 48. Perhaps Uncle Bob puts it better? Without TDD, Refactoring, Simple Design, and yes, even Pair Programming, Agile becomes an ineffectual flaccid shell of what it was intended to be. - Robert C. Martin
- 49. What happened to Frank? • The Author of GFA BASIC • And Turbo-Basic XL for Atari 8 bit • Atari ST support ended in 1991 • By 2002 GFA was Bankrupt Frank Ostrowski 1960 - 2011
- 50. Thank You Mike Harris . m.harris@elsevier.com https://mbharris.co.uk/fe3
Editor's Notes
- #2: In his recent book, Clean Agile, Robert C "Uncle Bob" Martin chooses Extreme Programming (XP) for the basis of his explanation of Agile because "of all the Agile processes, XP is the best defined, the most complete, and the least muddled." So why is it that in my professional life I only hear us speaking about Agile in terms of Scrum, Sprints, and possibly Kanban? Often I mention XP and people are not sure what I mean. Am I sure myself? Coined in 1999 by Kent Beck and Ward Cunningham, XP has been with us for twenty years, but may of its practices have been with us for much longer. Many of them will be familar to you, but did you know they came from XP? This talk aims to take us back to what XP is, how it fits in the Agile world, how it sits alongside other methodologies, and why, like Uncle Bob, I believe it is the best defined methodology, and what we should all be talking about.
- #15: Oldest reference may be in “Digital Computer Programming” Daniel D. McCracken, 1957 Ward Cunningham, the granddaddy, invented the Wiki (WikiWikiWeb)
- #20: Continuous Integration, TDD, Collective Ownership, Pairing, Refactoring, Simple Design
- #23: Martin Fowler at the board, then Dave Thomas, not sure, Bob Martin, Jim Highsmith, not sure, Ron Jeffries, James Grenning
- #30: Important to note speed as a factor, for example we have Git, he had probably punch cards, to work with. Also the programming languages, such as Fortran, BASIC, COBOL, Algol, PL/1
- #33: YAGNI grows from a too much future anticipation, overzealous workers if you may. KISS is a strategy that tries to counteract human tendency for design creep.
- #51: GFA Systemtechnik GmbH