Agile Software Development Agile Characterized by quickness, lightness, and ease of movement; nimble.

Manifesto Individuals and interactions over processes and tools 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 Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave 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 Stories Short Cycles Acceptance Testing Pair Programming Collective Ownership Test-Driven Development Continuous Integration Sustainable Pace Open Workspace Simple Design Refactoring Metaphor