Agile Methodologies And Extreme Programming - Svetlin Nakov

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

Transcript of Agile Methodologies And Extreme Programming - Svetlin Nakov

Page 1: Agile Methodologies And Extreme Programming - Svetlin Nakov

Agile Development and Agile Development and Extreme Programming Extreme Programming

Svetlin NakovSvetlin NakovNational Academy for Software National Academy for Software DevelopmentDevelopment

academy.devbg.org

Page 2: Agile Methodologies And Extreme Programming - Svetlin Nakov

AgendaAgendaAgendaAgenda

• 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

Page 3: Agile Methodologies And Extreme Programming - Svetlin Nakov

Development Development MethodologiesMethodologies Development Development MethodologiesMethodologies

Page 4: Agile Methodologies And Extreme Programming - Svetlin Nakov

What is a Methodology?What is a Methodology?What is a Methodology?What is a Methodology?

• A A methodologymethodology is a formalized process is a formalized process or set of practices for creating softwareor 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 A set of conventions the organization decides to followdecides to follow

• A systematical, engineering approach for A systematical, engineering approach for organizing software projectsorganizing software projects

• A A methodologymethodology is a formalized process is a formalized process or set of practices for creating softwareor 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 A set of conventions the organization decides to followdecides to follow

• A systematical, engineering approach for A systematical, engineering approach for organizing software projectsorganizing software projects

Page 5: Agile Methodologies And Extreme Programming - Svetlin Nakov

The Waterfall Development The Waterfall Development ProcessProcess

The Waterfall Development The Waterfall Development ProcessProcess

Page 6: Agile Methodologies And Extreme Programming - Svetlin Nakov

The Waterfall ProcessThe Waterfall ProcessThe Waterfall ProcessThe Waterfall Process

• The traditional development process:The traditional development process:• The traditional development process:The traditional development process:

SystemRequirements

SoftwareRequirements

Analysis

ProgramDesign

Coding

Testing

Operations

• Or at worst …Or at worst …

• But this always ends up happening!But this always ends up happening!

Page 7: Agile Methodologies And Extreme Programming - Svetlin Nakov

SystemRequirements

Formal ProcessesFormal ProcessesFormal ProcessesFormal Processes

• Formal efforts to “fix” the problemFormal efforts to “fix” the problem• Formal efforts to “fix” the problemFormal efforts to “fix” the problem

SoftwareRequirements

Analysis

Coding

Testing

Operations

PreliminaryDesign

Analysis

ProgramDesign Coding

Testing

Usage

PreliminaryDesign

Document

UI Design Document

TestPlan

FinalDesign

PreliminaryDesignSoftware

RequirementsSpecification

Prelim.Revie

w

ProgramDesign

DesignRevie

w

OperatingInstructions

Page 8: Agile Methodologies And Extreme Programming - Svetlin Nakov

Agile DevelopmentAgile DevelopmentAgile DevelopmentAgile Development

Page 9: Agile Methodologies And Extreme Programming - Svetlin Nakov

Agile ManifestoAgile ManifestoAgile ManifestoAgile Manifesto

““Our highest priority is to satisfy the Our highest priority is to satisfy the

customer through early and continuouscustomer through early and continuous

delivery of valuable software“delivery of valuable software“

[Manifesto for Agile][Manifesto for Agile]

““Our highest priority is to satisfy the Our highest priority is to satisfy the

customer through early and continuouscustomer through early and continuous

delivery of valuable software“delivery of valuable software“

[Manifesto for Agile][Manifesto for Agile]

Page 10: Agile Methodologies And Extreme Programming - Svetlin Nakov

• IncrementalIncremental

• Working softwareWorking software over comprehensive over comprehensive documentationdocumentation

• CooperationCooperation

• Customer collaborationCustomer collaboration over contract over contract negotiationnegotiation

• StraightforwardStraightforward

• Individuals and interactionsIndividuals and interactions over processes over processes and toolsand tools

