Published on

COMP2120 - Week 1 - Agile

Table of Contents

Agile Software Development

Rapid Software Development

  • Fast paced operating environment makes rapid development and delivery an important requirement
    • Software evolution after delivery is vital

Agile Software Development

  • Stakeholders involved in the specification and evaluation of the series of versions/increments

  • Minimal documentation -> Focus on working code

Plan-drive vs Agile

Plan-driven Spec

  • Planning largely upfront, but not necessarily waterfall, but can also be incremental

    • Can be incremental

  • Iteration generally occurs in activities, not in planning

Agile Spec

  • Specification, design, implementation and testing are interleaved -> Outputs of which undergo negotiation process with stakeholders

  • Reduces overhead by limiting documentation and allowing for quick response times to changing requirements

Agile

Agile Manifesto

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a set plan

Five Principles

      Principle      |                               Description
---------------------------------------------------------------------------------------------------
Customer Involvement | Customer closely involved + provide and prioritize new system requirements |
---------------------------------------------------------------------------------------------------
Incremental Delivery | Software is developed and delivered incrementally                          |
---------------------------------------------------------------------------------------------------
People not process   | Skills should be exploited and left to work without prescriptive processes |
---------------------------------------------------------------------------------------------------
Embrace change       | Expect system to change so build system to accommodate changes             |
---------------------------------------------------------------------------------------------------
Maintain simplicity  | Simplicity in both design and development processes                        |
---------------------------------------------------------------------------------------------------

Agile Applicability

  • Virtually all software products are developed with Agile

  • Clear commitment from customer is required

  • Few external rules or regulations

Extreme Programming (XP)

  • Versions built many times per day

  • All tests must be run for every build

XP Practices

      Principle       |                               Description
--------------------------------------------------------------------------------------------------------
Incremental planning  | User story mapping (requirements on story cards). Broken into tasks            |
--------------------------------------------------------------------------------------------------------
Small releases        | Minimal useful set of functionality that provides business value               |
--------------------------------------------------------------------------------------------------------
Simple design         | Just enough is done to meet requirements                                       |
--------------------------------------------------------------------------------------------------------
Test-first            | Automated unit testing framework                                               |
--------------------------------------------------------------------------------------------------------
Refactoring           | Continuous refactoring required to keep code simple and maintainable           |
--------------------------------------------------------------------------------------------------------
Pair programming      | Quality checking + support and checking                                        |
--------------------------------------------------------------------------------------------------------
Collective ownership  | All developers can change anything + no islands of expertise develop           |
--------------------------------------------------------------------------------------------------------
Continuous integration| Integrated as soon as complete, after all tests pass                           |
--------------------------------------------------------------------------------------------------------
Sustainable pace      | Large amounts of overtime no acceptable. Reduces code quality and productivity |
--------------------------------------------------------------------------------------------------------
On-site customer      | Customer avaliable for bringing requirements for implementation                |
--------------------------------------------------------------------------------------------------------

XP Release Cycle

XP Release Cycle

Influential XP Practices

  • XP rarely used in "pure" form

  • Common practices:

    • User stories
    • Refactoring
    • Test-driven development
    • Pair programming

Refactoring

  • Good SE includes designing for change

  • XP proposes constant code improvement

  • Improvements made, even if no immediate need for them

  • Improve understandability and reduce need for documentation

  • architecture refactoring can be more expensive

    • Design for change at an architecture level in the first place
Examples

  • Re-organisation to remove duplicate code

  • Tidying up

Test-driven development

  • Tests can unveil new/hidden requirements

  • Tests should build on each other

    • Should run automatically (e.g. JUnit)

    • Previous tests run to check that new code has not broken previous code/requirements

Customer testing

  • Acceptance tests -> Some tests may be more important to the customer than others

  • Provides higher level insight

Pair programming

  • Working in pairs

  • Informal review process + encourages refactoring

  • Sharing of knowledge occurs -> Reduces risk if team members leave

  • Not necessarily inefficient -> Can save time as developed software can be better

User Stories for Requirements

  • Customer/user is part of XP team -> Decision maker

    • Customer chooses stories for inclusion

  • Written down and broken into implementation tasks

Agile Project Management

  • Management should be able to oversee a process such that it is delivered on time and within budget

Scrum

  • Adopted into software (Programming methodology)

  • Three phases

    • First phase (Outline planning) -> Establishes general objectives and designs software architecture

    • Second phase (Development) -> Focussed series of sprint cycles

      • Each spring develops an increment

    • Third phase (Project closure) -> Wraps up project + documentation + asseses lessons learnt from the project for future improvement

Termonology

Scrum term : Definition

  • Development team -> No more than 7 people + self-organising

  • Potentially shippable produce increment -> Finished state, such that no further work is required to incorporate it into final product

  • Product backlog -> 'To do' list.

    • May be:
      • Feature definitions
      • Software requirements
      • User stories
      • Refactoring
      • Documentation

  • Product owner -> Individual or group who identifies features and requirements + reviews product backlog

  • Scrum -> Daily team meeting, short and includes whole team. Progress review + prioritisation

  • Scrum master -> Ensures team follows process effectively

    • Should not be a project manager (but often are)
    • Responsible for interfacing with rest of company

  • Sprint -> Development iteration, usually 2-4 weeks long

  • Velocity -> Estimate of how much product backlog the team can cover. Helps for future planning and as a basis for measuring, and improving performance

Scrum Sprint Cycle

Scrum Sprint Cycle

Scrum Benefits

  • Chunking is good

  • Unstable requirements don't hold up progress -> Put into next sprint

  • Positive culture created -> Trust between customers and developers

  • Scrum can be integrated with existing practices and Agile principles indroduced if and when appropriate

Bertrand Meyer - Agile - The good, bad and ugly

  • What about testing?

  • User stories -> Not a fundamental requirement technique, cannot define requirements

    • Not abstract enough
    • Too specific
    • Describe current processes
    • Don't support evolution

The ugly

  • Rejection of upgront tasks

  • User stories replace abstract requirements

  • Dismissal of a priori concern for extendibility, reusability and architecture work

The indifferent

  • Pair programming

  • Sustainable pace

  • Cross-functional, self-organising teams

The good

  • Frequent interactions

  • No branching

  • Daily meeting

The brilliant

  • Closed window rule

    • Requirements frozen during sprint cycle

  • Refactoring

  • Test with all functionality