1. Agile Development and Extreme Programming Svetlin Nakov National Academy for Software Development academy.devbg.org

2. AgendaAgenda Development MethodologiesDevelopment Methodologies Agile DevelopmentAgile Development Extreme Programming (XP)Extreme Programming (XP) How It Works for Me?How It Works for Me? Develop Your Own MethodologyDevelop Your Own Methodology Development MethodologiesDevelopment Methodologies Agile DevelopmentAgile Development Extreme Programming (XP)Extreme Programming (XP) How It Works for Me?How It Works for Me? Develop Your Own MethodologyDevelop Your Own Methodology

3. Development Methodologies Development Methodologies

4. What is a Methodology? A methodology is a formalized process or set of practices for creating softwareA methodology is a formalized process or set of practices for creating software A set of rules you have to followA set of rules you have to follow A set of conventions the organization decides to followA set of conventions the organization decides to follow A systematical, engineering approach for organizing software projectsA systematical, engineering approach for organizing software projects A methodology is a formalized process or set of practices for creating softwareA methodology is a formalized process or set of practices for creating software A set of rules you have to followA set of rules you have to follow A set of conventions the organization decides to followA set of conventions the organization decides to follow A systematical, engineering approach for organizing software projectsA systematical, engineering approach for organizing software projects

5. The Waterfall Development Process

6. The Waterfall Process The traditional development process:The traditional development process: System Requirements Software Requirements Analysis Program Design Coding Testing Operations Or at worst …Or at worst … But this always ends up happening!But this always ends up happening!

7. System Requirements Formal Processes Formal efforts to “fix” the problemFormal efforts to “fix” the problem Software Requirements Analysis Coding Testing Operations Preliminary Design Analysis Program Design Coding Testing Usage Preliminary Design Document UI Design Document Test Plan Final Design Preliminary Design Software Requirements Specification Prelim. Revie w Program Design Revie w Operating Instructions

8. Agile Development

9. Agile Manifesto “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“ [Manifesto for Agile] [Manifesto for Agile] “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“ [Manifesto for Agile] [Manifesto for Agile]

10. IncrementalIncremental Working software over comprehensive documentationWorking software over comprehensive documentation CooperationCooperation Customer collaboration over contract negotiationCustomer collaboration over contract negotiation StraightforwardStraightforward Individuals and interactions over processes and toolsIndividuals and interactions over processes and tools AdaptiveAdaptive Responding to change over following a planResponding to change over following a plan IncrementalIncremental Working software over comprehensive documentationWorking software over comprehensive documentation CooperationCooperation Customer collaboration over contract negotiationCustomer collaboration over contract negotiation StraightforwardStraightforward Individuals and interactions over processes and toolsIndividuals and interactions over processes and tools AdaptiveAdaptive Responding to change over following a planResponding to change over following a plan The Agile Spirit

11. Agile Methodologies eXtreme Programming (XP)eXtreme Programming (XP) ScrumScrum Crystal family of methodologiesCrystal family of methodologies Feature-Driven Development (FDD)Feature-Driven Development (FDD) Adaptive Software Development (ASD)Adaptive Software Development (ASD) Dynamic System Development Model (DSDM)Dynamic System Development Model (DSDM) Agile Unified Process (AUP)Agile Unified Process (AUP) eXtreme Programming (XP)eXtreme Programming (XP) ScrumScrum Crystal family of methodologiesCrystal family of methodologies Feature-Driven Development (FDD)Feature-Driven Development (FDD) Adaptive Software Development (ASD)Adaptive Software Development (ASD) Dynamic System Development Model (DSDM)Dynamic System Development Model (DSDM) Agile Unified Process (AUP)Agile Unified Process (AUP)

12. eXtreme Programming

13. The XP Guru: Kent Beck eXtreme ProgrammingeXtreme Programming The most prominent agile development methodologyThe most prominent agile development methodology eXtreme ProgrammingeXtreme Programming The most prominent agile development methodologyThe most prominent agile development methodology Kent Beck 1 st ed. Oct 1999 2 nd ed. Nov 2004