• AdaptiveAdaptive

• Responding to changeResponding to change over following a plan over following a plan

• IncrementalIncremental

• Working softwareWorking software over comprehensive over comprehensive documentationdocumentation

• CooperationCooperation

• Customer collaborationCustomer collaboration over contract over contract negotiationnegotiation

• StraightforwardStraightforward

• Individuals and interactionsIndividuals and interactions over processes over processes and toolsand tools

• AdaptiveAdaptive

• Responding to changeResponding to change over following a plan over following a plan

The Agile SpiritThe Agile SpiritThe Agile SpiritThe Agile Spirit

Page 11: Agile Methodologies And Extreme Programming - Svetlin Nakov

Agile MethodologiesAgile MethodologiesAgile MethodologiesAgile 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 Dynamic System Development Model (DSDM)(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 Dynamic System Development Model (DSDM)(DSDM)

• Agile Unified Process (AUP)Agile Unified Process (AUP)

Page 12: Agile Methodologies And Extreme Programming - Svetlin Nakov

eXtreme eXtreme ProgrammingProgramming

eXtreme eXtreme ProgrammingProgramming

Page 13: Agile Methodologies And Extreme Programming - Svetlin Nakov

The XP Guru: Kent BeckThe XP Guru: Kent BeckThe XP Guru: Kent BeckThe XP Guru: Kent Beck

• eeXXtreme treme PProgrammingrogramming

• The most prominent agile development The most prominent agile development methodologymethodology

• eeXXtreme treme PProgrammingrogramming

• The most prominent agile development The most prominent agile development methodologymethodology

Kent Beck

1st ed. Oct 19992nd ed. Nov 2004

Page 14: Agile Methodologies And Extreme Programming - Svetlin Nakov

The 12 Key PracticesThe 12 Key PracticesThe 12 Key PracticesThe 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

Page 15: Agile Methodologies And Extreme Programming - Svetlin Nakov

1. Metaphor1. Metaphor1. Metaphor1. Metaphor

• Guide all development and conversations Guide all development and conversations with a simple shared story of how the with a simple shared story of how the whole system works whole system works

• Gives the team a whole picture of Gives the team a whole picture of describing the system, where new parts describing the system, where new parts fit, etc.fit, etc.

• Words used to identify technical entities Words used to identify technical entities should be chosen from the metaphorshould be chosen from the metaphor

• The default metaphor is the business The default metaphor is the business domain, and it’s usually just finedomain, and it’s usually just fine

• Guide all development and conversations Guide all development and conversations with a simple shared story of how the with a simple shared story of how the whole system works whole system works

• Gives the team a whole picture of Gives the team a whole picture of describing the system, where new parts describing the system, where new parts fit, etc.fit, etc.

• Words used to identify technical entities Words used to identify technical entities should be chosen from the metaphorshould be chosen from the metaphor

• The default metaphor is the business The default metaphor is the business domain, and it’s usually just finedomain, and it’s usually just fine

Page 16: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Metaphors are good ideaMetaphors are good idea

• People should know the business needs People should know the business needs and how their work fits in the projectand how their work fits in the project

• Metaphors are good ideaMetaphors are good idea

• People should know the business needs People should know the business needs and how their work fits in the projectand how their work fits in the project

Page 17: Agile Methodologies And Extreme Programming - Svetlin Nakov

2. Release Planning2. Release Planning2. Release Planning2. Release Planning

• Requirements via Requirements via User StoriesUser Stories

• Short cards with natural language Short cards with natural language description of what a customer wantsdescription of what a customer wants

• Prioritized by customerPrioritized by customer

• Resource and risk estimated by Resource and risk estimated by developersdevelopers

• Via “The Planning Game”Via “The Planning Game”

• Play the Planning Game after each Play the Planning Game after each incrementincrement

• Requirements via Requirements via User StoriesUser Stories

• Short cards with natural language Short cards with natural language description of what a customer wantsdescription of what a customer wants

• Prioritized by customerPrioritized by customer

• Resource and risk estimated by Resource and risk estimated by developersdevelopers

• Via “The Planning Game”Via “The Planning Game”

• Play the Planning Game after each Play the Planning Game after each incrementincrement

Page 18: Agile Methodologies And Extreme Programming - Svetlin Nakov

User StoriesUser StoriesUser StoriesUser Stories

Page 19: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Requirements specification (SRS) is better Requirements specification (SRS) is better than user storiesthan user stories

• Written documentation works well for large Written documentation works well for large projectsprojects

• I prefer prototyping the user interface as I prefer prototyping the user interface as source of documentationsource of documentation

• Sometimes its is hard to estimate the Sometimes its is hard to estimate the required resourcesrequired resources

• Small releases have less riskSmall releases have less risk

• Requirements specification (SRS) is better Requirements specification (SRS) is better than user storiesthan user stories

• Written documentation works well for large Written documentation works well for large projectsprojects

• I prefer prototyping the user interface as I prefer prototyping the user interface as source of documentationsource of documentation

• Sometimes its is hard to estimate the Sometimes its is hard to estimate the required resourcesrequired resources

• Small releases have less riskSmall releases have less risk

Page 20: Agile Methodologies And Extreme Programming - Svetlin Nakov

3. Testing3. Testing3. Testing3. 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 TestsAcceptance Tests

• Written with the customerWritten with the customer

• Acts as “contract”Acts as “contract”

• Measure of progressMeasure of progress

Page 21: Agile Methodologies And Extreme Programming - Svetlin Nakov

Test-Driven DevelopmentTest-Driven DevelopmentTest-Driven DevelopmentTest-Driven Development

• Developers write unit tests before codingDevelopers write unit tests before coding

• Motivates codingMotivates coding

• Improves design: cohesion and coupling Improves 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));}

