Agile Unit I

Agile Methodology
Examination Scheme : 80 M Theory

20 M Class Test
50 M Term Work
 Ref Book :
1. Agile Software Development with Scrum by Ken Schawber,
Mike Beedle Publisher: Pearson Published: 21 Mar 2008.
2. Agile Testing: A Practical Guide for Testers and Agile Teams
by Lisa Crispin, Janet Gregory Publisher: Addison Wesley
Published: 30 Dec 2008.
3. Agile Software Development, Principles, Patterns and
Practices by Robert C. Martin Publisher: Prentice Hall
Published: 25 Oct 2002.
5/17/2019 1
Unit 1-Fundamentals of Agile: (6 hours)
• The Genesis of Agile
• Introduction and background
• Agile Manifesto and Principles
• Overview of Scrum, Extreme Programming
• Feature Driven development, Lean Software
Development, Agile project management
• Design and development practices in Agile
projects, Test Driven Development, Continuous
Integration, Refactoring, Pair Programming
• Simple Design, User Stories, Agile Testing, Agile
Tools
5/17/2019 2
Introduction
• Agile : Latin word
• Adjective
1. Able to move quickly and easily
2. Able to think and understand quickly
5/17/2019 3
Software development processes
Software Engineering
• Software Engineering is the application of
systematic, disciplined, quantifiable approach
to the development, operation and
maintenance of software ; i.e. the application
of engineering to software
5/17/2019 5
What is Quality?
Software Quality is conformance to:
• explicitly stated functional and performance
requirements,
• explicitly documented development
standards,
• implicit characteristics that are expected of all
professionally developed software.
© Oscar Nierstrasz ESE — Software Quality ESE 11.6

Problems with Software Quality
• Software specifications are usually incomplete and often inconsistent
• There is tension between:

– customer quality requirements (efficiency, reliability, etc.)
– developer quality requirements (maintainability, reusability, etc.)
• Some quality requirements are hard to specify in an unambiguous way

– directly measurable qualities (e.g., errors/KLOC),
– indirectly measurable qualities (e.g., usability).
Quality management is not just about reducing defects!

Hierarchical Quality Model
Define quality via hierarchical quality model, i.e. a number of quality
attributes (a.k.a. quality factors, quality aspects, ...)
Choose quality attributes (and weights) depending on the project context
... Quality attribute
Reliability may be further

refined into
Software Efficiency subattributes
Quality
Usability
Maintainability
Portability

Quality Attributes
Quality attributes apply both to the product and
the process.
• product: delivered to the customer

• process: produces the software product
• resources: (both the product and the process
require resources)
– Underlying assumption: a quality process leads to
a quality product (cf. metaphor of manufacturing
lines)

Quality Attributes ...
Quality attributes can be external or internal.
• External: Derived from the relationship between the environment and the
system (or the process). (To derive, the system or process must run)
– e.g. Reliability, Robustness
• Internal: Derived immediately from the product or process description (To

derive, it is sufficient to have the description)
– Underlying assumption: internal quality leads to external quality (cfr.
metaphor manufacturing lines)
– e.g. Efficiency

Correctness, Reliability, Robustness
Correctness
• A system is correct if it behaves according to its specification
– An absolute property (i.e., a system cannot be “almost correct”)
– ... in theory and practice undecidable
Reliability
• The user may rely on the system behaving properly
• Reliability is the probability that the system will operate as expected over a
specified interval
– A relative property (a system has a mean time between failure of 3 weeks)
Robustness
• A system is robust if it behaves reasonably even in circumstances that were not
specified
• A vague property (once you specify the abnormal circumstances they become part
of the requirements)

Efficiency, Usability
Efficiency (Performance)
• Use of resources such as computing time, memory
– Affects user-friendliness and scalability
– Hardware technology changes fast!
– First do it, then do it right, then do it fast
• For process, resources are manpower, time and money

– relates to the “productivity” of a process

Quality perspective
Customer View User View Developer View
Low cost Functionality Good

Increased Ease of learning documentation
productivity Ease of use Minimum errors
Flexibility Ease of Readable code
Reliability remembering Good design
Efficiency Reliability Reliability
Efficiency
5/17/2019 13
Waterfall Development
REQUIREMENTS
DESIGN
DEVELOPMENT
Waterfall Development is
another name for the more
TESTING
traditional approach
to software development MAINTENANCE
phase
User Requirements output User Requirements Document
Software Requirements Software Requirements

Document
Architecture Design Architectural Design

Document
”Swimming
Detailed design & Coding Detailed
upstream”
Design
& Code
Testing
The Waterfall
Lifecycle Workflow
Delivery
Time
Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost
or schedule
Waterfall Development (contd..)
You complete one phase (e.g. design) before moving
on to the next phase (e.g. development)
You rarely aim tore-visit a ‘phase’ once it’s

completed. That means, you better get whatever
you’re doing right the first time!
But…
Changes
REQUIREMENTS
DESIGN
DEVELOPMENT
You don’t realize any value until
Skipped
the end of the project Takes too long
You leave the testing until the end TESTING
You don’t seek approval from the
stakeholders until late in the day
MAINTENANCE
This approach is highly risky, often more costly and

