SlideShare a Scribd company logo
1 of 24
Extreme Programming
AnIntroductiontoXP Practices
David Hanson
www.slideshare.net/DavidHanson5/
June 2020,Version 1.2
119:12 17:45
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
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
XP Practices
RonJefferies
Viewpoint
ronjeffries.com/xprog/what-is-
extreme-programming/
419:12 17:54
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)
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
Sustainable
Pace
40-hourweek
Rest
Work
Play
719:12 18:03
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
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
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
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
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
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
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
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
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
XP Practices
Interrelated
Planning
Game
Small
Releases
System
Metaphor
Simple
Design
Testing
Refactor
Pairing
Collective
Owner.
CI
Sustain.
Pace
On-site
Customer
Coding
Standards
1719:12 18:33
TheXPSeries
eXtreme
Programming
eXplained
EmbraceChange
KentBeck
FirstEdition1999
1819:12 18:36
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
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
Appendix
XP Adoption Planning Game
19:12 18:45 21
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.
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
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

More Related Content

What's hot

Extreme programming
Extreme programmingExtreme programming
Extreme programming
Mr SMAK
 
Extreme & pair programming Slides ppt
Extreme & pair programming Slides pptExtreme & pair programming Slides ppt
Extreme & pair programming Slides ppt
Mr SMAK
 
optimizing code in compilers using parallel genetic algorithm
optimizing code in compilers using parallel genetic algorithm optimizing code in compilers using parallel genetic algorithm
optimizing code in compilers using parallel genetic algorithm
Fatemeh Karimi
 
Xp exterme-programming-model
Xp exterme-programming-modelXp exterme-programming-model
Xp exterme-programming-model
Ali MasudianPour
 
Twelve practices of XP_Se lect5 btech
Twelve practices of XP_Se lect5 btechTwelve practices of XP_Se lect5 btech
Twelve practices of XP_Se lect5 btech
IIITA
 

What's hot (20)

Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
XP In 10 slides
XP In 10 slidesXP In 10 slides
XP In 10 slides
 
eXtreme programming (XP) - An Overview
eXtreme programming (XP) - An OvervieweXtreme programming (XP) - An Overview
eXtreme programming (XP) - An Overview
 
Xp(Xtreme Programming) presentation
Xp(Xtreme Programming) presentationXp(Xtreme Programming) presentation
Xp(Xtreme Programming) presentation
 
extreme programming
extreme programmingextreme programming
extreme programming
 
Myths
MythsMyths
Myths
 
Extreme & pair programming Slides ppt
Extreme & pair programming Slides pptExtreme & pair programming Slides ppt
Extreme & pair programming Slides ppt
 
Introduction To Extreme Programming
Introduction To Extreme ProgrammingIntroduction To Extreme Programming
Introduction To Extreme Programming
 
Going extreme-with-extreme-programming
Going extreme-with-extreme-programmingGoing extreme-with-extreme-programming
Going extreme-with-extreme-programming
 
optimizing code in compilers using parallel genetic algorithm
optimizing code in compilers using parallel genetic algorithm optimizing code in compilers using parallel genetic algorithm
optimizing code in compilers using parallel genetic algorithm
 
Get Smart About Technical Debt
Get Smart About Technical DebtGet Smart About Technical Debt
Get Smart About Technical Debt
 
Xp exterme-programming-model
Xp exterme-programming-modelXp exterme-programming-model
Xp exterme-programming-model
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
Audrys Kažukauskas - Introduction into Extreme Programming
Audrys Kažukauskas - Introduction into Extreme ProgrammingAudrys Kažukauskas - Introduction into Extreme Programming
Audrys Kažukauskas - Introduction into Extreme Programming
 
Extreme programming - a quick and agile overview !
Extreme programming - a quick and agile overview !Extreme programming - a quick and agile overview !
Extreme programming - a quick and agile overview !
 
Agile Software Development with XP
Agile Software Development with XPAgile Software Development with XP
Agile Software Development with XP
 
Extreme Programming (XP)
Extreme Programming (XP)Extreme Programming (XP)
Extreme Programming (XP)
 
Twelve practices of XP_Se lect5 btech
Twelve practices of XP_Se lect5 btechTwelve practices of XP_Se lect5 btech
Twelve practices of XP_Se lect5 btech
 