Page 22: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?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 The real world is different: you always need the functionality "for tomorrow"!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 The real world is different: you always need the functionality "for tomorrow"!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

Page 23: Agile Methodologies And Extreme Programming - Svetlin Nakov

4. Pair Programming4. Pair Programming4. Pair Programming4. Pair Programming

• Two software engineers work on one Two software engineers work on one task at one computertask at one computer

• The driverThe driver has control of the keyboard and has control of the keyboard and mouse and creates the implementationmouse and creates the implementation

• The navigatorThe navigator watches the driver’s watches the driver’s implementationimplementation

• Identifies defects and participates in on-Identifies defects and participates in on-demand brainstormingdemand brainstorming

• The roles of driver and observer are The roles of driver and observer are periodically rotatedperiodically rotated

Page 24: Agile Methodologies And Extreme Programming - Svetlin Nakov

Pair ProgrammingPair ProgrammingPair ProgrammingPair 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

Page 25: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Pair programming is great for complex and Pair programming is great for complex and critical logiccritical 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 Peer reviews instead pair programming is often alternativeoften alternative

• Pair programming is great for complex and Pair programming is great for complex and critical logiccritical 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 Peer reviews instead pair programming is often alternativeoften alternative

Page 26: Agile Methodologies And Extreme Programming - Svetlin Nakov

5. Refactoring5. Refactoring5. Refactoring5. Refactoring

• Improve the design of existing code Improve the design of existing code without changing its functionalitywithout changing its functionality• Relies on unit testing to ensure the code is Relies on unit testing to ensure the code is

not brokennot broken

• Bad smells in code:Bad smells in code:• Long method / classLong method / class

• Duplicate codeDuplicate code

• Methods does several different things (bad Methods does several different things (bad cohesion)cohesion)

• Too much dependencies (bad coupling)Too much dependencies (bad coupling)

• Complex / unreadable codeComplex / unreadable code

Page 27: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Delivering working software faster is Delivering working software faster is important!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 Refactoring is not a reason to intentionally write bad code!write bad code!

