Notes Unit 1:

Agile Software Development

The Agile method is flexible and customer-focused. Although methodologies similar to Agile were already
being practiced, the Agile model wasn't official until 2001, when seventeen software developers joined
together to figure out a solution to their frustrations with the current options and came up with the
Manifesto for Agile Software Development, also known as the Agile Manifesto.

Agile Manifesto:

According to the Agile Manifesto, the values of Agile are:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation

 Customer collaboration over contract negotiation

 Responding to change over following a plan

The manifesto lists twelve different principles:

1. Customer focus - Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Embrace change and adapt - Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Frequent delivery of working software - Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
 4. Collaboration - Business people and developers must work together daily throughout the project.
5. Motivated teams - Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. Face-to-face conversations - The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software - Working software is the primary measure of progress.
8. Work at a sustainable pace - Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Agile environment - Continuous attention to technical excellence and good design enhances agility.
10. Simplicity - The art of maximizing the amount of work not done--is essential.
11. Self-organizing teams - The best architectures, requirements, and designs emerge from self-organizing teams.
12. Continuous Improvement - At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behaviour accordingly.

Agile Methods (Tools / framework for agile)

Vehicle ……..> car, 2 wheeler

Various Agile Methods:

The Agile Manifesto by design, wasn't precise about how Agile should work. After forging the Manifesto, its originators
(and many others) kept evolving these ideas, absorbing new ideas from many sources, and testing them in practice. As
a result, over the past few decades, many takes on Agile have emerged, and some have become widely popular. These
include:

(1) Extreme Programming (XP) - Compared with Scrum, XP is more prescriptive about software engineering best-
practices, and more deliberately addresses the specific kinds of quality-of-life issues facing software development
teams.
(2) Agile Scrum - In rugby, the term scrum describes a point in game play where players crowd together and try to gain
possession of the ball. The Scrum focuses on small, self-organizing teams that meet daily for short periods and work in
iterative sprints, constantly adapting deliverables to meet changing requirements.

Scrum Elements:
(1) THREE Roles: also knows as scrum team
 Product Owner:
 Scrum Master:
 Team Member :
Scrum Team:
 Scrum teams are cross-functional, collaborative, self-managed and self-empowered. Ideally, these scrum teams
should not be larger than 10 individuals, but they should be big enough to finish a user story within a sprint.
 Every day, each scrum team should have a daily stand-up. A stand-up is a meeting that should last no longer than
15 minutes, and should take place at the same time every day. In fact, it's called a "stand-up" because ideally it
should be short enough for the team to accomplish it without having to sit down.
 The goal of the daily stand-up is to keep all team members in sync with what each person has accomplished since the
last stand-up, what they are going to work on until the next stand-up, and what obstacles they have that may be
preventing them from finishing their task. The scrum master facilitates these stand-ups, and their job is to report
and/or help remove obstacles.

(2) THREE Meetings: scrum team meeting.

 Planning (Release & Sprint): during planning and release phase (when ready for deployment)
  Daily Scrum(stand-up): in every 24 hours for 15 min only.
 Sprint Review: after completion of a sprint.
(3) THREE Lists: also knows as Scrum Artifacts: physical records which provide project details.

 Product Backlog
 Sprint Backlog
 Product Increments
What is Backlog?

 It is the role of the product owner to create the backlog.

 This backlog is made up of all of the features for the software, in a prioritized list. The features in the backlog are
a result of the Requirements & Analysis phase, and include features that won't necessarily be in the immediate
release.
 New features can be added to the backlog at any time, and the product owner can reprioritize the backlog based
on customer feedback.
 The Product Backlog is the list of “everything” – in priority order.
 In a Sprint, the team will work on a very small subset of the Product Backlog.
When planning the Sprint, the team will consider the business value they will be able to deliver at the end of
the Sprint.

The reasons for the Product Backlog:

 The team can start doing the “most valuable” parts of the system in early iterations – the system features
that have the highest business value to the customer.
 If some new “high-value features” are discovered later, they can be added to the Product Backlog – and
they might actually push some other less valuable features out of the release. This is OK – assuming that
your customers really want you to build the newly discovered features (instead of just blindly delivering the
items in the original release plan).
 The estimates in the Product Backlog help managers plan the release: they should try not to promise more
than the team thinks they can deliver.
 Even if there are problems delivering everything in the release plan, following the Product Backlog in each
iteration will result in the team delivering the maximum customer value possible with the resources
available

(4) Burn down chart

(5) Scrum Board

Sprints: In the Agile model, the software development life cycle still applies. Unlike the waterfall method, where there
is single long iteration of the SDLC, Agile is many quick iterations of the SDLC.
A Scrum iteration (called a Sprint) contains a list of tasks and work product outputs that will be done in a 4-week*
time-box.
These quick iterations are called sprints, and the purpose of sprints is to accomplish the frequent delivery of working
software principle of the Agile manifesto. A sprint is a specific period of time (time-boxed) which is usually between two
weeks and four weeks, but preferably as short as possible. The duration of the sprint should be determined before the
process begins and should rarely change.

During a sprint, each team takes on as many tasks, also known as user stories, as they feel they can accomplish within
the time-boxed duration of the sprint. When the sprint is over, the software should be working and deliverable, but that
doesn't necessarily mean that it will be delivered; a sprint doesn't always lead to a release, but Agile requires the
software to remain deliverable.

What is User story?