Xtreme Programming
Xtreme ProgrammingXtreme Programming
Xtreme Programming
 

Similar to Extreme Programming: An Introduction to XP Practices

Xp presentation 2003
Xp presentation 2003Xp presentation 2003
Xp presentation 2003
eaiti
 
eXtreme programming
eXtreme programmingeXtreme programming
eXtreme programming
Jean Pаoli
 
Agile Development Ultimate Slides
Agile Development Ultimate SlidesAgile Development Ultimate Slides
Agile Development Ultimate Slides
gilashikwa
 
Agile Methodologies And Extreme Programming - Svetlin Nakov
Agile Methodologies And Extreme Programming - Svetlin NakovAgile Methodologies And Extreme Programming - Svetlin Nakov
Agile Methodologies And Extreme Programming - Svetlin Nakov
Svetlin Nakov
 
Extreme Programming Talk Wise Consulting Www.Talkwiseconsulting
Extreme  Programming    Talk Wise  Consulting   Www.TalkwiseconsultingExtreme  Programming    Talk Wise  Consulting   Www.Talkwiseconsulting
Extreme Programming Talk Wise Consulting Www.Talkwiseconsulting
talkwiseone
 
Extreme programming talk wise consulting - www.talkwiseconsulting
Extreme programming   talk wise consulting - www.talkwiseconsultingExtreme programming   talk wise consulting - www.talkwiseconsulting
Extreme programming talk wise consulting - www.talkwiseconsulting
talkwiseone
 
Agile Practices in a Traditional Environment
Agile Practices in a Traditional EnvironmentAgile Practices in a Traditional Environment
Agile Practices in a Traditional Environment
Markus Gärtner
 

Similar to Extreme Programming: An Introduction to XP Practices (20)

Periodic Table of Agile Principles and Practices
Periodic Table of Agile Principles and PracticesPeriodic Table of Agile Principles and Practices
Periodic Table of Agile Principles and Practices
 
Xp presentation 2003
Xp presentation 2003Xp presentation 2003
Xp presentation 2003
 
eXtreme programming
eXtreme programmingeXtreme programming
eXtreme programming
 
Agile Values, Principles and Practices
Agile Values, Principles and PracticesAgile Values, Principles and Practices
Agile Values, Principles and Practices
 
Agile Development Ultimate Slides
Agile Development Ultimate SlidesAgile Development Ultimate Slides
Agile Development Ultimate Slides
 
Agile Methodologies And Extreme Programming
Agile Methodologies And Extreme ProgrammingAgile Methodologies And Extreme Programming
Agile Methodologies And Extreme Programming
 
xTreme Programming by Sejo Ćesić and Enis Zeherović
xTreme Programming by Sejo Ćesić and Enis ZeherovićxTreme Programming by Sejo Ćesić and Enis Zeherović
xTreme Programming by Sejo Ćesić and Enis Zeherović
 
xp.ppt programming softwares engineering
xp.ppt programming softwares engineeringxp.ppt programming softwares engineering
xp.ppt programming softwares engineering
 
Agile Methodologies And Extreme Programming - Svetlin Nakov
Agile Methodologies And Extreme Programming - Svetlin NakovAgile Methodologies And Extreme Programming - Svetlin Nakov
Agile Methodologies And Extreme Programming - Svetlin Nakov
 
Extreme Programming Talk Wise Consulting Www.Talkwiseconsulting
Extreme  Programming    Talk Wise  Consulting   Www.TalkwiseconsultingExtreme  Programming    Talk Wise  Consulting   Www.Talkwiseconsulting
Extreme Programming Talk Wise Consulting Www.Talkwiseconsulting
 
Extreme programming talk wise consulting - www.talkwiseconsulting
Extreme programming   talk wise consulting - www.talkwiseconsultingExtreme programming   talk wise consulting - www.talkwiseconsulting
Extreme programming talk wise consulting - www.talkwiseconsulting
 
Agile Practices in a Traditional Environment
Agile Practices in a Traditional EnvironmentAgile Practices in a Traditional Environment
Agile Practices in a Traditional Environment
 
Ch04
Ch04Ch04
Ch04
 