• Good coding style is always important!Good coding style is always important!

• Delivering working software faster is Delivering working software faster is important!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 Refactoring is not a reason to intentionally write bad code!write bad code!

• Good coding style is always important!Good coding style is always important!

Page 28: Agile Methodologies And Extreme Programming - Svetlin Nakov

6. Simple Design6. Simple Design6. Simple Design6. 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 Ship working functionality faster and get feedback earlyfeedback early

• ““Do The Simplest Thing That Could Do The Simplest Thing That Could Possibly Work”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 Ship working functionality faster and get feedback earlyfeedback early

• ““Do The Simplest Thing That Could Do The Simplest Thing That Could Possibly Work”Possibly Work”

• Later use refactoring to change itLater use refactoring to change it

• Not too much formal documentationNot too much formal documentation

Page 29: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Simple design does not mean "no Simple design does not mean "no design"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 If something is important for this release and for the whole system, it release and for the whole system, it should be designed wellshould be designed well

• Don't lose time to design something Don't lose time to design something you will not use soon!you will not use soon!

• Simple design does not mean "no Simple design does not mean "no design"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 If something is important for this release and for the whole system, it release and for the whole system, it should be designed wellshould be designed well

• Don't lose time to design something Don't lose time to design something you will not use soon!you will not use soon!

Page 30: Agile Methodologies And Extreme Programming - Svetlin Nakov

7. Collective Code 7. Collective Code OwnershipOwnership7. Collective Code 7. Collective Code OwnershipOwnership

• Code to belongs to the project, not to an Code to belongs to the project, not to an individual engineer!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 Engineers are not required to work around deficiencies in code they do not around deficiencies in code they do not ownown

• Faster progressFaster progress

• No need to wait for someone else to fix No need to wait for someone else to fix somethingsomething

• Code to belongs to the project, not to an Code to belongs to the project, not to an individual engineer!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 Engineers are not required to work around deficiencies in code they do not around deficiencies in code they do not ownown

• Faster progressFaster progress

• No need to wait for someone else to fix No need to wait for someone else to fix somethingsomething

Page 31: Agile Methodologies And Extreme Programming - Svetlin Nakov

Collective Code Collective Code Ownership?Ownership?Collective Code Collective Code Ownership?Ownership?

Page 32: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Collective code ownership is absolutely Collective code ownership is absolutely indispensableindispensable

• You need to fight the people who don't You need to fight the people who don't agree with this!agree with this!

• Fire people writing unreadable and Fire people writing unreadable and unmaintainable codeunmaintainable code

• Don't allow somebody to own some Don't allow somebody to own some module and be irreplaceablemodule and be irreplaceable

• Collective code ownership is absolutely Collective code ownership is absolutely indispensableindispensable

• You need to fight the people who don't You need to fight the people who don't agree with this!agree with this!

• Fire people writing unreadable and Fire people writing unreadable and unmaintainable codeunmaintainable code

• Don't allow somebody to own some Don't allow somebody to own some module and be irreplaceablemodule and be irreplaceable

Page 33: Agile Methodologies And Extreme Programming - Svetlin Nakov

8. Continuous Integration8. Continuous Integration8. Continuous Integration8. Continuous Integration

• Pair writes up unit test cases and code Pair writes up unit test cases and code for a task (part of a user story)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 Pair moves on to next task with clean slate and clear mindslate and clear mind

• Should happen once or twice a dayShould happen once or twice a day

• Pair writes up unit test cases and code Pair writes up unit test cases and code for a task (part of a user story)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 Pair moves on to next task with clean slate and clear mindslate and clear mind

• Should happen once or twice a dayShould happen once or twice a day

Page 34: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Integrating often is really valuableIntegrating often is really valuable

• Sometimes you cannot finish a task for Sometimes you cannot finish a task for one day and integrate itone day and integrate it

• For small projects with small teams For small projects with small teams integration is not an issueintegration is not an issue