generally less efficient than Agile approaches
V-Shaped SDLC Model
• A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
• Testing of the product is
planned in parallel with a
corresponding phase of
development
V-Shaped Steps
• Project and Requirements Planning – • Production, operation and
allocate resources maintenance – provide for
enhancement and corrections
• Product Requirements and • System and acceptance testing –
Specification Analysis – complete check the entire software system in
specification of the software system its environment
• Architecture or High-Level Design –

defines how software functions fulfill • Integration and Testing – check that
the design modules interconnect correctly
• Detailed Design – develop algorithms • Unit testing – check that each

for each architectural component module acts as expected
• Coding – transform algorithms into

software
V-Shaped Strengths
• Emphasize planning for verification and
validation of the product in early stages of
product development
• Each deliverable must be testable
• Project management can track progress by
milestones
• Easy to use
V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in
requirements
• Does not contain risk analysis activities
Current State of Affairs in IT Industry
– Customers are disappointed by slipping schedules,
growing budgets, and poor quality.
– Developers are disheartened by working ever longer

hours to produce ever poorer software.
– Development documentation (design) is always out

of date and causes more confusion than help
– Market moves ahead leaving the resultant product

outdated.
Some Figures…
An average team of 6-10 members produces
fewer than 10 lines of code per day over the
average lifetime of the project.
Sixty errors found per every thousand lines of
code.
One of every three projects scrapped before
ever being completed
Only 1 in 8 finished software projects
considered "successful”.
Key Aspects of a Software Project
History
• Software Crisis (1960’s)
– Software intensive systems delivered late, over budget
and do not meet the quality requirements
•Solution attempt #1: Structured Methods (in

1980’s)
– SSADM – Waterfall method
History
• Chronic Software Crisis (1990’s)
– Software intensive systems still delivered late, over
budget and do not meet the quality requirements
• Solution attempt #2: Software process improvement (in 1990’s)

• SPICE by ISO - framework for the assessment of software processes
• Software Process Improvement and Capability determination
• Solution attempt #3: Agile development

methodologies (2001 onwards)
Aspect Civil Engineering Software Engineering
Design vs. Construction - 20 (design) 60 (design)

