Agile Software Development — the SST Version

Best Practice Software Development Process is SST — avoid Extreme Programming

Agile Software Development (as defined by the Agile Manifesto) is both: a step forward, but also a step backward (see e.g. what Gartner found). Though it is — without any doubt — true that the classical waterfall models for the software development process are too rigid for the fast moving world of today, implementing agility as suggested by the Manifesto or by XP is not the right thing to do. Better ways must be found, and so more abstract definitions of Agility came up: [en], [de].

SST can implement them without throwing away what we learned up to 1995, i.e. before the need for agility became more and more obvious:

Comparing two Process Models for Software Development

SST is the one we recommend

Please note: SST is to be understood as a spiral process (rather than as a strictly waterfall model) because Requirements are allowed to change (though strictly controlled by change management). To have a change management process in place is necessary at least in projects creating software for a fixed price.

What in XP is achieved by Pair Programming, SST achieves by stipulating that Design and Code should be created by different persons: The programmer is seen as the designer's subcontractor.

SST also recommends that code implementing a given design should be tested – from a black box point of view – by the author of the design (he or she will know better than any other person whether the design was implemented correctly, and so there is no need for a third person to learn the design). By the same principle the Requirements Manager — who in SCRUM is called the Product Owner — should be responsible for acceptance test.

When choosing a process model for your own project, please convince yourself that you know precisely where in the spectrum between XP and SST you want it to be (and for what reasons exactly). I recommend:

XP is dangerous — always use SST

Combine SST with FDD (to have results as soon as possible).

Note: The benefits of Pair Programming in XP
are achieved in SST by stipulating that Designer (= Black Box Tester) and Coder should be different persons.

Each SST cycle is to produce
one single, specific Software Release

consisting of at least the following — always up to date — deliverables:

Requirements Specification (responsible: Product Owner and/or Requirements Manager)
Architecture and Design Specification (responsible: System Architect)
Code
Test Result Documentation (responsible: Quality Manager)

Please note:

What we call a Product Owner is a Requirements Manager representing the customer.
More competent System Architects also guarantee
- a high degree of testability
- a high degree of test automation
- and therefore a high degree of maintainability (for code as well as all the specification documents).
Documents should be acessible in (automatically generated) HTML presentation, so that consulting them is as easy as possible.
Quite an important part of the environment needed to maintain the product is a suitable Issue Tracking System.

Interesting is also the following picture (published 2002 by Barry Boehm):

In the sense of this classification, the FDD SST process is aiming at a Milestone/Risk-driven model.

Wissenswertes zu "Avoid XP: Be agile with SST, Process Models for Software Development" zusammengestellt durch Gebhard Greiter.
tags: seiteSSTRequirementsManager: SSTngegreit Requirementsngegreit Managerngegreit