Introduction

• Software development methodology associated with Agile

methodology
• Allow small - mid sized teams to adapt to evolving and changing
eXtreme requirements
Programming • Emphasizes on the technical aspects of software development
(XP) • Collection of good practices taken into an extreme
• pair programming is good, let’s do it all of the time
ARIF NURWIDYANTORO
• testing early is good, let’s test before the production code was written

Brief History Core Components

• eXtreme Programming (XP) was created by Kent Beck

• During his work on the C3 (Chrysler’s Comprehensive Compensation) Project
• Formalized the practices, principles, and values of XP into a book Values Principles Practices
• Extreme Programming Explained: Embrace Change
• Published in 1999
• Kent Beck became one of the 17 original signatories of the Agile • Values bring purpose to Practices
Manifesto • Practices are evidence of Values
• Principles provide guidelines, bridging the gap between Values and Practices
XP Values XP Values - Communication

• Provide purpose to teams, guide decisions in a high-level way • Avoid lack of communication
• yet abstract and too fuzzy for specific guidance • Lack of communication can
• The values of XP • Prevents knowledge flowing within the team
• Someone may know how to solve the problem
• Communication
• Simplicity • Employing many practices that could not be carried out without
• Feedback communication
• e.g., pair programming, unit testing
• Respect
• Courage • Employs a “Coach”: noticing when people are not communicating and
reintroduce them

XP Values - Simplicity XP Values - Feedback

• Always strive to “do the simplest thing that could possibly works” • Unlike more traditional, waterfall software development
• DTSTTCPW methodologies
• Not only the simplest thing • Too little: Not enough feedback
• Too late: At the end of development stage
• Often ignoring the “that works” part
• Receive early, constant feedback
• Simplicity is contextual
• If there is a problem, the team needs to know as soon as possible
• Everyone has their own skills, experience, and knowledge
• Simple for a person may mean complex for another • Unit tests: provide feedback on a minute time scale
• Customer reviews: scheduled every 2-3 weeks
XP Values - Feedback XP - Courage

• In a pair programming, the comments from peers are vital • “Effective action in the face of fear” (Kent Beck)
• Also from other team members, including the customer • Many opportunities to be afraid and plenty opportunities to show
• Tests become another source of feedack courage
• Whether writing tests is easy or hard is feedback too • Speak the truth, esp. the unpleasant ones
• If writing the tests is hard, maybe the design is too complex • Giving and receiving feedback
• Feedback can be too much too handle • Discard a failing solution
• May result in missing important feedback • Still need to take the consequences into consideration
• Slow down

XP Values - Respect XP Principles

• Everyone cares about their work • Provide more specific guidance than values
• Every person is worthy of dignity and respect • Principles:
• Including customers and users of the project • Humanity, Economics, Mutual benefit, Self-similarity, Improvement, Diversity,
Reflection, Flow, Opportunity, Redundancy, Failure, Quality, Baby Steps,
Accepted Responsibilities
XP Principles XP Principles

• Humanity • Mutual Benefit

• Put human perspectives into software • Must benefit all, not only benefit one party
• Taking human basic needs, strengths, and weaknesses into consideration • Solution: using automated acceptance tests
during software development • Self-similarity
• Economics • if a given solution works at a level, it might also work at the other elvels
• E.g., obtaining early and constant feedback is beneficial in every level
• Assess the economic risks and needs of the project
• Developer level: Programmer receives feedbacks using the test-first approach
• Every action should have business values • Team level: the continuous integration integrated, builds, and tests the codes several
times a day
• Organization level: the weekly and quarterly cycles allow teams to get feedbacks and
improve their work

XP Principles XP Principles

• Improvement • Reflection
• Teams do not strive for perfection in an initial implementation, but just good • Reflect on work and analyze how to be better
enough • Both logical anaysis and feelings
• Improve upon the impementation with feedbacks from real users
• Flow
• Diversity • Activities in XP happen all of the time, in a consistent “flow” of value
• Teams benefit from a diversity of perspectives, skills, and attitudes • Unlike traditional methodologies that have discrete phases
• Conflict and disagreement are opportunities for better ideas
• As long as everyone plays by the values or courage and respects
XP Principles XP Principles

• Opportunity • Failure
• Problems could become opportunities for improvement • Is not a waste when results in knowledge
• A good perspective to come up with creative, goal-oriented solutions • Acting on failures and quickly learning from it is more productive
• Redundancy • Quality
• If a given problem is critical, employ many tactics to counter it • Pushing for quality improvements to make the team goes faster
• Solution in XP: stack a bunch of quality measures • E.g., refactoring: make the code easier to understand and change -> less likely
• Pair programming, tests, continuous integration to introduce defects and bugs, deliver sooner

XP Principles XP Practices

• Baby Steps • Primary

