1.2.D. Software Process Models - Agile

1.2.d. Software Process Models - Agile

Agile Methods

• Agile refers to a collection of software development models.
• It came up after years and years after developing using the traditional models, and addressing many of the drawbacks with other models such as waterfall.
• Traditional models are relatively rigid, and software development needs to be able to address change. While they can be effective in particular scenarios, there is a whole rango of scenarios where an agile approach would be more beneficial.
• 'Agile' comes from the idea that the actual product will be created quickly and high quality, giving the client value as soon as possible rather than going through a rigid process that takes a long time before delivering anything.
• It has an emphasis on flexibility in producing software quickly and capably.
• All agile metholodogies adhere to particular principles, regardless of their differences.

Agile Manifesto

• It talks about individuals in the interactions being more important than processes and tools, although doesn't aim to exclude them altogether.
• It doesn't exclude organisation, requirements gathering or organisations, but gives more value to individual interactions, producing working software, having a deep customer collaboration and being able to respond to change.
• The misconception with agile is that there are no rules, you just 'code', which is not really the case as there are a number of rules as opposed to a random process. There still needs to be some process or plan.
• Therefore, agile:
  • Values individuals and interactions over process and tools
  • Prefers to invest time in producing working software rather than in producing comprehensive documentation
  • Focusing on customer collaboration rather than contract negotiation
  • Concentrating on responding to change, as opposed to creating a plan and strictly following it

Examples of Agile Process

• Extreme processing (XP)
• Crystal: a collection of approaches based on the notion that every project needs a unique set of policies and conventions
• Scrum: fixed duration iterations (2 or 4 weeks); multiple self-organising teams; daily coordination

Extreme Programming (XP)

• Emphasis on four characteristics of agility:
  • Communication
  • Simplicity
  • Courage
  • Feedback

Twelve Facets of XP

The planning game (customer defines value)

• Customer identifies the value of particular elements of a piece of software, rather than just an understanding of the product as a whole.

Small release

We try to deliver as quickly as possible, focusing on that by breaking the software into small parts, so that value is provided to the customer as often as possible.

Metaphor (common vision, common names)

• Providing a common vision for the product between all the team members, using common names and ensuring everyone is 'speaking the same language'.

Simple design

• We not only have a simplicity of process, but the design itself should be simple as possible. Compared to traditional models like waterfall that have big blueprints, the aim is to try to follow simple designs so we can move more quickly into developing these smaller releases.

Writing tests first

• For example, writing the tests even before the code is started, ensuring the code is as high-quality as it can be.

Refactoring

• Improving the code without changing the functionality.
• Sometimes we create code that solves a particular problem but it may not be the best code, it could have been too confusing or rigid, refactoring provides the opportunity of looking at code that either you or colleagues have written, and changing it to help improve the structure.
  • For example, breaking a method in several to simplify understanding.

Pair programming

• By pairing programmers together to address a particular part of software development, it brings many advantages.
  • Quality, one person is checking what the other person is doing, meaning it is less likely for people to make mistakes, reducing times in debugging and bug-fixing.
  • Ideas, as ideas can be very easily exchanged with someone else.
• This overall collaboration improves the overall output.

Collective ownership

• The whole team owns the whole project. While people may specialise to some extent, but they should have an overall view, and be able to participate in the project fully and work in every element of the software at a given point.

Continuous integration (small increments)

• Small changes are integrated into the product which then facilitates future deployment.

Sustainable pace (40 hours/week)

• To avoid people from being burned out, we create a good base but a sustainable one.

On-site customer

• By having the customer on-site and meeting the team, we are involving them in the process, they can very quickly answer questions, clear up and doubts, check in on development and check out the prototypes, including giving quick feedback.

Coding standards

• If things are not consistent, it is very hard for Person A to change the code of Person B, so there needs to be some standards and some standards of quality.