CO559: Software Develoment
Agile Development






Tomas Petricek

email: t.petricek@kent.ac.uk
twitter: @tomaspetricek
office: S129A

Development methodologies

How to build software well?

Development methodologies

  • Is there a "scientific method" for SW?
  • Follow some kind of structured process
  • Starts with reasonable principles...
  • May end with mindless rule following!

Methodologies have context

  • Culture it originates from - engineer vs. manager?
  • Product vs. process oriented

Process vs. product

Do we have a specification or adapt continually?

Manager vs engineer

Focus on process and team structure or tools and code?

Semi-Automatic Ground Environment (SAGE)

First attempt at a methodology

Focused on product
and management

Multi-stage process

Waterfall methodology

Multi-stage process
Royce (1987)

  1. Gather requirements
  2. Analyse and design
  3. Programming
  4. Testing
  5. Deployment

Chrysler Comprehensive Compensation System (C3)

Rapid software system development (in Smalltalk)

Focused on process
and engineering

First project using
Extreme Programming (XP)

Extreme Programming

Engineering practices drive the process

User stories to capture requirements

Planning game to plan the next iteration

Pair programming to build shared understanding

Continuous integration to always have running system

Test-driven development process

The New New Product Development Game

In today's fast-paced, fiercely competitive world (...) [c]ompanies are increasingly realizing that the old, sequential approach to developing new products simply won't get the job done.

Instead, companies in Japan and the United States are using a holistic method - as in rugby, the ball gets passed within the team as it moves as a unit up the field.

Takeuchi, Nonaka (1986)

SCRUM methodology

Following the Rugby terminology

Managerial, but process oriented

Manifesto for Agile Software Development (2001)

Popularized process-oriented or agile methodologies.

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

Requirements and user stories

Specifying and learning

Typical clients

  • Experts in their domain
  • Do not speak computer-speak
  • Not sure what is possible

Typical software provider

  • Hopefully knows how to build software systems
  • No idea about trading of energy derivatives and commodity price risk management
  • Rare exceptions sometimes happen!

Learning unfamiliar domain

Put knowledge on paper
Specification that programmers can understand and follow

Keep knowledge in brains
Not scalable, but developers can use intuition and contribute ideas

Lightweight requirement capture

Agile methodologies

  • Formal specifications are too hard
  • How do we get customers involved?
  • What is a good way of talking to them?

User stories

  • Not requirements, but stories
  • Use paper or Word or whatever works
  • As a user I want something so that benefit

Fixed story format

User so that we know who needs this

Benefit so that
there is a reason

User stories

Three critical aspects

❶ Card - artefact representing requirement

❷ Conversation - exchange of ideas with customer

❸ Confirmation - customer-defined acceptance test

As an online customer, I want to save my cart,
so that I can complete the purchase later

Q: For how long should the cart be saved?
A: For 3 days from the last access.

Q: What is an item in the cart becomes unavailable?
A: When item becomes unavailable,
remove it and warn the user.

Q: Can the user modify the cart after saving?
A: Yes, the user can modify the cart after saving.

Where do requirements come from?

Who is the customer

  • Product Owner in SCRUM
  • Actual system customer in XP

Being a customer is hard!

  • Will Extreme Programming
    kill your customer? (2001)
  • Marie DeArment in the Chrysler project

SCRUM development process

Management of:

Team structure
Who does what

Project planning
How to progress

Interactions
What to do when

Scrum roles

Who does what in the team?

Product owner - customer representative
Defines stories, prioritizes tasks, business-focus

Scrum master - process facilitator
Mentors team, removes obstacles, controls process

Development team - cross-functional team
Contribute to coding, testing, debugging, planning

SCRUM process

Backlog of user stories to implement

Planning based
on value*effort

Sprints add functio-
nality in 1-2 weeks

SCRUM ceremonies

Daily scrum 15 minute meeting

  • What you did yesterday
  • Pick the next task
  • What is blocking you

Sprint-related meetings

  • Planning to choose tasks for iteration
  • Review to engage with stakeholders
  • Retrospective to continuously improve

Summary

Agile development

Development methodologies
Waterfall, extreme programming, SCRUM
Managerial vs. engineering; process vs. product

Capturing requirements as stories
As a CO559 lecturer, I want you to remember this,
so that you can use user stories in your projects!

SCRUM development methodology
Product owner, scrum master, development team
Backlog, sprint meetings, daily scrum meeting

CO559: Agile Development

What you should remember from this lecture

  • What context determines a methodology?
  • Write user stories & have conversations
  • Roles and ceremonies in the SCRUM process


Tomas Petricek
t.petricek@kent.ac.uk | @tomaspetricek

References

Academic papers

Relevant books

Online material