Rebecca Wirfs-Brock

Rebecca Wirfs-Brock invented the way of thinking about objects known as Responsibility-Driven Design. She is lead author of the classic Designing Object-Oriented Software (1990 still in print!), and Object Design: Roles, Responsibilities and Collaborations (2003). She is the design columnist for IEEE Software and past board member of the Agile Alliance. Through her writing, teaching and speaking she popularizes the use of informal techniques and thinking tools for designers, programmers, and analysts. Among her widely-used inventions are object role stereotypes and the conversational form of use cases.

Rebecca is recognized as an innovative and influential design practitioner. She spent 15 years at Tektronix where among other accomplishments were managing the first commercial Smalltalk system, project leader for low cost graphics terminals, and Program Manager of the Reusable Components Group at Tek Labs. Beginning in 1990 she was Director of Consulting and Training for Instantiations, Digitalk, and ParcPlace-Digitalk. In 1997 she founded Wirfs-Brock Associates. Most recently she has taught object design, architecture, and use case writing, and advises clients on design, modeling, and object-technology management in the financial, telecommunications, and government sectors.

Presentation: "Lessons Learned from Architecture Reviews"

Session: Architecture and Design Best Practices

Time: Thursday 11:15 - 12:00

Location: Ballroom Le Grand 3

Abstract: Complex software projects are often late, have quality problems and don't deliver all that was promised. Often such problems are the result of an inadequate or inappropriate software architecture. Software architecture reviews are a tool that help reveal architectural risks and strengths as well as uncover unidentified issues that need to be addressed. Sometimes the biggest risks are technical ones. And other times, the biggest risk is that too much attention has been placed on the technical architecture to the exclusion of other essential factors. This talk reflects on lessons learned from preparing for, presenting, and conducting architecture reviews. I'll discuss what to avoid, what information to seek, and how to effectively resolve issues.

Presentation: "Skills for the agile designer"

Session: Lean and Agile Software Development

Time: Thursday 13:00 - 13:45

Location: Ballroom Le Grand 1

Abstract: What makes an agile designer effective? Agile designers need to quickly see the essence of a problem, shape reasonable solutions, and communicate complex ideas. When things don't exactly go according to plan, they must react, readjust their thinking, and try again. This presentation introduces several techniques and vocabulary for articulating the nature of design problems and their solutions: Problem frames identify the 'typical structure' of software tasks. Designer stories set the stage for collaborative design. Role stereotypes are useful for assigning or assessing object behaviors. Control styles can help characterize and communicate control center designs. Trust regions can aid in spotting places where ?defensive? programming is needed. Seasoned designers strike a balance. They know the difference between core and revealing design tasks and plan accordingly. When unanticipated difficulties crop, they adapt their work rhythms. Finally, we conclude by introducing different forms of criticism and how to handle them on the spot so you can hold your own and even learn something instead of having a heated discussion. Audience: Developers, programmers, leads, and testers can benefit from learning how to characterize problems and solutions. Participants should be familiar with software programming, agile development, and object design, and be looking for new ways of 'seeing'.

Workshop: "The Art of Telling Your Design Story"

Time: Wednesday 09:00 - 12:00

Location: Bastille

Abstract:

Do you have trouble communicating design ideas, getting buy-in to new approaches, or informing others about your design? The best way to present your design isn’t the same way you came up with it. As Francis Galton, a 19th century geneticist remarked, “It often happens that after being hard at work, and having arrived at results that are perfectly clear and satisfactory to myself, when I try to express them I feel that I must begin by putting myself upon quite another intellectual place. I have to translate my thoughts into a language that does not run very evenly with them.” This course presents tips, techniques, and guidelines for communicating your designs to others. To be an effective communicator, you need to know what belongs together and what deserves special emphasis. By choosing what to emphasize, understanding what's fundamental, and using progressive realization techniques, you can unfold a design in successively interesting parts. In this short course we'll present options for drawing and explaining your design using informal as well as formal notation. We’ll demonstrate some fun ways to get people to simulate object interactions by tossing koosh balls, and we'll have time to plot out your own design storyline.

Topics:
I. Why tell design stories?
II. A story-telling strategy
    a. Stories worth telling
    b. A presentation planning “template”
    c. Understand the needs and concerns of your audience
d. Story considerations for presenting an architecture
    e. Early design stories
III. Storytelling basics
a. An ordering of story fundamentals: from most to least fundamental
b. Use progressive realization
c. Decide what to emphasize and understand visual impact
IV. Storytelling dilemmas
    a. The crowd
    b. The impatient audience
    c. Massive details
    d. Missing details
    e. How to solicit and handle criticism
V. Storytelling patterns
    a. Describing exception handling
b. Describing how to adapt a design
c. Describing design decisions
VI. Elements of Style
    a. Strunk and White’s advice applied to design stories
    b. Representation options—formal, informal, detailed, overview

Tutorial Objectives
At the completion of this course attendees should be able to:
•    Plot a design story
•    Use techniques to increase emphasis
•    Order a story’s topics from most to least fundamental
•    Choose an ordering to tell a story based on the audience and context
•    Determine an appropriate storytelling strategy and format