Unit 3 Agile-Development

Download as pdf or txt
Download as pdf or txt
You are on page 1of 32

Agile Development

 Fundamentals Characteristics of Rapid


Software Development.
◦ The process of specification, design, and
documentation are interleaved.
◦ Software is developed in a series of versions.
All the stakeholders are involved in specifying
and evaluating each version.
◦ User interfaces are developed using an
interactive development system that allows
the interface design to be quickly created by
drawing and placing icons on the interface.
Agile Methods
 Agile methods are incremental development
methods in which the increments are small and,
typically, new releases of the system are
created and made available to customers every
two or three weeks.
 Customers are involved to get rapid feedback in
changing requirements.
 They minimize to write documentation rather
than conducting formal meeting with written
documents.
 Agile methods universally rely on an incremental
approach to software specification, development,
and delivery.
Agile Methods
 They are best suited to application development
where the system requirements usually change
rapidly during the development process.
 The philosophy behind agile methods is reflected
in the agile manifesto that was agreed on by
many of the leading developers of these methods.
 Agile methods are all based around the notion
of incremental development and delivery, they
propose different processes to achieve this.
Principles of Agile Software Development
 Customer Involvement
 Incremental Delivery
 People not Process
 Embrace Change
 Maintain Simplicity
Agile Methods Continue
 The software requirements document is usually
part of the contract between the customer and
the supplier.
 Agile methods have to rely on contracts in which
the customer pays for the time required for
system development rather than the
development of a specific set of requirements.
 If problems arise then there may be difficult
disputes over who is to blame and who should
pay for the extra time and resources required to
resolve the problems.
Agile Methods Continue
 There are two questions that should be
considered when considering agile methods
and maintenance:
◦ Are systems that are developed using an agile
approach maintainable, given the emphasis in
the development process of minimizing formal
documentation?
◦ Can agile methods be used effectively for
evolving a system in response to customer
change requests?
Agile Methods Continue
 In practice formal documentation is often not
kept up to date, for this reason agile methods
argue that it is a waste of time.
 To write documentation and that the key to
implementing maintainable software is to
produce high-quality, readable code.
 Agile emphasize the importance of writing well-
structured code and investing effort in code
improvement.
 System maintenance suggests that the key
document is the system requirements
document, which tells what the system is
supposed to do.
Benefits of agile Methodology
 Superior Quality Product
 Customer Satisfaction
 Better Control
 Improved Project Predictability
 Reduced Risk
 Increased Flexibility
 Continuous Improvement
 Improved Team Morale
 Morale relevant Matrix
Plan Driven and Agile Methodology
 Agile approaches to software development
consider design and implementation to be the
central activities in the software process.
 Plan-driven approach identifies separate stages
in the software process with outputs associated
with each stage.
 Iteration occurs within activities with formal
documents used to communicate between
stages of the process.
 In agile methods, the requirements and the
design are developed together, rather than
separately due to iteration process.
Plan Driven and Agile Methodology
Question that may occur to solve problem
between Plan Driven Process and Agile
 Is it important detailed specification and design
before moving to implementation? use a plan-
driven approach.
 Is an incremental delivery strategy, if customers
provide rapid feedback from, and realistic? If so,
consider using agile methods.
 How large is the system that is being developed
?small system can communicate informally but
in large system this may not be possible that
require larger development teams so a plan-
driven approach may have to be used.
Question that may occur to solve problem
between Plan Driven Process and Agile
 What type of system is being developed?
Systems that require a lot of analysis before
implementation e.g., real-time system need a
fairly detailed analysis. So, a plan driven
approach may be best in those circumstances.
 What is the expected system lifetime? Long-
lifetime systems may require more design and
documentation. But in agile, documentation is
frequently not kept up to date.
 What technologies are available to support
system development? If system use IDE that
does not have proper tools for program
visualization and analysis, then more design
documentation may be required.
Question that may occur to solve problem
between Plan Driven Process and Agile
 How is the development team organized? if part
of the development is being outsourced, then
develop design documents to communicate
across the development teams with plan.
 Are there cultural issues that may affect the
system development? Traditional engineering
need plan-based development requires
extensive design documentation, rather than the
informal knowledge used in agile processes.
 How good are the designers and programmers
in the development team?
 Is the system subject to external regulation?
Extreme Programming (XP)
 XP is most widely used agile methods. The
approach developed by pushing recognized
good practice, such as iterative development,
to‘extreme’ levels. For Ex. in XP, several new
versions of a system is developed by different
programmers, integrated and tested in a day.
Extreme Programming principles
 Incremental Planning
 Requirements are recorded on Story Cards can
be included in a release are determined by the
time available and their relative priority. These
stories are break into development.
 Small Release
 The minimal useful set of functionality that
provides business value is developed first.
Releases of the system are incrementally add
functionality to the first release.
 Simple Design
 Enough design is carried out to meet the current
requirements and no more.
Extreme Programming principles
 Test First Development
 An automated unit test framework is used to
write tests for a new piece of functionality before
that functionality itself is implemented.
 Refactoring
 All developers are expected to refactor the code
as soon as possible code improvements are
found, keeps the code simple and maintainable.
 Pair programming
 Developers work in pairs, checking each other’s
work and providing the support to always do a
good job.
Features of Testing in XP
 Test-first development.
 In this features, Instead of writing some code
and then writing tests for that code, you write
the tests before you write the code.
 This means that you can run the test as the
