Agile%20Software%20Development

1
Agile Software Development

• An Alternate Approach

Umar K. Munroe MSCS Candidate Union
College 1/9/2004
2
Topics of Discussion

• Why an alternate approach
• Overview of Agile Software Development
• Agile Processes
• Limitations of Existing Agile Processes
• Adoption Future in Industry

3
Why an alternate software development approach?

• Traditional Approaches ? Slow Rigid
• Highly structured
• Detailed process scripts
• Required Artifacts (i.e. documents)

4
Why an alternate software development approach?

• Internet mobile technology increase demand for
  software development to
• to be faster
• more responsive to change
• Traditional methods arent exactly working well
• 13,522 IT projects (Standish Group, 2002)
• 34 on-time, on-budget, sufficient functionality
• 51 late, over-budget, less functionality
• 15 fail

5
Agile Software Development

• Quick development
• Responsive to changing requirements
• Simple, straightforward process
• Frequent customer involvement and feedback
• Guide development
• Iterative, incremental development
• Provides flexibility, responsiveness

6
Agile Alliance

• In 2001, software industry experts formed the
  Agile Alliance
• Goals
• Outline values and principles of agile software
  development
• Promote agile software development in industry
• http//www.agilealliance.org

7
Agile Manifesto
8
Value 1 Individuals and interactions over
process and tools

• A good process will not save the project from
  failure if the team doesnt have strong players,
  but a bad process can make even the strongest of
  players ineffective. Robert C. Martin
• people and their relationships most important to
  a successful project

9
Value 1 Individuals and interactions over
process and tools

• Team
• motivated
• good programmers (not necessarily most talented)
• excellent communication skills
• Tools and environment built around team, not vice
  versa

10
Value 2 Working software over
comprehensive documentation

• Documentation produced only when necessary
• Short one or two dozen pages at most
• Less time
• Salient describing the overall design rationale
  and only high level structures in the system
• Details likely to change
• Primary goal is working software
• Demonstrated to customer frequently
• Measure of progress

11
Value 3 Customer collaboration over
contract negotiation

• "A contract that specifies the requirements,
  schedule, and cost of a project is fundamentally
  flawed." Robert C. Martin
• Contracts govern the working relationship between
  developers and customer
• Customer is intimately involved
• Guide development

12
Value 4 Responding to change over following
the plan

• Change is expected
• Planning Strategy (iterative)
• a detailed plan over the next 2 weeks
• a very rough plan for the next 3 months
• an extremely crude plan beyond 3 months
• Minimize time wasted planning too far into the
  future

13
Agile Development 12 Principles

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 customers competitive advantage
3. Deliver working software frequently, from a
   couple of weeks to a couple of months, with a
   preference of a shorter time scale
4. Business people and developers must work together
   daily throughout the project

14
Agile Development 12 Principles

1. Build projects around motivated individuals.
   Give them the environment and support they need,
   and trust them to get the job done.
2. The most efficient and effective method of
   conveying information to and within a development
   team is face-to-face conversation.
3. Working software is the primary measure of
   progress
4. Agile process promote sustainable development.
   The sponsors, developers, and user should be able
   to maintain a constant pace indefinitely.

15
Agile Development 12 Principles

• 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

16
Agile Processes

• Typically,
• Less structured
• Practices and rules
• Selected Agile Processes
• eXtreme Programming (XP)
• Scrum
• Dynamic Systems Development Method (DSDM)

17
eXtreme Programming (XP)

• Most famous and documented agile process
• Rules practices
• Developed by Kent Beck mid 1990s
• More info
• http//www.extremeprogramming.org

18
XP Concepts/Practices

• Customer Team Member
• Highly accessible (on-site)
• User Stories over detailed requirements
• Describe functionality
• Reduces unnecessary upfront restrictions
• Simple Design
• Quick, easy, sufficient

19
XP Concepts/Practices

• Test Driven Development
• Tests written first, code written to make tests
  pass
• Automated
• Acceptance Tests
• Verify user stories
• Written before implementation
• Short Cycles
• 2-3 month releases
• 2 week Iterations

20
XP Concepts/Practices

• Pair Programming (2 people, 1 computer)
• Generate production code
• Transfer Knowledge
• Better Quality ? Faster development
• Collective Ownership
• Team knowledgeable in all aspects of project
• Open Workspace
• Easy access for conversation
• Limits team size (lt10 people)

21
XP Concepts/Practices

• Continuous Integration
• Refactoring
• tiny transformations to improve the structure of
  the code without changing its behavior
• continuous
• Metaphor
• Provides big picture of the system

22
XP Concepts/Practices

• Sustainable Pace
• 40 hr week
• Planning Game
• Plan made at the start of each iteration and
  release
• Customer decides which user stories to implement
  next

23
XP Project Lifecycle
24
Scrum

• Management approach using existing processes and
  practices
• empirical approach based in control systems
  theory
• Developed (mid 90s) maintained by Advanced
  Development Methods (ADM, Inc) http//www.controlc
  haos.com