14. The 12 Key Practices The Planning GameThe Planning Game Small ReleasesSmall Releases MetaphorMetaphor Simple DesignSimple Design Test-Driven DevelopmentTest-Driven Development RefactoringRefactoring Pair ProgrammingPair Programming Collective OwnershipCollective Ownership Continuous IntegrationContinuous Integration 40-Hour Workweek40-Hour Workweek On-site CustomerOn-site Customer Coding StandardsCoding Standards The Planning GameThe Planning Game Small ReleasesSmall Releases MetaphorMetaphor Simple DesignSimple Design Test-Driven DevelopmentTest-Driven Development RefactoringRefactoring Pair ProgrammingPair Programming Collective OwnershipCollective Ownership Continuous IntegrationContinuous Integration 40-Hour Workweek40-Hour Workweek On-site CustomerOn-site Customer Coding StandardsCoding Standards

15. 1. Metaphor Guide all development and conversations with a simple shared story of how the whole system worksGuide all development and conversations with a simple shared story of how the whole system works Gives the team a whole picture of describing the system, where new parts fit, etc.Gives the team a whole picture of describing the system, where new parts fit, etc. Words used to identify technical entities should be chosen from the metaphorWords used to identify technical entities should be chosen from the metaphor The default metaphor is the business domain, and it’s usually just fineThe default metaphor is the business domain, and it’s usually just fine Guide all development and conversations with a simple shared story of how the whole system worksGuide all development and conversations with a simple shared story of how the whole system works Gives the team a whole picture of describing the system, where new parts fit, etc.Gives the team a whole picture of describing the system, where new parts fit, etc. Words used to identify technical entities should be chosen from the metaphorWords used to identify technical entities should be chosen from the metaphor The default metaphor is the business domain, and it’s usually just fineThe default metaphor is the business domain, and it’s usually just fine

16. How It Works for Me? Metaphors are good ideaMetaphors are good idea People should know the business needs and how their work fits in the projectPeople should know the business needs and how their work fits in the project Metaphors are good ideaMetaphors are good idea People should know the business needs and how their work fits in the projectPeople should know the business needs and how their work fits in the project

17. 2. Release Planning Requirements via User StoriesRequirements via User Stories Short cards with natural language description of what a customer wantsShort cards with natural language description of what a customer wants Prioritized by customerPrioritized by customer Resource and risk estimated by developersResource and risk estimated by developers Via “The Planning Game”Via “The Planning Game” Play the Planning Game after each incrementPlay the Planning Game after each increment Requirements via User StoriesRequirements via User Stories Short cards with natural language description of what a customer wantsShort cards with natural language description of what a customer wants Prioritized by customerPrioritized by customer Resource and risk estimated by developersResource and risk estimated by developers Via “The Planning Game”Via “The Planning Game” Play the Planning Game after each incrementPlay the Planning Game after each increment

18. User Stories

19. How It Works for Me? Requirements specification (SRS) is better than user storiesRequirements specification (SRS) is better than user stories Written documentation works well for large projectsWritten documentation works well for large projects I prefer prototyping the user interface as source of documentationI prefer prototyping the user interface as source of documentation Sometimes its is hard to estimate the required resourcesSometimes its is hard to estimate the required resources Small releases have less riskSmall releases have less risk Requirements specification (SRS) is better than user storiesRequirements specification (SRS) is better than user stories Written documentation works well for large projectsWritten documentation works well for large projects I prefer prototyping the user interface as source of documentationI prefer prototyping the user interface as source of documentation Sometimes its is hard to estimate the required resourcesSometimes its is hard to estimate the required resources Small releases have less riskSmall releases have less risk

