Agile Software Development

Agile

Characterized by quickness, lightness, and ease

of movement; nimble.

Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim Highsmith

Andrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas

Individuals and interactions over processes and tools

• Individuals are the biggest asset

• Individuals are creative and need space

• Team work and collaboration are more important than ‘star’ player

• Tools can be useful to a point

• Grow into sophisticated tools, do not start with them

Working software over comprehensive documentation

• Software itself is the documentation

• Documentation tends to diverge

• Documentation needs to be crisp and short, verbose comments pollute the code

Martin’s First Law of documentation

Produce no document unless its need is immediate and significant

Customer collaboration over contract negotiation

• Customers are the members of your team

• Your manager is your customer

• Understand what they want, deliver what they want

• Make customers part of the process

• Rely on customer feedback

Responding to change over following a plan

• Be ready for change, embrace the change

• Pride yourself on being adaptive

• Do not be afraid to change things, when you changing something you own it, when you do not it owns you

• Evaluate the change in the current context

• Ensure progress

Principles of Agile Development

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Principles of Agile Development

Welcome changing requirements even late in the development. Agile processes harness change for the customer advantage.

Principles of Agile Development

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter time scale.

Principles of Agile Development

Business people and developers must work together daily through the project.

Principles of Agile Development

Build projects around motivated individuals. Give them environment and support that they need, and trust them to get the job done.

Principles of Agile Development

The most effective method of conveying information to and within development team is a face to face conversation.

Principles of Agile Development

Working software is a primary measure of progress.

Principles of Agile Development

Continuous attention to technical excellence and good design enhances agility.

Principles of Agile Development

Simplicity – the art of maximizing the amount of work not done – is essential.

Principles of Agile Development

The best architectures, requirements and designs emerge from self-organizing teams.

Extreme Programming

• Pioneered by Kent Beck

• Somewhat of a misnomer, better called Adaptive programming

• Agile software methodology centered around User stories, short deliverables, Testing, Refactoring and pair programming.

Practices of Extreme Programming:User Stories

• A user story is 1-2 sentences on an index card. For example: – Our web site will need to have a login screen

that will validate customers.– The car needs to have adjustable seats

User story is a planning tool used by the customer to convey the requirements.

Practices of Extreme Programming:Short Cycles

• XP project delivers every 2 weeks

• Each iteration addresses specific need of the stakeholders (User stories)

• User stories in the plan are chosen by the customer according to priority

• Short term releases (2 weeks) are called iterations, long term releases (3 months) are called production releases.

Practices of Extreme Programming:Acceptance Testing

• The test is written before or in conjunction with the implementation of the story

• Tests are written in the scripting language and can be ran automatically and repeatedly.

• Once acceptance test is passed is never allowed to fail in the future. So once feature is implemented it should never be broken.

Practices of Extreme Programming:Pair Programming

• The code is written by pair of programmers working together

• They both discuss the design and the code, both are engaged in act of writing software.

• One of them types the code the other one watches for errors and improvements.

• The roles change frequently and people rotate to different pairs

• Collective ownership of the code is implied.• Knowledge spreads quickly, junior programmers

learn faster.

Practices of Extreme Programming:Test-Driven Development

• First write the test, then write the code• Leads to smaller cleaner code• If you can not test it you can not be

responsible for it• The code must always pass all the tests.• If the test fails you need to fix the code.• Programmers switch between writing tests

and code frequently.• Testing facilitates refactoring

Practices of Extreme Programming:Collective Ownership

• No programmer is responsible for any particular module, all code is shared.

• Reduces risk for companies

• Facilitates faster individual growth

Practices of Extreme Programming:Continuous Integration

• Hourly check-ins

• If something broke – fix it

• The checked in code must pass all unit tests.

• Daily build and test

Practices of Extreme Programming:Sustainable Pace

• Software development is a marathon

• XP teams do not work overtime

• Must be fresh, alert and ready to go

Practices of Extreme Programming:Open Workspace

• Teams work together in the open room

• Pairs can overhear nearby conversations and decide to switch around and help others.

• Open environment leads to greater productivity and more personal software development

Practices of Extreme Programming:Simple Design

• The designs are as simple as possible

• Sufficient to address the needs of User stories

• Do not worry about the stories to come

• Infrastructure emerges as oppose to being specifically created.– Simplest thing that can work– You think you need it but you do not– Write it once and only one

Practices of Extreme Programming:Refactoring

• Always change the code to make it simpler

• Always merge code to ensure reuse

• Do not let code degrade, refactor continuously

• Run Unit tests to ensure that you did not break anything

Practices of Extreme Programming:Metaphor

• Always keep the big picture in mind

• Always keep the structure in mind

• Use natural analogies to understand and explain to others your design and code

User StoriesShort Cycles

Acceptance TestingPair Programming

Collective OwnershipTest-Driven

DevelopmentContinuous Integration

Sustainable PaceOpen Workspace

Simple DesignRefactoring

Metaphor