• For large and complex projects it's For large and complex projects it's crucialcrucial

• 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 Sometimes you cannot finish a task for one day and integrate itone day and integrate it

• For small projects with small teams For small projects with small teams integration is not an issueintegration is not an issue

• For large and complex projects it's For large and complex projects it's crucialcrucial

• Think of automated build environmentThink of automated build environment

Page 35: Agile Methodologies And Extreme Programming - Svetlin Nakov

9. On-Site Customer9. On-Site Customer9. On-Site Customer9. 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 Developers don’t have to wait for decisionsdecisions

• Face to face communication minimizes Face to face communication minimizes the chances of misunderstandingthe 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 Developers don’t have to wait for decisionsdecisions

• Face to face communication minimizes Face to face communication minimizes the chances of misunderstandingthe chances of misunderstanding

Page 36: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• On-site customer actually does not On-site customer actually does not work!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 Customers always say "Yes, this is what I want" and later say the oppositeI 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 On-site customer actually does not work!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 Customers always say "Yes, this is what I want" and later say the oppositeI want" and later say the opposite

• You need to think instead of themYou need to think instead of them

• Use prototypingUse prototyping

Page 37: Agile Methodologies And Extreme Programming - Svetlin Nakov

10. Small Releases10. Small Releases10. Small Releases10. Small Releases

• TimeboxedTimeboxed

• As small as possible, but still delivering As small as possible, but still delivering business valuebusiness 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 Do the planning game after each iterationiteration

• 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 As small as possible, but still delivering business valuebusiness 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 Do the planning game after each iterationiteration

• Do they want something different?Do they want something different?

• Have their priorities changed?Have their priorities changed?

Page 38: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Small releases are really valuableSmall releases are really valuable

• Manage the risk of delivering something Manage the risk of delivering something wrongwrong

• Helps the customer to define better Helps the customer to define better requirementsrequirements

• 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 Try to release something, even you know that it will be changedthat it will be changed

• Small releases are really valuableSmall releases are really valuable

• Manage the risk of delivering something Manage the risk of delivering something wrongwrong

• Helps the customer to define better Helps the customer to define better requirementsrequirements

• 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 Try to release something, even you know that it will be changedthat it will be changed

Page 39: Agile Methodologies And Extreme Programming - Svetlin Nakov

11. Forty-Hour Work Week11. Forty-Hour Work Week11. Forty-Hour Work Week11. Forty-Hour Work Week

• Kent Beck says, “ . . . fresh and eager every Kent Beck says, “ . . . fresh and eager every morning, and tired and satisfied every morning, and tired and satisfied every night”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 If you mess with people’s personal lives (by taking it over), in the long run the project taking it over), in the long run the project will pay the consequenceswill pay the consequences

• Kent Beck says, “ . . . fresh and eager every Kent Beck says, “ . . . fresh and eager every morning, and tired and satisfied every morning, and tired and satisfied every night”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 If you mess with people’s personal lives (by taking it over), in the long run the project taking it over), in the long run the project will pay the consequenceswill pay the consequences

Page 40: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• 40 hours a week or 40 hours without a 40 hours a week or 40 hours without a sleep?sleep?

• Come back to the real world!Come back to the real world!

• Overtime is not recommendable but often Overtime is not recommendable but often can not be avoidedcan not be avoided

• Better planning can helpBetter planning can help

• Highly skilled senior engineers always Highly skilled senior engineers always suffer of overtime and high pressuresuffer 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 40 hours a week or 40 hours without a sleep?sleep?

• Come back to the real world!Come back to the real world!

• Overtime is not recommendable but often Overtime is not recommendable but often can not be avoidedcan not be avoided

• Better planning can helpBetter planning can help

• Highly skilled senior engineers always Highly skilled senior engineers always suffer of overtime and high pressuresuffer of overtime and high pressure

• That's how the business works!That's how the business works!

Page 41: Agile Methodologies And Extreme Programming - Svetlin Nakov

