COMP33711 Agile Software Engineering syllabus 2019-2020
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
On successful completion of this unit, a student will be able to:
- Compare and contrast the pros and cons of conventional Big Up-Front approaches to software development with those of the new iterative/agile approaches.
- Explain the meaning of the 4 agile values and 12 agile principles, and use them to diagnose and correct problems in a variety of software engineering scenarios.
- Write user stories to capture user requirements and associated business values, and refine stories to varying levels of granularity for use in project planning.
- Create and implement release and iteration plans given a collection of user stories, by applying a range of agile project planning and tracking practices.
- Explain the role and purpose of task boards in managing self-organising agile teams, and design task board structures suitable for use in particular contexts.
- Use specification-by-example practices to create living documentation for a software system, and use it to guide the design and implementation of the system using Acceptance Test Driven Design (ATDD) and Unit Test Driven Design (TDD) practices.
- Explain the role of feedback in the management of agile projects and apply feedback oriented practices, such as retrospectives, to identify and correct problems in team processes.
- Explain how formal contracts and funding models for agile projects differ from contracts/funding models used on more traditional projects.
|Art of agile development||Shore, James and Shane Warden||9780596527679||O'Reilly Media||2007||✖|
|Test driven: practical TDD and acceptance TDD for Java developers||Koskela, Lasse||9781932394856||Manning||2008||✖|
|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||✖|
|Agile estimating and planning||Cohn, Mike||0131479415||Prentice Hall||2005||✖|
|User story mapping: discover the whole story, build the right product||Patton, Jeff and Peter Economy||9781491904909||O'Reilly||2014||✖|
|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.