Tag Archives: design

How to build the Right Thing

Posted on by

The software industry is going through a shift of mindset.

Agile basically solved the problem of how to deliver software. Most any company that applies an agile method and mindset can get working software out the door. Now, the biggest waste in software development seems to be building the wrong product, or the wrong features.

“There is surely nothing quite so useless as doing with great efficiency that which should not be done at all” -Peter Drucker

This insight has given rise to methods and techniques such as Lean Startup, Impact Mapping, Story Mapping, Feature Injection, etc. But is there a common denominator, a set of underlying principles?

On Feb 11, Gojko Adzic organized a full-day meetup in London with people deeply engaged in this issue, people like Jeff Patton, Mary Poppendieck, Ingrid Domingues, Chris Matts and others who have been inventing and spreading techniques for dealing with the how-to-build-the-right-stuff issue.

It was a very inspiring day! We compared our different approaches and experiences, extracted the core principles, and (to our surprise) managed to condense it into this shared message:

Great results happen when:
1. People know why they are doing their work.
2. Organizations focus on outcomes and impacts rather than features.
3. Teams decide what to do next based on immediate and direct feedback from the use of their work.
4. Everyone cares.

There. So now just go do it! ūüôā
Actually, if you want a more detailed description of each point see Gojko’s post.

Posts from the other participants:

Full participant list (in no particular order): Gojko Adzic, Mary Poppendieck, Gabrielle Benefield, Tom Poppendieck, Gordon Weir, Henrik Kniberg, Jeff Patton, Ingrid Domingues, Karl Scotland, Russ Miles, Christian Hassa, Dulce Goncalves, Aaron Sanders, Shadi Almviken, Chris Matts, Olaf Lewitz and Matthias Edinger.

read more »

Lyft på rumpan!

Posted on by

I dessa agila tider sker allt mer utvecklingsarbete vid tangentbordet, men är det verkligen bra? Ställ er vid tavlan och rita pilar och bubblor innan ni knackar kod! Fast man kan inte göra som vi gjorde förr, BDUF är fortfarande dött.

Även om man parprogrammerar och kan diskutera fram kod och design och även om man nu för tiden inte fokuserar på att skriva dokument som ingen ändå kommer att läsa, får man inte glömma bort att göra design och arkitektur innan man sätter sig ner och implementerar. Så lyft på rumpan då och då och rita på tavlan. Hans Brattberg brukar hävda att ingen form av kommunikation är så effektiv som två personer framför en tavla.

Vid tavlan gör man både arkitektur och design. Eftersom vi jobbar agilt har vi alltså inte alla bitar på plats från start – inte ens arkitekturen – och därför behöver man komplettera (och refaktorera) även denna varje gång man lägger till nya funktioner av dignitet i systemet. En refaktorering av ett hörn i arkitekturen kan få stora konsekvenser i koden och just därför vill man stämma av den ofta. Annars riskerar man att åka på Big Bang.

Till hörnstenarna i systemkonstruktionen hör även domänmodellen. Inte heller här kan vi kosta på oss att göra den i förväg, utan den växer fram gradvis sprint för sprint. En av effekterna av att jobba agilt som jag märkt för egen del är att domänmodellen kan bli så mycket bättre, eftersom man putsar på den hela tiden och de nya objekt man lägger till är de som man precis skall till att använda i sin design och implementation.

Det här leder förstås till frekventa refaktoreringar av modellen och har man den persistent i en databas innebär det även frekventa uppdateringar av schemat. En del kanske backar inför detta, men det finns tekniker för att hantera detta som gör databasuppgraderingarna hanterbara eller rent av lätta. Kanske ännu ett ämne för ett framtida blogginlägg…

Det viktiga är att för det första ser till att ha en arkitektur och en domänmodell och för det andra inte låter någon av dem vara huggna i sten. Därför måste man se över och bättra på dem varje gång man tillför ny (vertikal) funktionalitet i systemet och detta kan man inte göra vid tangentbordet. Bästa sättet är att rita upp sin design på tavlan och se om den, arkitekturen och domänmodellen håller.

När man sedan sätter sig för att koda kanske man rent av börjar med en smärre refaktorering för att "kratta" för sin nya fuktionalitet.