Notes on Distributed Agile for Agile Boston 7/29/09
Notes on Distributed Agile for Agile Boston 7/29/09Notes on Distributed Agile for Agile Boston 7/29/09
Notes on Distributed Agile for Agile Boston 7/29/09
 
Notes on Distributed Agile for Agile Boston 7/29/09
Notes on Distributed Agile for Agile Boston 7/29/09Notes on Distributed Agile for Agile Boston 7/29/09
Notes on Distributed Agile for Agile Boston 7/29/09
 
Human computer interaction research at ibm t
Human computer interaction research at ibm tHuman computer interaction research at ibm t
Human computer interaction research at ibm t
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software Engineering
 
Domain Driven Design Introduction
Domain Driven Design IntroductionDomain Driven Design Introduction
Domain Driven Design Introduction
 
Agile software development
Agile software developmentAgile software development
Agile software development
 
How Dealogic Scaled Agile &; Delivers Effectively
How Dealogic Scaled Agile &; Delivers EffectivelyHow Dealogic Scaled Agile &; Delivers Effectively
How Dealogic Scaled Agile &; Delivers Effectively
 

More from David Hanson

More from David Hanson (15)

Agile Maturity Assessments
Agile Maturity AssessmentsAgile Maturity Assessments
Agile Maturity Assessments
 
Relative Estimation: Exercises & Illustrations
Relative Estimation: Exercises & IllustrationsRelative Estimation: Exercises & Illustrations
Relative Estimation: Exercises & Illustrations
 
Root Cause Analysis
Root Cause AnalysisRoot Cause Analysis
Root Cause Analysis
 
Backlog Refinement 101 & 202
Backlog Refinement 101 & 202Backlog Refinement 101 & 202
Backlog Refinement 101 & 202
 
WIP: A Couple Exercises and Some Simple Math
WIP: A Couple Exercises and Some Simple MathWIP: A Couple Exercises and Some Simple Math
WIP: A Couple Exercises and Some Simple Math
 
Lean Software 101
Lean Software 101Lean Software 101
Lean Software 101
 
Exercises in Self-management
Exercises in Self-managementExercises in Self-management
Exercises in Self-management
 
Unplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitableUnplanned Work: Options for managing the inevitable
Unplanned Work: Options for managing the inevitable
 
Scrum of Scrums Patterns Library
Scrum of Scrums Patterns LibraryScrum of Scrums Patterns Library
Scrum of Scrums Patterns Library
 
What is wrong with Jira? My top 20 for 2020.
What is wrong with Jira?  My top 20 for 2020.What is wrong with Jira?  My top 20 for 2020.
What is wrong with Jira? My top 20 for 2020.
 
Scaled Agile Survey
Scaled Agile SurveyScaled Agile Survey
Scaled Agile Survey
 
The Way Forward: A Scaled Agile Experience
The Way Forward: A Scaled Agile ExperienceThe Way Forward: A Scaled Agile Experience
The Way Forward: A Scaled Agile Experience
 
Managing Multiple Priorities
Managing Multiple PrioritiesManaging Multiple Priorities
Managing Multiple Priorities
 
Epic Estimation 2019
Epic Estimation 2019Epic Estimation 2019
Epic Estimation 2019
 
Kanban 101
Kanban 101Kanban 101
Kanban 101
 

Recently uploaded

Jax, FL Admin Community Group 05.14.2024 Combined Deck
Jax, FL Admin Community Group 05.14.2024 Combined DeckJax, FL Admin Community Group 05.14.2024 Combined Deck
Jax, FL Admin Community Group 05.14.2024 Combined Deck
Marc Lester
 

Recently uploaded (20)

Software Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements EngineeringSoftware Engineering - Introduction + Process Models + Requirements Engineering
Software Engineering - Introduction + Process Models + Requirements Engineering
 
Prompt Engineering - an Art, a Science, or your next Job Title?
Prompt Engineering - an Art, a Science, or your next Job Title?Prompt Engineering - an Art, a Science, or your next Job Title?
Prompt Engineering - an Art, a Science, or your next Job Title?
 
What is a Recruitment Management Software?
What is a Recruitment Management Software?What is a Recruitment Management Software?
What is a Recruitment Management Software?
 