code is being written and discover problems
during development.
 Incremental test from scenarios.
 User requirements in XP are expressed as
scenarios or stories and the user prioritizes
these for development.
 The development team assesses each scenario
and breaks it down into tasks.
Features of Testing in XP
 User Involvement in the test Development and
Validation.
◦ Large number of customers are involve for the
testing purpose.
◦ System is checked based on already set
requirements.
 The use of automated testing frameworks.
◦ Linear tools framework
◦ Modular tools framework
◦ Data Driven Framework
◦ Hybrid Testing Framework
Pair Programming
 Innovative practice, Introduced in XP is
that programmers work in pairs to develop
the software.
 A pair of programmers are sit together at
the same workstation to develop the
software.
 However, the same pairs do not always
program together.
 Pairs are created dynamically so that all
team members work with each other
during the development process.
Advantages of Pair Programming
 It supports the idea of collective ownership and
responsibility for the system. The team has
common responsibility for resolving problems.
 Pair programming is a less formal process that
probably doesn’t find as many errors as code
inspections, it is a much cheaper inspection
process than formal program inspections.
 It helps support refactoring, which is a process
of software improvement. Where pair
programming and collective ownership are
used.
Summarize Advantages of Pair Programming
 Fewer Coding Mistakes
 Knowledge is spread among the pairs.
 Reduced effort to Co-ordinate.
 Increase Resiliency

Challenges of Pair Programming


 Efficiency
 Equally Engaging pairs
 Social and Interactive Process
 Sustainability
Agile Project Management
 software project managers is to manage the
project so that the software is delivered on time
and within the planned budget for the project.
 A plan-based approach requires a manager to
have a stable view of everything that has to be
developed and the development processes.
 Agile development has to be managed so that
the best use is made of the time and resources
available to the team.
 This requires a different approach to project
management, which is adapted to incremental
development and the particular strengths of
agile methods.
The Scrum approach
 It is a general agile method but it focus on
managing iterative development rather than
specific technical approaches to agile software
engineering.
The Scrum Phase
 The first phase is an outline planning phase
where team establish the general objectives for
the project and design the software architecture.
 A Scrum sprint is a planning unit in which the
work to be done is assessed, features are
selected for development, and the software is
implemented.
 At the end of a sprint, the completed
functionality is delivered to stakeholders.
 Closure phase wraps up the project, completes
required documentation such as system help
frames and user manuals, and assesses the
lessons learned from the project.
Characteristics of Scrum Methodology
 Sprints are fixed length, normally 2–4 weeks.
They correspond to the development of a
release of the system in XP.
 Backlog, which is the list of work to be done on
the project. During the assessment phase of the
sprint, this is reviewed, and priorities and risks
are assigned.
 The customer is closely involved in this process
and can introduce new requirements or tasks at
the beginning of each sprint.
 The selection phase involves all of the project
team who work with the customer to select the
features and functionality to be developed
Characteristics of Scrum Methodology
 Them team organizes themselves to develop
the software.
 Short daily meetings involving all team
members are held to review progress and if
necessary, reprioritize work.
 Team is isolated from the customer and the
organization, with communications channelled
through the so-called ‘Scrum master’.
 The role of the Scrum master is to protect the
development team from external distractions.
 The way in which the work is done depends on
the problem and the team. Unlike XP, Scrum
does not make specific suggestions on how to
write requirements, test-first development, etc.
Advantages of Scrum Methodology
 The product is broken down into a set of
manageable and understandable chunks.
 Unstable requirements do not hold up progress.
 The whole team has visibility of everything and
consequently team communication is improved.
 Customers see on-time delivery of increments
and gain feedback on how the product works.
 Trust between customers and developers is
established and a positive culture is created in
which everyone expects the project to succeed.
Scaling Agile Methods
 Large systems are usually collections of
separate, communicating systems, where
separate teams develop each system.
Frequently, these teams are working in different
places, sometimes in different time zones.
 Large systems are ‘brownfield systems’ that is
they include and interact with a number of
existing systems.
 Several systems are integrated to create a
system, a significant fraction of the development
is concerned with system configuration rather
than original code development.
Scaling Agile Methods
 Large systems and their development
processes are often constrained by external
rules and regulations limiting the way.
 Large systems have a long procurement and
development time.
 Large systems usually have a diverse set of
stakeholders.
Two perspective on scaling agile methods
 A ‘scaling up’ perspective, which is concerned
with using these methods for developing large
software systems that cannot be developed by a
small team.
 A ‘scaling out’ perspective, which is concerned
with how agile methods can be introduced
across a large organization with many years of
software development experience.
Agile methods and Large System Engineering
 For large systems development, it is not possible
to focus only on the code of the system. You need
to do more up-front design and system
documentation.
 Cross-team communication mechanisms have
to be designed and used. This should involve
regular phone and video conferences between
team members.
 Continuous integration, where the whole system
is built every time any developer checks in a
change, is practically impossible when several
separate programs have to be integrated to
create the system.
Why not to use Agile methods for large
companies.
 Project managers who do not have experience of
agile methods may be reluctant to accept the risk
of a new approach.
 Large companies often have quality procedures
and standards that all projects are expected to
follow, because of their bureaucratic nature, these
are likely to be incompatible with agile methods.
 Within large organizations, there are likely to be a
wide range of skills and abilities, and people with
lower skill levels may not be effective team
members in agile processes.
 There may be cultural resistance to agile method,
in that companies that have a long history of using
conventional systems engineering processes.

You might also like