When a feature gets close to the top of the priority list, it gets broken down into smaller tasks called user stories. Each
user story should be small enough that a single team can finish it within a single sprint. If it's too large to be completed
in a single sprint, the team should break it down further. Because the software must be deliverable at the end of each
sprint, a user story must also abide by those rules. A user story is a simple statement of what a user (or a role) needs,
and why. The suggested template for a user story is:

As a <user|role>, I would like to <action>, so that <value|benefit>

Completing a user story requires completing all of the phases of the SDLC. The user story itself should already have the
requirements defined by the product owner, and the team taking on the user story needs to come up with a design for
the task, implement it and test it.

(3) Lean - Based on Lean Manufacturing, the Lean method emphasizes elimination of wasted effort in planning and
execution and reduction of programmer cognitive load.

(4) Feature-Driven Development (FDD)

IMP NOTES points: An Agile methodology for developing software, Feature-Driven Development (FDD) is customer-
centric, iterative, and incremental, with the goal of delivering tangible software results often and efficiently. FDD in Agile
encourages status reporting at all levels, which helps to track progress and results.

FDD allows teams to update the project regularly and identify errors quickly. Plus, clients can be provided with
information and substantial results at any time. FDD is a favorite method among development teams because it helps
reduce two known morale-killers in the development world: Confusion and rework.

First applied in 1997 during a project for a Singapore bank, FDD was developed and refined by Jeff De Luca, Peter
Coad and others. The original project took 15 months with 50 people, and it worked; it was followed by a second, 18-
month long, 250-person project./p>

Since then, it’s become a pragmatic approach ideal for long-term, complex projects looking for a simple but
comprehensive methodology. While Scrum and new variations of Agile are more widely recognized methods (especially
outside of software development), FDD can be a good option for software development teams looking for a structured,
focused Agile methodology that can be scaled across the product organization and will deliver clear outcomes.

FDD prescribes that software development should proceed in terms of an overall model, broken out, planned, designed,
and built feature-by-feature. It specifies a process of modeling used to estimate and plan feature delivery, and a detailed
set of roles for both the core development team and support people.

How is FDD Different from Scrum?

(1) FDD is related to Scrum, but as its name implies, it’s a feature-focused method (as opposed to a delivery-focused
method). Features are a foundational piece of FDD; they’re to FDD what user stories are to Scrum: Small functions that
are, most importantly, client-valued.

(2) “During FDD, a feature should be delivered every 2-10 days – which differs from Scrum, in which sprints typically
last two, but sometimes four, weeks.”

(3) FDD values documentation more than other methods (Scrum and XP included), which also creates differences in the
roles of meetings.
(4) In Scrum, teams typically meet on a daily basis; in FDD, teams rely on documentation to communicate important
information, and thus don’t usually meet as frequently.

(5) Another key difference is the end user; in FDD, the actual user is viewed as the end user, whereas in Scrum it’s
typically the Product Owner who is seen as the end user.

How Does FDD Work?

FDD used in large-scale development projects; five basic activities exist during FDD:

Process #1: Develop an Overall Model ---- from step 1 to 3 project wise upfront design activities perform.
Process #2: Build a Features List.
Process #3: Plan By Feature
Process #4: Design By Feature --- in step 4 and 5 deliver the system by feature by feature.
Process #5: Build By Feature

Imp Note: (1) An overall model shape is formed during the first two steps, while the final three are repeated for each
feature. The majority (roughly 75%) of effort during FDD will be spent on the fourth and fifth steps – Design by Feature
and Build by Feature.

Stages of Feature-Driven Development

Stage 0: Gather Data

As with all Agile methodologies, the first step in FDD is to gain an accurate understanding of content and context of the
project, and to develop a clear, shared understanding of the target audience and their needs. During this time, teams
should aim to learn everything they can about the why, the what, and the for whom about the project they’re about to
begin (the next few steps will help clarify the how). This data-gathering can be thought of as stage 0, but one that
cannot be skipped. To compare product development with writing a research paper, this is the research and thesis
development step.
Once teams have a clear understanding of their goals, the targeted audience and their current (and potentially, future)
needs, the first named stage in FDD can begin: Developing an Overall Model.

Develop an overall model

Continuing the research paper metaphor, this stage is when the outline is drafted. Using the “thesis” (aka primary goal)
as a guide, the team will develop detailed domain models, which will then be merged into one overall model that acts as
a rough outline of the system. As it develops and as the team learns, details will be added.
Plan by features:
 Construct initial schedule
◦ Formed on level of individual features
 Prioritize by business value
 Also consider dependencies, difficulty, and risks
 Assign responsibilities to team members
◦ Determine Class Owners
◦ Assign feature sets to chief programmers
Build a features list
Use the information assembled in the first step to create a list of the required features. Remember, a feature is a client-
valued output. Make a list of features (that can be completed in two weeks’ time), and keep in mind that these features
should be purposes or smaller goals, rather than tasks.

Design by Feature:
A chief programmer will determine the feature that will be designed and build. He or she will also determine the class owners and
feature teams involved, while defining the feature priorities. Part of the group might be working on technical design, while others
work on framework. By the end of the design stage, a design review is completed by the whole team before moving forward.

Build by Feature:
This step implements all the necessary items that will support the design. Here, user interfaces are built, as are components detailed
in the technical design, and a feature prototype is created. The unit is tested, inspected and approved, then the completed feature can
be promoted to the main build. Any feature that requires longer time than two weeks to design and build is further broken into
features until it meets the two-week rule.

Conclusion
Feature-Driven Development is a practical Agile approach suited for long-term, complex projects. It is a suitable choice for
development teams seeking a simple but structured Agile method that is scalable and delivers predictable results.