 |
 |
|
 |
 |
5 International Software Testing conference
th
February 21- February 22, 2005
Hyderabad, India
Agile Development/Testing – Is history repeating itself?
A Technical Paper
By
Shrini Kulkarni
Microsoft India R&D pvt Ltd
Hyderabad
India
Disclaimer:
The views presented in this paper purely, are of the author and in no way relate to or
represent those of Microsoft Corporation. There are different teams in Microsoft currently
that are trying out agile methodologies and there are different opinions emerging.
The ideas expressed in this paper are a combination of my own ideas and those expressed
in public forums by some of the leading practitioners of the Agile processes. I have
quoted directly or indirectly from Jim Hightower, Alistair Cockburn, Ken Schwaber, Kent
Beck, Martin Fowler and many others, and relied on sources atwww.c2.com,
www.agilealliance.com, While I stand behind the concepts I’ve described, and I use them
in my daily work, I could not succeed without these amazing thinkers and practitioners
who freely give their time and expertise to improving the practice of software
development. I wish to convey my gratitude to my colleague Nick Malick who gave lots of
insights for this paper.
Introduction
In good old days we had project teams where everybody played every possible role. A
developer performed system testing, a tester developed a core module, and a support analyst
performed some development/testing. So it was the team of all-rounders. As projects started
failing due to - late delivery, cost overruns, and cancelled projects, it led to more clearly defined
processes of project management, development, test, and support.
Then there were customer surprises, production bugs causing “Quality” to take center
stage and software testing emerged as separate discipline. So roles like testers, Test leads, and
Test managers evolved and we have organizations focusing on independent software testing
services as core business. But the woes of customer though reduced but left him asking for more
sophistication in delivery and agility.
The phrase “Agile“ was coined in February 2001. A group of proponents of what were then called
"lightweight methods" gathered to find out what they had in common. The term lightweight" was
not considered very flattering, so "agile" was chosen instead. The group also produced "The
Manifesto for Agile Software Development" (www.agilemanifesto.org).
The values, principles and practice of Agile are best described as in agile manifesto –
Agile
Non Agile
Individuals and interactions
processes and tools
Working software
comprehensive documentation
Customer collaboration
contract negotiation
Responding to change
following a plan
It is important to note that agilists have no problem with the items on the right. It is just that given
achoice, they will prefer to go with the items on the left.
Agile methodology tries to address following key customer pain points.
Responsive to changes business requirements – Agility
Quick adaptability
Quality– with continuous customer involvement and feedback, customer gets close to what
he/she paid for.
This required project teams focus on delivering customer demonstratable smaller chunks in small
iterative cycles, responsiveness and agility to change in requirements. Hence agile team started
surfacing–where in close knit project teams worked based on following three principles
Communication–Avoid busy work – focus on optimum documentation and communication
Simplicity in process and management – iterative development and daily team meeting
Agility to customer requests and changes – small iterative cycle with each cycle producing
something that delivers some immediate business value.
Served in various flavors like Extreme programming (XP), Scrum, Crystal, ASD (adaptive
software development) DSDM (Dynamic system development Method) etc, it has really caught
the eyes of purists, reformers and everyone alike. Common values and principles can be found at
agile manifesto
The practice of agile as it is known today has emerged as light weight process is fast generating
2
interest and acceptance as sustainable SDLC model and practice.
In Quest of new SDLC models –
Most of the SDLC models that we use today suffer from following problems:
Requirements are not clear – not clear to start with
Customer can give feedback only by seeing some working functionality
Requirements change too often– the problem is that Traditional models expect that
requirement do not change.
Decrease customer satisfaction due to budget overruns delayed deliveries etc.
Problems with not getting everything upfront – big solid design to begin with.
As per some estimates, project teams build about 30% of the functionality that is not needed.
That means that a large portion of the time spent developing every application is wasted on
developing (and testing, and debugging, and deploying) functionality that no one uses. This
happens due to lack of customer involvement or lack of getting early and continuous
feedback.
So there is quest to invent new models or methodologies that produce software in faster in cost
effective manner, satisfying the customer in quality and time to deliver.
Features of Agile development
People
Highly people oriented – expects high degree of discipline by people.
Process
Simplified communication and project management – daily meetings.
Customer involvement at every stage of the project – seek continuous feedback.
Continuous integration – keep droping some working code to test as often as possible.
Start coding ASAP – Do not expect big and robust upfront Design
Test-Driven-Development, the programmer first devises a simple example of what some
chunk of code should do and implements it as a test that the code either passes or fails.
Since the code doesn't exist yet, it fails. He next writes a tiny bit of code that makes the
test pass. There is now one good example of what the code does, and code that does
nothing but match that one example. He then picks another example, probably slightly
more complicated, and goes through the process again, slightly expanding the code.
The process continues until there are no more examples.
Test as early as possible
Project proceeds in iterations each consisting of a week to a month at the end of which
the team delivers “nearly shippable product” containing promised features.
Project team has agility – does not worry in N cycle about what is coming in (N+5)
th
th
Cycle– “let us cross the bridge when we approach”.
Communication
Agile programmers rely a great deal on constant communication.
Teams typically work in bullpens rather than offices or cubicles so that there are no
barriers to asking questions or sharing information. Most have daily meetings intended to
tell each other what they did yesterday, what they plan to do today, and what help they
need.
Programmers are not guided by set of documents but by communications within team
and with the customer.
Flavors of Agile practice
1
Today’s agile projects are run in any one of the following flavors of agile with all following basic
principles of agile while making subtle modifications to suit a given context.
Extreme programming XP
Of all the agile methodologies, this is the one that has got the most attention.XP begins with four
values: Communication, Feedback, Simplicity, and Courage. It then builds up to a dozen
practices which XP projects should follow. Many of these practices are old, tried and tested
techniques, yet often forgotten by many, including most planned processes. As well as
resurrecting these techniques, XP weaves them into a synergistic whole where each one is
reinforced by the others. On this platform XP builds an evolutionary design process that relies on
refactoring a simple base system with every iteration. All design is centered around the current
iteration with no design done for anticipated future needs. The result is a design process that is
disciplined, yet startling, combining discipline with adaptivity in a way that arguably makes it the
most well developed of all the adaptive methodologies. Few practices of XP are: Planning
2
Game, small releases, simple design, pair programming, test driven development, Collective
code ownership.
Scrum
3
Scrum is an agile process for developing software. With Scrum, projects progress via a series of
month-long iterations called sprints. Scrum is ideally suited for projects with rapidly changing or
highly emergent requirements. The work to be done on a Scrum project is listed in the Product
Backlog, which is a list of all desired changes to the product. At the start of each Sprint a Sprint(or
an iteration) Planning Meeting is held during which the Product Owner prioritizes the Product
Backlog and the Scrum Team selects the tasks they can complete during the coming Sprint.
These tasks are then moved from the Product Backlog to the Sprint Backlog. During the Sprint
the team stays on track by holding brief daily meetings. At the end of each Sprint the team
demonstrates the completed functionality at a Sprint Review Meeting.
However management does not disengage during the sprint. Every day the team holds a short
(fifteen minute) meeting, called a scrum, where the team runs through what it will do in the next
day. In particular they surface to the management blocks: impediments to progress that are
getting in the way that management needs to resolve. They also report on what's been done so
management gets a daily update of where the project is. Scrum literature focuses mainly on the
iterative planning and tracking process. It's very close to the other agile’s in many respects and
works well with the coding practices from XP.
DSDM (Dynamic System Development Method)
DSDM started in Britain in 1994 as a consortium of UK companies who wanted to build on the
RAD (Rapid Application development) and iterative development. Starting with 17 founders it now
boasts over a thousand members and has grown outside its British roots. Being developed by a
consortium, it has a different flavor to many of the other agile methods. It has a full time
organization supporting it with manuals, training courses, accreditation programs, and the like
Using the method begins with a feasibility and a business study. The feasibility study considers
whether DSDM is appropriate to the project at hand. The business study is a short series of
workshops to understand the business area where the development takes place. It also comes up
with outline system architectures and project plan.
The rest of the process forms three interwoven cycles - the functional model cycle produces
analysis documentation and prototypes, thedesign and build cycle engineers the system for
operational use, and the implementation cycle handles the deployment to operational use. DSDM
has underlying principles that include active user interaction, frequent deliveries, empowered
teams, testing throughout the cycle. Like other agile methods they use short time-boxed cycles of
between two and six weeks. There's an emphasis on high quality and adaptivity towards
changing requirements.
Crystal
4
Crystal is a family of human-powered and adaptive, ultra-light, "shrink-to-fit" software
development methodologies. "Human-powered" means that the focus is on achieving project
success through enhancing the work of the people involved (other methodologies might be
process-centric, or architecture-centric, or tool-centric, but Crystal is people-centric). "Ultra-light"
means that for whatever the project size and priorities, a Crystal-family methodology for the
project will work to reduce the paperwork, overhead and bureaucracy to the least that is practical
for the parameters of that project. "Shrink-to-fit" means that you start with something possibly
small enough, and work to make it smaller and better fitting. Crystal is non-jealous, meaning that
a Crystal methodology permits substitution of similar elements from other methodologies.
The Crystals share a human orientation with XP, but this people-centeredness is done in a
different way. The Crystal also puts a lot of weight in end of iteration reviews, thus encouraging
the process to be self-improving. This method believes that the iterative development is there to
find problems early, and then to enable people to correct them. This places more emphasis on
people monitoring their process and tuning it as they develop.
Challenges of Agile
5
Adopting agile methods for any projects are typically associated with “skeptism”, resistance to
change and most importantly getting a buy-in from sponsors and management. Here are few
challenges that I have observed and faced. Views expressed against each of this are - a
compilation of responses or voices of agile community at large.
How does Agile/XP handles design changes that come along? If an agile project is
considered to be equivalent to building house, how would one add basement to a house
that does not have one, after the house is built?
Kent Beck (Father/creator of XP) states with the assumption that design of software is inherently
different than physical construction design, in that the cost of changing the design of a well-
architected system does NOT increase over time. In other words, in software, we have no
gravity. Therefore, adding a basement is no more difficult, for a well architected application, than
adding a new roof. The design changes are incorporated as and when they come. It might cause
us to have to drop a story or whatever we need to do to make time for the design change.
Is Agile "Anti process" oriented? It is often said that Agile does not follow any process.
When an agile project is not run on agile principles, it tends to become ad-hoc. When people from
predominantly traditional models try agile, there is a strong urge to follow process and do the
things as dictated by these models yet there is a tendency to call the project as agile. In such
cases of ambiguity or people deciding to do a hybrid model, project tends to become Ad-hoc.
Agile, fundamentally requires a high degree of individual discipline. Some times people tend to
become ad-hoc. They may panic in the face of difficulty and go back to old, bad habits even
though they don't work.
What happens to metrics like bugs slipped to UAT by test etc?
For a defect to "slip to UAT," the requirements were either misunderstood or were not fully tested.
While the second happens, the first is by far more common. Rather than saying "let's fix the
requirements, and measure the drop in this number," Agile processes say "let's increase
communication, and measure customer satisfaction and the total number of useful features
delivered in a product."
What are the metrics that Agile project teams measuring? How about Effort and schedule
variance?
Measuring anything is always tricky because it is open to interpretation. From the stand point of
delivering the business value, metrics that we measure need to be built around “delivered
features”. To count, a feature must be finished, meaning it must have its GUI, its database tables,
its installation procedures, and its tests. And all its code must be refactored to fit in with the pre-
existing code.
Here is what I heard about metrics measured by agile teams.
The count of running, finished, tested features
The time from a business decision to delivering the result
Code Complexity
Total lines of code
Code coverage by unit and acceptance tests
Velocity- The number of features finished per week.
Metrics like effort v/s schedule variance are not measured as this is pretty hard to track since re-
estimations of stories will affect the schedule. At an iteration level, one can measure the
completed stories with what was on the plate for the iteration. Sometimes it is possible to achieve
more stories than in the initial iteration plan.
How are bugs managed in agile projects?
What is Agile's recommendation of Defect management? Is every bug logged and tracked
as such - if yes this contradicts agile principle of simple communication -Emphasis on
people than process.
By and large there are two approaches for handling bugs in agile methodologies. There is some
degree of disagreement between using a full fledged defect tracking system and using simple
backlogtracking system. Some Argue that there is need to have both as a defect tracking system
isquality focused – meaning it helps to track the defects, causes, trends and remedial measures
where as backlog sheet is “feature focused” as it keeps track of features and bugs in them.
TDD, pair programming, and continuous integration have been found to show absurdly low defect
rates. Just as you rarely find yourself using a debugger, or hunting bugs for a long time, you also
rarely find yourself delivering a bug. In case of legacy system that still has a lot of bug a defect
tracking system would be of some use.
Bugs are found in the testing of the story. A bug may become a story if it's too big to fix during
the same iteration, or if it's not really a bug but an unstated requirement/feature.
 |
|
 |
|