20. 3. Testing Test-Driven Development (TDD)Test-Driven Development (TDD) Write tests before codeWrite tests before code Tests are automatedTests are automated Often use xUnit frameworkOften use xUnit framework Must run at 100% before proceedingMust run at 100% before proceeding Acceptance Tests Acceptance Tests Written with the customerWritten with the customer Acts as “contract”Acts as “contract” Measure of progressMeasure of progress Test-Driven Development (TDD)Test-Driven Development (TDD) Write tests before codeWrite tests before code Tests are automatedTests are automated Often use xUnit frameworkOften use xUnit framework Must run at 100% before proceedingMust run at 100% before proceeding Acceptance Tests Acceptance Tests Written with the customerWritten with the customer Acts as “contract”Acts as “contract” Measure of progressMeasure of progress

21. Test-Driven Development Developers write unit tests before codingDevelopers write unit tests before coding Motivates codingMotivates coding Improves design: cohesion and couplingImproves design: cohesion and coupling Provides regression testsProvides regression tests Provides specification by exampleProvides specification by example Developers write unit tests before codingDevelopers write unit tests before coding Motivates codingMotivates coding Improves design: cohesion and couplingImproves design: cohesion and coupling Provides regression testsProvides regression tests Provides specification by exampleProvides specification by example public void TestMultiplication() { Dollar five = Money.dollar(5); AssertEqual(new Dollar(10), five.times(2)); AssertEqual(new Dollar(15), five.times(3)); }

22. How It Works for Me? TDD is good for most projects, not for allTDD is good for most projects, not for all The real world is different: you always need the functionality "for tomorrow"!The real world is different: you always need the functionality "for tomorrow"! I use unit testing for complex logic onlyI use unit testing for complex logic only Testing simple logic is overheadTesting simple logic is overhead TDD is good for most projects, not for allTDD is good for most projects, not for all The real world is different: you always need the functionality "for tomorrow"!The real world is different: you always need the functionality "for tomorrow"! I use unit testing for complex logic onlyI use unit testing for complex logic only Testing simple logic is overheadTesting simple logic is overhead

23. 4. Pair Programming Two software engineers work on one task at one computerTwo software engineers work on one task at one computer The driver has control of the keyboard and mouse and creates the implementationThe driver has control of the keyboard and mouse and creates the implementation The navigator watches the driver’s implementationThe navigator watches the driver’s implementation Identifies defects and participates in on- demand brainstormingIdentifies defects and participates in on- demand brainstorming The roles of driver and observer are periodically rotatedThe roles of driver and observer are periodically rotated Two software engineers work on one task at one computerTwo software engineers work on one task at one computer The driver has control of the keyboard and mouse and creates the implementationThe driver has control of the keyboard and mouse and creates the implementation The navigator watches the driver’s implementationThe navigator watches the driver’s implementation Identifies defects and participates in on- demand brainstormingIdentifies defects and participates in on- demand brainstorming The roles of driver and observer are periodically rotatedThe roles of driver and observer are periodically rotated

24. Pair Programming Pairs produce higher quality codePairs produce higher quality code Pairs complete their tasks fasterPairs complete their tasks faster Pairs enjoy their work morePairs enjoy their work more Pairs feel more confident in their workPairs feel more confident in their work Pairs produce higher quality codePairs produce higher quality code Pairs complete their tasks fasterPairs complete their tasks faster Pairs enjoy their work morePairs enjoy their work more Pairs feel more confident in their workPairs feel more confident in their work

25. How It Works for Me? Pair programming is great for complex and critical logicPair programming is great for complex and critical logic When developers need good concentrationWhen developers need good concentration Where quality is really importantWhere quality is really important Especially during designEspecially during design Reduces time wasting, e.g. ICQ chattingReduces time wasting, e.g. ICQ chatting Trivial tasks can be done aloneTrivial tasks can be done alone Peer reviews instead pair programming is often alternativePeer reviews instead pair programming is often alternative Pair programming is great for complex and critical logicPair programming is great for complex and critical logic When developers need good concentrationWhen developers need good concentration Where quality is really importantWhere quality is really important Especially during designEspecially during design Reduces time wasting, e.g. ICQ chattingReduces time wasting, e.g. ICQ chatting Trivial tasks can be done aloneTrivial tasks can be done alone Peer reviews instead pair programming is often alternativePeer reviews instead pair programming is often alternative

