MS - Sem1 - OO Analysis and Design - post 3

v  Agile software development

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001.

Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others does 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.

The meanings of the manifesto items on the left within the agile software development context are described below:

• Individuals and interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
• Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.
• Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
• Responding to change – agile development is focused on quick responses to change and continuous development.

Predictive planning: In the early stages of project plan need to be made for different phases. This type of planning is adapted when the project is fixed price/fixed scope contract. The requirement understanding is very strong in the earlier stage. With predictive planning, a project has two stages. The first stage comes up with plans and is difficult to predict, but the second stage is much more predictable because the plans are in place.

Adaptive planning: The majority of software projects experience significant requirements churn: changes in requirements in the later stages of the project. These changes shatter the foundations of a predictive plan. You can't say "according to plan" in an adaptive environment, because the plan is always changing. This doesn't mean that adaptive projects don't plan; they usually plan a lot, but the plan is treated as a baseline to assess the consequences of change rather than as a prediction of the future.

Naturally, the adaptive approach is less desirable, as anyone would prefer greater predictability in a software project. However, predictability depends on a precise, accurate, and stable set of requirements. If you cannot stabilize your requirements, the predictive plan is based on sand and the chances are high that the project goes off course. This leads to two important pieces of advice.

1.     Don't make a predictive plan until you have precise and accurate requirements and are confident that they won't significantly change.

2.     If you can't get precise, accurate, and stable requirements, use an adaptive planning style.

Predictivity and adaptivity feed into the choice of life cycle. An adaptive plan absolutely requires an iterative process. Predictive planning can be done either way, although it's easier to see how it works with waterfall or a staged delivery approach.

Ø   Agile methodologies

•XP (Extreme Programming)

–      Most popular agile methodology

•Scrum

–      Concentrates on management aspects of development

•Rational Unified Process

–      Debatable about its agility though!!

–      Misconstrued and misinterpreted

XP motivation

§  Good clean code is easy to change

§  Customers make all business decisions

§  Developers make all technical decisions

§  Make iterations as short as possible so that Customer can drive with rapid feedback

XP Activities

§  Write User Stories

§  Release Planning

–      Plan iterations (The project is divided into iterations)

–      Plan by time, scope, resources and quality use CRC cards

–      Make frequent small releases

•       release small units of functionality into customers environment

•       critical to get valuable feedback

–      Iteration planning starts each iteration

•       Each iteration is 1 to 3 weeks long

•       User stories are chosen by the customer for a particular iteration

o    High priority stories are chosen first

•       Stories are broken down into tasks and implemented

•       Fix stand up meetings everyday

§  Designing

–      Simplicity

•       Keep it simple, not easy though!!

–      Use CRC cards for design sessions

–      No functionality is added early

•       Stick to that particular iteration

§  Development

–      An important requirement of (XP) is to make the customer part of the development team

–      Coding standards are followed

1.     Pair programming

2.     Test Driven Development

3.     Refactoring                                           Agile Toolkit

4.     Continuous Integration

5.     Collective Ownership

§  Use Case:

–              Describes how an Actor interacts with the system to achieve a Goal

–              Focus is on user and validation

–              Tells a “complete story”

§  User Story:

–              A bite-size bit of functionality that has business value and can be developed in a few days

–              Focus is on developer and production

–              Part of a “complete story”

–              Drives the creation of acceptance tests

When to use XP?

§  Problem domains whose requirements change

§  Customers may not have a firm idea of what the system should do.

§  A system whose functionality is expected to change every few months

§  XP practices are set up to mitigate the risk and increase the likelihood of success

Drawbacks of XP

§  May not be suitable for large complex projects

§  Requires a great amount of discipline

v  Scrum

§  Highly iterative development methodology

§  Concentrates on the management aspects of software development

–      Divides development into thirty day iterations (called 'sprints')

–      Applies closer monitoring and control with daily scrum meetings.

–      Less emphasis on engineering practices

–      Combined with extreme programming's engineering practices

Motivations of Scrum

§  Changes may be hard to make, so identify them as soon as possible

§  Developers know how to develop, so just stay out of their way and let them do it

§  Make 30-day iterations for two reasons:

o    Enough heft to allow Developers to believe they’re doing something real

o    Short enough so that Management doesn’t feel abandoned

Scrum Activities

§  Sprint Planning

§  Sprint

§  Daily Scrum

§  Sprint Review

Scrum practices

§  Identify and Remove Impediments

§  Identify Product Backlog

§  Define Sprint Backlog

§  No Interference, no Intruders, no Peddlers

§  Frequent, First-Hand Observations

Which one to choose?

§  Projects can choose a combination of the practices from these methodologies

§  For a large projects

o    Choose RUP

o    Use 1 month iterations like Scrum

o    –Use XP development practices

o    Handle interactions like Scrum

§  For small projects

o    Start with XP

o    Use Scrum iterations

o    Develop use cases like RUP for marketing