Overview

1. Overview • What is agility? • Agile manifesto • What is an agile process, agile team and agile method? • Agile process models - XP - ASD - DSDM - Scrum - Crystal - FDD - AM

2. Agility • Agility is dynamic, content specific, aggressively change embracing, growth oriented. • Agility is more than an effective response to change. • It emphasizes rapid delivery of operational software. • It adopts the customer as part of the development team. • It recognizes that planning in an uncertain world has it’s limits and that a project plan must be flexible

3. Agile Software Development • Agile software engineering represents a reasonable alternative to conventional software engineering for certain classes of software and certain types of software projects • Agile development processes can deliver successful systems quickly • Agile development stresses continuous communication and collaboration among developers and customers

4. Agile Software Development • Agile software engineering embraces a philosophy that encourages customer satisfaction, incremental software delivery, small project teams (composed of software engineers and stakeholders), informal methods, and minimal software engineering work products • Agile software engineering development guidelines stress on-time delivery of an operational software increment over analysis and design

5. The Agile Alliance In early 2001, a group of industry experts met to outline the values and principles that would allow software teams to develop quickly and respond to change. They called themselves the Agile Alliance. Over two days they worked to create a statement of values. The result was the manifesto of the Agile Alliance. Over the next three months they continued to work together to create the principles of agility.

6. Agile Manifesto a statement of agile values Manifesto for Agile Software Development Through this work they came 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.

7. Agile Manifesto Principles 1. Our highest priority is to satisfy the costumer through early and continuous delivery of valuable software 2. Welcome changing requirements, even late in development. Agile process harness change for the customer´s competitive advantage 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

8. Agile Manifesto 4. Business people and developers must work together daily throughout the project 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9. Agile Manifesto 7. Working software is the primary measure of progress 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely 9. Continuous attention to technical excellence and good design enhances agility

10. Agile Manifesto 10. Simplicity – the art of maximizing the amount of work not done – is essential 11. The best architectures, requirements, and designs emerge from self-organizing teams 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

11. Agile Processes Any agile software process is characterized in a manner that address three key assumptions 1. It is difficult to predict in advance which requirements or customer priorities will change and which will not. 2. For many types of software design and construction activities are interleaved (construction is used to prove the design). 3. Analysis, design, and testing are not as predictable from a planning perspective as one might like them to be

12. Agile process models • Extreme programming • Adaptive software development • Dynamic systems development method • Scrum • Crystal • Feature driven development • Adaptive modeling

13. XP (Extreme Programming) • XP is a most common agile method which uses an object oriented approach. • XP phases : Planning - customers write set of stories in index cards, that describe the required features and functionality for software to be built. And set priority of stories • Project team assess each story and assign a cost (in development weeks). Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level, combine some stories.

14. XP - planning Customers and XP team work together to decide how to group stories into the next release. small units of functionality that make good business sense and can be released into the customer's environment early in the project • Once the basic commitment (delivery date, stories to be included ) is made the XP team orders the stories. • After the first release,XP team computes project velocity • project velocity is used to determine either how many stories can be implemented before a given date (time) or how long a set of stories will take to finish (scope).

16. Designing -XP design fallows KIS principle. Simplicity. - Use CRC (class responsibility collaboration) cards for design sessions. These cars identify and organize the object oriented classes relevant to the current software increment -Create spike solutions to reduce risk. Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns .

17. XP-designing -No functionality is added early. -Refactor whenever and wherever possible. When we remove redundancy, eliminate unused functionality, and rejuvenate obsolete designs we are refactoring. Refactoring throughout the entire project life cycle saves time and increases quality. Refactor mercilessly to keep the design simple as you go and to avoid needless complexity

18. Coding • The customer is always available. Code must be written to agreed standards. • Code the unit test first.Once the stories are developed and preliminary design work is done, the team should not move to code rather develop a series of unit tests for the current release. • All production code is pair programmed. XP recommends two people to work together to create code for a story. each person takes slightly different role • As the pair programmers complete their work ,the code is integrated with others. Integrate often.

19. Testing - focuses on unit tests to exercise stories • unit tests created before coding are implemented using an automated testing framework to encourage use of regression testing • integration and validation testing done on daily basis • acceptance tests focus on system features and functions viewable by the customer • All the individual test are organized into a universal testing suite and integration, validation testing of the system can occur on a daily basis • This provides XP team with continual progress and also can raise warning flags early.

