Grey Scope Creep

Når man anvender agile projektledelsformer og processer, så vil der altid være et indbygget krav om, at hver iteration - hvad enten den hedder iteration, sprint eller noget andet - skal levere demonstrerbar og færdig funktionalitet. Det kan være utrolig svært at sikre dette formål. Hvis man ikke er meget påpasselig, så vil der være mange løse ender i det som leveres efter hver iteration. Dette kaldes grey scope creep og betyder, at arbejdet hober sig op på usynlig vis. For hver iteration kommer man længere og længere bagud, specielt hvis man bogfører funktionerne, som er blevet leveret, som "done". Jeg har selv været i den situation og kan derfor kun samtykke, når der tales om, at man skal operere med en meget striks version af "done". Det er langt bedre at lægge ganske lidt funktionalitet i en iteration, og så får denne funktionalitet færdig. Og færdig betyder her, at funktionerne er gennemtestede både på unit-test og brugergrænsefladeniveau, at dokumentation er udført, at alle integrationstests er foretaget osv...

Hvis udviklere/programmører på et givent projekt ikke lever efter denne devise, så skal det tages meget alvorligt. Ingen udvikler skal have lov til at cutte i koden for at komme hurtigere i mål. Heller ingen skal springe test eller review over. Samtidig skal projektlederen aldrig bogføre funktioner som "done", før de rent faktisk er det. Dette er en kunst, tro mig, men det lønner sig altsammen i form af mere stabil kode og mere stabil projektplanlægning (burn-rates der kan bruges til noget, iterationplanlægning som er realistisk osv...)

Hvad skal en brugergrænseflade egentlig?

Jeg læste i dag en præsentation vedrørende web 2.0 (trend, så det batter....). Jeg stødte på nogle ret spændende betragtninger på, hvad en brugergrænseflade skal tilbyde for at være usable. Donald Norman - med hans formiddable Design of Everyday Things - anvender betegnelsen affordance til at forklare, hvordan et materiale, en form eller dims ligesom udstråler sin egenskab... sit tilbud. En stols affordance er at "kunne blive siddet på". Designet udstråler det simpelthen. På samme måde er det med mere kompleks teknologi.

Det betragtninger, jeg læste om i dag, handler på mange måder således om, hvad websoftware affordance er struktureret omkring.

Det kan koges ned til følgende tre kategorier:

• Invitation
• Transition
• Feedback

Invitation handler om, at websiderne skal kommunikere deres potentiale. Det vil sige, man skal som bruger kunne se meningen med informationen, strukturen og samtidig forstå, hvad der kan manipuleres eller interageres med. Siderne, eller funktionen, skal altså naturligt invitere til deres egen brug. Det er deres affordance! Den skabes af designeren...

Transition handler om forvandling eller ændring fra en tilstand til en anden. I forhold til websider betyder det, at det skal være tydeligt for brugeren, når noget ændrer tilstand, men måske endnu vigtigere, hvad der kan ændre tilstand. Eksempelvis hvad er knap, hvad er ikke.. hvad er link, hvad er ikke...

Feedback handler om at give brugeren kontekstuel korrekt svar på handling. Det lyder banalt, men det kræver faktisk overvejelse. Når noget går godt, skal brugeren informeres. Hvis der er fejl skal brugeren informeres. Hvis en given funktions udførelse tager lang tid, så skal dette illustreres for brugeren i form af progress indicators. Så langt så godt. Det er findes mange langt mere komplekse interaktionsformer at tage stilling til: når brugeren indtaster password, skal man så ala google gøre brugeren opmærksom på, hvor stærkt og sikkert det er? når brugeren indtaster information i formularer, skal informationen så valideres med det samme, eller skal brugeren kunne læse sig til, hvad der må skrives i felterne?

Nåmen... umiddelbart var det der slog mig styrken i disse tre kategorier. Hvis blot alle designere tænkte disse tre affordances ind i brugergrænsefladerne, så ville arbejdet med design sikkert foregå langt mere struktureret, og det ville sikkert også lette besværlige discipliner såsom papirprototyper og wireframe designing.