• Big changes are risky • Sit together/Whole team, informative workspaces, energized works, pair
• Do changes in tiny steps, at all levels programming, stories, weekly/quarterly cycle, slack, 10 minute build,
• E.g., programmers write code in tiny steps using test-driven development continuous integration, test-first programming, incremental design

• Accepted Responsibility • Corollary

• Responsibility should be accepted, never assigned • Real customer involvement, incremental deployment, team continuity,
shrinking teams, root cause analysis, shared code, code and tests, single code
• Should be accompanied by the authority to make decisions on what you are
base, daily deployment, negotiated scope contract
responsible for
XP Practices - Software Engineering XP Practices - Software Engineering

• Pair Programming
• Write code in pairs sitting at one machine
• The pair talk to each other while analyzing, implementing, and testing the
feature they are working on
• Effective, engaging, fun, and tiring
• Ten Minute Build
• The CI server is expected to buid the whole project in ten minutes at most
• including running all the automated tests
• Keep the tests lean and focused

XP Practices - Software Engineering XP Practices - Software Engineering

• Test-First Programming • Incremental Design

• Also called Test-Driven Development (TDD) • Must invest in the application design every day
• The cycle: • Remove duplication and make small improvements
• Write a failing test
• Write a production code to make the test pass • Continuous Integration
• If necessary, refactor the production code to make it cleaner and easier to understand • Integrate a programmer’s work to the shared main repository many times a
• Benefits day
• Provide feedback if we need to simplify the design
• Triggering an automatic build of the whole system
• Allow programmers to trust the code they write
• Ensure 100% code coverage -> safety net for future changes, encouraging code • Integrate as early and often as possible
refactoring, and circle of quality • reduces the cost of integration, make it less likely for merge or logical conflicts to occur
XP Practices - Software Engineering XP Practices - Software Engineering

• Shared Code (Collective Ownership) • Daily Deployment

• Every developer is responsible for all of the code • Deploying to production at least once a day -> from CI
• Encourages an exchange of information, thus increasing the overall quality • Now, some teams practice continuous deployment
• Single Code Base • Code and Tests
• There is only one single source of truth • Source code and tests are the only permanent artefacts of a software project
• Merge contributions to the single stream early and frequently • Putting effort into generating other types of artefacts (e.g., documentation) is
often a waste
• Strive to generate other artefacts from the production code and the tests

XP Practices - Software Engineering XP Practices - Work Environment

• Root-Cause Analysis • Sit Together

• If a defect found, do not just fix the defect • Teams favor working together in an open space
• Ensure understand the cause and why the team cannot prevent it • Encourage communication and the sense of belonging of a team
• Take steps to ensure it won’t happen again • Whole Team
• Everyone who is needed for the success of the project is a part of the XP team
XP Practices - Work Environment XP Practices - Work Environment

• Informative Workspaces
• Use the team’s physical space to display information
• Let anyone know, at a glance, the progress of the project
• Could use physical notes and charts, screens with Kanban Boards, etc.
• Energized Work
• Work only as long as the person can do energized work
• Limited to 40 hours a week at most

XP Practices - Work Environment XP Practices - Work Environment

XP Practices - Project Management XP Practices - Project Management

• Stories • Cycles (Quarterly and Weekly)

• Write user requirements in user stories format • Weekly cycle
• Short descriptive name and brief description of what is to be implemented • Starts with a meeting with customers choosing which stories they want to implement
during the week
• Slack • The team reviews their work, including last week progress, and how to improve it
• When planning for a cycle, add minor tasks that can be dropped if necessary • Quarterly cycle
• More stories could be added to the over-delivers team • The team reflects and identifies opportunities for improvement in their process
• The customer picks one or more themes for the quarter, along with stories in the themes

XP Project XP Project Iteration

XP Project Development XP Project Coding

Roles and Responsibilities Roles and Responsibilities

• Customer • Coach
• Real customers on-site to answer questions, prioritizes user stories, and • Is not mandatory
collaborate with acceptance testing • Ensure the team members follow the practices and turn them into habits
• Could be fulfilled by a customer representative
• Tracker
• Programmers • Tracks the team’s progress metrics and talks with every team member to
• Estimate the effort needed to complete tasks and stories identify roadblocks and figure out solutions
• Write automated tests • Calculate the metrics indicating how well the team is doing (e.g., velocity and
• Implement the stories burndown charts)
XP vs Scrum References

• Scrum is more general • https://www.digite.com/agile/extreme-programming-xp/

• Does not dictate how developers do the work • https://www.slideshare.net/DamianGordon1/the-extreme-
• Helping any teams develop complex projects in an adaptive manner programming-xp-model
• Could be applied to any projects
• https://www.slideshare.net/nashjain/introduction-to-extreme-
• XP emphasizes on good programming practices programming
• Thus, it is possible and recommended to use XP and Scrum together