12. Coding Standards12. Coding Standards12. Coding Standards12. 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, Use code audit tools (FxCop, CheckStyle, TFS)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, Use code audit tools (FxCop, CheckStyle, TFS)CheckStyle, TFS)

Page 42: Agile Methodologies And Extreme Programming - Svetlin Nakov

How It Works for Me?How It Works for Me?How It Works for Me?How It Works for Me?

• Coding standards are importantCoding standards are important

• Enforce good practices to whole the team Enforce good practices to whole the team – tools, code reviews, etc.– 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 Standards should be more strict for larger teamslarger teams

• Developers don't like utter rules like Developers don't like utter rules like ""comment any class membercomment any class member""

• Coding standards are importantCoding standards are important

• Enforce good practices to whole the team Enforce good practices to whole the team – tools, code reviews, etc.– 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 Standards should be more strict for larger teamslarger teams

• Developers don't like utter rules like Developers don't like utter rules like ""comment any class membercomment any class member""

Page 43: Agile Methodologies And Extreme Programming - Svetlin Nakov

The 13The 13thth Practice? Practice? The Stand Up MeetingThe Stand Up MeetingThe 13The 13thth Practice? Practice? The Stand Up MeetingThe Stand Up Meeting

• Start the day with 15-minute meetingStart the day with 15-minute meeting

• Everyone stands up (so the meeting Everyone stands up (so the meeting stays short) in circlestays short) in circle

• Going around the room everyone says Going around the room everyone says specifically: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 Everyone stands up (so the meeting stays short) in circlestays short) in circle

• Going around the room everyone says Going around the room everyone says specifically: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

Page 44: Agile Methodologies And Extreme Programming - Svetlin Nakov

People Communicate Most People Communicate Most Effectively Face-to-FaceEffectively Face-to-FacePeople Communicate Most People Communicate Most Effectively Face-to-FaceEffectively Face-to-Face

Richness of the communication channel

Co

mm

un

icat

ion

eff

ecti

ven

ess

2 people atwhiteboard

2 people on phone

2 peopleon email

Videotape

Paper

Page 45: Agile Methodologies And Extreme Programming - Svetlin Nakov

How XP Solve Some SE How XP Solve Some SE ProblemsProblemsHow XP Solve Some SE How XP Solve Some SE ProblemsProblems

ProblemProblem SolutionSolution

Slipped scheduleSlipped schedule Short development cyclesShort development cycles

Cancelled projectCancelled project Intensive customer presenceIntensive customer presence

Cost of changesCost of changes Extensive, ongoing testing, Extensive, ongoing testing, system always runningsystem always running

Defect ratesDefect rates Unit tests, customer testsUnit tests, customer tests

Misunderstand the Misunderstand the businessbusiness Customer part of the teamCustomer part of the team

Business changesBusiness changes Changes are welcomeChanges are welcome

Staff turnoverStaff turnover Intensive teamworkIntensive teamwork

Page 46: Agile Methodologies And Extreme Programming - Svetlin Nakov

So What does XP Apply to?So What does XP Apply to?So What does XP Apply to?So What does XP Apply to?

• Domains with changing requirementsDomains with changing requirements

• High-risk projects (including those with High-risk projects (including those with high schedule risk)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-risk projects (including those with high schedule risk)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

Page 47: Agile Methodologies And Extreme Programming - Svetlin Nakov

Your Own Development Your Own Development Process?Process?

Your Own Development Your Own Development Process?Process?

Page 48: Agile Methodologies And Extreme Programming - Svetlin Nakov

Mix-and-MatchMix-and-MatchMix-and-MatchMix-and-Match

• The practices in different agile methods The practices in different agile methods can be extracted and combinedcan 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 The practices in different agile methods can be extracted and combinedcan 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

Page 49: Agile Methodologies And Extreme Programming - Svetlin Nakov

Agile Development and XPAgile Development and XPAgile Development and XPAgile Development and XP