Enrolment on this course unit is limited to 100 students.
COMP33711 Agile Software Engineering syllabus 2017-2018
In 2001, a group of influential and experienced software developers met in the mountains of Utah to discuss was going wrong in software development and how things could be done differently. Together, they produced the Agile Manifesto, a concise summary of the key values they agreed should underpin successful software development. In essence, these values state that: we should value the people involved and their interactions more than the processes and tools used; we should focus on the delivery of working code over the production of comprehensive documentation; we should strive for effective collaboration with the customer rather than wrangling over contract details; and we should aim to respond sensibly to change rather than sticking rigidly to our original plan, which may no longer be appropriate.
Much conventional software engineering is based around a key idea from manufacturing: namely, the notion that the quality of a product depends on the quality of the process that creates it. According to this way of thinking, if we aren't developing good software products then we need to have a better process with which to develop them. Unfortunately, as the proponents of agile methods point out, rather than better processes, we often ended up only with bigger processes, requiring an ever increasing set of deliverables to be produced: feasibility studies, statements of project scope, project plans, requirements specifications, risk assessment plans, interview reports, contracts, architecture designs, detailed designs, test strategy documents, test plans, change requests, etc., etc. But in the end, say the agile proponents, the only deliverable that matters is the delivered code. Why are we diverting so much effort and energy to these other deliverables, at the expense of the one that really matters?
The Agile Manifesto, and the work on lightweight software development approaches that preceded it, led to the design of several new software development methods, all coming under the title of "agile methodologies". These approaches seek to focus the efforts of the project team on the activities that lead directly to the delivery of genuinely useful software for the customer. They give a key role to the customer in achieving this value, and suggest radical ways in which customers and developers should interact. They reduce (or abolish) the role of middle managers, and put decision making power back in the hands of the development team, to reduce delays in information flow and to increase the quality of communication between the customer and developers. They use cheap and cheerful approaches to heavyweight tasks such as requirements gathering, emphasising the need to be flexible, and to embrace change as an inevitable necessity rather than something to be feared and resisted.
Initially heavily criticised, many agile practices are now becoming the accepted way of working in the software industry. The number of organisations claiming to be wholly or partly agile is fast increasing, and an awareness of agile approaches (their limitations as well as their strengths) is invaluable for anyone contemplating a career as a software engineer.
The aim of this course unit is to introduce you to the basic values and principles behind agile software engineering, and to give you an understanding of how the key agile practices work together to deliver real value to customers in a predictable and controllable way. We'll look at some of the problems with the conventional "plan-based" approach to software development, and examine how agile methods attempt to do better.
Rather than being lectured at, you'll take part in industry-standard coaching games, plus team-based exercises, group discussions and hands-on demonstrations that let you experience the agile approach at work and make up your own mind about the strengths and limitations of the ideas being presented.
- Week 1: The Agile Lego Game - an Introduction to Agile Software Engineering
- Week 2: The Trouble with Big Up-Front Requirements Gathering
- Week 3: How Do We Know What to Build?
- Week 4: What Can We Promise to Deliver (and When)?
- Week 5: How Do We Know What to Build Next?
- Week 7: How Do We Know When We're Done?
- Week 8: How Do We Build the Right Product?
- Week 9: How Do We Know When We're (Done) Done? (sic)
- Week 10: How Do We Build The Product Right?
- Week 11: Software Design Without A Crystal Ball?
- Week 12: Agile in a Nutshell
For a detailed description of each weeks' activities please see COMP33711's weekly lesson plan.
One two-hour session per week
Feedback methodsDuring lectures, many team and whole group activities are undertaken, with feedback being given face-to-face during the activities and in the whole-group debrief sessions afterwards.
A series of self-tests are available for students to try after lectures, with detailed feedback being provided by the automatic marking system.
Feedback can be obtained on interim versions of coursework at any of the (optional) clinic sessions. Written comments will be provided on returned marked coursework, with pointers towards aspects of the work that the student did well and suggestions for areas where further study might be required.
- Assessment written exam (2 hours)
- Lectures (22 hours)
- Practical classes & workshops (22 hours)
- Group/team working
- Project management
- Oral communication
- Problem solving
- Written communication
|Programme outcome||Unit learning outcomes||Assessment|
|A2 A7||Students should be able to explain the problems with conventional, "plan-based" approaches to software engineering, specifically the "Big Up-Front" approaches to software requirements gathering and specification, software project planning and software design. (Comprehension Level)|
|A2 A6 B3||Students should be able to explain the motivation behind the four agile values and the twelve agile principles, and give examples of how they might apply in a given scenario to solve a perceived development problem. (Comprehension Level, Application Level)|
|A2 B1 D9||Students should be able to write user stories to capture user requirements and their associated business values, and to successively refine them until they describe a unit of functionality that can be implemented within a single (short) iteration. (Synthesis Level)|
|A2 A4 B1 D3 D9||Students should be able to create release and iteration plans given a collection of stories with relative business values and size estimates, based on an evaluation of their technical risk and the learning opportunities they present. (Synthesis Level, Evaluation Level)|
|A2 B1 D9||Students should be able to apply agile estimation techniques to software development tasks, and to use these estimates in release and iteration planning. (Application Level)|
|A2 A4 A7 D3 D9 D10||Students should be able to set up and use a task board to capture the status of a software project, to track changes as they occur and to support decision making in a self-organising team (Application Level)|
|A2 B1 B2 C5 D3 D9 D10||Students should be able to use specification-by-example techniqes to create a specification for a set of user stories in the form of executable acceptance tests. (Synthesis Level)|
|A7 D3 D9 D10||Students should be able to use automated acceptance, integration and unit tests to drive the design of a software system in an evolutionary/emergent manner, using the principles of Acceptance Test Driven Design (ATDD) and Unit Test Driven Design (TDD). (Synthesis Level, Analysis Level)|
|A7 D3 D9 D10||Students should be able to pair programme following the core guidelines for pairing, and to apply variants such as ping-pong pairing. (Application Level)|
|A2 A4 B3 D3 D9||Students should be able to use agile retrospective techniques to detect and diagnose problems in their team process, and to suggest steps that could be taken to improve the overall team performance. (Analysis Level, Synthesis Level)|
|A6 C7||Students should be able to explain how formal contracts/funding models for agile projects differ from contracts/funding models from more traditional projects.|
|User stories applied: for agile software development||Cohn, Mike||9780321205681||Addison Wesley||2004||✖|
|Growing Object-Oriented software, guided by tests||Freeman, Steve and Nat Pryce||0321503627||Addison Wesley||2009||✖|
|Test driven: practical TDD and acceptance TDD for Java developers||Koskela, Lasse||9781932394856||Manning||2008||✖|
|Art of agile development||Shore, James and Shane Warden||9780596527679||O'Reilly Media||2007||✖|
|User story mapping: discover the whole story, build the right product||Patton, Jeff and Peter Economy||9781491904909||O'Reilly||2014||✖|
|Agile estimating and planning||Cohn, Mike||0131479415||Prentice Hall||2005||✖|
|Integrating agile development in the real world||Schuh, Peter||9781584503644||Charles River Media||2004||✖|
|Test-driven development by example||Beck, Kent||9780321146533||Addison Wesley Signature Series||2002||✖|
|Lean software development: an agile toolkit||Poppendieck, Mary and Tom Poppendieck||9780321150783||Addison Wesley||2003||✖|
Course unit materials
Links to course unit teaching materials can be found on the School of Computer Science website for current students.