Software Engineering

CS1502

Dr. Ramachandra Reddy

 Agile Process

Text Book Reference:

Roger S. Pressman, Software Engineering – A Practitioner‟s Approach, Seventh Edition,
Mc Graw-Hill International Edition, 2010.
What is “Agility”?
• Effective (rapid and adaptive) response to change
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control of the work
performed
Yielding …
• Rapid, incremental delivery of software
 What is “Agility”?

• Agile is a time boxed, iterative approach to software delivery that

builds software incrementally from the start of the project,
instead of trying to deliver it all at once near the end.
• It works by breaking projects down into little bits of user
functionality called user stories, prioritizing them, and then
continuously delivering them in short two week cycles called
iterations.
Why Use Agile Methods

• Improve Customer Involvement

• Increase Quality
• Simplify Releases
• Drive Down Risk
AGILE MANIFESTO
The 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 et al
WATERFALL vs AGILE
WATERFALL vs AGILE
Agile Vs Traditional Methods
Agility and the Cost of Change
An Agile Process
• Is driven by customer descriptions of what is
required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy
emphasis on construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur
Agility Principles - I
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information
to and within a development team is face–to–face conversation.
 Agility Principles - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self–organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
Human Factors
• The process molds to the needs of the people and team, not
the other way around
• key traits must exist among the people on an agile
team and the team itself:
• Competence.
• Common focus.
• Collaboration.
• Decision-making ability.
• Fuzzy problem-solving ability.
• Mutual trust and respect.
• Self-organization.
Agile Methods
• Agile methods:
• Kanban (development)
• Scrum
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic System Development Method (DSDM)
• Agile modeling
• Agile Unified Process (AUP)
• Crystal Clear Methods
• Disciplined agile delivery
• Feature-driven development (FDD)
• Lean software development
• Scrumban
• Agile Alliance
• A non-profit organization promotes agile development
Extreme Programming (XP)
Extreme Programming (XP)
• The most widely used agile process, originally proposed by
Kent Beck
• XP Planning
• Begins with the creation of “user stories”
• Agile team assesses each story and assigns a cost
• Stories are grouped to for a deliverable increment
• A commitment is made on delivery date
• After the first increment “project velocity” is used to help
define subsequent delivery dates for other increments
Extreme Programming (XP)
• XP Design
• Follows the K.I.S (Keep It Simple) principle
• Encourage the use of CRC cards (see Chapter 8)
• For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
• Encourages “refactoring”—an iterative refinement of the internal
program design
• XP Coding
• Recommends the construction of a unit test for a store before coding
commences
• Encourages “pair programming”
• XP Testing
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and executed to assess
customer visible functionality
Core Values of XP

• Communication
• Simplicity
• Feedback
• Courage
• Respect
XP Values: Communication

• Poor communication in software teams is one of the root causes of

failure of a project
• Stress on good communication between all stakeholders--customers,
team members, project managers
• Customer representative always on site
• Paired programming
XP Values: Simplicity

• ‘Do the Simplest Thing That Could Possibly Work’

• Implement a new capability in the simplest possible way
• Refactor the system to be the simplest possible code with the current feature
set
• ‘You Aren’t Going to Need It’
• Never implement a feature you don’t need now
• Developers strive to write simple code bringing more value to a
product, as it saves time and effort.
XP Values: Feedback

• Always a running system that delivers information about itself in a

reliable way
• The system and the code provides feedback on the state of
development
• Catalyst for change and an indicator of progress
XP Values

• Courage. Programmers objectively evaluate their own

results without making excuses and are always ready to
respond to changes.

• Respect. The agile team inculcates respect among it

members, between other stakeholders and team
members, and indirectly, for the software itself.
XP Practices

