Академический Документы
Профессиональный Документы
Культура Документы
Seminar Report
On
Signature of guide
Associate Professor
DECLARATION
I, Ajay Kumar Gahalot hereby declare that this seminar titled “Agile Software
Engineering” is a record of original work done by me under the supervision and
guidance of Dr. Rajesh Purohit. We further certify that this project work has not
formed the basis for the award of the Degree/Diploma/Associateship/Fellowship or
similar work to any candidate of any university and no part of this report is
reproduced as it is from any other source without seeking permission.
Signature of student
Abstract.................................................................................................................5
1. Introduction.......................................................................................................6
1.1 What is agile?..............................................................................................6
1.2 Where did agile come from?.......................................................................6
1.3 Why agile?..................................................................................................7
2. Agile Manifesto.................................................................................................8
2.1 Basic aspects of manifesto.........................................................................8
2.2 Agile principles..........................................................................................11
3. Agile Characteristics.......................................................................................12
3.1 Iterative, Incremental and Ready to Evolve..............................................12
3.2 Face-to-Face Communication...................................................................12
3.3 Feedback loop...........................................................................................12
3.4 Time-bound...............................................................................................13
3.5 Parsimony.................................................................................................13
3.6 Convergent................................................................................................13
3.7 People-oriented.........................................................................................13
4. Comparison of Agile and
Conventional...............................................................14
4.1 Shortcomings of conventional waterfall
approach.........................................14
4.2 Iterative and agile methods.......................................................................15
4.3 Agile vs.
Conventional...................................................................................16
5. Agile Methods.................................................................................................19
5.1 Adaptive software development................................................................19
5.2 Extreme Programming..............................................................................21
5.3 Scrum........................................................................................................27
5.4 Crystal.......................................................................................................32
6. Summary.........................................................................................................36
7. References......................................................................................................38
Abstract
In software development process there is always a problem and tension about
quality of software, cost of software development, and time period of software
development process from planning to release. In today’s time, it is very difficult for
developers to deliver a good quality software in required time with cost efficient.
Conventional software development methods are plan-driven which means they
execute a predefined plan for development process in which they have lot of
documentations and these plans often are not applicable for every project for good
quality and fullfill user requirements.
In the past few years the interest in lightweight methods is growing continuously
which provide a way to useful compromise between no process and very much
process.
1. Introduction
Software development activity used to follow “code and fix” approach in earlier days.
This way worked well for systems which were small but it failed when the systems
grew larger, and when there was a need to add some new features. To avoid this
methodology of Engineering came into existence. The purpose of these methods
was to make the software methods more efficient and predictable and by having a
strong focus on planning activity. This way of implementation works also well for
other engineering fields. But the software market is always changing and brings
greater choices into market. Managers and users must deal with some issues for
example what to exclude and what types of technologies include in the software
product, what technologies to be used, what will give a competitive edge to the
company? These questions are difficult to answer and trying predict them in a fastly
changing market is more difficult.
In 1970, Dr. Winston Royce presented a document with title “the Development and
management of Large Software Systems,” which criticized the sequential methods of
development. He stated that the software should not be developed like an
automobile on the assembly line, in which every piece added in sequential phases.
In such type of sequential phases, each phase of project should be completed
compulsory before next phase begin. Dr. Royce suggested against phase based
approach inwhich developers first collect all the project’s requirements, then
complete all of its structure and the design, then write all the code, and so on
continuously. Royce objected specifically to this approach due to lack of the
communication between the specialized groups those complete each part of work.
A collection of lightweight software development processes came in
existence in the mid - 1990s in reaction to the observed heavy weight waterfall type
methods, which critics called heavily organised, controlled, and micro-managed;
although some partisans of these light weight processes contended that these were
simply returning back to earlier software development practices. These light weight
processes include: from 1994, dynamic systems development method (DSDM) and
unified process; from 1995, scrum; 1996, extreme programming (also known as
"XP") and crystal clear; and from 1997, feature-driven development and adaptive
software development. Although these resulted before the publication of Agile
Manifesto in 2001, they are now together referred to as agile methodologies.
2. Agile Manifesto
In 2001, founders of the many of lightweight agile software development
methodologies came altogether with others who were also implementing many types
of agile methods in the field and they created an “Agile Manifesto” which summarize
their belief that there is a better approach to develop software. The Agile Manifesto
was a synthesis of some common beliefs that under lie the various methods that
they were practicing and promoting. It substantially boosted up the adoption of agile
methodologies in the industry because it provided common base for all who headed
down this way, and it did a very good job of integrating and defining the basic beliefs
that underlying the agile movement.
That is, while there is value in the items on the right, we value the items on the left
more.”
People form the base of agile software approach. Using adaptive process requires a
very effective team of developers. The team has to work well together to be more
effective. Teamwork is given high importance than using a specific methods and
tools. Any methods and tools should be used as to increase the team work except of
replacing it. Communication also plays a important role in upgrading the Teamwork.
The face to face meetings have some special importance in agile methodologies. It
is considered that people respond faster and transfer beliefs or concepts more fastly
when talking face to face, than they can while reading or writing documentation.
Extreme programming brings the idea of pair programming where two developers
code a module together to provide much quicker and better output than the same job
they done individually. The concept of synergy (i.e. the interaction of two or more
forces or agents, so that the together effect is greater than the sum of their individual
effects) takes hold because of a few designers, sharing a common space, working
together, can produce more code quicker than can produce the same individuals
working alone.
An other important point of individuals and interactions is that the team should be
provided rights to take all technical decisions. At the times fast decision making is
required, if we have to wait every time for the management to approve it then it slows
down the entire process of development. So the power of technical decisions taking
must rest in the hands of technical people.
It has been a practice, in the Waterfall model to deliver the design documents, the
architecture documents or the test plans, the test cases etc to customer before we
deliver real piece of the working software.
In this continuously changing industry it is not possible to collect the complete set of
customer requirements that are unchanging and stable. The customer is not always
sure of what does he want. He gets a better understanding only when he looks a
prototype of the system or a working model. That helps the customer to predict the
final system better. As the time passes customer may want to add some descriptions
which at that time looks important to have.
However agile methods link code and requirements together. Users of agile methods
view the requirements as changing and fluid. In agile practice of working, the
conventional practice of creating design documents, test plans, test cases, etc. to
customer before it should be substituted with giving piece of working software
increment iteration. It does not mean that we have to escape documentation
completely; but the only necessary documentation which is produced i.e. never
Agile methods say that the requirements can never be fixed so fixed price
development practice would not work in this condition. This doesn’t mean that we
can’t budget what the project made using agile methods would cost. Agile method is
to fix time, cost, and to allow the scope to change in a controlled way. As customer
has better control on project making changes based on feedback got. At the every
iteration, customer and the development team can check progress and can decide
with development team if to alter the direction of the project.
Writing contracts with customers is the profit motive and the collaboration is a
purpose oriented. The purpose motive should be given more importance than the
profit motive. Good agile softwares will build the something different and a better
than original plan foresaw.
Today’s market is a volatile and, the ever changing making it impossible for a
predictive method to work on constant set of requirements. Responding to change
than following laid out plan makes agile software process successful in market today.
Software development is more of a design activity, so it’s hard to plan and cost. For
software development to be predictable there is need for plenty of time, a large team,
and stable requirements which is not possible in small projects. The problem with
predictive processes is their difficult to map new requirement to additional cost, as
they cannot predict how much it would cost to implement the new requirement.
Software is intangible in nature, it is difficult to see what value a software feature has
until we use it for real. Only after seeing the early prototype or version can one
understand what features are important what are not. So this means that
3. Agile-Characteristics
There are many specific agile development methods. Most promote development,
teamwork, collaboration, and process adaptability throughout the life-cycle of the
project. Some characteristics of agile methods are:
Most of the agile development methods break a problem into smaller tasks. There is
no direct long-term planning for any requirement. Normally, iterations are planned
which are of vary short period of time, for example, 1 to 4 weeks. A cross-functional
team is created for each iteration that works in all functions of software development
like planning, requirements analysis, design, coding, unit testing, and acceptance
testing. The result at the end of the iteration is a working product and it is
demonstrated to the stakeholders at the end of an iteration. This minimizes overall
risk and allows the project to adapt to changes quickly. An iteration might not add
enough functionality to warrant a market release, but the goal is to have an available
release (with minimal bugs) at the end of each iteration. Multiple iterations might be
required to release a product or new features.
Working software is the primary measure of progress.
A common characteristic in agile is the daily "stand-up", also known as the daily
scrum. It is a kind of a brief session where each team member reports to each other
regarding the status of what they have done, what to do next, and any issues they
are facing.
3.4 Time-Bound
Iterations become the perfect unit for planning the software development project. We
can set time limits (between one and six weeks is normal) on each iteration and
schedule them accordingly. Chances are, we will not (unless the process contains
very few activities) schedule all of the activities of our process in a single iteration.
Instead, we will only attempt those activities necessary to achieve the goals set out
at the beginning of the iteration. Functionality may be reduced or activities may be
rescheduled if they cannot be completed within the allotted time period.
3.5 Parsimony
Agile processes are more than just a conventional software development process
with some time constraints. Attempting to create impossible deadlines under a
process not suited for rapid delivery puts the onus on the software developers. This
leads to burnout and poor quality. Instead, agile software processes focus on
parsimony. That is, they require a minimal number of activities necessary to mitigate
risks and achieve their goals. By minimizing the number of activities, they allow
developers to deliver systems against an aggressive schedule.
3.6 Convergent
Convergence states that we are actively attacking all of the risks worth attacking. As
a result, the system becomes closer to the reality that we seek with each iteration.
As risks are being proactively attacked, the system is being delivered in increments.
We are doing everything within our power to ensure success in the most rapid
fashion.
3.7 People-Oriented
Agile processes favour people over process and technology. They evolve through
adaptation in an organic manner. Developers that are empowered raise their
productivity, quality, and performance. After all, they are the best individuals in the
organization to know how to make these changes.
Conclusion
Agile processes are not a new phenomenon. They are the evolution of the
best practices which have been refined over the past thirty years. They are not a
silver bullet which will cure your project of all of its ills or guarantee success.
Successfully delivering a project requires hard work and the understanding of the
potential pitfalls. No single process will work for every project. Yet, most projects
would agree that they would like to be more agile. Developing a more agile process
for your project requires an understanding of the dynamics of these projects. It also
requires a certain amount of common sense.
Conventional development approaches have been around for a very long time.
Since its introduction the waterfall model (Royce 1970) has been widely used in both
large and small software projects and has been reported to be successful to many
projects. Despite the success it has a lot of drawbacks, like linearity, inflexibility in
changing requirements, and high formal processes irrespective of the size of the
project. Kent Beck took these drawbacks into account and introduced Extreme
Programming, the first agile methodology produced. Agile methods deal with
unstable and volatile requirements by using a number of techniques, focusing on
collaboration between developers and customers and support early product delivery.
This approach holds that complex systems can be built in a single pass, without
going back and revisiting requirements or design ideas in light of changing business
or technology conditions. It was first introduced in an article written by Winston
Royce in 1970, primarily intended for use in government projects. Waterfall equates
software development to a production line conveyor belt. “Requirements analysts”
compile the system specifications until they pass the finished requirements
specification document to “software designers” who plan the software system and
create diagrams documenting how the code should be written. The design diagrams
are then passed to the “developers” who implement the code from the design.
some requirements may arise after the initial requirement gathering was
completed, which influences negatively the product development;
not all problems detected during a stage are completely solved during the
same stage;
there is no flexibility in partitioning the project into stages;
new requirements added by the client lead to additional costs, because they
cannot be solved in the current edition of the product;
it is difficult to estimate the time and budget for each stage;
there are no prototypes until the life cycle is finished;
if testing detects some problems, it is very difficult to return to design stage;
there is a high risk and uncertainty;
it is not recommended for complex and object oriented projects.
The idea of revisiting phases over and over is called “incremental and iterative
development” (IID). The development lifecycle is cut up into increments or
“iterations” and each iteration touches on each of the conventional “phases” of
development. For example, with IID requirements is an ongoing process that is
periodically revisited. IID allows for multiple “passes”, or iterations, over a project
lifecycle to properly address complexities and risk factors.
In the incremental model the requirements are divided into subsets. The model
involves multiple development cycles, which makes the life cycle look like a “multiple
waterfall” model. The cycles are again divided into smaller cycles, modules easier to
manage. Each module goes through requirement analysis, design, implementation
and testing. During the first module, a working version of the software is created.
Each following version adds new features and functionalities to the previous one.
The process continues until the system is completed.
each stage delivers a working product, that meets some of the client
requirements;
prototypes are delivered to the client;
client feed-back is distributed throughout the entire development process;
it is more flexible – involves lower costs when purpose and requirements
change;
it is easy to test and debug during a small iteration; cuts down on initial
delivery costs;
the risk is easier to manage because all risks are identified and managed
during the iteration;
when there are new requirements, they can be introduces in the next
prototype
Predictive methods, in contrast, focus on analysing and planning the future in detail
and cater for known risks. In the extremes, a predictive team can report exactly what
features and tasks are planned for the entire length of the development process.
Predictive methods rely on effective early phase analysis and if this goes very
wrong, the project may have difficulty changing direction. Predictive teams often
institute a change control board to ensure they consider only the most valuable
changes.
One of the differences between agile and waterfall is the approach to quality and
testing. In the waterfall model, there is always a separate testing phase after a build
phase; however, in agile development testing is usually done concurrently with, or at
least in the same iteration as, programming.
Because testing is done in every iteration which develops a small piece of the
software, users can frequently use those new pieces of software and validate the
value.
After the users know the real value of the updated piece of software, they can make
better decisions about the software's future. Having a value retrospective and
software re-planning session in each iteration, scrum typically has iterations of just
two weeks that helps the team continuously adapt its plans so as to maximize the
value it delivers.
This iterative practice also introduces a product mindset rather than the waterfall
model's project mindset. Software can be seen as a living organism, which actively
changes due to environmental change. As long as the software is being used,
especially when it has competition, iterations in agile software development drive the
change.
Because of the short iteration style of agile software development, it also has strong
connections with the lean start-up concept.
Crystal considers development a series of co-operative games, and intends that the
documentation is enough to help the next win at the next game. The work products
for Crystal include use cases, risk list, iteration plan, core domain models, and
design notes to inform on choices...however there are no templates for these
documents and descriptions are necessarily vague, but the objective is clear, just
enough documentation for the next game. I always tend to characterize this to my
team as: what would you want to know if you joined the team tomorrow.
5. Agile Methods
Agile is a whole methodology. You can call, it is a type of project management, it is a
way of working as a team. For example, comparing with playing basketball,
sometimes you want to play man-to-man and other times you want to play a zone.
Thus we can say there are two ways of executing game of basketball. Similarly, we
can say that Agile is a way of executing software development project management.
So it is a project methodology. Here the word ‘methodology’ can be referred as "A
series of related methods or techniques." A method is a "systematic procedure,"
similar to a technique.
ASD, developed by Jim Highsmith1 does not provide the details often associated
with a process. Milestones, methods, and deliverables are not specific elements
discussed by ASD. Instead, ASD places its emphasis on applying ideas originating
in the world of complex adaptive systems (i.e. Chaos theory). ASD provides the
fundamental base to develop adaptive systems from which arise agile and adaptive
processes.
Jim Highsmith states that the premise of ASD is that outcomes are naturally
unpredictable and, therefore, planning is a paradox. It is not possible to plan
successfully in a fast moving and unpredictable business environment. Adaptive
development is essential when you have developers, customer, vendors,
competitors and, stockholders all attempting to interact with one another at such a
pace that linear cause and effect rules cannot assure success. ASD replaces the
evolutionary life cycle model with the adaptive cycle model as shown in following
figure:
5.1.1 Process
Speculate:
ASD recognizes the fact that there is no point in experimenting endlessly in search
of success. So the first phase of ASD is named “speculate” rather than planning
which is not suitable for unpredictable world. Speculation means developing the
good idea of where the project is heading, and put mechanisms in place to adapt to
changing customer needs, changing technology and a changing market.
Collaborate:
Collaboration replaces build because of ASD’s recognition that people are essential
while making a successful product. The customer collaborates in all activities of the
software creation to get what he needs from the system. Collaboration is the activity
of balancing: managing a project, such as configuration control and change
management, with creativity the act of trusting people to find creative answers in an
unpredictable environment.
Learn:
Learning replaces revise because revise is backward looking. In the evolutionary life
cycle revise means that while change is necessary it should be based on original
plan i.e. change cannot question original plan, it has to be in conformance with
original plan. Learning is the act of gaining knowledge through experience. Learning
is often discouraged in predictable environments; we may lay out things in advance
and then follow then in design. In learning we can question all previous assumptions,
using the results to decide in which direction to move.
The ASD largely originates from organisational and management culture and,
especially, the importance of collaborating teams and teamwork. The approach does
not, however, describe team structures in detail. Likewise, very few roles or
responsibilities are listed. An "executive sponsor" is named as the person with
overall responsibility for the product being developed.
5.1.3 Practices
ASD provides very few practices for day-to-day software development work.
Basically, (Highsmith 2002) expressly names three: iterative development, feature-
based (component based) planning and customer focus group reviews.
Extreme Programming (XP) is a high profile agile process known to many advocates
and novices alike and is likely the most widely used. Extreme Programming (XP)
originators aimed at developing a methodology suitable for “object-oriented projects
using teams of a dozen or fewer programmers in one location.”
5.2.1 Process
Exploration Phase:
The customers write out the story cards that they wish to be included in the first
release. Each story card describes a feature to be added into the program. At the
same time the project team familiarize themselves with the tools, technology and
practices they will be using in the project.
Planning Phase:
The planning phase sets the priority order for the stories and an agreement of the
contents of the first small release is made. The programmers first estimate how
much effort each story requires and the schedule is then agreed upon.
This phase includes several iterations of the systems before the first release. The
schedule set in the planning stage is broken down to a number of iterations. The first
iteration creates a system with the architecture of the whole system. The customer
decides the stories to be selected for each iteration. The functional tests created by
the customer are run at the end of every iteration. At the end of last iteration the
system is ready for production.
Productionizing Phase:
This phase requires extra testing and checking of the performance of the system
before the system can be released to the customer. At this phase, new changes may
still be found and the decision has to be made if they are included in the current
release.
Maintenance Phase:
After the first release of the product, the project must both keep the system in the
production running while also producing new iterations. In order to do this, the
Maintenance phase requires an effort for the customer support tasks. This phase
may require incorporating new people into the team and changing the team
structure.
Death Phase:
The Death phase is near when the customer does no longer have any stories to be
implemented. This requires that the system satisfies customer needs also in other
aspects (e.g., concerning performance and reliability). This is the time when the
necessary documentation of the system is finally written. Death may also occur if the
system is not delivering the desired outcomes, or if it becomes too expensive for the
further development.
There are different roles in XP for different tasks and purposes during the process
and its practices. These are as following:
Manager – The manager owns the team and its problems. He or she forms
the team, obtain resources, and manage people and problems, and interfaces
with external groups.
Coach – The coach teaches team members about the XP process as
necessary, intervenes in case of issues; monitors whether the XP process is
being followed. The coach is typically a programmer and not a manager.
Tracker – The tracker regularly collects user story and acceptance test case
progress from the developers to create the visible wall graphs. The tracker is
a programmer, not a manager or customer.
Programme – The programmer writes tests, design, and code; refactors;
identifies and estimates tasks and stories (this person may also be a tester) o
Tester, helps customers write and develop tests (this person may also be a
programmer).
Customer – The customer writes stories and acceptance tests; picks stories
for a release and for iteration. A common misconception is that the role of the
5.2.3 Practices
Slack – in every iteration, plan some lower-priority tasks that can be dropped
if the team gets behind such that the customer will still be delivered their most
important functionality.
Ten-minute build – structure the project and its associated tests such that the
whole system can be built and all the tests can be run in ten minutes so that
the system will be built and the tests will be run often.
Test-first programming – all stories have at least one acceptance test,
preferably automated. When the acceptance test(s) for a user story all pass,
the story is considered to be fulfilled. Additionally, automated unit tests are
incrementally written using the test-driven development (TDD) practice in
which code and automated unit tests are alternately and incrementally written
on a minute-by-minute basis.
Continuous integration – programmers check in to the code base completed
code and its associated tests several times a day. Code may only be checked
in if all its associated unit tests and all of unit tests of the entire code base
pass.
Incremental design – rather than develop an anticipatory detailed design prior
to implementation, invest in the design of the system every day in light of the
experience of the past. The viability and prudence of anticipatory design has
changed dramatically in our volatile business environment. Refactoring to
improve the design of previously-written code is essential. Teams with robust
unit tests can safely experiment with refactorings because a safety net is in
place.
Spike
Metaphor
First Iteration
Small Releases
Refactoring
Team Practices
Spike
During the release planning game, the team has the opportunity to do spikes: quick
throw away (and thrown away) exploration into the nature of the solution.
We decide the system approach based on the stories and spikes. For example is the
story is about managing orders on the Internet then the solution we might think of
contains an application server, a web server, a database and a pair of firewalls. The
spikes one does in the early phase guides us to the Deployment phase. Because
spikes begin early on one can be prepared with the installation of hardware and
software needed, so that project doesn’t get halted because of inadequate
resources.
Metaphor
First iteration
The first iteration is the key in making the system come together. From Extreme
Programming explained (Kent Beck)
“The first iteration puts the system in place. Pick stories for the first iteration that will
force one to create “the whole system” even if it is in skeletal form. “
Small releases
XP’s small releases help jell the architecture quickly. As we are installing a few
months work, we are forced to get the essential structure together. We deliver the
stories most important to the user first. So we get immediate feedback from the user
which will help us correct the weak areas in the architecture.
Refactoring
Team Practices
Though not one of the “official” XP practices, essentially all XP teams also have
short Stand-Up Meetings daily. In these meetings, the team stands in a circle
(standing is intentional to motivate the team to keep the meeting short). In turn,
each member of the team tells the group:
Often the pair-programming pairs are dynamically formed during the daily meeting
as the tasks for the day are discussed and the two programmers that are best
equipped to handle the task join together.
5.3 Scrum
In the Scrum process puts a project management “wrapper” around a software
development methodology. The methodology is flexible on how much/how little
ceremony but the Scrum philosophy would guide a team towards as little ceremony
as possible. Usually a Scrum teams works co-located. However, there have been
Scrum teams that work geographically distributed whereby team members
participate in daily meeting via speakerphone. Scrum teams are self-directed and
self-organizing teams. The team commits to a defined goal for an iteration and is
given the authority, autonomy, and responsibility to decide how best to meet it.
With Scrum, projects progress via a series of iterations called sprints. Each sprint is
typically 2-4 weeks long. Scrum is ideally suited for projects with rapidly changing or
highly emergent requirements.
5.3.1 Documents
Product backlog
The product backlog is a high-level document for the entire project. It contains broad
descriptions of all required features, wish-list items, etc. It is the "What" that will be
built. It is open and editable by anyone. It contains rough estimates, usually in days.
This estimate helps the Product Owner to gauge the timeline and, to a limited extent,
priority (e.g. if "add spell-check" feature is estimated at 3 days vs. 3 months, that
may affect the Product Owner's desire).
Sprint backlog
The sprint backlog is a greatly detailed document containing information about how
the team is going to implement the requirements for the upcoming sprint. Tasks are
broken down into hours with no task being more than 16 hours. If a task is greater
than 16 hours, it should be broken down further. For each task in the backlog, the
spreadsheet contains a short task description, who originated the task, who owns
the task, the status and the number of hours remaining to complete the task. The
Sprint Backlog is updated each day by a daily tracker who visits the team members
to obtain the latest estimates of the work remaining to complete the task. Estimates
can increase when the team member realizes that the work was underestimated.
Tasks on the sprint backlog are never assigned; rather tasks are signed-up for by
the team members as they like.
The Burn down chart is a publicly displayed chart showing the number of tasks
remaining for the current sprint or the number of items on the product backlog. The
hours remaining to complete Sprint tasks are graphed and predominantly displayed
for the team. It should not be confused with an earned value chart. A burn down
chart could be flat for most of the period covered by a sprint and yet the project
could still be on schedule.
Several roles are defined in Scrum; these are divided into two groups; pigs and
chickens, based on a joke about a pig and a chicken.
The pigs are committed to building software regularly and frequently, while everyone
else are chickens that are interested in the project but are really irrelevant because if
it fails they're not a pig, that is they weren't the ones that committed to doing it. The
needs, desires, ideas and influences of the chicken roles are taken into account, but
not in any way letting it affect or distort or get in the way of the actual Scrum project.
"Pig" Roles
Pigs are the ones committed to the project and the Scrum process; they are the
ones with "their bacon on the line."
Product Owner
The Product Owner represents the voice of the customer. They ensure that
the Scrum Team works with the right things from a business perspective. The
Product Owner writes User Stories, prioritizes them, then places them in the
Product Backlog.
Team
The team has the responsibility to deliver the product. A small team of 5-9
people with cross-functional skills to do the actual work (designer, developer
etc.).
"Chicken" Roles
Chicken roles are not part of the actual Scrum process, but must be taken into
account. An important aspect of agile approach is the practice of involving users,
business and stakeholders into part of the process. It is important for these people to
be engaged and provide feedback into the outputs for review and planning of each
sprint.
Users
The software is being built for someone! Never forget that software that is not
used is like a tree falling in the forest - was it ever written?
The people that will enable the project, but are not directly involved in the
process.
Managers
People that will set up the environment for the product development
organization.
5.3.3 Process
The Sprint Planning Meeting is attended by the Product Owner, Scrum Master, the
entire Scrum Team, and any interested and appropriate management or customer
representatives.
During the sprint planning meeting the product owner describes the highest priority
features to the team. The team asks enough questions during this meeting so that
they can go off after the meeting and determine which tasks they will move from the
product backlog to the sprint backlog.
The product owner doesn't have to describe every item being tracked on the product
backlog. Depending on the size of the backlog and the speed of the team it may be
sufficient to describe only the high priority items, saving the discussion of lower
priority items for the next sprint planning meeting. Typically, the Scrum team will
provide guidance when they start to get further into the backlog list than they know
could be done in the next sprint.
Collectively, the Scrum team and the product owner define a sprint goal, which is a
short description of what the sprint will attempt to achieve. The success of the sprint
will later be assessed during the Sprint Review Meeting against the sprint goal,
rather than against each specific item selected from the product backlog.
After the sprint planning meeting, the Scrum team meets separately to discuss what
they heard and decide how much they can commit to during the coming sprint. In
some cases there will be negotiation with the product owner but it will always be up
to the team to determine how much they can commit to completing.
On each day of a sprint, the team holds daily meetings (“the daily scrum”). Meetings
are typically held in the same location and at the same time each day. Ideally the
daily scrums are held in the morning as they help set the context for the coming
day's work.
Scrum affords special status to those who are committed and many teams enforce a
rule in which only those who are committed are allowed to talk during the daily
scrum.
All team members are required to attend the daily scrum. Anyone else (for example,
a departmental VP, a salesperson, or a developer from another project) is allowed to
attend but is there only to listen. This makes the daily scrums an excellent way for a
Scrum team to disseminate status information--if you're interested in hearing where
things are at, attend that day's meeting.
The daily scrum is not used as a problem-solving or issue resolution meeting. Issues
that are raised are taken offline and usually dealt with by the relevant sub-group
immediately after the daily scrum. During the daily scrum each team member
provides answers to the following three questions:
By focusing on what each person accomplished yesterday and will accomplish today
the team gains an excellent understanding of what work has been done and what
work remains. The daily scrum is not a status update meeting in which a boss is
collecting information about who is behind schedule. Rather, it is a meeting in which
team members make commitments to each other. If a programmer stands up and
says "Today I will finish the data storage module" everyone knows that in tomorrow's
meeting he will say whether or not he did finish. This has the wonderful effect of
helping a team realize the significance of these commitments and that their
commitments are to each other, not to some far-off customer or salesman.
Any impediments that are raised become the Scrum Master's responsibility to
resolve as quickly as possible. In cases where the Scrum Master cannot remove
these impediments directly himself (e.g., usually the more technical issues) he still
takes responsibility for making sure someone on the team does quickly resolve the
issue.
At the end of each sprint a sprint review meeting is held. During this meeting the
Scrum team shows what they accomplished during the sprint. Typically this takes
the form of a demo of the new features.
The sprint review meeting is intentionally kept very informal, typically with rules
forbidding the use of PowerPoint slides and allowing no more than two hours of
preparation time for the meeting. A sprint review meeting should not become a
distraction or significant detour for the team; rather, it should be a natural result of
the sprint.
Participants in the sprint review typically include the Product Owner, the Scrum
team, the Scrum Master, management, customers, and engineers from other
projects.
During the sprint review the project is assessed against the sprint goal determined
during the Sprint planning meeting. Ideally the team has completed each product
backlog item brought into the sprint, but it is more important that they achieve the
overall goal of the sprint.
5.3.4 Practices
Customers become a part of the development team. (i.e., the customer must
be genuinely interested in the output.)
Like all other forms of agile software processes, Scrum has frequent
intermediate deliveries with working functionality. This enables the customer
to get working software earlier and enables the project to change its
requirements according to changing needs.
Frequent risk and mitigation plans developed by the development team itself.
– Risk Mitigation, Monitoring and Management (risk analysis) at every stage
and with genuinity.
Transparency in planning and module development – Let everyone know who
is accountable for what and by when.
Frequent stakeholder meetings to monitor progress – Balanced (Delivery,
Customer, Employee, and Process) Dashboard updates – Stakeholders'
update – You have to have Advance Warning Mechanism, i.e. visibility to
potential slippage / deviation ahead of time.
No problems are swept under the carpet. No one is penalized for recognizing
or describing any unforeseen problem.
Workplaces and working hours must be energized. – "Working more hours" does not
necessarily mean "producing more output."
5.4 Crystal
Comfort
Discretionary money
Essential money
Life A system failure for the first
As such, the different methods are assigned colors arranged in ascending opacity;
the most agile version is Crystal Clear, followed by Crystal Yellow, Crystal Orange,
and Crystal Red.
Crystal Clear is designed for very small projects comprising up to six developers.
Crystal Clear should be located in a shared office space due to the limitation in its
communication structure. The property of close communication is strengthened to
“osmotic” communication meaning that people overhear each other discussing
project priorities, status, requirements, and design on a daily basis.
Crystal Orange is designed for medium sized projects, with a total of 10 to 40 project
members, and with a project duration of one to two years .In Crystal Orange the
project is split up for several teams with cross-functional groups . It emphasizes the
importance of the time to market issue.
5.4.3 Practices
Monitoring
The progress is monitored regarding the team deliverables during the development
process with respect to their progress and stability .Monitoring is required in both
Crystal Clear and Crystal Orange.
Once the monitoring of stability gives the positive result for the deliverables the next
task can start. In Crystal Orange this means that the multiple teams can proceed
with maximum parallelism successfully.
Crystal Orange includes this method for splitting large functional teams into cross-
functional groups. The central idea of this is to include multiple specialities in one
team
User viewings
Two user viewings are suggested for Crystal Clear per one release. In Crystal
Orange, user reviews must be organized three times for each increment.
It is one of the basic tuning techniques for Crystal Clear and Orange. It uses project
interviews and team work shops for working out a specific Crystal methodology for
each individual project.
Staging
Staging includes the planning of the next increment of the system. It should be
scheduled to produce a working release in every 3 to 4 months at the maximum. The
team selects the requirements to be implemented in the increment and schedules
what they feel they are able to deliver.
Each increment includes several iterations. Each iteration includes the following
activities: construction, demonstration and review of the objectives of the increment.
While each of the Crystal processes share the standards the rigor involved is
dependent on the project and the chosen process. For example, less critical projects
suggest two-month incremental delivery time spans whereas critical projects,
demanding a rigorous process, may extend time-to-delivery increments to a
maximum of four months. Projects are comprised of multiple increments. Crystal
processes define the functions contained in an increment.
6. Summary
Agile process tell that the organisation that implement these in software
development processes and the softwares that are built using these methods are
acceptable to change as per user requirements . A method is agile if it is one which
supports and accepts the change without any hesitation or reluctance.
Large organizations prefer heavyweight methods over agile processes as they have
the contracts with fixed price and an strong tendency for following software
engineering concepts. They have a big investment in big design up front methods.
Life critical systems project have the severity to use BDUF processes, which also
increases their cost and time to produce. But now a days these organizations
learning to use agile methods for their existence in the industry and to compete with
other organisations.
One of the biggest challenges undercoming is that how they handle larger projects
and systems. Extreme programming clearly says that it has creates teams for
software development process having around 20 people. The message is one
should implement agile when the user requirements are not constant and one can
not have a fixed design and cannot follow a planned process.
Incremental
Cooperative
Straight forward
Adaptive to changeable requirements
“Agile methods are more people centric except than plan-centric.” Agile methods are
not defined by a small set of principles, practices and techniques. It creates a
strategy which has capability of responding to change, capability of innovation and
creations through development team and uncertainty, capability to balance the
project structure and flexibility.
We also have discussed about some different Agile Software development methods
as following:
7. References
Manifesto for Agile software development; http://agilealliance.com
New methodology; Fowler; Martin;
http://www.martinfowler.com/articles/newMethodology.html
Highsmith Jim (2002) Agile Software Development ecosystems. Boston, MA
Pearson Education
Extreme Programming Explored; Wake, William; Addison Wesley ISBN 0-
201-73397-8; July 2001; Chapter 5
www.extremeprogramming.org; Last modified January 26, 2003;
The Agile Manifesto is online at http://www.agilemanifesto.org/
Agile Software Development
https://en.wikipedia.org/wiki/Agile_software_development