Views

1
Agile / High-Speed Development Methods
2
21st Century Development Environment

• Faster metabolism of modern business
• Era of time-based competition / Internet speed
  Web time
• Shorter windows of opportunity
• Need for increased organisational flexibility and
  adaptability
• The load on IT organisations is heavier than ever
  before, and the management of IT is more complex
• Quantum leaps in developer productivity are
  necessary we need the new system a.s.a.p.!!

3
21st Century Development Environment

• Systems are becoming
• mission critical
• strategic
• Modern business demands complex systems
• to be produced and delivered in a short time
• within budget constraints
• that are of high quality
• that truly fulfill the needs of end users
• that are quick and easy to modify and maintain

4
A Brief Reprise The Traditional SDLC

• The traditional SDLC is popular in the Irish
  software industry
• It is a natural fit to contract-based development
• Although the traditional SDLC is a useful project
  management framework, its implicit assumptions
  are questionable

5
Traditional SDLC Separable Phases

• The traditional SDLC partitions the development
  effort into clearly separated phases, in
  sequential order
• In practice, phases are not clearly separated
• In particular, requirements analysis and design
  necessarily overlap
• the logic behind the separation is to avoid
  premature commitment to a given implementation
• however, it is difficult to define a requirement
  without an idea of how that requirement will be
  implemented
• the requirements must define a technically
  feasible and realistic system
• often, requirements are discovered during design
  as users and developers learn more

6
Traditional SDLC for Interactive Systems ?

• Active consideration of end-users needs is a
  critical factor in the development of interactive
  systems
• The traditional SDLC was originally devised when
  interactive systems were rare
• User involvement is supported only during the
  early stages and at the very end
• The traditional SDLC does not work well for
  many classes of software, particularly
  interactive end user applications - Boehm, 1988
• Ill know it when I see it (IKIWISI) systems
  requirements very difficult to pin down
• The traditional SDLC relies strictly on the
  formal specification document, which freezes
  requirements
• This practice can lead to obsolescence even
  before delivery !!

7
Traditional SDLC User Lock-Out and Volatile
Requirements
8
Modern Development Approaches

• Lean Lightweight methodologies / Just-in-Time
  Software
• Rapid prototyping
• Rapid Application Development (RAD)
• Timeboxing
• Incremental / Iterative / Evolutionary
  Development
• Agile Methodologies (e.g. eXtreme Programming,
  SCRUM, DSDM)
• Commercial Off-The-Shelf (COTS) development
• Open Source Software solutions (e.g.
  osCommerce.com)

9
Rapid Application Development

• RAD is a life-cycle process, popularised by James
  Martin, that aims to
• Enable speedier development
• Improve the quality of software
• Decrease the cost of development
• Speed is essential
• Martin, 1990
• Speedy development ought not imply quick and
  dirty delivery
• there should be no compromise between time / cost
  / quality

10
Rapid Application Development

• RAD features
• Interviewing
• JRP/JAD workshops
• Features of Participatory Design
• Rapid Prototyping
• Iterative development
• The use of integrated CASE(I-CASE) / 4GL tools by
  Specialist with Advanced Tools (SWAT) teams
• Some RAD approaches use timeboxing
• Timeboxing fixes the resources and time
  available, and prioritises the deliverables
• This means that timely delivery is critically
  dependent on necessary resources being made
  available

4
11
RAD Model
12
RAD and Quality

• Traditional approaches have tended to view
  software quality in terms of effective
  conformance with the written specifications
• With the waterfall model of software
  development, specifications are frozen long in
  advance of the system becoming operational
• - in the interim period, business needs are
  likely to have changed
• James Martin redefines software quality as
• meeting the true business requirements as
  effectively as possible at the time the system
  comes into operation
• The less the timelag between analysis / design
  and implementation, the more likely the system
  will be satisfactory

7
13
RAD and Quality

• Use of prototyping enhances quality
• Integrated CASE (I-CASE) tools enforces technical
  integrity in modelling and designing the system
  use of code generator creates bug-free code
• Use of I-CASE repository can facilitate the
  re-use of well-proven templates, components or
  systems

14
RAD and User Involvement

• Users are involved at each stage of the process
• Requirements Planning Phase
• Joint Requirements Planning (JRP) workshop
• User Design Phase
• Joint Application Design (JAD) workshop advocates
  strong participation by users in the
  non-technical design of the system under the
  guidance of IS professionals
