Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile methods series (xp)
Similar to Agile methods series (xp) (20)
More from XPDays
More from XPDays (18)
Recently uploaded
Recently uploaded (20)
Agile methods series (xp)
- 1. Agile Methods Series eXtreme Programming (XP)
- 2. Ahmed Helmy • Software Consultant • Certified Scrum Master • Certified Scrum Developer • Certified Scrum Product Owner @helmy204 ahmedhelmy204@hotmail.com www.linkedin.com/in/helmy204 www.github.com/helmy204
- 3. Agenda • From Agile Manifesto • The Basic Problem • Agile Methodologies • eXtreme Programming (XP) • XP Framework • Practices • Activities • Values • Principles • Rules • Roles
- 4. Who are the Geeks!
- 5. Manifesto for Agile Software Development https://agilemanifesto.org/
- 6. Risk The Basic Problem Schedule slips Project canceled System goes sour Defect rate Business misunderstood Business changes False feature rich Staff turnover
- 7. Most Used Agile Methods
- 8. If everything seems under control You’re not going fast enough - Mario Anderetti
- 9. What is eXtreme Programming? XP aims to produce higher quality software using appropriate engineering practices Agile Software Development Methodology Lightweight Efficient Low-risk
- 10. Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way https://www.freepik.com/free-vector/curve-winding-roadway-background_4724894.htm
- 11. How would you program if you had enough time? Write tests Restructure the system Pair programming Talk with the customer often Now, you can’t have extra time, because this is business after all, and we are certainly playing to win
- 13. XP Practices • Fine-scale feedback • Pair programming • The Planning Game • Testing
- 14. You don’t choose whether or not you will write tests – if you don’t, you aren’t extreme: end of discussion. Extreme Programming Explained: Embrace Change https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658
- 15. XP Practices • Fine-scale feedback • Pair programming • The Planning Game • Testing • On-site customer • Continuous process • Continuous integration • Refactoring • Small releases
- 16. If it’s easier to change it, you’re more likely to improve it
- 17. XP Practices • Fine-scale feedback • Pair programming • The Planning Game • Testing • On-site customer • Continuous process • Continuous integration • Refactoring • Small releases • Shared understanding • Coding standards • Collective ownership • Simple design • Metaphor • Programmer welfare • 40 hour week
- 18. Steve Jobs, 1998 That's been one of my mantras — focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains.
- 19. XP Practices
- 20. XP Framework • 12 x Practices (Fine-scale Feedback, Continuous Process, Shared Understanding, Programmer Welfare)
- 22. XP Framework • 12 x Practices (Fine-scale Feedback, Continuous Process, Shared Understanding, Programmer Welfare) • 4 x Activities (Coding, Testing, Listening, Designing)
- 23. XP Values Communication Simplicity Feedback Courage Respect
- 24. XP Framework • 12 x Practices (Fine-scale Feedback, Continuous Process, Shared Understanding, Programmer Welfare) • 4 x Activities (Coding, Testing, Listening, Designing) • 5 x Values (Communication, Simplicity, Feedback, Courage, Respect)
- 25. XP Principles Rapid feedback Assume simplicity Incremental change Other Embracing change Quality work Teach learning Small initial investment Play to win Concrete experiments Open, honest communication Work with people’s instincts, not against them Accepted responsibility Local adaption Travel light Honest measurement
- 26. XP Framework • 12 x Practices (Fine-scale Feedback, Continuous Process, Shared Understanding, Programmer Welfare) • 4 x Activities (Coding, Testing, Listening, Designing) • 5 x Values (Communication, Simplicity, Feedback, Courage, Respect) • 3 x Principles (Rapid feedback, Assume simplicity, Incremental change) + 12
- 27. XP Rules Planning User stories are written Release planning Make frequent small releases Project divided into iterations Iteration planning starts each iteration Managing Give the team an open work space Set a sustainable pace A stand-up meeting starts each day The project velocity is measured Move people around Fix XP when it breaks Designing Simplicity Choose a system metaphor Use (Class Responsibility Collaborator) CRC cards for design sessions Create spike solutions to reduce risk No functionality is added early Refactor whenever possible Coding Customer is always available Code written to agreed standards Code the unit test first Production code is pair programmed Only one pair integrates code at a time Integrate often Use a dedicated integration machine Use collective ownership Testing All code must have unit tests All code must pass all unit tests When a bug is found tests are created Acceptance tests are run often and the score is published
- 28. XP Framework • 12 x Practices (Fine-scale Feedback, Continuous Process, Shared Understanding, Programmer Welfare) • 4 x Activities (Coding, Testing, Listening, Designing) • 5 x Values (Communication, Simplicity, Feedback, Courage, Respect) • 3 x Principles (Rapid feedback, Assume simplicity, Incremental change) + 12 • 29 x Rules (Planning, Managing, Designing, Coding, Testing)
- 29. XP Roles • The Customer • The Developer • The Tracker • The Coach
- 30. XP Framework • 12 x Practices (Fine-scale Feedback, Continuous Process, Shared Understanding, Programmer Welfare) • 4 x Activities (Coding, Testing, Listening, Designing) • 5 x Values (Communication, Simplicity, Feedback, Courage, Respect) • 3 x Principles (Rapid feedback, Assume simplicity, Incremental change) + 12 • 29 x Rules (Planning, Managing, Designing, Coding, Testing) • 4 x Roles (Customer, Developer, Tracker, Coach)
Editor's Notes
- Software development fails to deliver, and fails to deliver value. This failure has huge economic and human impact. We need to find a new way to develop software.
- XP: Kent Beck Lean: Mary Poppendieck Crystal: Alistair Cockburn Scrum: Schwaber & Sutherland
- “If everything seems under control, You’re not going fast enough” - Mario Anderetti
- XP is lightweight. In XP you only do what you need to do to create value for the customer. You can't carry a lot of baggage and move fast. However, there is no freezedried software process. The body of technical knowledge necessary to be an outstanding team is large and growing. XP is a methodology based on addressing constraints in software development. It does not address project portfolio management, financial justification of projects, operations, marketing, or sales. XP has implications in all of these areas, but does not address these practices directly. Methodology is often interpreted to mean "a set of rules to follow that guarantee success.“ Methodologies don't work like programs. People aren’t computers. Every team does XP differently with varying degrees of success. XP adapts to vague or rapidly changing requirements. XP is still good for this situation, which is fortunate because requirements need to change to adapt to rapid shifts in the modern business world. However, teams have also successfully used XP where requirements don't seem volatile, like porting projects.
- Chapter 6. Learning to Drive We need to control the development of software by making many small adjustments, not by making a few large adjustments, kind of like driving a car. This means that we will need the feedback to know when we are a little off, we will need many opportunities to make corrections, and we will have to be able to make those corrections at a reasonable cost Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way. The driver of software project is the customer. If the software doesn’t do what they want it to do, you have failed. Of course, they don’t know exactly what the software should do. That’s why software development is like steering, not like getting the car pointed straight down the road. Our job as programmers is to give the customer a steering wheel and give them feedback about exactly where we are on the road.
- Mentality of Sufficiency Forest People and Mountain People How would you program if you had enough time? Write tests Restructure the system Pair programming Talk with the customer often Now, you can’t have extra time, because this is business after all, and we are certainly playing to win.
- XP Values We will be successful when we have a style that celebrates a consistent set of values that serve both human and commercial needs: communication, simplicity, feedback, and courage. Communication Bad communication doesn’t happen by chance Practices that make short-term sense, like unit testing, pair programming, and task estimation has an effect that programmers and customers and managers have to communicate Everyone is part of the team and we communicate face-to-face daily Simplicity What is the simplest thing that could possibly work? We will do what is needed and asked for, but no more Feedback Concrete feedback about the current state of the system is absolutely priceless Feedback works at scale of minutes and days (unit tests, new stories estimation, task completion progress Feedback also works at scale of weeks and months (functional tests, team velocity review, early release) XP teams try to shorten the feedback cycle to minutes and hours instead of weeks or months. The sooner you know, the sooner you can adapt We will take every iteration commitment seriously by delivering working software Courage If the end of the day is coming and the code is a little out of control, toss it The courage to speak truths, discard failing solutions and seek new ones, seek real concrete answers To do the right thing and work on tough problems We will tell the truth about progress and estimates Respect Team members cares about each other and about the project Team members respect each other to be capable, independent people Everyone gives and feels the respect they deserve as a valued team member Exercise: Put each statement under the related value Bad communication doesn’t happen by chance Practices that make short-term sense, like unit testing, pair programming, and task estimation has an effect that programmers and customers and managers have to communicate Everyone is part of the team and we communicate face-to-face daily What is the simplest thing that could possibly work? We will do what is needed and asked for, but no more Concrete feedback about the current state of the system is absolutely priceless Feedback works at scale of minutes and days (unit tests, new stories estimation, task completion progress Feedback also works at scale of weeks and months (functional tests, team velocity review, early release) XP teams try to shorten the feedback cycle to minutes and hours instead of weeks or months. The sooner you know, the sooner you can adapt We will take every iteration commitment seriously by delivering working software If the end of the day is coming and the code is a little out of control, toss it The courage to speak truths, discard failing solutions and seek new ones, seek real concrete answers To do the right thing and work on tough problems We will tell the truth about progress and estimates Team members cares about each other and about the project Team members respect each other to be capable, independent people Everyone gives and feels the respect they deserve as a valued team member
- Small Releases XP teams practice small releases in two important ways: Release running, tested software, delivering business value chosen by the Customer, every iteration. The Customer can use this software for any purpose, whether evaluation or even release to end users. Release to end users frequently as well. Web projects release as often as daily, in house projects monthly or more frequently. Even shrink-wrapped products are shipped as often as quarterly. Metaphor “A metaphor is meant to be agreed upon by all members of a project as a means of simply explaining the purpose of the project and thus guide the structure of the architecture” Benefits: Communication, including between customers & developers Clarify project, explain functionality Favors simple design Helps find common vocabulary Simple design Do the simplest thing that could possibly work! – Kent Beck Refactor as needed Refactoring “Disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior“ Example refactoring techniques: Encapsulate attribute (field)into function Replace conditional with dynamic binding Extract routine (method) Rename routine or attribute Move routine or attribute to another class Pull up, pull down Used in agile methods as a substitute for upfront design Pair programming Two programmers sitting at one machine Thinking out loud Goals: Make thinking process explicit Keep each other on task Brainstorm refinements to system Clarify ideas Take initiative when other stuck, lowering frustration Hold each other accountable to team practices Collective Ownership Agile methods reject code ownership in favor of code whose responsibility is shared by entire team Rationale: Most non-trivial features extend across many layers in the application Code ownership creates unnecessary dependencies between team members and delays What counts is implemented features, not personal responsibility Avoid blame game Avoid specialization Minimize risk (team members leaving) Continuous Integration The combination of frequent releases with relentless testing Keep system fully integrated at all times Rather than weekly or daily builds, build system several times per day Benefits: Integration is easier because little has changed Team learns more quickly Unexpected interactions rooted out early: conflicts are found while team can still change approach Problematic code more likely to be fixed because more eyes see it sooner Duplication easier to eliminate because visible sooner Coding standards Project members all code to the same conventions
- XP is lightweight. In XP you only do what you need to do to create value for the customer. You can't carry a lot of baggage and move fast. However, there is no freezedried software process. The body of technical knowledge necessary to be an outstanding team is large and growing. XP is a methodology based on addressing constraints in software development. It does not address project portfolio management, financial justification of projects, operations, marketing, or sales. XP has implications in all of these areas, but does not address these practices directly. Methodology is often interpreted to mean "a set of rules to follow that guarantee success.“ Methodologies don't work like programs. People aren’t computers. Every team does XP differently with varying degrees of success. XP adapts to vague or rapidly changing requirements. XP is still good for this situation, which is fortunate because requirements need to change to adapt to rapid shifts in the modern business world. However, teams have also successfully used XP where requirements don't seem volatile, like porting projects.
- Small Releases XP teams practice small releases in two important ways: Release running, tested software, delivering business value chosen by the Customer, every iteration. The Customer can use this software for any purpose, whether evaluation or even release to end users. Release to end users frequently as well. Web projects release as often as daily, in house projects monthly or more frequently. Even shrink-wrapped products are shipped as often as quarterly. Metaphor “A metaphor is meant to be agreed upon by all members of a project as a means of simply explaining the purpose of the project and thus guide the structure of the architecture” Benefits: Communication, including between customers & developers Clarify project, explain functionality Favors simple design Helps find common vocabulary Simple design Do the simplest thing that could possibly work! – Kent Beck Refactor as needed Refactoring “Disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior“ Example refactoring techniques: Encapsulate attribute (field)into function Replace conditional with dynamic binding Extract routine (method) Rename routine or attribute Move routine or attribute to another class Pull up, pull down Used in agile methods as a substitute for upfront design Pair programming Two programmers sitting at one machine Thinking out loud Goals: Make thinking process explicit Keep each other on task Brainstorm refinements to system Clarify ideas Take initiative when other stuck, lowering frustration Hold each other accountable to team practices Collective Ownership Agile methods reject code ownership in favor of code whose responsibility is shared by entire team Rationale: Most non-trivial features extend across many layers in the application Code ownership creates unnecessary dependencies between team members and delays What counts is implemented features, not personal responsibility Avoid blame game Avoid specialization Minimize risk (team members leaving) Continuous Integration The combination of frequent releases with relentless testing Keep system fully integrated at all times Rather than weekly or daily builds, build system several times per day Benefits: Integration is easier because little has changed Team learns more quickly Unexpected interactions rooted out early: conflicts are found while team can still change approach Problematic code more likely to be fixed because more eyes see it sooner Duplication easier to eliminate because visible sooner Coding standards Project members all code to the same conventions
- XP is lightweight. In XP you only do what you need to do to create value for the customer. You can't carry a lot of baggage and move fast. However, there is no freezedried software process. The body of technical knowledge necessary to be an outstanding team is large and growing. XP is a methodology based on addressing constraints in software development. It does not address project portfolio management, financial justification of projects, operations, marketing, or sales. XP has implications in all of these areas, but does not address these practices directly. Methodology is often interpreted to mean "a set of rules to follow that guarantee success.“ Methodologies don't work like programs. People aren’t computers. Every team does XP differently with varying degrees of success. XP adapts to vague or rapidly changing requirements. XP is still good for this situation, which is fortunate because requirements need to change to adapt to rapid shifts in the modern business world. However, teams have also successfully used XP where requirements don't seem volatile, like porting projects.
- Small Releases XP teams practice small releases in two important ways: Release running, tested software, delivering business value chosen by the Customer, every iteration. The Customer can use this software for any purpose, whether evaluation or even release to end users. Release to end users frequently as well. Web projects release as often as daily, in house projects monthly or more frequently. Even shrink-wrapped products are shipped as often as quarterly. Metaphor “A metaphor is meant to be agreed upon by all members of a project as a means of simply explaining the purpose of the project and thus guide the structure of the architecture” Benefits: Communication, including between customers & developers Clarify project, explain functionality Favors simple design Helps find common vocabulary Simple design Do the simplest thing that could possibly work! – Kent Beck Refactor as needed Refactoring “Disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior“ Example refactoring techniques: Encapsulate attribute (field)into function Replace conditional with dynamic binding Extract routine (method) Rename routine or attribute Move routine or attribute to another class Pull up, pull down Used in agile methods as a substitute for upfront design Pair programming Two programmers sitting at one machine Thinking out loud Goals: Make thinking process explicit Keep each other on task Brainstorm refinements to system Clarify ideas Take initiative when other stuck, lowering frustration Hold each other accountable to team practices Collective Ownership Agile methods reject code ownership in favor of code whose responsibility is shared by entire team Rationale: Most non-trivial features extend across many layers in the application Code ownership creates unnecessary dependencies between team members and delays What counts is implemented features, not personal responsibility Avoid blame game Avoid specialization Minimize risk (team members leaving) Continuous Integration The combination of frequent releases with relentless testing Keep system fully integrated at all times Rather than weekly or daily builds, build system several times per day Benefits: Integration is easier because little has changed Team learns more quickly Unexpected interactions rooted out early: conflicts are found while team can still change approach Problematic code more likely to be fixed because more eyes see it sooner Duplication easier to eliminate because visible sooner Coding standards Project members all code to the same conventions
- XP Values We will be successful when we have a style that celebrates a consistent set of values that serve both human and commercial needs: communication, simplicity, feedback, and courage. Communication Bad communication doesn’t happen by chance Practices that make short-term sense, like unit testing, pair programming, and task estimation has an effect that programmers and customers and managers have to communicate Everyone is part of the team and we communicate face-to-face daily Simplicity What is the simplest thing that could possibly work? We will do what is needed and asked for, but no more Feedback Concrete feedback about the current state of the system is absolutely priceless Feedback works at scale of minutes and days (unit tests, new stories estimation, task completion progress Feedback also works at scale of weeks and months (functional tests, team velocity review, early release) XP teams try to shorten the feedback cycle to minutes and hours instead of weeks or months. The sooner you know, the sooner you can adapt We will take every iteration commitment seriously by delivering working software Courage If the end of the day is coming and the code is a little out of control, toss it The courage to speak truths, discard failing solutions and seek new ones, seek real concrete answers To do the right thing and work on tough problems We will tell the truth about progress and estimates Respect Team members cares about each other and about the project Team members respect each other to be capable, independent people Everyone gives and feels the respect they deserve as a valued team member Exercise: Put each statement under the related value Bad communication doesn’t happen by chance Practices that make short-term sense, like unit testing, pair programming, and task estimation has an effect that programmers and customers and managers have to communicate Everyone is part of the team and we communicate face-to-face daily What is the simplest thing that could possibly work? We will do what is needed and asked for, but no more Concrete feedback about the current state of the system is absolutely priceless Feedback works at scale of minutes and days (unit tests, new stories estimation, task completion progress Feedback also works at scale of weeks and months (functional tests, team velocity review, early release) XP teams try to shorten the feedback cycle to minutes and hours instead of weeks or months. The sooner you know, the sooner you can adapt We will take every iteration commitment seriously by delivering working software If the end of the day is coming and the code is a little out of control, toss it The courage to speak truths, discard failing solutions and seek new ones, seek real concrete answers To do the right thing and work on tough problems We will tell the truth about progress and estimates Team members cares about each other and about the project Team members respect each other to be capable, independent people Everyone gives and feels the respect they deserve as a valued team member
- XP is lightweight. In XP you only do what you need to do to create value for the customer. You can't carry a lot of baggage and move fast. However, there is no freezedried software process. The body of technical knowledge necessary to be an outstanding team is large and growing. XP is a methodology based on addressing constraints in software development. It does not address project portfolio management, financial justification of projects, operations, marketing, or sales. XP has implications in all of these areas, but does not address these practices directly. Methodology is often interpreted to mean "a set of rules to follow that guarantee success.“ Methodologies don't work like programs. People aren’t computers. Every team does XP differently with varying degrees of success. XP adapts to vague or rapidly changing requirements. XP is still good for this situation, which is fortunate because requirements need to change to adapt to rapid shifts in the modern business world. However, teams have also successfully used XP where requirements don't seem volatile, like porting projects.
- XP is lightweight. In XP you only do what you need to do to create value for the customer. You can't carry a lot of baggage and move fast. However, there is no freezedried software process. The body of technical knowledge necessary to be an outstanding team is large and growing. XP is a methodology based on addressing constraints in software development. It does not address project portfolio management, financial justification of projects, operations, marketing, or sales. XP has implications in all of these areas, but does not address these practices directly. Methodology is often interpreted to mean "a set of rules to follow that guarantee success.“ Methodologies don't work like programs. People aren’t computers. Every team does XP differently with varying degrees of success. XP adapts to vague or rapidly changing requirements. XP is still good for this situation, which is fortunate because requirements need to change to adapt to rapid shifts in the modern business world. However, teams have also successfully used XP where requirements don't seem volatile, like porting projects.
- Programmer Turn customer stories into working code Developer Obligations Know and understand technical issues Create and maintain the system as it evolves Answer: “How will we implement it?”, “How long will it take?” & “What are the risks?” Work with customer to understand his stories From a story, decide implementation Estimate work for each story, based on implementation decisions & experience Identify features that depend on other features Identify risky features and report them to customer Follow team guidelines Implement only what is necessary Communicate constantly with customers Developer Rights Estimate own work Work sensible & predictable schedule, by scheduling only work that can be done Produce code that meets the customer’s needs, by focusing on testing, refactoring, and customer communication Avoid need to make business decisions, by allowing the customer to make them Customer in XP Trust developers’ technical decisions, because developers understand technology Analyze risk correctly, weighing stories against each other Provide precise stories, enabling developers to produce comprehensive task cards and accurate estimates Choose stories with maximum value, scheduling the most valuable stories that could possibly fit in to next iteration Work within team, providing guidance and receiving feedback as quickly and accurately as possible The programmer knows how to program; The customer knows what to program Tracker Keeps track of the schedule Most important metric Velocity: ratio of ideal time estimated for tasks to actual time spent implementing them Other important data: Changes in velocity Amount of overtime worked Ratio of passing to failing tests These numbers measure progress and the rate of progress and help determine if the project is on schedule for the iteration To measure velocity within the iteration, every day or two, the tracker asks each developer how many tasks he has completed His job is to close the loop on feedback Keep a log of functional test scores Keep a log of defects Ability to collect the information you need without disturbing the whole process more than necessary Coach (Optional role) Guides team Mentors team Leads by example Teaches when necessary May teach by doing May offer ideas to solve thorny problems May serve as intermediary with management In Scrum: this role is mostly taken on by the ScrumMaster
- XP Values We will be successful when we have a style that celebrates a consistent set of values that serve both human and commercial needs: communication, simplicity, feedback, and courage. Communication Bad communication doesn’t happen by chance Practices that make short-term sense, like unit testing, pair programming, and task estimation has an effect that programmers and customers and managers have to communicate Everyone is part of the team and we communicate face-to-face daily Simplicity What is the simplest thing that could possibly work? We will do what is needed and asked for, but no more Feedback Concrete feedback about the current state of the system is absolutely priceless Feedback works at scale of minutes and days (unit tests, new stories estimation, task completion progress Feedback also works at scale of weeks and months (functional tests, team velocity review, early release) XP teams try to shorten the feedback cycle to minutes and hours instead of weeks or months. The sooner you know, the sooner you can adapt We will take every iteration commitment seriously by delivering working software Courage If the end of the day is coming and the code is a little out of control, toss it The courage to speak truths, discard failing solutions and seek new ones, seek real concrete answers To do the right thing and work on tough problems We will tell the truth about progress and estimates Respect Team members cares about each other and about the project Team members respect each other to be capable, independent people Everyone gives and feels the respect they deserve as a valued team member Exercise: Put each statement under the related value Bad communication doesn’t happen by chance Practices that make short-term sense, like unit testing, pair programming, and task estimation has an effect that programmers and customers and managers have to communicate Everyone is part of the team and we communicate face-to-face daily What is the simplest thing that could possibly work? We will do what is needed and asked for, but no more Concrete feedback about the current state of the system is absolutely priceless Feedback works at scale of minutes and days (unit tests, new stories estimation, task completion progress Feedback also works at scale of weeks and months (functional tests, team velocity review, early release) XP teams try to shorten the feedback cycle to minutes and hours instead of weeks or months. The sooner you know, the sooner you can adapt We will take every iteration commitment seriously by delivering working software If the end of the day is coming and the code is a little out of control, toss it The courage to speak truths, discard failing solutions and seek new ones, seek real concrete answers To do the right thing and work on tough problems We will tell the truth about progress and estimates Team members cares about each other and about the project Team members respect each other to be capable, independent people Everyone gives and feels the respect they deserve as a valued team member