This document provides an overview of agile software development. It discusses the differences between the waterfall model and agile approaches. The key principles of agile include prioritizing individuals and interactions, working software, customer collaboration, and responding to change. An example agile process used by Elsevier is described, involving roles like product owners, business analysts, developers, and quality analysts. Extreme programming is mentioned as an agile method that focuses on user stories, small releases, pair programming, unit testing, and simplicity.

1. Agile Software Development Overview Sunil Kumar | 18-04-08 | London www.exploreagile.blogspot.com

2. Agenda What is Agile Software Development? Introduction Waterfall model Vs. Agile Agile Principle Elsevier Agile Development Process Extreme Programming. Questions.

3. What is Agile Software Development? Introduction

4. Introduction A new software development methodology Faster software development Ability to react to changing situations quickly, appropriately, and effectively. "Agile is about being open about what we’re capable of doing, and then doing it" – Kent Beck

5. Waterfall Vs. Agile

6. Waterfall Vs. Agile Waterfall: collect and document all of the system requirements produce a set of design documents write code that implements the pieces specified in the design integrate all of the pieces and test to make sure the system satisfies the requirements package the system and ship to the customer

7. Waterfall Vs. Agile Agile: analyze a little, design a little, code a little spiral process or iterative more difficult to manage, hard to know when you are “done” you get to deliver early versions of the most important features, get customer feedback quickly you can get by with less documentation it is easier to react to customer changes

8. Agile Principles

9. Agile Principles 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan http://agilemanifesto.org/

10. Elsevier Agile Software Development

11. Model Type XP based weekly iterative Agile development model

12. Different parties involved in the process. Customer Team( Product manager, Business Analyst) UCD Team (User Centre Design) Development Team QA(Quality Analyst) Project Manager, Iteration Manager Shared Team ( Architecture team, content team and GWS) Various management stack holders ( e.g. sales team)

13. Elsevier Agile Software Development -Principles Communication Simplicity Courage Feedback (e.g. Developer measures) Respect

14. Product Owner Decide on the project vision continuously make decisions on the product priorities Build product that delivers business value early and continuously

15. Project Manager PMs are responsible for the successful delivery of a project Project forecasting and budgeting, Project resource planning and Project scheduling (Release Planning)

16. Business Analyst A facilitator; act as a communications bridge between product owner/UCD and development team, as well as between the business and technology. He is a bit technical as well. Convert requirements into Stories. Finally sign it off.

17. UCD Prototype preparation UI preparation for stories Provides CSS, Page structure

18. Iteration Manager IM facilitate iteration planning sessions, Track progress throughout the course of an iteration, Facilitate effective interaction within the team as well as with other teams, Report on iteration status and work to remove impediments to development team productivity

19. Developer Developers are experienced software development professionals able to write code in the language(s) required by the project Developers will pair together, so they must also have good communication and team skills.

20. Lead Developer Lead Developers set the technical direction on a day-to-day basis, within the guidelines set out by the architect A Lead Developer may also provide high level estimates on stories for the purposes of release planning when it is not practical to have the whole team doing estimating as would happen at an Iteration Planning Meeting.

21. Quality Analyst QA team ensure that the whole application is bug free and meets the requirements. The QA therefore works with the Product Manager and the Analyst to specify the story. when each story has been implemented they verify that those tests execute against the application They also look at higher level testing such as integration, system, performance and user acceptance testing

22. Extreme Programming

23. Some Rules Of Extreme Programming Planning rules do project planning via “user stories” plan a series of very small internal releases start each day with a “stand-up meeting” Design rules keep the design simple (use the simplest thing that could work) refactor as needed Coding rules talk with the customer throughout the coding process always code in pairs code unit tests first follow coding standards Testing rules unit tests for all code acceptance tests for each user story

24. Questions