• Uses I-CASE and prototyping
• Output is a design represented in an I-CASE tool
  - user does not sign off on a binder of paper
  specifications
• Construction Phase
• Users validate the screens and designs of each
  module as it is built
• Cutover Phase
• User training and use of the system

15
RAD and Maintenance

• One of the fundamental objectives of RAD is to
  create systems which can be changed rapidly
• Systems designed using RAD can be added to and
  changed to enable them to grow richer in
  functionality
• Facilitates much lower maintenance costs
• Case Example
• Nykredit, software house specialising in
  computing for banks. Designing a complex system
  for foreign currency loans at the cutover stage
  there was a change in legislation, severely
  affecting the system. However, the system was
  built with a sound data model, using the Texas
  Instruments I-CASE tool, the IEF (Information
  Engineering Facility). The new legislation was
  enacted on Friday, Feb 24th, 1989. The changes
  were incorporated into the design, and new code
  was generated over the weekend. On Monday
  morning, Feb 27th, the system ran with the
  changes. Nykredit claimed that this gave them a
  significant lead over our competitors.

16
RAD and Speed

• Development must be seen to be rapid relative
  to traditional SDLC
• RAD achieves speed by
• Parallel operations separation of tasks that
  can be carried out simultaneously (concurrent
  engineering)
• Use of Integrated-CASE tools and rapid
  prototyping
• Use of intensive JAD workshops
• Use of highly-skilled dedicated SWAT teams of 2-4
  individuals
• Active end-user involvement
• Reliance on reusable components
• Less paperwork
• Task automation

17
Nature of Software Requirements
Both parties (designers and clients) have to
give up the use of the requirements as a
semi-legal basis of control and measurement and
agree to work together in the continuous
meta-process of evolving the design brief and
sharing in the eventual decision as to how the
problem is to be seen and solved. - Jones,
1988 Requirements are often ambiguous, uncertain
and in flux ? systems development process must be
able to respond to change
18
Iterative, Incremental Development

• Q.    How would you eat a hippopotamus?
• A.    In lots of small bites, over the course of
  a number of meals

19
Benefits of Incremental Approaches

• Serious misunderstandings are made evident early
  in the lifecycle, when its possible to react to
  them
• It enables and encourages user feedback, thus
  improving requirements elicitation
• The team is forced to focus on the issues that
  are most critical to the project first
• Continuous, iterative testing enables an
  objective assessment of the projects status
• Inconsistencies between requirements, designs and
  implementations are detected early
• The workload of the team (even the testing team)
  is spread more evenly throughout the project life
  cycle
• The team can learn lessons and improve as they
  learn
• Stakeholders are given concrete evidence of the
  projects status throughout

20
Boehms Spiral Model
21
Rational Unified Process (RUP)
Traditional Waterfall Model
RUP an iterative approach that also recognises
the value of short sequential processes
22
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.

23
Principles of the Agile Manifesto (1)

• We follow these principles
• Our highest priority is to satisfy the customer
  through early and continuous delivery of valuable
  software
• Welcome changing requirements, even late in
  development. Agile processes harness change for
  the customer's competitive advantage
• Deliver working software frequently, from a
  couple of weeks to a couple of months, with a
  preference to the shorter timescale
• Business people and developers must work together
  daily throughout the project
• Build projects around motivated individuals. Give
  them the environment and support they need, and
  trust them to get the job done

24
Principles of the Agile Manifesto (2)

• The most efficient and effective method of
  conveying information to and within a development
  team is face-to-face conversation
• Working software is the primary measure of
  progress
• Agile processes promote sustainable development.
  The sponsors, developers, and users should be
  able to maintain a constant pace indefinitely
• Continuous attention to technical excellence and
  good design enhances agility
• Simplicity - the art of maximizing the amount of
  work not done - is essential
• The best architectures, requirements, and designs
  emerge from self-organizing teams
• At regular intervals, the team reflects on how to
  become more effective, then tunes and adjusts its
  behavior accordingly

25
Agile Methods

• eXtreme Programming (XP)
• SCRUM
• Dynamic Systems Development Method (DSDM)
• Feature Driven Development (FDD)
• Adaptive Software Development
• Crystal
• and many more !

26
Generic Agile Process
27
eXtreme Programming (XP)
28
XP Practices

• Planning game
• Programmers estimate effort of implementing
  customer stories and customer decides about scope
  and timing of releases
