Based on more than 100 actual commercial projects, this book clearly explains how to run an agile software development project that delivers high–quality, high–value solutions to business clients. It concentrates on the practical, social, business, and management aspects as well as the technical issues involved.
Professor Holcombe successfully connects readers with the wave of "Agile 2.0" concepts that take the techniques of agile development and place them in the service of business goals. Since it is widely believed that the use of Windows XP will become much more common in coming years, readers should be armed with cutting–edge knowledge of the latest practices in the field. Further features of the book include:
Case studies provide real–world examples and describe how XP was introduced into the environment
Analysis is provided to help readers determine which elements of XP are suitable for the unique challenges and environments for different projects
Problems of a failing agile project and how they can be fixed are covered, including insight into which managerial techniques can be employed
An Instructor′s Guide provides practical advice on how to motivate students, organize real group projects, and deal, in a simple and effective way, with many of the problems that arise
A sample syllabus, sample tests, and additional case study information are available on an instructor′s password–protected ftp site
Running an Agile Software Development Project is an indispensable guide for professional software developers, engineers, and project managers interested in learning how to use agile processes. It is also a valuable textbook for advanced undergraduate– and graduate–level students in computer engineering and software engineering courses.
Chapter 1: What is an agile methodology?
1.1 Rapid business change – the ultimate driver.
1.2 What must agile methodologies be able to do?
1.3 Agility – what is it and how do we achieve it?
1.4 Evolving software – obstacles and possibilities.
1.5 The quality agenda.
1.6 Do we really need all this mountain of documentation?
1.7 The human factor.
1.8 Some Agile Methodologies.
1.8.1 Dynamic Systems Development Method (DSDM).
1.8.2 Feature Driven Design (FDD).
1.8.4 Agile modeling.
1.8.6 Summary table.
Chapter 2: Extreme Programming Outlined.
2.1 Some guiding principles.
2.2 The five values.
2.3 The twelve basic practices of XP.
2.3.1 Test first programming.
2.3.2 Pair programming.
2.3.3 On–site customer.
2.3.4 The planning game.
2.3.5 System metaphor.
2.3.6 Small, frequent releases.
2.3.7 Always use the SIMPLEST solution that adds business value.
2.3.8 Continuous integration.
2.3.9 Coding standards.
2.3.10 Collective code ownership.
2.3.12 Forty hour week.
2.5 The evidence for XP.
2.5.1 Evidence for Test First.
2.5.2 Evidence for pair programming.
2.5.3 Evidence for XP.
2.6 Preparing to XP.
Chapter 3: Foundations – people and teams working together.
3.1 Software engineering in teams.
3.2 Personalities and team success.
3.3 Observations of team behaviour in XP projects.
3.4 Setting up a team.
3.5 Developing team skills.
3.6 Training together.
3.7 Finding and keeping a client for a university based project or a small business start up.
3.8 The organisational framework.
3.9.1 PERT (Programme Evaluation and Review Technique).
3.9.2 Gantt Charts.
3.10 Dealing with problems.
3.10.1 Basic strategies.
3.10.2 When things go really wrong.
3.11 Risk analysis.
Chapter 4: Starting an XP project.
4.1 Project beginnings.
4.1.1 Researching the business background.
4.1.2 Exploring the outline system description.
4.2 The first meetings with the client.
4.3 Business analysis and problem discovery.
4.4 The initial stages of building a requirements document.
4.5 Techniques for requirements elicitation.
4.6 Putting your knowledge together.
4.7 Getting technical.
4.8 Developing the requirements documents.
4.9 Specifying and measuring the quality attributes of the system.
4.10 The formal requirements document and system metaphor.
4.11 Contract negotiation.
4.12 Case study – the impact of organisational politics – learning from a failed project.
Chapter 5: Identifying stories and preparing to build.
5.1 Looking at the user stories.
5.2 Collections of stories.
5.2.2 Stamps system.
5.2.3 DELTAH (Developing European Leadership Through Action–learning in Healthcare).
5.3 User interfaces.
5.4 Communicating clearly with the customer and building confidence.
5.5 Demonstrating the non–functional requirements.
5.6 Estimating resources.
Chapter 6: Bringing the system together as a coherent concept.
6.1 What is the problem?
6.2 A simple common metaphor.
6.3 Architectures and patterns.
6.4 Finite state machines.
6.5 Extreme modelling (XM).
6.6 Multiple stories and XXMs.
6.7 Building the architecture to suit the application – a dynamic system metaphor.
6.8 Another look at estimation.
Chapter 7: Designing the system tests.
7.1 Preparing to build functional test sets.
7.1.1 Tests and testing.
7.1.2 Testing from a model.
7.1.3 Developing the model.
7.2 Testing with the Data in mind.
7.3 The full functional system testing strategy.
7.4 The thinking behind the system test process.
7.5 Design for test.
7.6 Test documentation.
7.7 Non–functional testing.
7.8 Testing internet applications and web sites.
Chapter 8: Units and their tests.
8.1 Basic considerations.
8.2 Identifying the units.
8.3 Unit testing.
8.4 More complex units.
8.5 Automating unit tests.
8.5.1 Writing Unit Tests in JUnit.
8.6 Documenting unit test results.
Chapter 9: Evolving the system.
9.1 Requirements change.
9.2 Changes to basic business model and functionality.
9.3 Dealing with change – refining stories.
9.3.1 Changes to the underlying data model.
9.3.2 Changes to the structure of the interface, perhaps the introduction of a new.
9.3.3 Adding a new function.
9.3.4 Changing the functionality of a function.
9.4 Changing the model.
9.4.1 Changing a process.
9.4.2 Removing states.
9.4.3 Adding states.
9.4.4. Adding a complete machine.
9.4.5 Adding processes.
9.5 Testing for changed requirements.
9.6 Refactoring the code.
9.7 Estimating the cost of change.
Chapter 10: Documenting and delivering the system.
10.1 What is documentation for and who is going to use it?
10.2 Coding standards and documents for programmers.
10.3 Coding standards for Java.
10.4 Maintenance documentation.
10.5 User manuals.
10.6 Version control.
10.6.1 The project archive.
10.6.2 Naming conventions.
10.7 Delivery and finalisation.
Chapter 11: Reflecting on the process.
11.1 Skills and lessons learnt.
11.2 The XP experience.
11.3 Personal and Team Assessment.
11.5 Conundrums – discussion.
Chapter 12: Lifestyle matters.
12.1 Keeping fit.
12.1.1 Correct sitting position.
12.1.2 Combating RSI.
12.2 General well–being.
12.3 Mental preparation.
12.4.1 Diet and Brain function.
12.4.2 Summary of dietary information.
12.5 Music and work.
12.6 Conclusions and summary.