Alistair Cockburn

Agile software development, the people factor

In a previous article (2001), we introduced agile software development through the problem it addresses and the way in which it addresses the problem. Here, we describe the effects of working in an agile style.

Agile software development: it's about feedback and change

Currently, the focus is on determining how to blend agile methodologies with plan-driven approaches to software development.

Selecting a project's methodology

How do we determine the need for various software processes or methodologies, and what helps us choose the appropriate one for our project? To answer these questions, we need to get to the bottom of the controversy over methodologies and discover the dimensions along which they vary. This article describes a framework for methodology differentiation, principles for methodology selection, and project experiences using these ideas.

Question time! about use cases

In Britain there is a very successful form of panel session, on a television program called “Question Time.” In this programme, four panelists, all public figures, are chosen to give a spectrum of viewpoints. There is always a figure from the two main political p<a.rties, usually one from the third largest party, and some complementary figure, perhaps a a business leader, union leader, or media person. This gives a wide spread of views. There are no position statements, the program is filled by discussing questions at about 10 minutes each. Each question is asked by an audience member, all four panelists respond, moderated by the panel moderator (a well known BBC ligure). The questioner then makes a brief reply, and there is a brief period of comments from the floor. The questions are submitted in advance by the audience members and the progr‘am organizers pick six questions that will be interesting. This panel on use cases follows roughly the same format. A well known (English!) 00 figure will question four expert panelists with differing views, to expose their views and their reasons for differing. There are no position statements, the 90-minute pane1 is filled by discussing eight questions. The questions are submitted in advance by the public and audience members. The moderator picks eight questions that will be interesting and help tease ap‘art subtle issues and differences between the panelists. For each question, all four panelists respond, moderated by the pane1 moderator. The questioner makes a brief reply, and there is a brief period of comments from the floor.

Using formalized temporal message-flow diagrams

Temporal message‐flow diagrams (TMFDs), alternatively called sequence charts, interaction diagrams, event traces, or actor diagrams, are illustrations of a systems global message‐passing activity over time, and a pictorial aid to understanding the systems behavior. They are widely used for requirements and documentation for network protocols and object‐oriented applications. We present a general formalism for TMFDs, describe a suite of tools we have designed that employs this formalism, and present our experiences with these tools. The formalism and tools described serve to support and broaden the use of TMFDs in developing communicating systems.

Efficient implementation of the OSI transport protocol checksum algorithm using 8/16-bit arithmetic

The checksum algorithm recommended in the OSI transport-protocol specfications is an arithemetic checksum algorithm which makes heavy use of base-255 addition. In this technical note, an efficient implementation of the recommended checksum algorithm is derived, using 8-bit unsigned addition as the base for an inexpensive modulo-255 addition.

A fishbowl with piranhas: coalescence, convergence or divergence?

Agile software development practices including XP and Scrum have risen to prominence within the software engineering community over the past ten years. Are agile software development practices converging? Are some practices becoming more integrated and/or more widely adopted than others? In the early 90s there was a convergence of object-oriented design methodologies - is a similar pattern being repeated within the agile software development community? Several years ago conferences featured debates on the number of practices inherent to XP - or for that matter what constituted XP. Is the Agile community on the verge of converging to standardization or do individual practices retain their individually and evangelists/disciples? A somewhat related question is: Can an agile practice be applied out of the box or is some assembly required? What does it take to get agility going in an organization? Does it work as advertised? What practices work and play well with others? Hear the experiences of panelists in their attempts to actually make agile work in the real world. From Crystal, DSDM, FDD, LEAN, Scrum, to XP (and others) - participants will to share their perspectives and experiences. Be warned - this fishbowl will be stocked with piranhas.

Carla: A rule language for specifying communications architectures

Due to the unique requirements of a series of projects to specify communications architectures using graphical representations (Cara and MFD), we have developed the communications-oriented rule-based language Carla (Cara Rule Language), which provides an executable specification of the architecture being developed. Carla is designed to provide the ability to specify and simulate high-level, possibly incomplete, specifications of communications architectures, and to allow the developer to refine the specification through the addition of behavior-describing rules. Carla is also well-suited to creating black-box specifications of any system whose behavior depends on input/output history. We describe the features of the language, discuss various design issues, and provide examples of various communications protocols specified in Carla.

Processes (panel session): the roles of ceremony and adaptation

As industry begins to invest in OO/CBD (Component-Based Development) processes and the OMG considers whether/how to standardize on process, many issues arise. Those to be debated include process framework versus process; high ceremony versus low ceremony; the need for flexibility and tailorability; and the role of automation.