COMP33711: Agile Software Engineering
Weekly lesson plan
Week 1: The Agile Lego Game - an Introduction to Agile Software Engineering
In this introductory session, you will get the chance to work as part of an agile team, developing a new product for a customer in just 2 hours: using lego. We'll experience the major stages of agile development plus some of the key practices, to give you a flavour of how these unconventional methods work together to meet customer goals on a predictable schedule.
Week 2: The Trouble with Big Up-Front Requirements Gathering
We explore the problems with attempting to gather all requirements at the start of a project, as well as the limitations of relying on written requirements specifications. The agile solution? Don't try to gather all requirements up front, and certainly don't bother to write them all down. But can this approach possibly work? And why isn't it just hacking? In this and the following session, we present some (sometimes surprising) answers to these questions.
Week 3: How Do We Know What to Build?
We explore agile's lightweight approach to requirements gathering using user stories, focussing on that most important of questions for agile requirements gathering: what will the customer get out of this? We also demonstrate the latest in requirements gathering gadgets: it's cheap, effective and fits in your pocket. You'll get to try it out for yourself in a team-based activity.
Week 4: What Can We Promise to Deliver (and When)?
Estimating how long it will take to implement a complex piece of functionality is a brain-curdlingly difficult thing to do, even for experienced software engineers. It's common for estimates to be 2-3 times lower than the actual time required for implementation, resulting in news headlines of late delivery and massive budget overruns. But if estimating software task durations is difficult, time-consuming and usually gives the wrong answer, why bother to do it at all? We look at how agile approaches to estimation avoid assigning durations to user stories, but still manage to produce expected dates for delivery. It's a classic piece of agile magic, involving the wisdom of crowds, Nebulous Units of Time and a poker table. You'll get to try your hand at it, during the session.
Week 5: How Do We Know What to Build Next?
In many software development organisations, it can seem as if the programmers are the least important of the software production process. What they do, when they do it, and how they get the information they need is all controlled by managers, managers of managers, and so on. The agile approach turns this idea on its head. If the thing the customer really needs is some working reliable code, then programmers---the people who actually create it---are the most important links in the chain. In this session, we'll look at how agile planning techniques allow self-organising teams to make good decisions about how to use their time to produce the best value for the customer on a reliable schedule, without getting locked into an out-dated and unhelpful plan. And the tool we use to achieve this? Answer: an office wall. We'll try out some agile planning techniques during the session, through a series of team-based exercises. (Walls provided at no additional expense.)
Week 6: Reading Week
There is no formal teaching this week.
Week 7: How Do We Know When We're Done?
In traditional development approaches, testing is seen as an expensive luxury, tacked on to the end of the project, and often the first task to be squeezed out when development runs late (and it almost always runs late...) We'll use a room full of balloons to explore the problems with this approach, as the starting point for a five week examination of the agile viewpoint on the critical topic of testing. If doing testing at the end of the project is too late, we ask, what are the alternatives? The answers may surprise you. We'll try our hands at one technique (paper prototyping) and take the first steps towards getting ourselves test-infected.
Week 8: How Do We Build the Right Product?
In this session, we (finally) supply the last piece of the agile requirements gathering jigsaw and show how detailed specification information is captured and used in an agile project. By using specification-by-example techniques, we can create a specification containing far more detail and precision than any UML specification, that can warn us automatically when the implementation deviates from it. Best of all, these specifications are not only readable by customers - with just a little initial help, customers can actually write them themselves.
You'll get to write your own specification using these techniques, based on a snakey problem that you may find strangely familiar from your 1st year Java labs.
Week 9: How Do We Know When We're (Done) Done? (sic)
In this, the first of our lab-based sessions, we'll be working some agile magic to transform the business of acceptance testing from a tedious contractual obligation into an executable requirements specification, a ubiquitous language for communication between customers and developers, a key design tool and defence against bloat, a safety net against change and an objective, no-nonsense progress indicator for your team.
You'll use pair programming techniques to turn the paper specifications we created in the previous session into "living documentation", in the form of automated acceptance tests. We'll use the FitNesse tool, but focus on covering the key concepts that will allow you to get started quickly with any ATDD or BDD tool.
Week 10: How Do We Build The Product Right?
In this lab-based session, we learn a key technique for building high-quality, agile code that sticks precisely to our specification: namely, test-driven development (TDD). In TDD, we write tests before we write the code that gets tested. Sounds impossible? Using pair-programming, we'll work through a series of exercises, each adding an additional component of the TDD toolkit, until, by the end of the session, you'll be applying the full TDD approach.
TDD: over-hyped waste of time or the most revolutionary approach to the way we code since structured programming? You decide.
Warning: this session may seriously change your brain!
Week 11: Software Design Without A Crystal Ball?
In this lab-based session, we develop and extend our TDD skills to the development of a complete system increment, starting from the automated acceptance tests that specify it. We see how Acceptance-Test-Driven Development (ATDD) techniques can guide us through an evolutionary design process towards a clean, lean implementation that is not locked down by our early (often incorrect) design decisions. We look at outside-in and middle-out approaches, as well as looking ahead to some of the pitfalls of this approach when applied to real-scale projects.
Week 12: Agile in a Nutshell
We end the semester with a team-based challenge that asks you to bring together all the key ideas and practices we have covered throughout the course unit. Can you and your team deliver some new functionality of real value for the project we have been working on in just 2 hours?