(Source: http://www.xprogramming.com/xpmag/whatisxp.htm)
XP Practices: Planning Game
• Planning for the upcoming iteration
• Uses stories provided by the customer
• Technical persons determine schedules, estimates, costs, etc
• A result of collaboration between the customer and the
developers
• Advantages
• Reduction in time wasted on useless features
• Greater customer appreciation of the cost of a feature
• Less guesswork in planning
• Disadvantages
• Customer availability
• Is planning this often necessary?
 XP Practices: Planning Game
• XP Release Planning
• Customer presents required features
• Programmers estimate difficulty
• Imprecise but revised regularly
• XP Iteration Planning
• Two week iterations
• Customer presents features required
• Programmers break features down into tasks
• Team members sign up for tasks
• Running software at end of each iteration
 XP Practices: Small Releases
• Small in terms of functionality
• Team releases running, tested software every iteration
• The Customer can evaluate or in turn, release to end users, and provide
feedback
• Important thing is that the software is visible and given to the Customer at
the end of every iteration
• Advantages
• Frequent feedback
• Tracking
• Reduce chance of overall project slippage
• Disadvantages
• Not easy for all projects
• Versioning issues
XP Practices: Metaphor
• The oral architecture of the system
• XP Teams develop a common vision of the system
• Define common system of names
• Ensure everyone understands how the system works,
where to look for functionality, or where to add
functionality
• Advantages
• Encourages a common set of terms for the system
• A quick and easy way to explain the system
XP Practices: Simple Design
• Build software to a simple design
• Through programmer, testing and design improvement, keep the
software simple and the design suited to current functionality
• Not a one-time thing nor an up-front thing
• Design steps in release planning and iteration planning
• Teams design and revise design through refactoring, through the
course of the project
• Advantages
• Easier to understand what is going on
• Refactoring and collective ownership is made possible
• Helps keeps programmers on track
 XP Practices: Pair Programming
• Two Developers, One monitor, One Keyboard
• One “drives” and the other thinks
• Switch roles as needed
• Research into pair programming shows that pairing produces better
code in the same time as programmers working singly
• Pairing also communicates knowledge throughout the team
 XP Practices: Test-Driven Development
• Teams practice TDD by working in short cycles of adding a test, and
then making it work
• Easy to produce code with 100 percent test coverage
• These programmer tests or unit tests are all collected together
• Each time a pair releases code to the repository, every test must run
correctly
XP Practices: Design Improvement/
Refactoring
• Continuous design improvement process called
‘refactoring’:
• Removal of duplication
• Increase cohesion
• Reduce coupling
• Refactoring is supported by comprehensive
testing--customer tests and programmer tests
• Prompts developers to proactively improve the product
as a whole
• Increases developer knowledge of the system
XP Practices: Design Improvement/
Refactoring
 XP Practices: Continuous Integration

• New features and changes are worked into the system immediately
• Teams keep the system fully integrated at all times
• Daily, or multiple times a day builds
• Avoid ‘integration hell’
• Avoid code freezes
 XP Practices: Coding Standard
• Use common coding standard
• All code in the system must look as though written by an individual
• Code must look familiar, to support collective code ownership
 XP Practices: Collective Code Ownership

• Any pair of programmers can improve any code at any time

• No ‘secure workspaces’
• All code gets the benefit of many people’s attention
• Avoid duplication
• Programmer tests catch mistakes
• Pair with expert when working on unfamiliar code
XP Practices: Sustainable Pace/40-Hour Week

• The work week should be limited to 40 hours

• Team will produce high quality product when not overly exerted
• ‘Death march’ projects are unproductive and do not produce quality
software
• Work at a pace that can be sustained indefinitely
XP Practices: Whole Team

• All contributors to an XP project are one team

• Must include a business representative--the ‘Customer’
• Provides requirements
• Sets priorities
• Steers project
• Team members are programmers, testers, analysts, coach, manager
• Best XP teams have no specialists
XP Practices: Customer Tests/Testing

• The Customer defines one or more automated

acceptance tests for a feature
• Team builds these tests to verify that a feature is
implemented correctly
• Once the test runs, the team ensures that it keeps
running correctly thereafter
• System always improves, never backslides
• Unit testing
• Test-first design
• All automated
Scrum
• Originally proposed by Jeff Sutherland and extended by
Schwaber and Beedle.
• Scrum—distinguishing features
• Development work is partitioned into “packets”
• Testing and documentation are on-going as the product is
constructed
• Work occurs in “sprints” and is derived from a “backlog” of
existing requirements
• Meetings are very short and sometimes conducted without
chairs
• “demos” are delivered to the customer with the time-box
allocated
Scrum
Product Owner

• Define the features of the product.

• Prioritize features according to market value.
• Adjust features and priority every iteration, as
needed
• Decide on release date and content.
• Be responsible for the profitability of the product
(ROI).
• Accept or reject work results.
Team

• Seven (plus/minus two) members

• Is cross-functional (Skills in testing, coding, architecture etc.)
• Selects the Sprint goal and specifies work results
• Has the right to do everything within the boundaries of the
project guidelines to reach the Sprint goal
• Organizes itself and its work
• Demos work results to the Product Owner.
Scrum Master

• Ensure that the team is fully functional and productive

• Enable close cooperation across all roles and functions
• Remove barriers
• Shield the team from external interferences during the
Sprint
• Ensure that the process is followed, including issuing
invitations to Daily Scrum, Sprint Review and Sprint Planning
meetings.
Burndown Chart
XP vs Scrum
Aspects XP Scrum

Iteration Length 1-2 weeks 2-4 weeks

Scrum is not allowed

It can be replaced with
to do this. Once the
other requirements
iteration is completed,
Handle Changes when a need is not
no changes are
with an Iteration implemented, but the
allowed, and Scrum
implementation time is
Master is strictly
equal.
checked.
Priority of No need to
Yes
Features

Engineering Require developers to

Very strict
Practices be conscious
Kanban

• Kanban is an Agile approach described alternatively as

a methodology, system, framework or workflow management method
depending on the context in which it is applied.
• Kanban is a Just In Time (JIT) production process designed to
optimise the flow of the raw resources and components used in the
creation of an end product.
• In software development, the Kanban system optimises the flow of
work in progress (WIP) with the capacity of the development team.
• Another key pillar to Kanban is that it is a “pull” not “push” system.
Kanban (agile) Methodology

• Service Delivery Manager (SDM)

• /Flow Manager
• Service Request Manager (SRM)
Kanban

• Kanban’s namesake board visualizes the team’s workflow.

• The board is split into categories of work to be done, work in
progress, and completed work, and teams can add more categories
as necessary to better visualize their process.
Kanban
Kanban

• WIP limits
• The Kanban methodology requires strict limits on the amount of work in
progress at any given time. Teams assign a limit to the number of cards in
any active-work columns. When the limit is met, no new work can enter the
column until a task is completed and moved to the next column.
• Continuous improvement
• The goal of the Kanban methodology is to improve the team’s process.
• The team meets periodically to discuss changes that need to be made, and
the data displayed on the Kanban board guides these discussions.
Kanban vs Scrum
Adaptive Software
Development
• Originally proposed by Jim Highsmith
• ASD — distinguishing features
• Mission-driven planning
• Component-based focus
• Uses “time-boxing”
• Explicit consideration of risks
• Emphasizes collaboration for requirements gathering
• Emphasizes “learning” throughout the process
Adaptive Software Development