The VCS prep course in Engineering (3rd part) does an excellent job in helping to understand this topic. The whole story behind it is fascinating; I will try to make here only important highlights.
Starting from 50’s, for decades, designing computer software was a daunting task. The enormous complexity of successful code creation, processes prone to human errors, expensive and time-consuming bug fixing discovered very late, the high variability of projects. Specialists tried to find a solution to these. This situation was named as software crisis. They even sought to copy practices used for decades by civil engineers and apply them in software programming. It occurred soon that software engineering is an entirely different type of engineering whatsoever. Although both of them share same two phases: design and build part, in the software world, building part is done by machines, or so-called compilers…. in civil engineering – by people.
One of the first attempts to sort out this messy process was to apply project management methodology. Around 1970 Winston W. Royce proposed an idea of stages in making the software: checking what’s required, designing architecture and solutions, coding, testing installation, and maintenance. It was named waterfall.
It became so popular that governmental and commercial bodies started implementing it at a fast rate. Soon it became apparent that in many cases the odds are too big in using this technique. The process was very expensive, time-consuming (building software was taking more than a year), prone to have too many features which were never used by customers. It was very useful in big projects not focusing on customers i.e. space software or where the mistake would cause even death – health care sector.
Customers had a limited budget and wanted software built quickly so it will keep up with ie. changes in consumers behaviour. In 2001 groupd of software engineers piblished Agile Manifesto emphasizing value of:
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
Altough the right side – proceses – is very important, it is the left side – people – which is crucial for successfull outcome. Here, clients get exactly what they want, programmers see results of their work much quicker which boosts motivation and creativity, there is emphasizes on dividing tasks into small managable pieces, through collboration code is reviewed frequntly and bugs are removed in the early stage. In cases where requirements are not strictly set and demanded, Agile answered the call resounding for 40 years.
Here we come to XP which stands for eXtreme Programming – Agile implementation in coding practices and Scrum – which is Agile implementation in project management.
Some of the most popularized XP recommendations are:
- Continuous Integration (which is frequent merging branch of code with the main code),
- Pair Programming – so at least two programmers work on the same piece of code, reviewing each other’s work,
- Time measuring techniques needed for production,
- Frequent interactions with final user.
Scrum, fantastic concept of implementing synergy among people and their skills. Everything starts from user stories and individuals involved. Let’s think about designing a movie website as a simple example. We need people like designers, developers. Scrum Master is chosen and he will be responsible for workflow of the team making sure they have everything they require. The requestor and qudience have their needs in terms of what this website should be about, what they like in movie websites and find entartaining, what they like about the movie, etc – these are the user stories. Once this list is created, it becomes a product backlog and all of the user stories are divided into managable pieces with assigned time estimation for finishing (ie. designning interface – 8 hours). Backlog is organized into sprint backlogs (each taking form 2 days to 30 days).
Let’s say that very simple working website is done within 5 days. The retrospective meeting that follows it, is held between users, Scrum team, the requestor. Product is tried and any new requierements or changes are raised.The second spint starts after during which final imprved website is done and if all stakeholders are happy, it goes live. During the whole process Scrum team met everyday. These meetings were help with everyone standing! – so it would be as short as possible. Everyone speaks of work done the day before, work planned for the current day and any potential problems happening.
Is the duration of the project entirely based on estimation? Well, no. Each user story holds estimate duration, but the team working on them regularly update time remaining to completion. This apparently means the project can be finished earlier, but more frequently it happens later. In teh chart below we see how everyday bars are getting shorter – just like clepsydre. The amount of sand left is moved to the next day and shrinks again… in the case of any obstacles time is added, but this would mean either bad project management or unforseen obstacles and growing unsatisfaction of the requestor.
Source: The Agile Warrior
I’m going back to studying this subject. I still want to understand more. Please feel free to add any objections, which I would greatly welcome.
Till next post!