architecting-ai-in-the-enterprise-apis-and-applications.pdf
architecting-ai-in-the-enterprise-apis-and-applications.pdfarchitecting-ai-in-the-enterprise-apis-and-applications.pdf
architecting-ai-in-the-enterprise-apis-and-applications.pdf
 
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...
COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...
 
Evolving Data Governance for the Real-time Streaming and AI Era
Evolving Data Governance for the Real-time Streaming and AI EraEvolving Data Governance for the Real-time Streaming and AI Era
Evolving Data Governance for the Real-time Streaming and AI Era
 
Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024Automate your OpenSIPS config tests - OpenSIPS Summit 2024
Automate your OpenSIPS config tests - OpenSIPS Summit 2024
 
Jax, FL Admin Community Group 05.14.2024 Combined Deck
Jax, FL Admin Community Group 05.14.2024 Combined DeckJax, FL Admin Community Group 05.14.2024 Combined Deck
Jax, FL Admin Community Group 05.14.2024 Combined Deck
 
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jGraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
 
Abortion Clinic Pretoria ](+27832195400*)[ Abortion Clinic Near Me ● Abortion...
Abortion Clinic Pretoria ](+27832195400*)[ Abortion Clinic Near Me ● Abortion...Abortion Clinic Pretoria ](+27832195400*)[ Abortion Clinic Near Me ● Abortion...
Abortion Clinic Pretoria ](+27832195400*)[ Abortion Clinic Near Me ● Abortion...
 
Transformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with LinksTransformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with Links
 
A Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdfA Deep Dive into Secure Product Development Frameworks.pdf
A Deep Dive into Secure Product Development Frameworks.pdf
 
BusinessGPT - Security and Governance for Generative AI
BusinessGPT  - Security and Governance for Generative AIBusinessGPT  - Security and Governance for Generative AI
BusinessGPT - Security and Governance for Generative AI
 
Modern binary build systems - PyCon 2024
Modern binary build systems - PyCon 2024Modern binary build systems - PyCon 2024
Modern binary build systems - PyCon 2024
 
Auto Affiliate AI Earns First Commission in 3 Hours..pdf
Auto Affiliate  AI Earns First Commission in 3 Hours..pdfAuto Affiliate  AI Earns First Commission in 3 Hours..pdf
Auto Affiliate AI Earns First Commission in 3 Hours..pdf
 
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
 
^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto
^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto
^Clinic ^%[+27788225528*Abortion Pills For Sale In soweto
 
Encryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key ConceptsEncryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key Concepts
 
Workshop: Enabling GenAI Breakthroughs with Knowledge Graphs - GraphSummit Milan
Workshop: Enabling GenAI Breakthroughs with Knowledge Graphs - GraphSummit MilanWorkshop: Enabling GenAI Breakthroughs with Knowledge Graphs - GraphSummit Milan
Workshop: Enabling GenAI Breakthroughs with Knowledge Graphs - GraphSummit Milan
 
From Theory to Practice: Utilizing SpiraPlan's REST API
From Theory to Practice: Utilizing SpiraPlan's REST APIFrom Theory to Practice: Utilizing SpiraPlan's REST API
From Theory to Practice: Utilizing SpiraPlan's REST API
 

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
  • 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

Editor's Notes

  1. 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.
  2. 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
  3. 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
  4. Inner circle: incremental work Middle circle: framework for success Outer circle: interaction with users
  5. 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
  6. If smaller releases have lower risk with early value, then why not release every iteration or better yet every story Bugs fixed next iteration
  7. 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
  8. 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.
  9. 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.
  10. If code reviews are good, then why not work in pairs so code is reviewed while written Drivers focus tactical; navigators focus strategic
  11. If common standards improve to interoperability, why not set coding standards leading to interoperable team members
  12. If code merges and integrated testing is difficult but critical, then why not integrate as soon as possible Single code base or stream
  13. If architecture is challenging, then why not use a metaphor to keep everyone thinking about design
  14. If simplicity is better than complexity, they why not keep the design as simple as it could be Don’t Repeat Yourself
  15. If important to refactor code and tests, why not refactor with every story and every build Major refactoring can be tackled over time incrementally
  16. 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.
  17. 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?
  18. 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.
  19. 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
  20. Others: scaling to team of teams and team of team of teams; big room planning
  21. On back of card, would outline acceptance criteria for verifying practice adoption.
  22. 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