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

2. 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

3. 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

4. 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

5. 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

6. 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

7. Principles of Agile Development
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

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

9. 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.

10. Principles of Agile Development
Business people and developers must work together daily through the project.

11. 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.

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

13. Principles of Agile Development
Working software is a primary measure of progress.

14. Principles of Agile Development
Continuous attention to technical excellence and good design enhances agility.

15. Principles of Agile Development
Simplicity – the art of maximizing the amount of work not done – is essential.

16. Principles of Agile Development
The best architectures, requirements and designs emerge from self-organizing teams.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. User Stories
Short Cycles
Acceptance Testing
Pair Programming
Collective Ownership
Test-Driven Development
Continuous Integration
Sustainable Pace
Open Workspace
Simple Design
Refactoring
Metaphor