% of Time/Effort Spent - 80 (construction) - 40 (construction/
development
Kind of people Different. Often same.
involved in design vs. Designers need much Quite similar skills.
construction higher skills.
Frequency of Rarely Almost always!

Requirement Change
during Construction
Impact of change in Low Very High!

construction people
during the project
Confidence level in High Low
Estimating changing
requirements
Rapid Adaptable
AGILE
Cooperative Iterative
Quality-driven
Not a process, it's a philosophy or set of values

Agile Software Development
• Agile software development is a group of software
development methods based on iterative and incremental
development, where requirements and solutions evolve
through collaboration between self-organizing, cross-functional
teams.
• It promotes adaptive planning, evolutionary development and

delivery, a time-boxed iterative approach, and encourages
rapid and flexible response to change.
• It is a conceptual framework that promotes foreseen

interactions throughout the development cycle.
• The Agile Manifesto[ introduced the term in 2001.

Software Development Method
• A software development methodology or
system development methodology in software
engineering is a framework that is used to
structure, plan, and control the process of
developing an information system.
Software Engineering / Software Development
• Software Engineering (SE) is the application of

a systematic, disciplined, quantifiable
approach to the design, development,
operation, and maintenance of software, and
the study of these approaches; that is, the
application of engineering to software.
Information System
• An information system (IS) - is any combination of
information technology (IT) and people's activities that
support operations, management and decision making.
• In a very broad sense, the term information system is

frequently used to refer to the interaction between
people, processes, data and technology.
• In this sense, the term is used to refer

– not only to the information and communication
technology (ICT) that an organization uses,
– but also to the way in which people interact with this
technology in support of business processes
Iterative and Incremental Development
•Iterative and Incremental development is at the heart of
a cyclic software development process developed in
response to the weaknesses of the waterfall model.
It starts with an initial planning and ends with
deployment with the cyclic interactions in between.
•Iterative and incremental development are essential

parts of the Rational Unified Process, Extreme
Programming and generally the various agile software
development frameworks.
Time-Boxed Approach
• In time management, a time box allots a
fixed period of time for an activity.
• Timeboxing plans activity by allocating time

boxes.
Introductory Thoughts
• Fears regarding software development led to a
number of pioneers / industry experts to
develop the Agile Manifesto based up some
firm values and principles.
• Practitioners had become afraid that repeated

software failures could not be stopped
without some kind of guiding process to guide
development activities.
Common Fears
• Practitioners were afraid that
– The project will produce the wrong product
– The project will produce a product of inferior
quality
– The project will be late
– We’ll have to work 80 hour weeks
– We’ll have to break commitments
– We won’t be having fun.
History of Agile Methods
• Particularly in 1990s, some developers reacted against
traditional “heavyweight” software development processes.
• New methods were being developed and tested,
– e.g. extreme programming, SCRUM, Feature-driven development
– Generally termed “light” processes
• “Representatives” from several of these methods got together
in Utah in 2001
– Settled on term “Agile” as a way to describe these methods
– Called themselves the “Agile Alliance”
– Developed a “manifesto” and a statement of “principles”
– Focuses on common themes in these alternative methodologies
Agile Alliance
• Several individuals, The Agile Alliance,
– motivated to constrain activities
– such that certain outputs and artifacts are
predictably produced.
– Around 2000, these notables got together to
address common development problems.
• Goal: outline values and principles to allow

software teams to
– develop quickly and
– respond to change.
Agile Alliance
• These activities arose in large part to runaway
processes.
– Failure to achieve certain goals was met with ‘more
process.’ Schedules slipped; budgets bloated, and
processes became even larger.
• The Alliance (17) created a statement of values:

termed the manifesto of the Agile Alliance.
• They then developed the 12 Principles of Agility.

Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
The Manifesto for Agile Software Development
1. Ken Schwaber – Founder of the Agile Alliance, Creator of Scrum
2. Mike Beedle
3. Arie van Bennekum
4. Alistair Cockburn – Creator of Crystal family light weight methodologies
5. Ward Cunningham
6. Martin Fowler – Chief Scientist at ThoughtWorks, specializes in OOAD, UML
7. Kent Beck - Creator of the Extreme Programming and Test Driven Development software
8. James Grenning
9. Jim Highsmith
10. Andrew Hunt
11. Ron Jeffries
12. Jon Kern
13. Brian Marick
14. Robert C. Martin – Founder and President of Object Mentor Group, Author of Agile Design
Principles
15. Steve Mellor
16. Jeff Sutherland
17. Dave Thomas
Value 1: Individuals and Interactions over
Processes and Tools
• Strong players: a must, but can fail if don’t work together.
• Strong player: not necessarily an ‘ace;’ work well with others!
– Communication and interacting is more important than raw talent.
• ‘Right’ tools are vital to smooth functioning of a team.
• Start small. Find a free tool and use until you can demo you’ve
outgrown it. Don’t assume bigger is better. Start with white
board; flat files before going to a huge database.
• Building a team more important than building environment.
– Some managers build the environment and expect the team to fall
together.
– Doesn’t work.
– Let the team build the environment on the basis of need.
Value 2: Working Software over Comprehensive
Documentation
• Code – not ideal medium for communicating rationale and
system structure.
– Team needs to produce human readable documents describing
system and design decision rationale.
• Too much documentation is worse than too little.

– Take time; more to keep in sync with code; Not kept in
sync? it is a lie and misleading.
• Short rationale and structure document.

– Keep this in sync; Only highest level structure in the
system kept.
Value 2: Working Software over Comprehensive
Documentation
• How to train newbees if short & sweet?
– Work closely with them.
– Transfer knowledge by sitting with them; make part of team via
close training and interaction
• Two essentials for transferring info to new team members:
– Code is the only unambiguous source of information.
– Team holds every-changing roadmap of systems in their heads;
cannot put on paper.
– Best way to transfer info- interact with them.
• Fatal flaw: Pursue documentation instead of software:
• Rule: Produce no document unless need is immediate and
significant.
Value 3: Customer Collaboration over
Contract Negotiation
• Not possible to describe software requirements

up front and leave someone else to develop it
within cost and on time.
• Customers cannot just cite needs and go away
• Successful projects require customer feedback

on a regular and frequent basis – and not
dependent upon a contract or SOW.
Value 3: Customer Collaboration over Contract
Negotiation
• Best contracts are NOT those specifying requirements,
schedule and cost.
– Become meaningless shortly.
• Far better are contracts that govern the way the
development team and customer will work together.
• Key is intense collaboration with customer and a
contract that governed collaboration rather than details
of scope and schedule
– Details ideally not specified in contract.
– Rather contracts could pay when a block passed customer’s
acceptance tests.
– With frequent deliverables and feedback, acceptance tests
never an issue.
Value 4: Responding to Change over
Following a Plan
• Our plans and the ability to respond to changes is critical!
• Course of a project cannot be predicted far into the future.
– Too many variables; not many good ways at estimating cost.
• Tempting to create a PERT or Ghant chart for whole project.
– This does Not give novice managers control.
– Can track individual tasks, compare to actual dates w/planned dates and
react to discrepancies.
– But the structure of the chart will degrade
– As developers gain knowledge of the system and as customer gains
knowledge about their needs, some tasks will become unnecessary;
others will be discovered and will be added to ‘the list.’
– In short, the plan will undergo changes in shape, not just dates.
Value 4: Responding to Change over
Following a Plan
• Better planning strategy – make detailed plans for the
next few weeks, very rough plans for the next few
months, and extremely crude plans beyond that.
• Need to know what we will be working on the next few
weeks; roughly for the next few months; a vague idea
what system will do after a year.
• Only invest in a detailed plan for immediate tasks; once
plan is made, difficult to change due to momentum and
commitment.
– But rest of plan remains flexible. The lower resolution parts
of the plan can be changed with relative ease.
Agile Principles (12)
• The following principles are those that
differentiate agile processes from others.
Principle 1: Our Highest Priority is to Satisfy the Customer
through Early and Continuous Delivery of Valuable Software
• Number of practices have significant impact upon quality of final system:

• 1. Strong correlation between quality and early delivery of a partially
functioning system.
– The less functional the initial delivery, the higher the quality of the final
delivery.
• 2. Another strong correlation exists between final quality and frequently
deliveries of increasing functionality.
– The more frequent the deliveries, the higher the final quality.
• Agile processes deliver early and often.

– Rudimentary system first followed by systems of increasing functionality every
few weeks.
– Customers my use these systems in production, or
– May choose to review existing functionality and report on changes to be
made.
– Regardless, they must provide meaningful feedback.
Principle 2: Welcome Changing Requirements, even late in
Development. Agile Processes harness change for the Customer’s
Competitive Advantage.
• This is a statement of attitude.

• Participants in an agile process are not afraid of change.
– Requirement changes are good;
– Mean team has learned more about what it will take to satisfy
the market.
• Agile teams work to keep the software structure

flexible, so requirement change impact is minimal.
•
• Moreso, the principles of object oriented design help us
to maintain this kind of flexibility.
Principle 3: Deliver Working Software Frequently
(From a couple of weeks to a couple of months with a
preference to the shorter time scale.
• We deliver working software.

– Deliver early and often.
– Be not content with delivering bundles of
documents, or plans.
– Don’t count those as true deliverables.
• The goal of delivering software that satisfies

the customer’s needs.
Principle 4: Business People and Developers Must Work
Together Daily throughout the Project.
• For agile projects, there must be significant

and frequent interaction between the
– customers,
– developers, and
– stakeholders.
An agile project must be continuously guided.

Principle 5: Build Projects around Motivated Individuals. (Give
them the environment and support they need, and trust them to
get the job done.)
• An agile project has people the most important factor of
success.
– All other factors, process, environment, management, etc., are
considered to be second order effects, and are subject to
change if they are having an adverse effect upon the people.
• Example: if the office environment is an obstacle to the

team, change the office environment.
• If certain process steps are obstacles to the team, change
the process steps.
Principle 6: The Most Efficient and Effective Method of
Conveying Information to and within a Development
Team is face-to-face Communications.
• In agile projects, developers talk to each other.
– The primary mode of communication is conversation.
– Documents may be created, but there is no attempt to
capture all project information in writing.
• An agile project team does not demand written
specs, written plans, or written designs.
– They may create them if they perceive an immediate and
significant need, but they are not the default.
– The default is conversation.
Principle 7: Working Software is the Primary
Measure of Progress
• Agile projects measure their progress by
measuring the amount of working software.
– Progress not measured by phase we are in, or

– by the volume of produced documentation or
– by the amount of code they have created.
• Agile teams are 30% done when 30% of the
necessary functionality is working.
Principle 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 they run at a fast, but sustainable, pace.
• Running too fast leads to burnout, shortcuts, and debacle.

• Agile teams pace themselves.
– They don’t allow themselves to get too tired.
– They don’t borrow tomorrow’s energy to get a bit more done today.
– They work at a rate that allows them to maintain the highest quality
standards for the duration of the project.
Principle 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.
– Thus, all agile team-members are committed to

producing only the highest quality code they can.
– They do not make messes and then tell themselves

they’ll clean it up when they have more time.
– Do it right the first time!
Principle 10: Simplicity – the art of maximizing
the amount of work not done – is essential.
• Agile teams take the simplest path that is
consistent with their goals.
– They don’t anticipate tomorrow’s problems and

try to defend against them today.
– Rather they do the simplest and highest quality

work today, confident that it will be easy to
change if and when tomorrows problems arise.
Principle 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.
– Responsibilities are communicated to the team as a whole,
and the team determines the best way to fulfill them.
• Agile team members work together on all project

aspects.
– Each is allowed input into the whole.
– No single team member is responsible for the architecture,
or the requirements, or the tests, etc.
– The team shares those responsibilities and each team
member has influence over them.
Principle 12: At regular Intervals, the Team reflects on how
to become more effective, then tunes and adjusts its
behavior accordingly.
• An agile team continually adjusts its organization,

rules, conventions, relationships, etc.
• An agile team knows that its environment is

continuously changing, and knows that they must
change with that environment to remain agile.
The principles of agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the development
process. Their role is provide and prioritize new system
requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the customer

specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own ways
of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in the
development process. Wherever possible, actively work to
eliminate complexity from the system.
66
Characteristics :Agile method
• Modularity
• Iterative
• Time-bound
• Incremental
• Convergent
• People-oriented
• Collaborative
Agile : Timeline Comparison
8-9 months
Waterfall
Development Models
3-4 months
Analysis
Design
Agile Construction
Testing
Working Software
to the sponsor in 4-
6 weeks
Time
Market Scenario
Agile 2012 Surveys
Major Findings
• Agile Momentum
(i) Future plans to implement Agile grew from
59% in 2011 -> 83% in 2012.
(ii) Nearly half said their organization has

5+ agile teams (48%), compared to only 33% in 2011.
• Why Agile?
The top 3 benefits obtained include:
1. Ability to manage changing priorities (90%)
2. Productivity (85%)
3. Project visibility (84%)
Major Findings
• Agile Adoption and Use

(i) 15% jump in the number of respondents who work where there
are at least 5 Agile teams, and a 9% increase in those working with
up to 5 Agile projects.
(ii) Most are using Scrum or Scrum variants (72%), as in past years.
Agile method applicability
• Product development where a software company is
developing a small or medium-sized product for sale.
• Custom system development within an organization,
where there is a clear commitment from the customer
to become involved in the development process and
where there are not a lot of external rules and
regulations that affect the software.
• Because of their focus on small, tightly-integrated
teams, there are problems in scaling agile methods to
large systems.
75
Problems with agile methods
• It can be difficult to keep the interest of customers who are
involved in the process.
• Team members may be unsuited to the intense involvement
that characterises agile methods.
• Prioritising changes can be difficult where there are multiple
stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other approaches to
iterative development.
76
Agile methods and software
maintenance
• Most organizations spend more on maintaining existing
software than they do on new software development.
So, if agile methods are to be successful, they have to
support maintenance as well as original development.
• Two key issues:
– 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?
• Problems may arise if original development team
cannot be maintained.
77
Existing Agile Methods
• Extreme Programming (“XP”)
• Agile Unified Process
• Scrum
SCRUM
• Idea first appeared in a business journal in 1986
(applied to product development management).
• Used in software development and presented in
1995 paper.
• Term is based on rugby term
• Small cross-functional teams
Scrum
• There are three phases in Scrum.
– The initial phase is an outline planning phase where
you establish the general objectives for the project
and design the software architecture.
– This is followed by a series of sprint cycles, where
each cycle develops an increment of the system.
– The project 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.
•
80
SCRUM Practices
• Product and release backlog
– A list of the features to be implemented in the
project (subdivided to next release), ordered by
priority
– Can adjust over time as needed, based on
feedback
– A product manager is responsible for maintaining
SCRUM Practices
• Burn-down chart
– Make best estimate of time to complete what is
currently in the backlog
– Plot the time on a chart
– By studying chart, understand how team functions
– Ensure burn-down to 0 at completion date
• By adjusting what’s in the backlog
• By adjusting the completion date
SCRUM Practices
• The sprint
– The sprint is a ~1 month period after which some product is
delivered
– Features are assigned from the product backlog to a sprint
backlog
• Features divided into smaller tasks for sprint backlog
• Feature list is fixed for sprint
– Planning meeting
• Tasks can be assigned to team members
• Team members have individual estimates of time taken per item
– During sprint, work through features, and keep a burn-down
chart for the sprint
– New functionality is produced by the end of the sprint
– After sprint, a review meeting is held to evaluate the sprint
SCRUM Practices
• Scrum meeting
– 15 minute daily meeting
– All team members show up
– Quickly mention what they did since last Scrum, any obstacles
encountered, and what they will do next
– Some team member volunteers or is appointed to be the
Scrum Master - in charge of Scrum meeting, and responsible
for seeing that issues raised get addressed
– Customers, management encouraged to observe
SCRUM Practices
24 hours
Scrum
Sprint Sprint Meeting
Backlog Plan
Release
Backlog Begin
30 days End
Sprint
Sprint
Product Sprint New

Backlog Retrospective Functionality
Scrum benefits
• The product is broken down into a set of
manageable and understandable chunks.
• Unstable requirements do not hold up progress.
• The whole team have 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.
86
Extreme Programming (XP)
• One of the most well-known agile methods
• Developed in 1990s
– Kent Beck, 1996
– Chrysler Comprehensive Compensation Project
– Published book in 1999
Extreme programming
• Perhaps the best-known and most widely used
agile method.
• Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
– New versions may be built several times per day;
– Increments are delivered to customers every 2
weeks;
– All tests must be run for every build and the build
is only accepted if tests run successfully.
88
XP and agile principles
• Incremental development is supported through small,
frequent system releases.
• Customer involvement means full-time customer engagement
with the team.
• People not process through pair programming, collective
ownership and a process that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of code.
89
Extreme Programming Practices
1. On-Site Customer
– Customer is actively involved with development process
– Customer gives “User Stories”
• Short, informal “stories” describing features
• Keep on “story cards”
2. Planning Game
– Developers and customers together plan project
– Developers give cost estimates to “stories” and a budget of how much they
can accomplish
• Can use abstract accounting mechanism
• Later compare to actual cost, to improve estimates over time
– Customer prioritizes stories to fit within budget
3. Metaphor
– Come up with metaphor that describes how the whole project will fit
together
– The picture in a jigsaw puzzle
– Provides framework for discussing project in team
– Tools and materials often provide good metaphors
4. Small Releases
– Time between releases drastically reduced
• A few weeks/months
– Multiple iterations
– Can have intermediate iterations between bigger “releases”
5. Testing
– Test-first programming
– Unit testing frequently by developers
– Acceptance tests defined by customers
6. Simple Design
– Design should be quick, not elaborate
– Pick the simplest thing that could possibly work
– Resist adding stuff not ready yet
7. Refactoring
– Code gets worse with feature adds, bug fixes
– Rewrite small sections of code regularly
– Rerun all unit tests to know nothing broken
• Means you should have designed comprehensive tests
8. Pair Programming
9. Collective Ownership
– Anyone can edit anything
– Errors are the fault of the whole team
10. Continuous Integration
– Commit changes frequently (several times a day)
– Verify against entire test suite!
11. Coding Standards
– Enables effective teamwork
12. Sustainable Pace
– No overtime
– Only exceptions in final week
– Good estimation skills for budgeting will help ensure reasonable times
– Time less likely to be wasted in pairs, bullpen rooms
– Plan time each day for administrative work (<1 hour), breaks
The extreme programming release cycle
95
Extreme programming practices
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’. See Figures 3.5 and 3.6.
Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.
Simple design Enough design is carried out to meet the current requirements
and no more.
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 continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
96
Extreme programming practices
Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of
the development team and is responsible for bringing system
requirements to the team for implementation.
97
Pair programming
• In XP, programmers work in pairs, sitting together to
develop code.
• This helps develop common ownership of code and
spreads knowledge across the team.
• It serves as an informal review process as each line of
code is looked at by more than 1 person.
• It encourages refactoring as the whole team can
benefit from this.
• Measurements suggest that development productivity
with pair programming is similar to that of two people
working independently.
98
Pair programming
• In pair programming, programmers sit together at the
same workstation to develop the software.
• Pairs are created dynamically so that all team
members work with each other during the
development process.
• The sharing of knowledge that happens during pair
programming is very important as it reduces the
overall risks to a project when team members leave.
• Pair programming is not necessarily inefficient and
there is evidence that a pair working together is more
efficient than 2 programmers working separately.
99
Advantages of pair programming
• It supports the idea of collective ownership and
responsibility for the system.
– Individuals are not held responsible for problems with the
code. Instead, the team has collective responsibility for
resolving these problems.
• It acts as an informal review process because each
line of code is looked at by at least two people.
• It helps support refactoring, which is a process of
software improvement.
– Where pair programming and collective ownership are
used, others benefit immediately from the refactoring so
they are likely to support the process.
100
Pair Programming- Challenges
Pair programming can be uncomfortable in the
beginning, especially if you are not used to
collaborating.
Comfort needs repeating.
Communication issues.
Organizational buy-in - Isn’t it more expensive?

Feature Driven Development
• Feature Driven Development focuses on
regular delivery of client-valued features
• More structure than XP
• Embraces software development as a human
activity, subject to human limitations and
benefiting from human strengths
5/17/2019 102
• Feature-Driven Development (FDD) is a client-
centric, architecture-centric, and pragmatic
software process(1999)
• Jeff De Luca, Nebulon Pty. Ltd. (Australia)
• Peter Coad, TogetherSoft Corporation (now
Borland)
• FDD was first applied on a 15 month, 50-
person project for a large Singapore bank in
1997
5/17/2019 103
• As the name implies, features are an
important aspect of FDD.
• A feature is a small, client-valued function
expressed in the form
<action><result><object>.
• For example, "Calculate the total of a sale",
"Validate the password of a user", and
"Authorize the sales transaction of a
customer”
5/17/2019 104
Preliminary Processes
• Develop an Overall Model
• Build a Features List
• Plan By Feature
Preliminary Processes
• A system for building systems is necessary
• Simple is better
• Process steps should be obviously valuable to
each team member
• Good processes move to the background
Six Roles
• Project Manager
• Chief Architect
• Development Manager
• Chief Programmers
• Class Owners (aka Developers)
• Domain Experts
• What is FDD?
• Processes
– Preliminary Design
• Develop an Overall Model
• Build a Features List
• Plan By Feature
– Iterative Design
• Design By Feature
• Build By Feature
1. Develop an overall model
• Establishes the shape of the system
• Defines classes, how classes related to each
other
• Creates the base object model
• Includes internal and external reviews, model
notes
1. Develop an overall model
Study documents
Form the modeling Deelop a team Refine the overall

Conduct a domain walk through Write model notes
team model object model
Develop small
group models
2. Build a features list
Develop an overall Build a features

Plan by feature
model list
Design by feature Build by feature
Who?
Feature List Team: domain experts, chief
programmers, chief architect
• Functional decomposition of model developed in step 1
• Subject area to business activity to business activity step
• Feature is a business activity step, customer centric not
technology centric
• Nomenclature: <action> <result> <object>
• “Generate an account number for the new customer”
Form the features

Build features list
list team
http://www.nebulon.com/articles/fdd/DevView.html
3. Plan By Feature

Plan by feature
model list
Who?
The Planning Team: the project manager, the
development manager, and chief programmers.
3. Plan By Feature
Determine the
development
sequence
Form the planning Assign features to

team chief programmers
Assign classes to
developers
3. Plan By Feature
• Group features into feature sets (one or more
business activities)
• Prioritize based on customer need
• Establish completion dates (MM/YYYY)
4. Design by feature

Plan by feature
model list
Who?
The Feature Team: chief programmer, class owners
• Work package level—now based on the
technical architecture
• Two weeks or less of work
• Fleshes out class and object design, create
sequence diagrams as necessary
• Feature teams are very fluid
• Updates object model created in process #1.
Conduct a domain
walk through
Develop the
Form a feature Refine the object Write class and
sequence Design inspection
team model method prologue
diagrams
Study the
referenced docs
5. Develop by feature

Plan by feature
model list
Who?
Class owners, chief programmers

Plan by feature
model list
Who?
Class owners, chief programmers
• Implement
• Code inspection
• Unit test
• Promote to build
Unit Testing
Code Promote to build
Code inspections
Market Position: FDD v XP
FDD XP
• More hierarchical • Peer to peer
• Class owners • Collective ownership
• Success with above • Success with average
average developers developers
• Client works on 1,2,4 • Client on the team
• Process 1 • Constant refactoring
• “Live the life”! • 40 hour weeks
Lean Software Development
5/17/2019 126
Origins of Lean Software Development
• Originates from Toyota Production System (TPS)

– Called also Kanban or Just-In-Time system
– Post WWII Japanese automobile industry could not
compete with U.S. mass production systems
– Inspiration for TPS found in the 1950’s from U.S.
supermarkets
• Customers could get what they wanted, when they wanted it
and shelves were refilled when items were about to run out.
• The concepts transferred to the domain of software
engineering by Mary and Tom Poppendieck (2003,
2007).
Lean Management Principles
(Liker 2004)
1. Base your management decisions on a long-term

philosophy, even at the expense of short-term financial
goals.
2. Create continuous process flow to bring problems to
the surface.
3. Use “pull” systems to avoid overproduction.
4. Level out the workload.
5. Build a culture of stopping to fix problems to get quality
right the first time.
6. Standardized tasks are the foundation for continuous
improvement and employee empowerment.
7. Use visual control so no problems are hidden.
Lean Management Principles
(Liker 2004)
8. Use only reliable, thoroughly tested technology that serves your
people and processes.
9. Grow leaders who thoroughly understand the work, live the
philosophy and teach it to others.
10.Develop exceptional people and teams who follow your
company’s philosophy.
11.Respect your extended network of partners and suppliers by
challenging them and helping them improve.
12.Go and see for yourself to thoroughly understand the situation.
13.Make decisions slowly by consensus, thoroughly considering all
options; implement decisions rapidly.
14.Become a learning organization through relentless reflection and
continuous improvement.
The Principles of Lean Software Development
(Poppendieck & Poppendieck, 2007.)
• Eliminate waste
Waste is something that does not add value. For example unnecessary work.
• Build quality in
QA should not be a separate phase at the end of the project. Instead, it should
be continuous and something that is constantly improved. Automatization and
refactoring as tools.
• Create knowledge
Share information, teach others.
• Defer commitment
Make decisions at the ”last responsible moment”.
• Deliver fast
Deliver smaller increments of the product in short intervals
• Respect people
Respect colleagues, let people decide what and how to do it in order to meet
goals
• Optimize the whole
Optimize the whole value chain from customer request to complete product.
See the whole.
Comparison Of Lean and Agile Principles
• Eliminate waste
– Simplicity is essential
– Satisfy customer through early and continuous delivery
– Working software is the primary measure of progress
• Build quality in
– Working software is the primary measure of progress
• Create knowledge
– Regular reflection
– Close collaboration
• Defer commitment
– Welcome changes
• Deliver fast
– Deliver fast and frequently
– Satisfy customer through early and continuous delivery
• Respect people
– Self-Organizing Teams
• Optimize the whole
– All agile principles
The Lean Manifesto?
• Itsekussakin työssä ja toimessa tulee ennenkaikkea kysyä,

mikä arvo ja hyödytys niillä on; sillä työ, millä ei hyödytystä
ole, on parempi tekemätönnä, kun tehtynä.
(Elias Lönnrot, in the city of Kajaani, Finland.

October 23, 1841)
The Lean Manifesto?
• Considering what ever work or action one
should above all ask, what is the benefit and
value of it; because work that does not benefit
is better left undone
Waste in Software Development
• Something that does not create value

• Two categories of waste (Muda in Japanese)
– Type One muda: something that does not create customer
value but cannot be removed from the current production
environment
– Type Two muda: non-value adding activities that can be
eliminated immediately.
• Value Stream Mapping is a method for identifying and eliminating
waste
The Seven Wastes of Software Development
1. Partially done work. Something that is not done. E.g. untested
code, undocumented or not maintained code.
2. Extra features. Something that is not really needed.
3. Relearning (waste of knowledge). E.g. forgetting decisions, re-
trying solutions already tried, the inability to utilize the
knowledge of other people.
4. Handoffs. Passing the information/work to someone else, getting
information/work from someone else.
5. Task switching. How many other tasks people need to do. E.g. the
amount of projects done simultaneously.
6. Delays. Waiting for something.
7. Defects. Something that does not meet the targets, or is not what
it is supposed to be. E.g. software bugs, incorrectly implemented
business requirements.
Test Driven Development
5/17/2019 136
Traditional View of Testing
XP’s “Test First”
• Create test cases before writing code
– Business rep writes acceptance tests to demonstrate that
user stories are correctly implemented
– Programmers continually write unit tests which must run

flawlessly for development to continue
• “We only write new code when we have a test
that doesn’t work”
Reference: [Jeffries01]
Why Test Driven Development?
• One of the biggest problems in software is
requirements ambiguity
– A direct result of using natural language
specifications (e.g., “The system shall be fast”)
• A test case is inherently unambiguous

– Test cases are unambiguous “proxies” for
requirements
TDD Development cycle
1
Select a new feature
6 2
Refactor Write a test case
5 3
Run test to pass Run test to fail
4
Write enough code
140
TDD vs. Traditional Development Methodology
Traditional Development Cycle
Design Code Test
Test Driven Development Cycle
Test
Test Code
Code Refactor
Design
The term refactor is used to better communicate that the last step is about
transforming the current design toward a better design
141
TDD
• Is not about writing tests
• It is about writing Better Code

How to do TDD?
• Design: figure out what you want to do
• Test: write a test to express the design
– It should FAIL
• Implement: write the code
• Test again
– It should PASS
• Refactor
Design
• We need a method add(), which takes two

parameters and add them together, then it
will return the result.
Bad Test
• NO Assert/Meaningless Assert
• High maintenance cost
• Interacting Tests
• Require manual debugging
When is enough enough?
• One Test per class
• Testing the feature
• Find bugs, add tests
• Skip Getter/Setter if generated
• Skip Private methods
• Code coverage
Benefits of TDD
• Gradually builds an comprehensive suite of (hopefully
automated) test cases
– Run that suite each time the code is compiled
– All tests must pass except the brand new one(s)
• Code can be refactored with confidence
• Saves time during integration and system testing

– Most tests can be run automatically
– Many integration errors can be found before system test
Unit Test Frameworks
Open Source, downloadable, free
• Java – JUnit
• Python – PyUnit
• PHP – PHPUnit
• Ruby - Test:Unit
• C++ - CPPUnit
• .Net – NUnit
• ….
Junit
JUnit is an open source Java testing framework used to write and
run repeatable tests. It is an instance of the xUnit architecture for
unit testing frameworks.
JUnit features include:

* Assertions for testing expected results
* Test fixtures for sharing common test data
* Test suites for easily organizing and running tests
* Graphical and textual test runners
History
• Kent Beck developed the first xUnit automated test tool for
Smalltalk in mid-90’s
• Beck and Gamma (of design patterns Gang of Four) developed

JUnit on a flight from Zurich to Washington, D.C.
• JUnit has become the standard tool for Test-Driven

Development in Java (see Junit.org)
• JUnit test generators now part of many Java IDEs (Eclipse, BlueJ,
Jbuilder, DrJava)
• XUnit tools have since been developed for many other

languages (Perl, C++, Python, Visual Basic, C#, …)
JUnit Design
JUnit test framework is a package of classes that lets us write tests for each
method, then easily run those tests
Conclusions
• The professional goal of every software engineer, and every
development team, is to deliver the highest possible value to our
employers and customers.
– And yet, our projects fail, or fail to deliver value, at a dismaying rate.
• Though well intentioned, the upward spiral of process inflation is
culpable for at least some of this failure.
• The principles and values of agile software development were
formed as a way
– to help teams break the cycle of process inflation, and
– to focus on simple techniques for reaching their goals.
• At the time of this writing there were many agile processes to

choose from. These include
– SCRUM,
– Crystal,
– Feature Driven Development (FDD),
– Adaptive Software Development (ADP), and most significantly,
– Extreme Programming (XP).
– Others…

Agile Unit I

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agile Unit I

Transféré par

Droits d'auteur :

Formats disponibles

Agile Methodology

Examination Scheme : 80 M Theory

© Oscar Nierstrasz ESE — Software Quality ESE 11.6

• There is tension between:

• Some quality requirements are hard to specify in an unambiguous way

Quality management is not just about reducing defects!

© Oscar Nierstrasz ESE — Software Quality ESE 11.7

... Quality attribute

Reliability may be further

© Oscar Nierstrasz ESE — Software Quality ESE 11.8

• product: delivered to the customer

© Oscar Nierstrasz ESE — Software Quality ESE 11.9

• Internal: Derived immediately from the product or process description (To

© Oscar Nierstrasz ESE — Software Quality ESE 11.10

© Oscar Nierstrasz ESE — Software Quality ESE 11.11

• For process, resources are manpower, time and money

© Oscar Nierstrasz ESE — Software Quality ESE 11.12

Low cost Functionality Good

Software Requirements Software Requirements

Architecture Design Architectural Design

You rarely aim tore-visit a ‘phase’ once it’s

This approach is highly risky, often more costly and

• Architecture or High-Level Design –

• Detailed Design – develop algorithms • Unit testing – check that each

• Coding – transform algorithms into

– Developers are disheartened by working ever longer

– Development documentation (design) is always out

– Market moves ahead leaving the resultant product

•Solution attempt #1: Structured Methods (in

• Solution attempt #2: Software process improvement (in 1990’s)

• Solution attempt #3: Agile development

Design vs. Construction - 20 (design) 60 (design)

Frequency of Rarely Almost always!

Impact of change in Low Very High!

Not a process, it's a philosophy or set of values

• It promotes adaptive planning, evolutionary development and

• It is a conceptual framework that promotes foreseen

• The Agile Manifesto[ introduced the term in 2001.

• Software Engineering (SE) is the application of

• In a very broad sense, the term information system is

• In this sense, the term is used to refer

•Iterative and incremental development are essential

• Timeboxing plans activity by allocating time

• Practitioners had become afraid that repeated

• Goal: outline values and principles to allow

• The Alliance (17) created a statement of values:

• They then developed the 12 Principles of Agility.

Individuals and interactions over processes and tools

• Too much documentation is worse than too little.

• Short rationale and structure document.

• Not possible to describe software requirements

• Customers cannot just cite needs and go away

• Successful projects require customer feedback

• Number of practices have significant impact upon quality of final system:

• Agile processes deliver early and often.

• This is a statement of attitude.

• Agile teams work to keep the software structure

• We deliver working software.

• The goal of delivering software that satisfies

• For agile projects, there must be significant

An agile project must be continuously guided.

• Example: if the office environment is an obstacle to the

– Progress not measured by phase we are in, or

• An agile project is not run like a 50 yard dash; it is run like a