• Short releases
• New release every 2-3 months
• Simple design
• Emphasis on simplest design
• Testing
• Development is test-driven. Write unit tests
  before code
• Pair Programming 2 people at 1 computer
• Refactoring

29
XP Practices

• Collective ownership
• Anyone can change any part of the code at any
  time
• Continuous integration
• New builds as soon as code ready
• 40 hour week maximum no overtime
• On-site customer
• Customer present and available full-time for team
• Coding standards rules exist and are followed
• Open workspace large room, small cubicles

30
XP Practices

• Fine scale feedback
• Test Driven Development via Unit Tests and
  AcceptanceTests Planning Game On-site
  Customer Pair Programming
• Continuous process rather than batch
• Continuous Integration Refactor Mercilessly
  Small Releases
• Shared understanding
• Simple Design System Metaphor Collective Code
  Ownership Coding Conventions
• Programmer welfare
• Sustainable Pace (40 Hour Week)

31
XP Practices
On-Site Customer
Acceptance Tests
User Stories
Open Workspace
Coding Standard
CollectiveOwnership
Programmer Team Customer
Test-First Design
Pair Programming
Refactoring
Simple Design
Continuous Integration
Sustainable Pace
Metaphor
Release Plan
Iterations
32
XP Feedback Cycles
33
XP Myths

• XP is for Hackers
• Test First Design, Pair Programming, Refactoring
• XP ignores design
• Continuous Design, Refactoring, Risk
• XP produces no documentation
• Unit Tests, Acceptance Tests, Metaphor, Code
• XP is programmer-centric
• Business Value, Customer/Programmer, Customer
  Driven
• Pair Productivity is reduced
• Not borne out by empirical studies or experience

34
Convection Currents of Information
Developer 1
Information drifts in convection currents, so
proximity helps People dont ask as many
questions of each other if they have to walk down
the corridor or climb the stairs !
Developer 2
35
Collaborative Programming
Programming in pairs (More effective)
Near-by programming (Effective)
36
Information Radiators
Information is radiated passively People get
information just by walking past !
37
XP The Planning Game

• Informal brainstorming few hours to a few days
• Customer talks about what he/she wants
• Developers listen, ask questions, make user
  stories
• Engineers cost each story
• Customer values each story
• Rank order of cards
• Customer selects top items
• Developers produce Release One
• and reiterate

38
User Stories

• A story is the unit of functionality in an XP
  project. It is the medium to do analysis in XP
• Stories must be understandable to the customer
• Use plain, natural language
• Customers write stories. Developers do not write
  stories
• All proposals by developers are automatically
  approved by the customer
• The shorter the better. No detailed
  specification!
• A story is nothing more than an agreement that
  the customer and the developer will talk together
  about a feature.
• Each story must provide something of value to the
  customer
• So as to avoid building fancy features that will
  not be used
• A Story must be testable
• So that we can know when it is implemented

39
User Stories

• Writing stories is an iterative process,
  requiring lots of feedback
• Customers will propose a story to the programmers
• Programmers decide if story can be tested and
  estimated
• Customers may have to clarify or split the story
• Write stories on index cards
• cards are simple, physical devices that invite
  everybody to manipulate them
• A story contains not more than a few sentences
• if the story is too big, write only the essential
  core
• If the story is not quite right, tear the card up
  and write a new one

40
User Stories

• Programmers ask the customer to split a story if
• They cannot estimate a story because of its
  complexity
• Their estimate is longer than two or three weeks
  of effort
• Reasons
• Estimates get fuzzy for bigger stories
• The smaller the story, the better the control
  (tight feedback loop)
• Some rules for splitting stories
• Stories that have an important part and a less
  important part make two stories
• Stories covering several related cases make each
  case a story
• Also Bundle stories with estimates of less than
  a day together avoid cluttering the plan

41
Use Cases -v- User Stories

• A Use Case is an action with multiple
  participant objects that represent a meaningful
  business task, usually written in a structured,
  narrative style.
• Additional information can include
• Pre- and post- conditions
• Failure conditions, failure actions
• Refinement criteria what to consider when
  refining this use case into a sequence
• Action sequence
• Frequency, performance, data descriptions of the
  in/out data
• Compared to User Stories, Use Cases are
• More precise consistent, complete,
  non-overlapping, non-contradicting
• Hierarchically organized
• May tend to become a part of Big Methodology

42
SCRUM

