Not Signed-In
Which clippings match 'EXtreme Programming' keyword pg.1 of 1

Agile Software Development: what we've learned at Forty

"The general idea behind Agile is that instead of arguing about the wording of a requirements document written three months earlier with little perspective into the current situation, it's often healthier to acknowledge that the project is going to be flexible and evolving, and put processes in place that allow it to be that way.

Barely over 200 words, that manifesto become the foundation for a movement that has changed the world of software development forever. Endless writing and speaking has explored the various ways the manifesto could be interpreted, and many specific frameworks and methodologies (such as Extreme Programming, Kanban, Lean, and Scrum) have been developed to formalize its principles. A whole 'Agile industry' has emerged, with successful companies offering tools, training, consulting, certification, and other products and services. The economic engine behind the Agile movement as a whole is massive. ...

On the surface, it seems like design and Agile should magically work together, but there are some underlying philosophical issues you have to wrestle with before figuring it out. Design is all about big–picture thinking: planning, strategy, working out all the details, thinking everything through, making it perfect, etc. (Eric Karjaluoto called it the 'masterpiece mentality.') Agile, on the other hand, is more often about doing the basics and saving details for later: iteration, minimum viable products, 'perfect is the enemy of done,' etc. Those two worlds don't blend smoothly together, at least at first. Agile developers can get frustrated with designers for over–thinking things ('Why can't they just let it go? We can get to that later.'), while the designers get discouraged by the perceived low standards of Agile developers ('Don't you want it to be good? Don't you want the user to be happy?').

In both cases, though, the problem comes from a misunderstanding of each other's perspectives (as problems often do). The designer isn't being obsessive, they're just trying to do right by the user. And the developer isn't being lazy, they're just following a process that actually gets things done with minimal navel–gazing. Both sides could learn some important lessons from each other."

(James Archer, Forty)



agile development • agile model • agile modelling • agile software development • current situationdesign processdevelopment life cycle • development methodology • Eric Karjaluoto • evolving needseXtreme Programmingfacing unpredicted challengesflexible management methodology • flexible process • formalised principlesiterative approachiterative design processiterative developmentiterative processjust-in-time (JIT)Kanban • Lean (methodology) • management methodology • over-thinking • perfect is the enemy of done • requirements documents • saving details for later • scrum software development processsoftware developmentsoftware development methoduser experience design • UX design • waterfall modelwhirlpool model


Simon Perkins
14 APRIL 2011

Scrum and Extreme Programming: User Stories

"User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high–level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it."

(Scott W. Ambler, 2009)

Fig.1 User story card (informal, high level).

Fig.2 User story card (formal, high level).




Simon Perkins
14 APRIL 2011

UML Sequence Diagrams and detailed Object-Oriented Design

"If you figure that preliminary design is all about discovery of classes (aka object discovery), then detailed design is, by contrast, about allocating behavior (aka behavior allocation) – that is, allocating the software functions you've identified into the set of classes you discovered during preliminary design.

When you draw sequence diagrams, you're taking another sweep through the preliminary design, adding in detail.

With preliminary design, you made some informal first guesses at how the classes will interact with each other. Now it's time to make those statements very precise, to turn them into a detailed design that works within the Technical Architecture that you've defined.

You use sequence diagrams to drive the detailed design. But note that we advocate drawing your sequence diagrams in a minimal, quite specific format (which we describe fully in this chapter). There's a direct link between each use case, its robustness diagram, and the sequence diagrams. Just as you drew one robustness diagram per use case, you'll also draw one sequence diagram per use case.


UML 2.0 allows you to draw full–blown flowcharts on your sequence diagrams. However, even though the notation supports it, we consider the practice of drawing flowcharts on sequence diagrams to be inadvisable, because it puts emphasis on the wrong part of the problem.

In large part this is because drawing flowcharts simply misses the point of what you should be thinking about when you draw a sequence diagram. If you're trying to drive a software design from use cases, it's vitally important to get the allocation of operations to classes correct. This allocation of operations to classes tends to be a make–or–break design issue.

In the ICONIX Process, the primary purpose of the sequence diagram is to make this behavior allocation visible so that you get it right. If your mind is on drawing a flowchart, it's not going to be focused on this critically important set of behavior allocation decisions.

Once you've finished all the sequence diagrams for the use cases you're working on in the current release and updated your static model (class diagrams), you need to perform a Critical Design Review (CDR). The CDR forms something of a reality check for your design. We illustrate how to perform effective design reviews in our Use Case Driven book. Once the CDR is done, the implementation stage (coding and unit testing) begins."

(Doug Rosenberg and Matt Stephens, 2007)

Doug Rosenberg and Matt Stephens (2007) 'Use Case Driven Object Modeling with UML – Theory and Practice', Apress

Fig.1 sequence diagram notation.



activity diagrams • agile modellingarchitectureblueprintchart • collaboration diagrams • design • detailed design • diagram • Doug Rosenberg • dynamic behaviour • dynamic view • enterprise architect • eXtreme Programming • Grady Booch • ICONIX • information design • Ivar Jacobson • James Rumbaugh • Matt Stephens • MDG • model driven generation technologies • modelling languagenotation • Object Management Group • object oriented analysis • object-oriented design • object-oriented software • OML • OMT • OOAOOD • OOSE • preliminary design • product designrequirements • sequence diagram • softwaresoftware architecture • static view • structural view • technical architecturetechnologyUMLUnified Modelling Languageusage scenariosuse casesvisual languagevisualisation


Simon Perkins

to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.