26. 5. Refactoring Improve the design of existing code without changing its functionalityImprove the design of existing code without changing its functionality Relies on unit testing to ensure the code is not brokenRelies on unit testing to ensure the code is not broken Bad smells in code:Bad smells in code: Long method / classLong method / class Duplicate codeDuplicate code Methods does several different things (bad cohesion)Methods does several different things (bad cohesion) Too much dependencies (bad coupling)Too much dependencies (bad coupling) Complex / unreadable codeComplex / unreadable code Improve the design of existing code without changing its functionalityImprove the design of existing code without changing its functionality Relies on unit testing to ensure the code is not brokenRelies on unit testing to ensure the code is not broken Bad smells in code:Bad smells in code: Long method / classLong method / class Duplicate codeDuplicate code Methods does several different things (bad cohesion)Methods does several different things (bad cohesion) Too much dependencies (bad coupling)Too much dependencies (bad coupling) Complex / unreadable codeComplex / unreadable code

27. How It Works for Me? Delivering working software faster is important!Delivering working software faster is important! You can write the code to run somehowYou can write the code to run somehow With simple designWith simple design With less effortWith less effort Later you can refactor the code if necessaryLater you can refactor the code if necessary Refactoring is not a reason to intentionally write bad code!Refactoring is not a reason to intentionally write bad code! Good coding style is always important!Good coding style is always important! Delivering working software faster is important!Delivering working software faster is important! You can write the code to run somehowYou can write the code to run somehow With simple designWith simple design With less effortWith less effort Later you can refactor the code if necessaryLater you can refactor the code if necessary Refactoring is not a reason to intentionally write bad code!Refactoring is not a reason to intentionally write bad code! Good coding style is always important!Good coding style is always important!

28. 6. Simple Design No Big Design Up Front (BDUF) No Big Design Up Front (BDUF) Reduces the overheadReduces the overhead Ship working functionality faster and get feedback earlyShip working functionality faster and get feedback early “Do The Simplest Thing That Could Possibly Work”“Do The Simplest Thing That Could Possibly Work” Later use refactoring to change itLater use refactoring to change it Not too much formal documentationNot too much formal documentation No Big Design Up Front (BDUF) No Big Design Up Front (BDUF) Reduces the overheadReduces the overhead Ship working functionality faster and get feedback earlyShip working functionality faster and get feedback early “Do The Simplest Thing That Could Possibly Work”“Do The Simplest Thing That Could Possibly Work” Later use refactoring to change itLater use refactoring to change it Not too much formal documentationNot too much formal documentation

29. How It Works for Me? Simple design does not mean "no design"Simple design does not mean "no design" It is about establishing prioritiesIt is about establishing priorities It's a set of tradeoffs you makeIt's a set of tradeoffs you make If something is important for this release and for the whole system, it should be designed wellIf something is important for this release and for the whole system, it should be designed well Don't lose time to design something you will not use soon!Don't lose time to design something you will not use soon! Simple design does not mean "no design"Simple design does not mean "no design" It is about establishing prioritiesIt is about establishing priorities It's a set of tradeoffs you makeIt's a set of tradeoffs you make If something is important for this release and for the whole system, it should be designed wellIf something is important for this release and for the whole system, it should be designed well Don't lose time to design something you will not use soon!Don't lose time to design something you will not use soon!

30. 7. Collective Code Ownership Code to belongs to the project, not to an individual engineer!Code to belongs to the project, not to an individual engineer! Any engineer can modify any codeAny engineer can modify any code Better quality of the codeBetter quality of the code Engineers are not required to work around deficiencies in code they do not ownEngineers are not required to work around deficiencies in code they do not own Faster progressFaster progress No need to wait for someone else to fix somethingNo need to wait for someone else to fix something Code to belongs to the project, not to an individual engineer!Code to belongs to the project, not to an individual engineer! Any engineer can modify any codeAny engineer can modify any code Better quality of the codeBetter quality of the code Engineers are not required to work around deficiencies in code they do not ownEngineers are not required to work around deficiencies in code they do not own Faster progressFaster progress No need to wait for someone else to fix somethingNo need to wait for someone else to fix something