• A scrum is a team pack in Rugby, everybody in
  the pack acts together with everyone else to move
  the ball down the field
• Phases
• Pre-game
• Planning - define system. Product Backlog
• Architecture - high level design of system
• Development
• Iterative cycles (sprints) - new or enhanced
  functionality
• Postgame
• Requirements satisfied - no new items or issues
• SCRUM is an iterative, incremental, team-based
  systems development approach designed for use in
  environments where requirements are rapidly
  changing
• It aims to control the chaos of conflicting
  interests and needs

43
SCRUM

• SCRUM is a way to
• improve communications and maximize co-operation.
  
• detect and cause the removal of anything that
  gets in the way of developing and delivering
  products
• maximise productivity
• SCRUM is scalable from single projects to entire
  organisations

44
SCRUM Practices

• Product Backlog Current prioritised list of work
  to be done
• Effort Estimation iterate over backlogged items
• Series of sprints short, sharp iterations of 1
  - 4 weeks
• Sprint Planning Meeting decide goals for next
  sprint and how team will implement
• Sprint Backlog backlog items to be tackled in
  the sprint
• Daily Scrum meeting short 15 - 30 minute review
  (similar to daily stand-up meeting in XP)
• Sprint Review Meeting at end, present results of
  sprint

45
SCRUM Practices
46
SCRUM Meetings

• Short (15 - 30 min) frequent meetings,
  facilitated by the ScrumMaster
• All team members attend - even teleworkers
• One activity ScrumMaster asks each attendee
  three questions
• 1. What have you completed (relative to the
  Backlog) since the last Scrum meeting?
• 2. What got in your way of completing this work?
• 3. What will you do between now and the next
  Scrum meeting?

47
What Happens During a SPRINT?

• Frequent, short Scrum Meetings
• Each team produces a visible, usable increment
• Each increment builds on prior increments
• Clearly defined deliverables and responsibilities
• Each team member buys into the assignment
• Rule Total focus, no diversions or interruptions

48
At the End of a SPRINT

• Status meeting with all stakeholders
• Increments are delivered
• Surprises are reported
• ANYTHING can be changed, work can be added,
  eliminated, re-prioritised
• New estimates and team assignments are made for
  the next Sprint
• The project can be cancelled
• Experience from earlier increments allows
  better estimates and planning as project
  progresses. It's always easier to estimate
  shorter development periods

49
Using Agile Methodologies

• So far, industrial experiences with XP and SCRUM
  are largely favourable
• However, some words of advice
• Agile methods require a lot of energy after a
  few months, a team can grow weary
• After a team makes an incremental delivery, there
  tends to be a natural pause. This time should be
  opportunely used to conduct periodic checkups -
  to facilitate process improvement and corrective
  action (Dont wait until the final increment at
  the end of the project to perform these checkups,
  or they mightnt get done!)
• Agile methods require discipline, commitment,
  talent and good leadership
• Do agile methods scale up? Do they work in
  distributed environments?
• Some programmers prefer to work solo and might
  resist pair programming

50
Using Agile Methodologies

• With agile methods, the customer plays an
  essential role he steers the project.
• A good customer
• understands the domain well by working in that
  domain, and also by understanding how it works
• can understand, with developments help, how
  software can provide business value within the
  domain
• can make decisions about what's needed now and
  what's needed later
• is willing to accept ultimate responsibility for
  the success or failure of the project
• It can be difficult to get good customers even
  more difficult to get on-site customers (XP)!

51
Agile Methods -v- Hacking

• Hackers ...spend all their time coding
• Agilists ... test according to project
  priorities, recheck results with users often
• Hackers ... talk to each other when they are
  stuck
• Agilists ...talk to each other and customers as
  a matter of practice
• Hackers ...avoid planning
• Agilists ... plan regularly
• Hackers ... management caves in out of fear
• Agilists ...expect management to provide
  priorities and participate jointly in project
  adjustments.

52
References

• Agile Methodologies (General)
• http//www.martinfowler.com/articles/newMethodolog
  y.html
• http//www.agilealliance.org/
• Extreme Programming
• Kent Beck, Extreme Programming Explained Embrace
  Change (Addison Wesley, 1999).
• Kent Beck and Martin Fowler, Planning Extreme
  Programming (Addison Wesley, 2001).
• www.xprogramming.com
• www.extremeprogramming.org
• SCRUM
• http//www.controlchaos.com/
• http//jeffsutherland.com/scrum/index.html