github twitter email rss
Agile Software Development
0001 Jun 1
6 minutes read

Agile Software Development

  • Manifesto for Agile Software Development

    • individuals and interactions over processes and tools
    • working software over comprehensive documentation
    • customer collaboration over contact negotiation
    • responding to change over following a plan

  • PM Declaration of interdependence
    – We increase return on investment by making continuous flow of value our focus.
    – We deliver reliable results by engaging customers in frequent interactions and shared ownership.
    – We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
    – We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
    – We boost performance through group accountability for results and shared responsibility for team effectiveness.
    – We improve effectiveness and reliability through situationally specific strategies, processes and practices.

  • Agile Alliance

  • iterative and incremental development a brief history

  • managing development of large software systems

waterfall model
Winston Royce model

plan driven development characteristics

  • sequential
  • deliver one increment
  • change is discouraged and controlled
  • adherence to the plan determines success or failure
  • done when part of the plan is done
  • gates to control quality
  • inspect work on completion
  • start b with prediction of what will be needed

agile development characteristics

  • concurrent
  • iterative
  • deliver many small
  • learn by small releases
  • change is encouraged and embraced
  • incentives based on customer satisfaction and ROI?
  • done when customer is happy
  • iterative to achieve quality
  • inspect work as being done
  • start with goal to fill customer needs, changing with feedback

agile principles

  • frequent and iterative delivery
  • adaptive and responsive to feedback
  • close customer relationships
  • transparency and openness

agile processes and methodologies

  • adaptive software development
  • agile modeling
  • agile unified process
  • crystal clear
  • dynamic systems development method
  • extreme programming
  • feature driven development
  • lean software development
  • scrum
  • user stories

working with people

  • planning
  • teamwork
  • engaging customers
  • providing leadership
  • colloboration
  • learning

agile techniques and practices

  • automated regression
  • behavior driven development
  • continuous integration
  • design pattern
  • domain driven design
  • DRY, SoC, Reuse, testability
  • incremental design
  • JIT architecture
  • separation of concerns
  • pair programming
  • refactoring
  • test driven development

working with software

  • design
  • coding
  • testing
  • deploying
  • user experience

agile is

  • iterative ( to final goal via small deliverables)
  • adaptive ( learn and change course)
  • value based (client values not team technology value)
  • easy to understand
  • hard to implement

agile is not

  • just writing code
  • undisciplined
  • unstructured
  • whatever you want it to be

Agile is not distinct process or methodology

Processes and methodologies

eXtreme Programming (XP)

  • Peaple should share same room
    • Problems should resolve just in time
  • Small groups
  • Iterative
  • Projects with changing requirements
  • Customer should be awailable constantly or be part of the team
  • Simple solution that satisfied requirements
  • Responsive to feedback


  • coding
  • testing
  • requirements analysis
  • design

Take good practice and push it to the extreme

code review           ->    pair programming
testing               ->    TDD and constant regression
software design       ->    relentless refactoring
simplicity            ->    the simplest thing that could possibly work
integration testing   ->    continuous integration
short iteration       ->    the planning game

XP practices

  • the planning game
  • small releases
  • metaphor as communication mechanism
  • simple design, waiting for layers and frameworks
  • testing
  • refactoring
  • pair programming
  • continuous integration
  • collective ownership
  • on site customer
  • 40 hours work week
  • coding standards


More iterative project management process than engineering practice


  • product backlog
    list of requirements
  • sprint backlog
    list of tasks to be done
  • 2-4 week sprint
  • 24 hour iteration

Lean Software Development

set of guidelines
focused on continuous improvement and value flow

  • eliminate waste
  • amplify learning, encourage to learn beyond level of current domain expertise
  • respect people
  • build quality in, not inject on completion
  • defer commitment, wait for more information for better decisions
  • deliver fast
  • recognize and optimize whole

Feature Driven Development

model driven
strict process rules
UML modeling witch drive design witch drive features that own by chief programmers


  • develop overall model
  • build feature list

    sum the total for monthly sales
    validate the password of the user
  • plan by feature
    feature no more than 2 weeks to complete
    assign ownership for features
  • design by feature
  • build by feature

  • milestones

    #design by feature
    domain walkthrough
    design inspection
    #build by feature
    code inspection
    promote to build


    • domain object modeling, UML
    • developing by feature
    • individual code ownership
    • feature teams
    • inspections
    • configuration management
      change history of system, traceability of features
    • regular build
    • high visibility progress and results

    Agile Unified Process (AUP)

    Requirements and estimation

    Requirement is

    • feature, behavior, constraint to be added to a system
    • prelude to conversation
    • request for someone to do work
    • request for software to change

    Requirement is not

    • solution design
    • decision about implementation
    • illustrative of the final deliverable
    • source of truth

    INVEST acronim (requirement characteristics in agile)

    • independent
    • negotiable
    • valuable
    • estimable
    • sized appropriately
    • testable

    user story

    As a I want so that .

    should be not the «user» but with use contextual role, like salesman, traveler etc.

    user story benefits

    • simple to write and understand
    • requirement is a communication problem
    • elicit detail in conversations
    • requirement analysis is effective when performed collaboratively
    • full intent or desired outcome can rarely be modeled or represented 100%

    Signs that user stories actually working

    • shift from writing to talking
    • stories are understood by customer and developer, basic outcome of functionality and why it is important
    • at estimation time, they are right size
    • participative design is occurring
    • emphasis is on the user goals, not the systems attributes

    Suit of tests, derived from user stories, defines success criteria for implemented user story

    Given (and ),
    Then (and )

    estimating work

    Estimates are necessary

    • to plan and proceed deliberately
    • to get feel for costs of feature
    • to calculate potential ROI
    • to understand the size of something
    • to know if work even can be done
    • to weigh options

    deadly estimation warning signs

    • someone other than the team is doing the estimation
    • estimates are given without looking at historical performance
    • estimate are treated as promises
    • estimates are rejected because they don’t fit an already existing plan

    story points

    • based on size and complexity, not time and duration
    • unitless, numerically relative
    • different for each team of estimators
    • additive, unlike time
    • based on historical reality

    using user stories

    • keep all previous records
    • with historical records we can see
      – which work items cost the most
      – total cost of all work
      – total cost of an iteration

    story points values

    • use units that make sense
      1 2 4 8 16 32
      1 2 3 5 8 13 20 40

    planning poker (estimation with groups)

    group derived estimates are demonstrably more accurate then estimates by individuals

    • emphasizes relative sizing
    • everyone is heard
    • finds hidden requirements and details
    • estimators must justify estimates
    • iterative



    Back to posts

    comments powered by Disqus