Extreme Programming: An Introduction to XP Practices
•Télécharger en tant que PPTX, PDF•
0 j'aime•149 vues
This document provides an overview of the twelve core Extreme Programming (XP) practices introduced by Kent Beck in his 1999 book Extreme Programming Explained. It discusses each practice in 1-2 paragraphs, including planning games, small releases, sustainable pace, whole team, testing, pair programming, coding standards, continuous integration, system metaphor, simple design, refactoring, and collective ownership. The presentation was given by David Hanson, who has experience adopting and integrating XP practices into Agile projects following Scrum and Kanban methodologies.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Extreme Programming: An Introduction to XP Practices
Similaire à Extreme Programming: An Introduction to XP Practices (20)
Plus de David Hanson
Plus de David Hanson (15)
Dernier
Dernier (20)
Extreme Programming: An Introduction to XP Practices
- 1. Extreme Programming AnIntroductiontoXP Practices David Hanson www.slideshare.net/DavidHanson5/ June 2020,Version 1.2 119:12 17:45
- 2. Focus onXP Practices DavidHanson dphanson63@yahoo.com www.linkedin.com/in/david-hanson/ About the Presentation ThisAgile 101 session will cover the twelve XP practices introduced by Kent Beck in Extreme Programming Explained published 1999. The XP practices, once extreme, now common, complement anyAgile methodology. XP introduced us to user stories, test driven development, pair programming and continuous integration. These practices changed the way software solutions are planned, developed and designed. About the Presenter David Hanson was first introduced to XP in 2000, when his manager asked her team to read Extreme Programming Explained. David was asked to lead the adoption of XP practices in a 6 month trial. While the team’s initial attempt to adopt XP was largely incomplete, over the years, his later teams integrated these practices into projects following Kanban and Scrum. 219:12 17:48
- 3. XP Practices Developing: Test First Pair Programming Coding Standards Continuous Integration Designing: System Metaphor Simple Design Refactor Mercilessly Collective Ownership Planning: PlanningGame Small Releases Sustainable Pace WholeTeam 319:12 17:51
- 4. XP Practices RonJefferies Viewpoint ronjeffries.com/xprog/what-is- extreme-programming/ 419:12 17:54
- 5. Planning Games Release Planning Customers and developers using story cards Exploration Phase: write, estimate, split stories Commitment Phase: sort by value, risk; set velocity, scope Steering Phase: iterate and adjust weekly 2/e: plan every quarter; release every iteration Iteration Planning Development team using task cards Exploration Phase: tasking Commitment Phase: accept & estimate tasks, set own load factor, rebalance Steering Phase: select, pair, test, code, design daily 2/e: iterate every week; deploy every day Explore Commit Steer IterationRelease Explore Commit Steer 519:12 17:57 Recommends placing cards on table and physically moving them around to create incremental iterations (a form of story mapping)
- 6. Small Releases shortrelease cycles Smaller releases have less risk Early and frequent releases improve feedback and provide greater returns Truest measure of done Deploy daily; release weekly Less extreme: continuous delivery (manual approval) More extreme: continuous deployment (fully automated) Advanced Deployment Strategies* Blue-Green Deployment A/BTesting Canary Release Rolling Deployment FeatureToggles *extreme practices not covered in XP 12 6 39 619:12 18:00
- 8. WholeTeam on-sitecustomer Not just cross-functional team with developers and testers But also representation of the business or the users Collocated Generalizing specialists One team all skills Users or user proxies on hand As a user… </> 819:12 18:06
- 9. Testing DeveloperTests CustomerTests Write automated, executable test before writing code Execute all tests with each build Test > Code > Refactor Code &Test Coverage: Target unit test code coverage of 80-95% Consider 20-80 rule for acceptance test automation Test Driven Development: Automated unit tests Arrange > Act > Assert Mock and stub interfaces Single responsibility principle Behavioral Driven Development: Automated acceptance tests Given <initial condition> When <some event> Then <expected result> Write New Test Run All Tests Write Code Run All Tests Refactor Code Run All Tests 919:12 18:09
- 10. Pair Programming One person drives, while the other person navigates Accelerates knowledge sharing, common understanding, cross-skills training Reduces defects and increases quality Alternate roles and partners Variations: Peer-to-peer pairing Master-apprentice pairing Cross-skill pairing Developer-tester pairing Consider: pairing on other activities such as analysis or testing Less extreme: swarming a story where everyone leads a task More extreme: mobbing a story where 3-5 team members work together (one screen, one keyboard) 1019:12 18:12
- 11. Coding Standards Communicate via code Set common coding standards for everyone to follow, enabling anyone to pickup where someone else left off Everyone agrees to follow a common format and style, perhaps favoring certain design patterns over others Helps establish collective ownership, avoid conflicts when pair programming, and enable liberal refactoring Common Standards Style and Formatting Code Structure Naming Conventions Error Handling Commenting Related Standards Design Patterns Editor and Lint Utility Code Coverage Source Control Management User Interface 1119:12 18:15
- 12. Continuous Integration Continuous Build ContinuousTesting Continuous Inspection Continuous Deployment Continuous Delivery Every developer uses same common code repository Every developer checks in changes at least daily, ideally after every working change Merge conflicts addressed at check-in Check-in triggers build Broken builds and failed tests addressed immediately Automate both unit testing and acceptance testing Enhance with code quality inspection tools Deploy continuously to lower environments Deliver in small batches to higher environments Production ready by EOD or start over next day 1219:12 18:18
- 13. System Metaphor A system metaphor helps customers and developers speak a common language A metaphor helps drive product vision, focus creativity and craft compelling solutions Helps maintain conceptual integrity Metaphors can be both big and small Think: Desktop vs. DOS Think: Recycle Bin vs. del An example: Circle of Life The organizing metaphor from my last major project The vision: replace suite of applications used by portfolio managers with one system for lifecycle of trade Also used to discuss how user entries would reflect across panels within the application SimplifiedVariants: CommonVocabulary Ubiquitous Language 1319:12 18:21
- 14. Simple Design Design for change: Simplest thing that could work You ain’t gonna need it Once and only once Refactor to remove: Duplication Extra features Keep it simple DRY |YAGNI | KISS Related: Emergent Design Allow design to emerge Add complexity only when needed Local rules lead to global properties Lean Foundation: Leave design options open as long as possible to maximize learning Delay committing to a design until the last responsible moment 1419:12 18:24
- 15. Refactoring Refactor code to remove complexity and duplication Refactor tests to keep them viable and relevant Refactor design as emerges Refactor build to keep it fast Refactor with every story to maintain simplicity Refactor with every iteration to eliminate technical debt TDD incorporates refactoring of code and tests with every incremental line of code Architectural refactoring may require larger effort with own independent task 1519:12 18:27
- 16. Collective Ownership Entire team owns all the code and the design Anyone can update any code or refactor any design Supported by common standards Enhanced by rotating partners when pairing Robust to planned and unplanned absences and turnover Requires ample unit test code coverage Leads to team pride in quality code Less reliance on leads and architects More reliance on collective intelligence Every team member empowered to contribute 1619:12 18:30
- 19. XP Practices Second Edition 2004 13primarypractices 11corollarypractices Primary Practices SitTogether WholeTeam InformativeWorkspace Energized Work Pair Programming Stories Weekly Cycle Quarterly Cycle Slack Ten-Minute Build Continuous Integration Test-First Programming Incremental Design Corollary Practices Real Customer Involvement Incremental Deployment Team Continuity ShrinkingTeams Root-Cause Analysis Shared Code Code andTests Single Code Base Daily Deployment Negotiated Scope Contract Pay-Per-Use 1919:12 18:39
- 20. WhatWas Once Extreme… Now Mainstream User Stories replaced Business Requirements Acceptance Criteria replaced Functional Specifications Research Spikes replaced Technical Design Business onTeam as PO Pairing Testing before Coding Embracing rework with Refactoring Weekly Releases, Daily Deployments CI/CD Story Cards andTeamVelocity Extreme Moved On Story Mapping Teams of Five Pairing > Mobbing TDD > Acceptance TDD User Acceptance in Production via Blue-Green, A/B, Canary CI/CD led to DevOps Infrastructure as Code and Continuous Monitoring Single Responsibility > Microservices Containers and Cloud Ideal Days > Story Points Backlog Burnups replaced Project Plans 2019:12 18:42
- 21. Appendix XP Adoption Planning Game 19:12 18:45 21
- 22. XPAdoption Stories 19:12 18:45 22 As a team, we practice System Metaphor to communicate ideas about code clearly. As a team, we practice Planning Game to schedule the most important work. As a team, we practice Sustainable Pace to go home tired, but not exhausted. As a team, we practice On-siteCustomer to address user concerns accurately and directly. As a team, we practice Refactoring to find the code’s optimal design. As a team, we practice Test First to prove that the code works as it should. As a team, we practice Pair Programming to spread knowledge, experience, and ideas. As a team, we practice Continuous Integration to reduce the impact of adding new features. As a team, we practice Small Releases to return the customer’s investment often. As a team, we practice CollectiveOwnership to share responsibility for code and design. As a team, we practice Coding Standards to communicate ideas clearly through code. As a team, we practice Simple Design to produce software that’s easy to change. As anAgile team, we adopt XP Practices to deliver higher value, at lower cost, with shorter timelines, while maintaining quality.
- 23. XPAdoption Planning Game 19:12 18:45 23 System MetaphorPlanning Game Sustainable Pace Should On-siteCustomer 1 Estimate Must Refactoring 2 Estimate Must Test First 5 (split) Guess Pair Programming Continuous Integration Should Small Releases 2 Known Less Certain Effort Risk More Certain LowerStoryValueHigher Could CollectiveOwnership 1 Known Coding Standards Could Simple Design 3 Guess Value XP Practice Effort Risk Must/Should/Could XP Practice 1/2/3 Known/Estimate/Guess Q1 Q2 Q3 Q4
- 24. Credits Sources Extreme Programming Explained, Kent Beck, First Edition, 1999 Extreme Programming Explained, Kent Beck with CynthiaAndres, Second Edition, 2005 Extreme Programming Pocket Guide, chromatic, O’Reilly, 2003 Extreme Programming Practices, https://en.wikipedia.org/wiki/Extre me_programming_practices Planning Game, http://wiki.c2.com/?PlanningGame Images https://ronjeffries.com/xprog/what-is- extreme-programming/ http://clipartmag.com/timer-clipart https://www.dreamstime.com/illustration/mi nutes-stopwatch.html https://www.quora.com/What-is-the- difference-between-pair-programming-and- parallel-programming https://www.qfs.de/en/blog/article/2019/07/11 /using-qf-test-in-continuous-integration- systems-1.html https://www.pngitem.com/middle/miRJm_co mmunity-garden-gardening-icon-iconic- community-garden-icon/ Various book covers, Amazon.com Coding and “desktop” icons also downloaded from Internet 19:12 24
Notes de l'éditeur
- Anticipate 45 min to 1.5 hrs; 45 min sticking mostly to script with few questions and comments; 1.5 hours with frequent questions, comments, and interaction, plus the Appendix with exercise. Goal: 55 min, will probably require skipping Appendix and shortcutting summary slides.
- Connection: What are you hoping to learn? What’s your experience with XP? Why are you here? Intended audience: definitely Scrum masters and managers; possibly developers and testers for the concepts, will need to seek implementation details elsewhere; product owners and stakeholders from whole team perspective
- Connection: Who can name an XP practice? Any others? Original order: Planning Game, Small Releases, System Metaphor, Simple Design, Test First, Refactoring, Pair Programming, Collective Ownership, Continuous Integration, Sustainable Pace, On-site Customer, Coding Standards Reconsider: swapping Coding Standards and Collective Ownership
- Inner circle: incremental work Middle circle: framework for success Outer circle: interaction with users
- If plans go stale as soon as engage, then why not plan on replanning regularly Release Steering: iteration, recovery, new story, re-estimate Iteration Steering: implement, record, recover, verify The game: maximize value delivered 1/e: release every 1 to 3 [iterations] and iteration every 1 to 4 weeks
- If smaller releases have lower risk with early value, then why not release every iteration or better yet every story Bugs fixed next iteration
- If need to work indefinitely, then why not plan on a sustainable pace Load factors are typically 2 to 4, meaning a 4 hour estimate may actually take 8 to 16 hours due to underestimation and distractions
- If user feedback is invaluable, then why not include a user on the team User on team helps insure perceived integrity. XP does not include an analyst on team.
- If testing early and often raises quality and reduces defects, then why not test before coding with developers and customers XP text suggests spending first day of iteration focused primarily on automating acceptance tests Code & test coverage: find balance which keeps build fast, avoids test duplication, avoids low value testing, and keeps escaped defects low.
- If code reviews are good, then why not work in pairs so code is reviewed while written Drivers focus tactical; navigators focus strategic
- If common standards improve to interoperability, why not set coding standards leading to interoperable team members
- If code merges and integrated testing is difficult but critical, then why not integrate as soon as possible Single code base or stream
- If architecture is challenging, then why not use a metaphor to keep everyone thinking about design
- If simplicity is better than complexity, they why not keep the design as simple as it could be Don’t Repeat Yourself
- If important to refactor code and tests, why not refactor with every story and every build Major refactoring can be tackled over time incrementally
- If owners take better care, why not have collective ownership Tools like Jira and words like “assigned” make this mindset a challenge; Jira allows only one “assignee” per story or task.
- Relations as outlined in original text. Confirmation: Do you see any relationships between the practices? Any others? Confirmation: What practices do your teams already practice? What would you want them to include next? What would they want to include next?
- 2nd edition covered 13 primary practices and 11 corollary practices; never caught on… XP Series included a dozen books of questionable value. Chapter 0 in XP Applied best summary of original practices. Time for an update, now that most of these extreme practices are no longer extreme.
- Comment on Stories/Weekly/Quarterly and Daily Deployment Ask about Informative Workspace and Slack Any ideas on Shrinking Teams and Code & Tests Extra time mention Incremental Deployment
- Others: scaling to team of teams and team of team of teams; big room planning
- On back of card, would outline acceptance criteria for verifying practice adoption.
- Coach reviews XP practices with developers including the purpose of each practice Developers estimate relative effort to adopt each practice: 1, 2, or 3 (perhaps weeks or iterations) Customer (Coach) assess value of each practice: must, should, or could Developers assess risk (confidence) related to effort as known, estimate, or guess For each column move Musts up and Coulds down * For each row move Guesses left and Knowns right ** Repeat steps 4 and 5 until nothing moves Development sets velocity (suggest 4-8 points per release; suggest setting adoption “release” to one quarter) Coach selects stories from top left to fill first, second, third iteration * Value tiebreaker: for Musts, move less certain risk up; for Shoulds, move lower effort up; for Coulds move more certain risk up ** Risk tiebreaker: move Musts left and Coulds right