Gartner rapport ondestreept belang van Agile (indirect)

Agile met andere woorden.

Enkele suggesties in dit Gartner rapport wijzen op een toenemend belang aan adaptief vermogen, zoals

"Tegen 2015 zal geen enkel bedrijf nog concurrentieel voordeel halen of behouden
als het geen gebruik maakt van de gecombineerde kracht van individuele keuzes,
sociale dynamiek en samenwerking."

"Web mash-ups zullen het dominante model worden voor de creatie van samengestelde bedrijfstoepassingen." Volgens de analist kunnen daarmee een nieuwe soort van kortetermijns- of zelfs wegwerpapplicaties gebouwd worden.

Simple visual example to motivate agile and lean processes

Heldere uitleg. Hoe een beeld duidelijke taal kan spreken.
Alleen al een vermelding waard omdat het artikel zo kort en duidelijk is, dat je het sneller kan lezen dan dat je ernaar kan surfen :) beknoptheid wordt beloond!

Het is een beeldvergelijking tussen een verkeerssituatie (alles staat stil ondanks de verkeerslichten en alle verkeersregels die iedereen toepast...)
en de situatie in een station, luchthaven, ... waar geen regels zijn over wie waar moet lopen, het individuele pad van elke passagier wordt last minute bepaald, door de passagier zelf: er zijn geen voorgedefinieerde sporen, het gebruikte pad is niet altijd de kortste weg, maar het systeem werkt wel. Ook dit systeem heeft zijn grenzen, en zal files veroorzaken als het overladen wordt, maar het is duidelijk veel stress bestendiger.

bron: http://jochenkrebs.com/agileportfolio/?p=28

User Stories Applied For Agile Software Development

Voor de zoveelste keer gebladerd door het boek van oa Mike Cohn, en deze keer enkele notities verzameld...

Schrijf elke user story in de vorm “als [type gebruiker x] wil ik .....” en hou dit beknopt

• Beknopt: Max 3 lijnen, indien mogelijk enkel een paar woorden – hulpmiddeltjes:
• beschouw elke user story (=een requirement) niet als iets dat nu volledig moet zijn, maar als “een reminder om te bespreken op het moment dat het in een sprint gepland wordt” -> dat vermijdt ook dat je veel werk steekt in requirements die nooit ontwikkeld worden
• focus op “bespreken”: communicatie op het goede moment is rijker en efficienter dan lange requirement listings
• ipv gedetailleerde beschrijvingen van requirements, is het nuttiger om voorbeelden toe te voegen in de vorm van test cases die voor acceptatie zullen gebruikt worden – steek je tijd eerder in de overweging of die test cases volledig en representatief zijn, eerder dan in de beschrijving ervan
• idem voor uitzonderingen, specialekes etc: voeg ze toe als test cases ipv ze te beschrijven
• wat niet in een voorbeeld kan, past vaak in de “definition of done” van sprints, releases, ...
• zolang een user story niet gepland is in een sprint kan je de test cases oplijsten ipv ze onmiddellijk te verzamelen bij elke user story
• als “herinnering” kan je notes toevoegen met dingen die je later niet mag vergeten bespreken
• vervang eventueel [type user x] door een concrete naam: dat maakt alles meer tastbaar en helpt de developer om in concrete situaties te denken
• vermijd zo veel mogelijk dependencies tussen user stories