Workshop: Best Practices for Finding your way into new Projects - quickly...

Marina Haase, Independent
We all know the situation: We are new in an IT-Project - there is very little documentation, and very few people to help us get into the project. I'm implying that most of us don't just arrive in a project - and "hey, presto!" by magic understand the project, are integrated in the team and start being productive.

I'm sure over the years many of you have collected best practices that you repeat when arriving in new project contexts… and I have started analysing what I do - what doesn't work and what does… and probably will work next time too! The goal of this workshop is to collect proven best practices for getting into projects and start being productive quickly.

We will spend the first few minutes introducing our best practices. Then we will spend a few moments thinking and brainstorming about the problems that occur when starting out in projects. We will then try and associate the problems to the collected best practices or other ideas of best practices. After this we will divide into groups and brainstorm about forces and consequences of using the best practices.

Workshop: Getting To 'No'

John Nolan + Paul Dyson, e2x Ltd
How often have you found yourself on a project where saying 'no' sooner would have saved a lot of time/money/stress ? Where, at the time, your gut feel was 'no' but for some reason you didn't speak up?

In our experience saying 'no' constructively is at the heart of good projects and good project teams. This session contains a small amount of presentation on the subject of saying 'no' (an iconoclastic view of 'Getting to Yes') and some personal examples but mainly is a structured/guided session to elicit thoughts and information from the attendees.

The objective is to have the attendees create a collaborative analysis of what circumstances produce contexts where 'no' is difficult to say, and techniques for avoiding those circumstances or addressing them constructively when they occur.

Tutorial: Awesome Acceptance Testing

Joe Walnes, Google + Dan North, ThoughtWorks
Acceptance tests are a lot more than traditional regression tests. They help to provide a shared understanding of what the system should do and when requirements are considered done.

They are written in a way that describes intent by example, and can be created before the implementation, helping:

• Project owners clarify vague requirements.
• Developers understand and implement these.
• Everyone focus on what 'done' means.

This session covers:

• The value of acceptance tests and how they differ from, yet complement, unit tests and end-to-end regression tests.
• The multiple factors of acceptance tests and the limitations of using a single testing tool.
• Approaches for creating executable 'specifications' in a form that makes sense to the customer. Such as: custom domain specific languages, FIT, Java, Ruby, etc.
• Designing and evolving a vocabulary that can be used for expressing intent. The UI is in a different domain to the world it's manipulating, so 'click link' is not enough.
• Determining which layers to hook into (UI, web, database, domain model, network, etc) and effectively using tools that enable this automation.
• Working with acceptance tests in agile development cycles where requirements, code and understanding are constantly evolving.
• Preventing test staleness and brittleness.

This tutorial will help you start applying techniques for acceptance testing to your project immediately.

Case study: Sid and Nancy apply for Life Insurance: Storyboarding the Domain Model

Justin Forder, LogicaCMG
In a large application development for a leading UK insurance provider, it was becoming difficult to recover the 'big picture' from a large number of use cases expressed against an evolving domain model.

This case study covers the adaptation of storyboarding to show the internal working of the system, rather than the screen flow. The resulting storyboard shows how interactive data capture, internal processing, and interaction with external systems combine to build up and use a complex domain model, in the course of an end-to-end business scenario.

While in principle the storyboard could be based on UML object diagrams, such diagrams would be very big. Techniques used to achieve more concise and digestible diagrams included spatial containment, meaningful layout in two dimensions, stacking, and folding away unnecessary detail.

Reactions to the storyboard have been very positive - people from programme managers to testers have found it understandable and useful. A typical comment: the storyboard "brought the system to life".

I have more recently begun using similar techniques in another project, again with good reactions.

The session has two objectives: to communicate the ideas and experience achieved so far, and to engage the audience in reviewing and improving the approach.

Tutorial: Domain-Specific Modelling for Full Code Generation

Risto Pohjonen
Domain-Specific Modelling (DSM) languages provide a viable solution for improving development productivity by raising the level of abstraction beyond coding. With DSM, the models are made up of elements representing concepts that are part of the domain world, not the code world. In many cases, full final product code can be automatically generated from these high-level specifications with domain-specific code generators.

This tutorial introduces DSM and looks at how it differs from modelling languages like UML that focus more on the level of the code world. This is followed by real-life examples of DSM from various fields of software development. The main part of the tutorial addresses the guidelines for implementing DSM: how to identify the necessary language constructs, how to define the metamodel to formalize language specification, and different ways of building code generation. Participants will have the chance to learn pragmatic skills of language creation and modification in exercises.

Workshop: Effective Pairing

John Daniels + David Cleal
The notion of pair working in IT projects became popular as a result of the promotion of the pair programming practice as part of Extreme Programming. Although all early literature on XP discusses only pairing during the act of programming (albeit the rather rich and extended form of “programming” that XP encourages), pair working rapidly came to be promoted as an important part of all development activities.

In this workshop we will consider the range of activities for which pair working is more effective than working alone. Some activities might be best done alone, some best always as a pair. The deliverable from this workshop will be a list of project activities and, for each, an assessment of the importance or otherwise of having a pair perform it.

An important aspect of the workshop is that we don’t just want this assessment to be based on recollections of the participants. We will provide exercises that will examine and measure the performance of participants in carrying out a variety of tasks.