Agile vs. Architecture

So far, we haven't spent a lot of time to talk about our development process. We have spent most effort into:

In the second part of the course, we will also learn how to describe:

When we talk about development process we mean how we should organize our work around these documents: When to create which document, how they depend on each other, and how to organize our team around these. Initially, we could follow this scheme:

An idealized method that connects the requirements to the final system given in code.  

We start by analyzing the user requirements, and develop the use cases based on them. Then, we look at the necessary system components and interactions between them. Once the interactions look okay, we develop the detailed state machines for the individual components, and then implement the state machines in code. The above model is also called "Waterfall Model", because the different stages follow each other.

But this is not how real projects work! In reality, the following will happen:

Have a look into the following presentation: (The part about the Waterfall model starts at 8:45, and lasts a few minutes. The details of the video are not part of the RAT.)

 

We can look at the waterfall model as one side in a spectrum of methods:

**The spectrum of development methods:** Aligned on an axis that goes from a waterfall model with lots of planning on the left towards pure hacking without planning to the right.  

This image is based on one from an article called "Get Ready for Agile Methods, With Care." To the left are methods that require a lot of planning, like waterfall. To the right, we have methods that require less (or no) planning, like just plain "hacking." Somewhere in between, we have methods such as milestone-driven approaches, extreme programming, and agile methods. Those last ones have received a lot of attention in industry, and it is very likely that you will work with an agile method in the future.

To popularize agile development, some engineers gathered and prepared the Agile Manifesto. This document explains some of the principles. It is short to read, and most developers have at some point heard about it.

A word of caution: There are a lot of people that have very strong opinions about development methods. This is understandable, since development methods can have a lot of influence on a project's success, but touch on complex issues and are often discussed based on anecdotes and in general a bit "fluffy". What is important in the course in the following is that you develop an understanding for the different forces between the need for planning and the ability to adapt to changes. For a project to be successful, you will need both planning and agility. In fact, all agile methods include some amount of planning. So it is important that you look at the arguments, observe, make your own conclusions and don't stop thinking. (Which is probably a generally good advice for many things in life.)

Mandatory Preparation

One popular agile method is Scrum. It is very likely that you will be invited to a course in Scrum when you start working. As part of the preparation, you should read through the Scrum Guide:

Optional Material

The guide above may be a bit dry to read, but contains all the essential information about SCRUM. I hence recommend that you find some more videos or other material that help you to get a more vivid picture and some illustrations, and watch them in addition to reading the guide. I'll leave the choice of videos to yourself, but give you two as a starting point below. Also, if you find one that you like, tell me and the others on MS Teams!

Video: Scrum in under 5 minutes

Video: Explaining Agile - Martin Fowler and Neil Ford at USI