31. Collective Code Ownership?

32. How It Works for Me? Collective code ownership is absolutely indispensableCollective code ownership is absolutely indispensable You need to fight the people who don't agree with this!You need to fight the people who don't agree with this! Fire people writing unreadable and unmaintainable codeFire people writing unreadable and unmaintainable code Don't allow somebody to own some module and be irreplaceableDon't allow somebody to own some module and be irreplaceable Collective code ownership is absolutely indispensableCollective code ownership is absolutely indispensable You need to fight the people who don't agree with this!You need to fight the people who don't agree with this! Fire people writing unreadable and unmaintainable codeFire people writing unreadable and unmaintainable code Don't allow somebody to own some module and be irreplaceableDon't allow somebody to own some module and be irreplaceable

33. 8. Continuous Integration Pair writes up unit test cases and code for a task (part of a user story)Pair writes up unit test cases and code for a task (part of a user story) Pair unit tests code to 100%Pair unit tests code to 100% Pair integratesPair integrates Pair runs ALL unit test cases to 100%Pair runs ALL unit test cases to 100% Pair moves on to next task with clean slate and clear mindPair moves on to next task with clean slate and clear mind Should happen once or twice a dayShould happen once or twice a day Pair writes up unit test cases and code for a task (part of a user story)Pair writes up unit test cases and code for a task (part of a user story) Pair unit tests code to 100%Pair unit tests code to 100% Pair integratesPair integrates Pair runs ALL unit test cases to 100%Pair runs ALL unit test cases to 100% Pair moves on to next task with clean slate and clear mindPair moves on to next task with clean slate and clear mind Should happen once or twice a dayShould happen once or twice a day

34. How It Works for Me? Integrating often is really valuableIntegrating often is really valuable Sometimes you cannot finish a task for one day and integrate itSometimes you cannot finish a task for one day and integrate it For small projects with small teams integration is not an issueFor small projects with small teams integration is not an issue For large and complex projects it's crucialFor large and complex projects it's crucial Think of automated build environmentThink of automated build environment Integrating often is really valuableIntegrating often is really valuable Sometimes you cannot finish a task for one day and integrate itSometimes you cannot finish a task for one day and integrate it For small projects with small teams integration is not an issueFor small projects with small teams integration is not an issue For large and complex projects it's crucialFor large and complex projects it's crucial Think of automated build environmentThink of automated build environment

35. 9. On-Site Customer Customer available on siteCustomer available on site Clarify user storiesClarify user stories Make critical business decisionsMake critical business decisions Developers don’t make assumptionsDevelopers don’t make assumptions Developers don’t have to wait for decisionsDevelopers don’t have to wait for decisions Face to face communication minimizes the chances of misunderstandingFace to face communication minimizes the chances of misunderstanding Customer available on siteCustomer available on site Clarify user storiesClarify user stories Make critical business decisionsMake critical business decisions Developers don’t make assumptionsDevelopers don’t make assumptions Developers don’t have to wait for decisionsDevelopers don’t have to wait for decisions Face to face communication minimizes the chances of misunderstandingFace to face communication minimizes the chances of misunderstanding

36. How It Works for Me? On-site customer actually does not work!On-site customer actually does not work! Customers are busyCustomers are busy Meetings every day is working betterMeetings every day is working better Customers are not competent!Customers are not competent! Customers always say "Yes, this is what I want" and later say the oppositeCustomers always say "Yes, this is what I want" and later say the opposite You need to think instead of themYou need to think instead of them Use prototypingUse prototyping On-site customer actually does not work!On-site customer actually does not work! Customers are busyCustomers are busy Meetings every day is working betterMeetings every day is working better Customers are not competent!Customers are not competent! Customers always say "Yes, this is what I want" and later say the oppositeCustomers always say "Yes, this is what I want" and later say the opposite You need to think instead of themYou need to think instead of them Use prototypingUse prototyping

