Agile software development

by Andres Baravalle

Agile software development

  • Software development phases
  • Software development approaches
  • Extreme Programming

Software development phases

Software development projects

In Web development, as in any other software development, projects can be divided into different phases - typically identified as:

  1. Planning
  2. Designing
  3. Coding
  4. Testing
  5. Maintenance

Planning

During the planning phase the project requirements are collected (or extracted) from the relevant sources and formalised.

Interviews, focus groups and questionnaires can all be used to extract the software requirements.

Designing

In the designing phase, developers work at defining the structure of the system and the relations between the different sub-elements.

This includes formalising the requirements and modeling the application (Case Diagrams, User Stories etc).

Please note that designing (in this context) is about "application design" not "interface design".

Coding

Once the design is sufficiently clear, the team can proceed to the coding phase.

In this phase, we are going from the high-level description of the design phase, to actually doing the ‘manual’ work. In web applications development, it may require one or more of the following tasks: (X)HTML coding, client-side scripting, Web design or server-side programming.

Testing

The testing phase is used to analyse the result of the implementation in terms of correctness, completeness, security, and quality and to compare it to the initial requirements.

If a Web application is correct, complete, secure and of good quality but doesn’t fulfill the initial requirements, you may have a number of issues to discuss, either with your customer or with your project manager.

Maintenance

The maintenance phase is the final phase in a project, and follows the actual delivery of the project. The maintenance phase deals with issues that have been raised after the delivery: enhancing the software, optimising it and remedying its defects.

Software development approaches

Waterfall vs. Agile approaches

We have not yet said anything about how these phases are linked. Different approaches are possible, but the more common ones are known as the waterfall approach and the iterative (or agile) approach.

  • Waterfall approaches emphasise a deep understanding of the system that is going to be developed and a strong attention to planning. Before ‘going down’ and implementing the system, the higher levels need to be sufficiently delineated.
  • Iterative (or agile) approaches imply an emphasis on starting the coding early and going through a progressive process in which additional components are planned, coded, designed and tested.

Waterfall approaches

Waterfall software development approaches

Agile approaches

Agile software development approaches

Agile approaches - cont'd

At first, the structure of the system is definitively at a high level, and then components are iteratively developed and refined. Iterations are typically short, with 1 to 4 weeks for a complete cycle.

This has the advantage of allowing testing at an early stage but may also imply that the structure of the system will be defined only in later stages.

In the following slides we will review two common agile software development methodologies: Extreme Programming and Scrum.

Extreme Programming

Extreme Programming

Extreme Programming (XP) is an agile software engineering methodology. Extreme Programming was developed in the early 1990s, by Kent Beck, Ward Cunningham and Ron Jeffries, as a way to escape from the disadvantages of the waterfall model.

XP advocates:

  • Frequent "releases" in short development cycles
  • Programming in pairs and, in general, extensive code review
  • Face to face interaction among programmers
  • Unit testing of all code
  • Avoiding programming of features until they are actually needed
  • A flat(ter) management structure
  • Expecting non-fixated requirements
  • Frequent contact with the customer

XP in practice

A set of twelve rules, grouped in four categories (fine scale feedback, continuous process, shared understanding, programmer welfare), are at the base of XP.

Fine scale feedback

Rule

Description

Pair Programming

Developers should work in couples, a driver (who types) and a navigator (who thinks). This typically leads to a better code, because there are two sets of eyes watching the code, while improving team cohesion and moral. The two developers should switch roles, at the very least once per day.

Planning Game

Includes release planning (initial and rough plan) and iteration planning (what to do next). There is no detailed, long-term plan in XP, and the planning game requires the involvement of the customer.

Test Driven Development

Define the tests before you start the implementation.

Whole team

Everyone responsible for the project should sit together regularly, including a representative for the customer.

Implementing fine scale feedback

Rule

Implementation in a Web project

Pair Programming

You need two persons working at the same computer at the same time. You shouldn't pair a Web designer with a Web developer, for example, unless they can work in both roles.

Planning Game

You can try a lighter version of the planning game by asking your customer to prioritise the stories that you develop.

Test Driven Development

Web application testing can be quite different from other types of testing. In most cases, the developers will have to define testing procedures (e.g. passing the W3C validation and passing a usability test).

Whole team

Involve the customer in all the phases, to make sure that he or she is comfortable with your choices. Instead of showing seven different designs to the customer, define it together.

Continuous process

Rule

Description

Continuous Integration