20. Adaptive Software DevelopmentFeatures • Self-organization arises when independent agents cooperate to create a solution to a problem that is beyond the capability of any individual agent • Adaptive cycle characteristics • Mission-driven • Component-based • Iterative • Time-boxed • Risk driven and change-tolerant

22. Adaptive Software Development - 1 • Speculation • project initiated • risk driven adaptive cycle planning takes place • Collaboration • requires teamwork from a jelled team • joint application development is preferred requirements gathering approach • minispecs created

23. Adaptive Software Development - 2 • Learning • components implemented and tested • focus groups provide feedback • formal technical reviews • postmortems

24. Dynamic Systems Development Method • Provides a framework for building and maintaining systems which meet tight time constraints using incremental prototyping in a controlled environment • Uses Pareto principle (80% of project can be delivered in 20%of time required to deliver the entire project) • Each increment only delivers enough functionality to move to the next increment • Uses time boxes to fix time and resources to determine how much functionality will be delivered in each increment

25. Dynamic Systems Development Method Life Cycle - 1 • Feasibility study • establishes requirements and constraints • Business study • establishes functional and information requirements needed to provide business value • Functional model iteration • produces set of incremental prototypes to demonstrate functionality to customer

26. Dynamic Systems Development Method Life Cycle - 2 • Design and build iteration • revisits prototypes to ensure they provide business value for end users • may occur concurrently with functional model iteration • Implementation • latest iteration placed in operational environment

27. Scrum Principles • Small working teams used to maximize communication and minimize overhead • Process must be adaptable to both technical and business challenges to ensure best product produced • Process yields frequent increments that can be inspected, adjusted, tested, documented and built on • Development work and people performing it are partitioned into clean, low coupling partitions • Testing and documentation is performed as the product is built • Ability to declare the product done whenever required

29. Scrum - 1 • Backlog • prioritized list of requirements or features the provide business value to customer • items can be added at any time) • Sprints • work units required to achieve one of the backlog items • must fit into a predefined time-box • affected backlog items frozen

30. Scrum - 2 • Scrum meetings • 15 minute daily meetings • what was done since last meeting? • what obstacles were encountered? • what will be done by the next meeting? • Demos • deliver software increment to customer for evaluation

31. Scrum • Roles and Responsibilities Scrum Master - project following rules and practices Product owner -officially responsible for project Scrum Team - project team. Free to organize as they see fit to achieve goals of each sprint Customer - participates in Backlog items Management - Makes final decisions

32. Scrum • Practices • Product Backlog -Current prioritized list of work to be done • Effort Estimation - iterative on Backlog items • Sprint - 30 day iteration • Sprint Planning Meeting - decide goals for next spring and how team will implement • Sprint Backlog -Product Backlog items for sprint • Daily Scrum meeting - what doing, what will do, and any problems • Sprint Review Meeting -present results of sprint

33. Feature Driven Philosophy • Emphasizes collaboration among team members • Manages problem and project complexity using feature-based decomposition followed integration of software increments • Technical communication using verbal, graphical, and textual means • Software quality encouraged by using incremental development, design and code inspections, SQA audits, metric collection, and use of patterns (analysis, design, construction)

35. Feature Driven Design - 1 • Develop overall model • contains set of classes depicting business model of application to be built • Build features list • features extracted from domain model • features are categorized and prioritized • work is broken up into two week chunks • Plan by feature • features assessed based on priority, effort, technical issues, schedule dependencies

36. Feature Driven Design - 2 • Design by feature • classes relevant to feature are chosen • class and method prologs are written • preliminary design detail developed • owner assigned to each class • owner responsible for maintaining design document for his or her own work packages • Build by feature • class owner translates design into source code and performs unit testing • integration performed by chief programmer

37. Agile Modeling - 1 • Practice-based methodology for effective modeling and documentation of software systems in a light-weight manner • Modeling principles • Model with a purpose • Use multiple models • Travel light (only keep models with long-term value) • Content is more important than representation • Know the models and tools you use to create them • Adapt locally

38. Agile Modeling - 2 • Requirements gathering and analysis modeling • Work collaboratively to find out what customer wants to do • Once requirements model is built collaborative analysis modeling continues with the customer • Architectural modeling • Derives preliminary architecture from analysis model • Architectural model mist be realistic for the environment and must be understandable by developers