37. 10. Small Releases TimeboxedTimeboxed As small as possible, but still delivering business valueAs small as possible, but still delivering business value No releases to ‘implement the database’No releases to ‘implement the database’ Get customer feedback early and oftenGet customer feedback early and often Do the planning game after each iterationDo the planning game after each iteration Do they want something different?Do they want something different? Have their priorities changed?Have their priorities changed? TimeboxedTimeboxed As small as possible, but still delivering business valueAs small as possible, but still delivering business value No releases to ‘implement the database’No releases to ‘implement the database’ Get customer feedback early and oftenGet customer feedback early and often Do the planning game after each iterationDo the planning game after each iteration Do they want something different?Do they want something different? Have their priorities changed?Have their priorities changed?

38. How It Works for Me? Small releases are really valuableSmall releases are really valuable Manage the risk of delivering something wrongManage the risk of delivering something wrong Helps the customer to define better requirementsHelps the customer to define better requirements Release every few weeksRelease every few weeks Large projects are not so flexibleLarge projects are not so flexible Try to release something, even you know that it will be changedTry to release something, even you know that it will be changed Small releases are really valuableSmall releases are really valuable Manage the risk of delivering something wrongManage the risk of delivering something wrong Helps the customer to define better requirementsHelps the customer to define better requirements Release every few weeksRelease every few weeks Large projects are not so flexibleLarge projects are not so flexible Try to release something, even you know that it will be changedTry to release something, even you know that it will be changed

39. 11. Forty-Hour Work Week Kent Beck says, “... fresh and eager every morning, and tired and satisfied every night”Kent Beck says, “... fresh and eager every morning, and tired and satisfied every night” Burning the midnight oil kills performanceBurning the midnight oil kills performance Tired developers make more mistakesTired developers make more mistakes Slows you down more in the long runSlows you down more in the long run If you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequencesIf you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequences Kent Beck says, “... fresh and eager every morning, and tired and satisfied every night”Kent Beck says, “... fresh and eager every morning, and tired and satisfied every night” Burning the midnight oil kills performanceBurning the midnight oil kills performance Tired developers make more mistakesTired developers make more mistakes Slows you down more in the long runSlows you down more in the long run If you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequencesIf you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequences

40. How It Works for Me? 40 hours a week or 40 hours without a sleep?40 hours a week or 40 hours without a sleep? Come back to the real world!Come back to the real world! Overtime is not recommendable but often can not be avoidedOvertime is not recommendable but often can not be avoided Better planning can helpBetter planning can help Highly skilled senior engineers always suffer of overtime and high pressureHighly skilled senior engineers always suffer of overtime and high pressure That's how the business works!That's how the business works! 40 hours a week or 40 hours without a sleep?40 hours a week or 40 hours without a sleep? Come back to the real world!Come back to the real world! Overtime is not recommendable but often can not be avoidedOvertime is not recommendable but often can not be avoided Better planning can helpBetter planning can help Highly skilled senior engineers always suffer of overtime and high pressureHighly skilled senior engineers always suffer of overtime and high pressure That's how the business works!That's how the business works!

41. 12. Coding Standards Use coding conventionsUse coding conventions Rules for naming, formatting, etc.Rules for naming, formatting, etc. Write readable and maintainable codeWrite readable and maintainable code Method commentingMethod commenting Self-documenting codeSelf-documenting code Don't comment bad code, rewrite it!Don't comment bad code, rewrite it! Refactor to improve the designRefactor to improve the design Use code audit tools (FxCop, CheckStyle, TFS)Use code audit tools (FxCop, CheckStyle, TFS) Use coding conventionsUse coding conventions Rules for naming, formatting, etc.Rules for naming, formatting, etc. Write readable and maintainable codeWrite readable and maintainable code Method commentingMethod commenting Self-documenting codeSelf-documenting code Don't comment bad code, rewrite it!Don't comment bad code, rewrite it! Refactor to improve the designRefactor to improve the design Use code audit tools (FxCop, CheckStyle, TFS)Use code audit tools (FxCop, CheckStyle, TFS)