The developed components need to be continuously integrated.

Design Improvement

Improve step-by-step. You can improve the design after every iteration, when new components are integrated and built.

Small Releases

Release early, release often.

Implementing continuous process

Rule

Implementation in a Web project

Continuous Integration

Your web application should always be ready for demo.

You shouldn’t have any non-included graphics, or orphaned pages waiting to be linked.

Design Improvement

The website is continuously refined when new components are available and integrated.

Small Releases

The website needs to be in a navigable form at the end of every iteration.

Shared understanding

Rule

Description

Coding Standards

Ensures that everyone can understand immediately the different parts of the project, and can immediately integrate new code.

Collective Code Ownership

Everybody is allowed to change everything in the project.

Simple Design

The design should be as simple as possible.

System Metaphor

Use an organising metaphor, a ‘shared story’ of how the system works.

Implementing shared understanding

Rule

Implementation in a Web project

Coding Standards

Use a consistent style for coding and design. If you write your JavaScript, HTML or PHP without spaces and tabulations (or inconsistent spaces and tabulations), it will be harder to modify for others.

Collective Code Ownership

Independently of the role in the project, everyone (Web developer, Web designer, project manager, etc.) can change anything in the implementation.

Simple Design

Don’t write unnecessarily complex code. Complexity is not given by length: allow more lines of code when it increases its understandability.

System Metaphor

Use a metaphor to describe your Web application. If it’s an e-commerce website, compare it to a shop. If it’s an online magazine, compare it to a newspaper. Find some metaphor for every project.

Programmer welfare

Rule

Description

Sustainable Pace

Programmers should not be over-stressed.

This applies to every component of the development team. How do you do it?

What are the "stories"?

User stories are one or more short sentences in the everyday or business language of the end user of a system that capture what a user does or needs to do as part of his or her job function" (Wikipedia, 2013). User stories are used in agyle software development "as the basis for defining the functions a business system must provide, and to facilitate requirements management".

They are normally written using the formula:

As an X I would like to do Y so that I can Z.

Example:

“As a student, I would like to find my timetable so that I can attend my lessons”

Scrum

Scrum

Scrum is another agile software development methodology, focusing on continuous and incremental innovation.

As XP, it relies on self-organizing, cross-functional team with no leader.

In the next slides we are going to cover its main aspects and peculiarities: core roles, sprints, meetings and artifacts.

Roles

Scrum teams are based on three core roles:

  • Product Owner: Represents the stakeholder and is the voice of the customer
  • Development Team:Includes the persons responsible for delivering features as part of a incrementally developed project.
  • Scrum Master: The Scrum Master enforces of the rules of Scrum, often chairs key meetings, and challenges the team to improve. It's not a Project Manager and does not have line management responsibilities.

Sprint

A sprint is an iteration with a fixed duration. Each sprint is preceded by a planning meeting and is the basic unit of development in Scrum.

Meetings

  • Daily scrums: starts on time; standup meeting of max 15 minutes
  • Scrum of scrums: daily cross-team meetings, to ensure co-ordination between different teams
  • Sprint planning meeting: to select what will be done in a sprint; prepare the Sprint Backlog; identify how much work will be done in the sprint; eight-hour time limit
  • Sprint review meeting and Sprint retrospective meeting: to review the work, present it to the customer (Sprint review) and reflect on the sprint just finished (Sprint retrospective)

Artifacts

  • Product backlog: it's an ordered list of requirements, including business value (determined by the product owner) and estimated effort (determined by the development team). It's normally written in story format.
  • Sprint backlog: it's the list of features to be implemented in a Sprint.

How do I implement this?

Most companies and developers typically don't follow any approach "word by word" but implement their own version - which can have elements of different approaches.

Readings

Complement this week's lecture with further research and readings on the topics covered.

These are some pointers to start:

Pham, A., Pham, Phuong-Van (2012). Scrum in Action: Agile Software Project Management and Development.
Wallace, D., Ragget, I. and Aufgang, J. (2002) Extreme Programming for the Web.
Wells, D. (2009). Extreme Programming: A gentle introduction. Available from http://www.extremeprogramming.org/
Wikipedia (2013). Extreme Programming. Available from http://en.wikipedia.org/wiki/Extreme_programming
Wikipedia (2013). User story. Available from http://en.wikipedia.org/wiki/User_story
Wikipedia (2013). Scrum. Available from http://en.wikipedia.org/wiki/Scrum_(software_development)

This work

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License

Creative Commons License