Week 8. Agile Software development

Project-based software development

Project-based software development usually comprises of:

• A one-off project
• Has a specific set of stakeholders with a reasonable chance to understand them
• Well-defined set of requirements
• Specific time period defined through negotiation
• We may bring in a dedicated team (e.g. consultants)

Link to original

Product-based product development

Product-based software development comprises of:

• Repeated releases of new product versions
• Potentially very wide set of stakeholders and users
• Externally defined (vs. by marketing)
• Release dates; driven by time to market
• Typically a constant in-house team

Link to original

Rapid software development

Rapid Software Development

“Time to market” is one of the most important requirements, especially for Product-based product development. Businesses operate in a fast-changing world, so:

• producing a stable set of software requirements is impossible
• software has to evolve quickly to reflect changing business needs
• perfect software next year is less useful than “ok” software tomorrow

Link to original

Plan-driven development

Plan-driven development

Essential for some types of system as it can give strong quality assurances. Does not usually meet “time-to-market” needs.

• Based around separate development stages with outputs at each.
• Planned in advanced.
• Not necessarily waterfall: incremental development is possible.
• Iteration occurs within activities.

Link to original

Agile development

Agile development

Emerged in late 1990s, aim to reduce delivery time for working software systems.

• Specification, design, implementation and testing are inter-leaved.
• Outputs from development process are decided through negotiation during software development.
• System is developed as a series of increments.
• Frequent delivery of new versions for evaluation.
• Extensive tool support (e.g. automation)
• Focus on working code (minimal design / documentation)

Principles of Agile:

• customer involvement: customers should be closely involved through the development process
• incremental delivery: software developed in increments; customer specifies requirements for each increment
• people not process: recognise and exploit skills of development team; leave team members to develop their own ways of working; no prescriptive processes
• embrace change: expect system requirements to change; design system to accommodate future changes
• maintain simplicity: focus on simplicity in both software and development process; actively work to eliminate complexity from system

Agile applies where:

• We are developing a small or medium-sized product.
• There is a clear commitment from customer to become involved in the development process.
• Where there are few external rules and regulations that affect development.

Link to original

Extreme Programming

Extreme Programming

Extreme programming is a fast iterative approach:

• new versions may be built several times per day
• increments delivered every 2 weeks
• all tests must run for every build
• build is only accepted if tests run successfully

There are some key principles when doing XP:

• incremental planning: user stories / cards for requirements; prioritisation for planning per release cycle; stories broken into dev. tasks by developers
• small releases: minimum viable product; frequent, incremental releases
• simple design: just enough design
• test-first development: write tests before solution; automate test execution
• refactoring: continuously refactor code to keep it simple and maintainable
• pair programming: developers work in pairs
• collective ownership: everyone can make changes everywhere; everyone is responsible for the quality of the whole code base
• CI: regular releases, supported by powerful tooling for integrating and testing
• sustainable pace: overtime is not considered acceptable
• on-site customer: full-time end-user representative on team

Link to original

Test-driven development

Test-driven development

Writing tests before code clarifies requirements to be implemented. Tests are programs rather than data, so:

• can be executed automatically
• test includes a check that is has executed correctly
• usually relies on a testing framework

Though programmers usually prefer programming to testing:

• they may take shortcuts when writing tests
• some test are difficult to write
• difficulty judging completeness of a set of tests without full spec

Link to original

Pair programming

Pair programming

Programmers sit together at the same computer to develop software.

• Pairs are created dynamically; all team members work with each other.
• Enables knowledge sharing and learning; reduces overall risks when a team member leaves the project.
• Not necessarily efficient.

It can be done in different ways:

• driver and co-pilot; different roles
• frequent switching

Link to original

Kanban

Kanban helps us organise user stories in vertical lists. Boards have column for process stages:

1. Epics
2. Backlog
3. Discovery
4. Development
5. Testing
6. Ready for Release
7. Done

Scrum

Scrum

Scrum is focused on managing iterative development rather than specific agile practices. There are three phases:

• initial phase (sprint 0): outline planning; establish objectives
• series of sprints: each sprint develops an increment of the system
• project closure: wraps up project; docs are finished

Scrum terminology:

• development team: self-organising team of no more than 7 people
• sprint: development iteration; usually 2-4 weeks long
• potentially shippable product increment: software increment delivered from a sprint; should be in a finished state with no further work
• product backlog: list of times dev team must tackle
• product owner: individual whose job it is to identify, prioritise and review product features or requirements
• scrum: daily meeting of development team at scrum board
• scrum master: responsible for ensuring the process is followed; guides the team for effective use of scrum
• velocity: number of tasks / cards that can be handled in a sprint

Link to original

Agility at scale

Agile methods are successful for small / medium sized projects but can be difficult to scale to larger projects.

Multi-team Scrum can be used:

• role replication: each team has a product owner for their work component and a scrum master to manage it
• product architects: each team chooses a product architect and these architects collaborate to design and evolve the overall system architecture
• release alignment: dates of product releases from each team are aligned so that a demonstrable and complete system is produce
• scrum of scrums: there is a daily scrum of scrums where representatives from each team meet to discuss and plan

Issues with Agile

• Agile methods require higher skill levels than plan-based approaches.
• Design documents may be required if team is distributed.
• Without documentation, IDE support for visualisation is required.
• Introducing it may be difficult:
  • Project managers without experience of agile methods.
  • Cultural resistance: long history of using conventional systems
  • Projects may be expected to follow standard quality procedures
• May have contractual concerns