42. How It Works for Me? Coding standards are importantCoding standards are important Enforce good practices to whole the team – tools, code reviews, etc.Enforce good practices to whole the team – tools, code reviews, etc. Standards should be simpleStandards should be simple Complex standards are not followedComplex standards are not followed Standards should be more strict for larger teamsStandards should be more strict for larger teams Developers don't like utter rules like "comment any class member"Developers don't like utter rules like "comment any class member" Coding standards are importantCoding standards are important Enforce good practices to whole the team – tools, code reviews, etc.Enforce good practices to whole the team – tools, code reviews, etc. Standards should be simpleStandards should be simple Complex standards are not followedComplex standards are not followed Standards should be more strict for larger teamsStandards should be more strict for larger teams Developers don't like utter rules like "comment any class member"Developers don't like utter rules like "comment any class member"

43. The 13 th Practice? The Stand Up Meeting Start the day with 15-minute meetingStart the day with 15-minute meeting Everyone stands up (so the meeting stays short) in circleEveryone stands up (so the meeting stays short) in circle Going around the room everyone says specifically:Going around the room everyone says specifically: What they did the day beforeWhat they did the day before What they plan to do todayWhat they plan to do today Any obstacles they are experiencingAny obstacles they are experiencing Can be the way pairs are formedCan be the way pairs are formed Start the day with 15-minute meetingStart the day with 15-minute meeting Everyone stands up (so the meeting stays short) in circleEveryone stands up (so the meeting stays short) in circle Going around the room everyone says specifically:Going around the room everyone says specifically: What they did the day beforeWhat they did the day before What they plan to do todayWhat they plan to do today Any obstacles they are experiencingAny obstacles they are experiencing Can be the way pairs are formedCan be the way pairs are formed

44. People Communicate Most Effectively Face-to-Face Richness of the communication channel Communication effectiveness 2 people at whiteboard 2 people on phone 2 people on email Videotape Paper

45. How XP Solve Some SE Problems ProblemSolution Slipped schedule Short development cycles Cancelled project Intensive customer presence Cost of changes Extensive, ongoing testing, system always running Defect rates Unit tests, customer tests Misunderstand the business Customer part of the team Business changes Changes are welcome Staff turnover Intensive teamwork

46. So What does XP Apply to? Domains with changing requirementsDomains with changing requirements High-risk projects (including those with high schedule risk)High-risk projects (including those with high schedule risk) Small project team: 2 – 12 programmersSmall project team: 2 – 12 programmers Cannot be used with a large teamCannot be used with a large team Extended development teamExtended development team Developers, managers and customerDevelopers, managers and customer Co-locatedCo-located Automated testabilityAutomated testability Domains with changing requirementsDomains with changing requirements High-risk projects (including those with high schedule risk)High-risk projects (including those with high schedule risk) Small project team: 2 – 12 programmersSmall project team: 2 – 12 programmers Cannot be used with a large teamCannot be used with a large team Extended development teamExtended development team Developers, managers and customerDevelopers, managers and customer Co-locatedCo-located Automated testabilityAutomated testability

47. Your Own Development Process?

48. Mix-and-MatchMix-and-Match The practices in different agile methods can be extracted and combinedThe practices in different agile methods can be extracted and combined Establish your own processEstablish your own process Build it step-by-stepBuild it step-by-step Adapt good practices one by oneAdapt good practices one by one ExamplesExamples Pair programming and its variationPair programming and its variation Daily 15-minutes meetingDaily 15-minutes meeting Test-driven developmentTest-driven development The practices in different agile methods can be extracted and combinedThe practices in different agile methods can be extracted and combined Establish your own processEstablish your own process Build it step-by-stepBuild it step-by-step Adapt good practices one by oneAdapt good practices one by one ExamplesExamples Pair programming and its variationPair programming and its variation Daily 15-minutes meetingDaily 15-minutes meeting Test-driven developmentTest-driven development

49. Agile Development and XP