• Training and certification available

25
Scrum Key Concepts/Practices

• Product Backlog
• Defines everything needed in the final product
• Goals, Resources
• Constantly updated
• Sprint (Cycles)
• 30 days
• Production of an executable product increment
• Requirements relatively frozen during Sprint

26
Scrum Key Concepts/Practices

• Sprint Planning Meeting
• Goals and functionality of sprint
• Decide an implementation approach
• Sprint Backlog
• Items specific to the Sprint from the Product
  Backlog
• Small teams (5 to 9 people)

27
Scrum Key Concepts/Practices

• Daily Scrum Meeting
• 15 minutes
• 3 questions addressed by each team member
• What did you do since the last meeting?
• Any obstacles or issues?
• What will you do before the next meeting?
• Sprint Review Meeting
• Demonstrate implemented functionality
• Make decisions as to the next sprint

28
Scrum Sprint Lifecycle
29
Feature Driven Development (FDD)

• Focuses on the design and implementation
• Well defined process
• Detailed Process Scripts
• http//www.nebulon.com/articles/fdd/download/fddpr
  ocessesA4.pdf
• Utilizes best practices found to be effective in
  industry
• Developed by Peter Coad, Jeff De Luca, And
  Stephen Palmer in the late 1990s, early 2000s

30
FDD Key Concepts/Practices

• Features
• functionality having direct value to customer
• Implementable in 2 weeks or less
• Domain Object Modeling
• Exploration and analysis of project domain
• Results in a framework where features are added
• Object Oriented Design
• Individual Code Ownership
• Unit Tests and Inspections

31
FDD Key Concepts/Practices

• Iterations by feature(s)
• 2 weeks
• Regular Builds
• Configuration Management
• Progress Reporting

32
FDD Process

• Five Phase Process
• 1 Develop the Overall Model
• Mini-teams of 3 or less develop models for the
  entire project
• Teams reassemble and decide a best model
• Participation of Customer paramount
• 2 Build a Features List
• Break down project into 2 week implementable
  features
• 3 Plan By Feature
• Plan features to be implemented based on
  dependencies, required resources, and complexity

33
FDD Process

• 4 Design By Feature
• Teams identified for one or more features
• Teams produce design for assigned features
• Sequence Diagrams
• Skeleton Classes with method signatures
• 5 Build By Feature
• Implement by class package for feature
• Start with supporting classes
• Code is written, unit tested, inspected
• Promoted to build of system

34
Dynamic Systems Development Method (DSDM)

• framework developed in the early 1990's for rapid
  application development (RAD)
• Driving Principle
• Time and Resources are fixed
• Functionality is flexible
• Very popular in Europe
• Maintained by the DSDM Consortium
• http//www.dsdm.org

35
DSDM Key Concepts/Practices

• MoSCoW Prioritization
• Must Haves ? critical to success
• o
• Should Haves ? important but not critical
• Could Haves ? nice to have
• o
• Won't Have ? will not be implemented

36
DSDM Key Concepts/Practices

• TimeBoxing
• Project end date is fixed
• Schedule broken into fixed 2-6 week blocks of
  time (time box)
• Assigned requirements of varying priorities
• Complete highest priority within the time box

37
DSDM Key Concepts/Practices

• Prototyping
• Demonstrate business process
• Evaluate user interaction
• Determine Performance/Capability
• Demonstrate proof of concept

38
DSDM Lifecycle

• Feasibility Study
• Is DSDM appropriate?
• Outline Plan
• Business Study
• Analyze requirements
• Recommended technical approach
• Plan potential prototypes

39
DSDM Lifecycle

• Functional Model Iteration
• Build on requirements
• Prototype functionality
• Design and Build Iteration
• Prototype design
• Refine prototypes into production
• Implementation
• Transition from development to operation
• Provide Training

40
DSDM Lifecycle
41
Other Agile Processes

• Feature Driven Development (FDD)
• Framework with features
• Crystal Methodologies
• Processes based on size and criticality
• Adaptive Systems Development (ASD)
• Large, complex systems

42
Limitations of Existing Agile Processes

• Limited support for large distributed
  development teams
• Communication breakdowns
• Limited support for code reusability
• Project specific
• Limited support for large, complex software
• May require significant up front design and
  planning
• Incremental delivery may not be valuable
• Unproven

43
Agile Adoption

• Adoption is slow but appears increasing
• In March 2002, the Giga Group estimated
• 10 of corporate IT groups are using agile
  processes
• 2/3 are exploring use for future projects

44
Future of Agile Software Development

• Processes still evolving
• i.e.) XP with Scrum
• Wont eliminate traditional approaches
• Traditional approaches still valuable
• Here to stay? The new standard?
• Only time will tell

45
Summary Agile Software Development

• Quick and Responsive development
• Iterative, incremental
• Ample Customer Involvement
• Different Processes available
• Alternative to Traditional Methods

46
Questions / Comments ?