Agile Development
Agile development is an ability to,
-
Develop s/w quickly along with
The support of integrating rapidly changing requirements.
For agile development, we need to employ,
-
Design principles
Design Patterns and
Practices that make our s/w flexible and maintainable.
Principles, Patterns, and practices are important but it’s the people that make them
work.
“We can’t manage team or programmers like components of a system.
We need to build collaborative and self organizing teams.”
A project with no practices to guide it leads to,
-
Unpredictability,
Repeated error,
Wasted effort.
Customers are disappointed by
-
Slipping schedules,
Growing budgets, and
Poor quality.
Developers are disheartened by working ever-longer hours to produce ever-poorer
software.
From past experiences,
-
We develop processes to constrain our activities and demands certain outputs and
artifacts.
Projects are not so simple that a few constraints and artifacts can reliably prevent
error.
We diagnose those errors and put in place even more constraints and artifacts in
order to prevent those errors in the future.
After many projects, we may find ourselves overloaded with a huge, cumbersome
process that greatly impedes our ability to get projects done
A big, cumbersome process can create the very problems that it is designed to
prevent. It can,
o Slow the team to the extent that schedules slip and budgets expand
o Reduce the responsiveness of the team to the point of always creating the
wrong product.
Agile Alliance
A group of industry experts (the Agile Alliance) met in early 2001 to outline the values
and principles that would allow software teams to develop quickly and
respond to change.
Over the next several months, this group worked to create a statement of values. The
result was The Manifesto of the Agile Alliance.
Value statements of AGILE Manifesto
1. Individuals and Interactions over Processes and Tools
People are the most important ingredient of success.
“A good process will not save a project from failure if the team doesn't have strong
players, but a bad process can make even the strongest of players ineffective.”
Even a group of strong players can fail badly if they don't work as a team.
A strong player may be an average programmer but someone who works well with
others
A team of average programmers who communicate well are more likely to succeed than
is a group of superstars who fail to interact as a team.
The right tools can be very important to success.
Compilers, interactive development environments (IDEs), source code control systems,
and so on, are all vital to the proper functioning of a team of developers.
However, tools can be overemphasized. An overabundance of big, bulky tools is just as
bad as a lack of tools.
Start with small. Instead of buying the top-of-the-line, expensive source code control
system, find a free one and use it until you can demonstrate that you've outgrown it.
Before you buy team licenses for the best of all computer-aided software engineering
(CASE) tools, use whiteboards and graph paper until you can unambiguously show that
you need more.
Before you commit to the top-shelf database system, try flat files.
Don't assume that bigger and better tools will automatically help you do better. Often,
they hinder more than they help.
Building the team is more important that building the environment. Many teams and
managers make the mistake of building the environment first and expecting the team to
gel automatically.
2. Working Software over Comprehensive Documentation
Software without documentation is a disaster.
Code is not the ideal medium for communicating the rationale and structure of a system.
The team needs to produce human-readable documents that describe the system and
the rationale for design decisions.
Too much documentation is worse.
-
Huge software documents take a great deal of time to produce and even more
time to keep in sync with the code.
If they are not kept in sync, they turn into large, complicated lies and become a
significant source of misdirection.
It is always a good idea for the team to write and maintain a short rationale and
structure document. But that document needs to be short and salient (MOST important).
-
Short means one or two dozen pages at most.
Salient means that it should discuss the overall design rationale and only the
highest-level structures in the system.
How do we train new team members about the system? We work closely with them. We
transfer our knowledge to them by sitting next to them and helping them. We make
them part of the team through close training and interaction.
The two documents that are the best at transferring information to new team members
are the code and the team.
“The code does not lie about what it does.”
Martin's First Law of Documentation: Produce no document unless its need is immediate and significant
3. Customer Collaboration over Contract Negotiation
“Software cannot be ordered like a commodity”
We cannot write a description of the software we want and then have someone develop
it on a fixed schedule for a fixed price
Company managers tell their development staff what their needs are and then expect
that staff to go away for a while and return with a system that satisfies those needs. But
this mode of operation leads to poor quality and failure.
Successful projects involve customer feedback on a regular and frequent basis.
Rather than depending on a contract, or a statement of work, the customer of the
software works closely with the development team, providing frequent feedback on its
efforts
A contract that specifies the requirements, schedule, and cost of a project is
fundamentally flawed (defective). In most cases, the terms it specifies become
meaningless long before the project is complete.
The best contracts are those that govern the way the development team and the customer will work together.
4. Responding to Change over Following a Plan
The ability to respond to change often determines the success or failure of a software project.
When we build plans, we need to make sure that they are flexible and ready to adapt to
changes in the business and technology.
A software project cannot be planned very far into the future.
-
The business environment is likely to change, causing the requirements to shift.
Once customers see the system start to function, customers are likely to alter the
requirements.
Even if we know what the requirements are and are sure that they won't change,
we are not very good at estimating how long it will take to develop them
Novice managers create a nice PERT or Gantt chart of the whole project by thinking that,
o
o
o
Chart gives them control over the project.
They can track the individual tasks and cross them off the chart as they are
completed.
They can compare the actual dates with the planned dates on the chart and react
to any discrepancies.
A better planning strategy is,
-
To make detailed plans for the next week
Rough plans for the next 3months
And extremely crude(basic) plans beyond that.
AGILE Principles
There are 12 principles.
These principles are the characteristics that differentiate conventional heavy weight
processes and AGILE practice.
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
Deliver a rudimentary (limited / basic) system within the first few weeks of the start
of the project.
Continue to deliver systems of increasing functionality every few weeks.
Customers may choose to put these systems into production if they think that they
are functional enough. Or, they may choose simply to review the existing
functionality and report on changes they want made.
-
The less functional the initial delivery, the higher the quality in the final delivery
The more frequent the deliveries, the higher the final quality.
2. Welcome changing requirements, even late in development. Agile processes
harness (bind) change for the customer's competitive advantage.
The participants in an agile process are not afraid of change.
They view changes to the requirements as good things, because those changes
mean that the team has learned more about what it will take to satisfy
the customer.
“An agile team works very hard to keep the structure of its software flexible, so
that when requirements change, the impact to the system is minimal.”
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter time scale
Deliver working software, and deliver it early and often.
Goal - “Delivering software that satisfies the customer's needs.”
4. Business people and developers must work together daily throughout the project
In order for a project to be agile, customers, developers, and stakeholders must
have significant and frequent interaction.
A software project must be continuously guided.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
All other factors like process, environment, management, and so are secondorder factors and are subject to change if they are having an adverse effect on
the people.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
In an agile project, people talk to one another.
The primary mode of communication is human interaction.
7. Working software is the primary measure of progress.
Agile projects measure their progress by measuring the amount of software that
is currently meeting the customer's need.
They don't measure their progress in terms of the phase they are in or by the
volume of documentation that has been produced or by the amount of
infrastructure code they have created.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
An agile project is not run like a 50-yard dash; it is run like a marathon.
The team does not take off at full speed and try to maintain that speed
for the duration.
Rather, it runs at a fast but sustainable pace.
They don't allow themselves to get too tired.
Don't borrow tomorrow's energy to get a bit more done today.
9. Continuous attention to technical excellence and good design enhances agility.
High quality is the key to high speed.
The way to go fast is to keep the software as clean and robust as possible.
All agile team members are committed to producing only the highest quality code
they can.
They do not make messes and then tell themselves that they'll clean them up when
they have more time. They clean any messes as they are made
10. Simplicity is the art of maximizing the amount of work not done is essential
Agile teams do not try to build the grand system in the sky.
Rather, they always take the simplest path that is consistent with their goals.
They don't put a lot of importance on anticipating tomorrow's problems; nor do
they try to defend against all of them today.
Rather, they do the simplest and highest quality work today, confident that it will
be easy to change if and when tomorrow's problems arise.
11. The best architectures, requirements, and designs emerge from self-organizing
teams
An agile team is a self-organizing team.
Responsibilities are not handed to individual team members from the outside but
rather are communicated to the team as a whole.
The team determines the best way to full-fill those responsibilities.
Agile team members work together on all aspects of the project.
Each member is allowed input into the whole.
No single team member is solely responsible for the architecture or the
requirements or the tests.
The team shares those responsibilities, and each team member has influence
over them.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behaviour accordingly.
An agile team continually
relationships, and so on.
adjusts
its
organization,
rules,
conventions,
An agile team knows that its environment is continuously changing and knows
that it must change with that environment to remain agile.
Main Agile Frameworks
XP: Extreme Programming
XP is a lightweight methodology for small-to-medium sized teams developing
software with rapidly changing requirements.
XP is designed to work with projects that can be built by teams of two to ten
programmers
Why is it called EXTREME PROGRAMMING???
XP takes common principles and practices to extreme levels by some standard
practices.
-
If code reviews are good, we'll review code all the time (pair programming).
-
If testing is good, everybody will test all the time (unit testing), even the
customers (functional testing).
-
If design is good, we'll make it part of everybody's daily business (refactoring)
-
If simplicity is good, we'll always leave the system with the simplest design
that supports its current functionality
-
If architecture is important, everybody will work defining and refining the
architecture all the time (metaphor)
-
If integration testing is important, then we'll integrate and test several times a
day (continuous integration)
-
If short iterations are good, we'll make the iterations short not months and
years (the Planning Game).
Promises of XP
-
-
To programmers,
They will be able to work on things that really matter, every day.
They won't have to face scary situations alone.
Able to do everything in their power to make their system successful.
They will make decisions that they can make best, and they won't make
decisions they aren't best qualified to make.
To customers and managers
They will get the most possible value out of every programming week.
Every few weeks they will be able to see concrete progress
-
They will be able to change the direction of the project in the middle of
development without incurring exorbitant costs
The practices of Extreme Programming
1. Customer Team Member
a. Who defines / priority of s/w modules
b. Both know the problems of each other
c. 100 ft
d. Representative
2. User Stories
a. Required for planning of project
b. Few statements / words which tell about the functionality
c. Not much technical
d. 50-100 stories (priority by customer)
e. Implementation budget is written by developer team (In relative terms)
f. CRC (Class, Responsibilities, Collaborators) card
g. Story points (relative)
3. Short cycles
a. Iteration plan (2 weeks)
b. Release plan (3moths / 6 iterations)
4. Acceptance Tests
a. Written along with user story or just before the actual coding starts
b. Script languages testing as a cont process
c. QA
5. Pair Programming
a. Pair of two
b. Roles changes freq (swap)
c. In a single day, each developer will work in at-least 2 pair
d. During each iteration (2 weeks), each member must have worked with all pairs
e. Spread of knowledge
f. Improve the quality
6. Test driven development
Test case, code to pass the test
Intent based programming
Test cases useful as doc
7. Collective ownership
a. Speciality
8. Cont. Integration (build)
Task are developed in parallel
Integrated
Shared/Non blocking src control (collaborative dev)
9. Sustainable pace
a. Overtime is not allowed
b. Release 3 months
10. Open workspace
a. War room
11. The planning game (chap 3) meeting
a. Release
b. Iteration
c. task
12. Simple design (we ..I1..
13. Refactoring
14. Metaphor (viewing the whole system together)
The basic problem of software development is risk. Here are some
examples of risk:
Schedule slips—the day for delivery comes, and you have to tell the
customer that the software won't be ready for another six months.
●
Project cancelled—after numerous slips, the project is cancelled without ever
going into production.
●
System goes sour—the software is successfully put into production, but after
a couple of years the cost of making changes or the defect rate rises so much
that the system must be replaced.
●
Defect rate—the software is put into production, but the defect rate is so high
that it isn't used.
●
Business misunderstood—the software is put into production, but it doesn't
solve the business problem that was originally posed.
●
Business changes—the software is put into production, but the business
problem it was designed to solve was replaced six months ago by another,
more pressing, business problem.
●
False feature rich—the software has a host of potentially interesting features,
all of which were fun to program, but none of which makes the customer much
money.
●
Staff turnover—after two years, all the good programmers on the project
begin to hate the program and leave.
●
How does XP address the risks listed above?
Schedule slips—XP calls for short release cycles, a few months at most, so
the scope of any slip is limited.
Within a release, XP uses one- to four-week iterations of customer requested
features for fine-grained feedback about progress.
Within an iteration, XP plans with one- to three-day tasks, so the team can
solve problems even during an iteration.
Finally, XP calls for implementing the highest priority features first, so any
features that slip past the release will be of lower value.
●
Project cancelled—XP asks the customer to choose the smallest release that
makes the most business sense, so there is less to go wrong before going
into production and the value of the software is greatest.
System goes sour—XP creates and maintains a comprehensive suite of tests,
which are run and re-run after every change (several times a day), to ensure a
quality baseline. XP always keeps the system in prime condition.
Defect rate—XP tests from the perspective of both programmers writing tests
function-by function and customers writing tests program-feature-by-programfeature.
Business misunderstood—XP calls for the customer to be an integral part of
the team. The specification of the project is continuously refined during
development, so learning by the customer and the team can be reflected in
the software.
Business changes—XP shortens the release cycle, so there is less change
during the development of a single release.
During a release, the customer is welcome to substitute new functionality for
functionality not yet completed.
The team doesn't even notice if it is working on newly discovered functionality
or features defined years ago.
False feature rich—XP insists that only the highest priority tasks are
addressed
Staff turnover—XP asks programmers to accept responsibility for estimating
and completing their own work, gives them feedback about the actual time
taken so their estimates can improve, and respects those estimates.
New team members are encouraged to gradually accept more and more
responsibility, and are assisted along the way by each other and by existing
programmers.
Planning In XP
User stories are written by customers / need not to be technical terms
Estimation of s/w: User story and Story points
If Story is large, developers may underestimate and if story is small it may be overestimated by
developers.
User Story: Uses can securely transfer money into, out of and between their accounts
SPLIT the story into several small stories
User can login
User can logout
User can deposit money into their account
User can withdraw money from account
User can transfer money from their account to other accounts.
AGILE Estimation
Reference story: one of the simple stories from product backlog which is
estimated first time.
Reference story is used to estimate other pending stories.
Story is estimated relatively not absolutely.
Relative estimation is done in the form of Story point (It is a number assigned
to story)
Generally, numbers are taken from Fibonacci series because stories are to be
estimated relatively.
0,1,1,2,3,5,8,13…. (numbers in this are related to eachother)
Criteria to assign story points
1. Complexity of logic and Architecture
2. Gaps, Risks, issues, open questions (more uncertainties)
3. Amount of work (no of textbox, drop down, call to api etc)
Trade-off between complexity and amount of work (high complex, less work
given more points and vice-versa)
Generally a simple story is picked up as reference story and assigned small
number as story point (e.g. 3)
Ask team to compare rest stories with ref story based on above criteria and
assign story points to pending stories.
Sample reference story
Given a new bank customer when open an account then details should be
entered in the system.
First Name,
Last Name
Address
AGE
Birth date
Mobile
Role
UI
DBA
Programmer
TESTER
Total Nearest
estimate
Hours
30
35
25
30
30 (means story
point =3)
Hours
50
55
40
52
50 (points 5)
Hours
60
50
30
45
Two outliers 30
and 60. Coach
will talk to UI and
SS.
Refined
estimates.
Reference table (used only once for reference story. Created based
experiences. It varies project to project, organization to organization ….
Hours
Story
points
20
2
30
3
50
5
80
8
Once ref story is estimated, the ref table is removed.
Assume the story point for ref story is 3. Now consider other two stories.
1. Login story (relatively easy compared to ref story…. Point of 2)
2. Search functionally (more complex than ref story. So given points 5)
Too big/complex stories may be assigned points like 13.
Other stories bigger may need to be split.
Velocity and capacity planning
Velocity: rate at which team delivers the stories (rate is in terms of story
points)
Capacity: Total productive hours of team
Other time may be used for ceremonies or planned/ad-hoc catch ups
2 week iteration
(10 working days, each person can work about 6.5 hours a day)
Resource (developer)
A
B
C
D
E
TOTAL CAPACITY of team
for particular iteration
MAX CAPACITY
Available
# days
10
8
5
10
9
Total capacity
65
52
33.5
65
58.5
241
325
Evolution of velocity and capacity over several iterations
Iteration
1
2
3
4
5
6
Story points (achieved)
32
38
25
40
?
?
Available capacity
325
325
241
325
265
213
AGILE Testing [TEST Driven Development]
Every single
operation.
function
of
the
program
has
tests
that
verify
its
By writing the test first, we design the software to be conveniently callable.
In order to be callable and testable, the software has to be decoupled from its
surroundings.
Writing tests
documentation
first
means
the
tests
act
as
an
invaluable
form
of
Example
The Wumpus game: The player moves through cave and try to kill wumpus befoe
wumpus eat the player. Cave is set of rooms. Rooms are connected to each other
via passages.
The below code is the test function which will test the game code.
-
Intentional programming (write a code which passes the test case. Here test
is the intent)
In above test, room idea is taken as integer. Actually, it may be represented in
form of class.
Test Isolation
The Payroll class uses the EmployeeDatabase class to fetch an Employee object, asks the
Employee to calculate its pay, passes that pay to the CheckWriter object to produce a
check, and, finally, posts the payment to the Employee object and writes the object
back to the database.
Once such, UML diagram is prepared, we write test case.
Now we need to write the tests that specify the behaviour of the Payroll object.
A number of problems are associated with writing this test.
-
What database do we use? Payroll needs to read from some kind of database.
Must we write a fully functioning database before we can test the Payroll class?
What data do we load into it?
How do we verify that the appropriate check got printed?
MOCK Object Pattern: Insert interfaces between all collaborators
In this case, we insert interfaces for EmplyeeeDB, CheckWriter and Employee
classes for the communication with Payroll class.
As per above diagram, payroll now uses interfaces to communicate with all other
component classes.
As per this, new test case intent would be as below.
As per the above design, payroll is decoupled from other components and makes
our design better.
This kind of design allows us to change databases and cheque writers.
TEST driven development inherently causes decoupling.
Unit Test: used to verify function of individual elements, can’t test overall functionality
of system, white box test
Acceptance test:
Black box test, QA people may write scripts to test software, used to verify that
customer’s req are fulfilled or not.
Acceptance tests are written by people who don’t know about internal of software
Acceptance tests are programs i.e. executable
Acceptance tests are written before so, it also increase decoupling in software
design
Example acceptance test: Iteration has following stories
-
Add / delete employee and store in DB
Create pay cheques
A person from customer side can write a acceptance test as below (plain text)
AddEmp 1429 “Robert Martin”, 3215
Payday
Verify paycheck Empid 1429 grosspay 3215
The above test is parsed and corresponding functions will be called.
Similarly, XML can also be used as below (XML based case)
<AddEmp Paytype=salaried>
<EmpID>1429 </EmpID>
<name>Robert Martin</name>
<salary>3215</salary>
</AddEmp>
Payroll application will generate XML document for generated pay cheques as below
<paycheque>
<EmpID>1429 </EmpID>
<name>Robert Martin</name>
<grosspay>3215</grosspay>
</paycheque>
When above xml file is given to verify() function, it will test / verify overall cheques.
-
REFACTORING
Whatever you are doing, make sure that you are doing your best
Refactoring is a change in s/w such a way that it does not alter the external
behaviour of code but improves internal structure of code
Refactoring example Prime Number Generation Program
Overall idea / logic: Refer excel
Unit Test (IntelliJ can be used in eclipse)
Above is the code without any refactoring. It can be seen that there are 3 main functions.
-
1st Initialize and setup the sieve
Execute sieve
Load results in array
After 1st round of refactoring