Jacob Hamacher

Var lugn, användarna kommer inte att bygga en ”The Homer” om de får styra dagordningen för utvecklingen

Jag hittade ett gammalt dokument som jag arbetade efter under de konsultuppdrag där jag jobbade som teknisk projektledare och arkitekt. Då varken jag, eller mina kunder, hade hört talas om Scrum och Agil utveckling så hade jag friheten att utveckla min egen metod som jag kallade Utveckla med HTML-prototyper. Jag använde mig av samma metod under lång tid och i olika uppdrag.

Idag när jag läser det jag skrev för mer än tio år sedan slås jag av hur mycket som har ändrats sen dess. Det var på den tiden då webbutveckling främst var sidutveckling. Man arbetade med en webbsida i taget. Man bröt ut moduler efterhand till separata include-filer. Det var svårt att versionshantera då man ibland tvingades att  jobba direkt mot en server. Arbetsstationerna var ofta för klena för att köra systemen lokalt.

Men trots skillnaderna så är principerna lika. Även på dinosauriernas tid så gick det att jobba agilt.

Utveckla med HTML-prototyper

Vad?
HTML-prototypen skall visa alla de sidor som vi senare skall utveckla. Det centrala är att alla de funktioner och kontroller som skall finnas i slutändan finns med så att man kan visa hur systemet kommer att se ut och fungera. Sedan så utvecklar vi funktion för funktion och byter ut de statiska sidorna i prototypen mot riktiga asp-sidor som går mot databasen.

Vem?
Användarna skall hela tiden styra dagordningen i utvecklingen. Prototypen är vårt främsta arbetsredskap i samarbetet med användarna.

Varje fredag morgon träffar utvecklarna referensgruppen med en uppdaterad prototyp. Steg för steg byts delar av prototypen ut mot nyutvecklade delar som faktiskt fungerar.

Varför?
För att utvecklarna skall kunna få överblick av systemet. Prototypen är enkel att ändra i. Ur prototypen går det även att generalisera och se att man kan återanvända kontroller mellan olika sidor. Exempelvis kan listfunktionen kanske vara en genväg in i sökfunktionen, och då måste prototypen visa att det går att genomföra. Det är även ett bra sätt att dela upp arbetet så att en utvecklare gör en sida och en annan gör en annan sida.

För formgivarna är det viktigt att prototypen visar en korrekt disposition så att det går att skapa grafisk profil samt design kring de olika vyerna och funktionerna.

Ett utvecklingsprojekt kan i långa faser vara ett abstrakt och mystiskt projekt. Det finns en stor mängd erfarenhet och idéer bland användarna som vi måste kunna ta till oss. Ett av de mest uppenbara sätt att visa vad vi åstadkommer är att visa upp prototypen.

Varför?
Med prototyp i ett tidigt skede kan vi vara flexibla. Vi kan snabbt lägga till och ta bort funktioner både i vårt egna kreativa arbete, samt vara öppna för förslag och synpunkter från våra användare och kollegor.

Ur prototypen får vi dessutom en tydlig konkret målbildmed ett antal sidor som skall implementeras innan projektet är färdigt. Detta är ett viktigt underlag för projektplanen.

Med hjälp av prototypen så kan vi även minimera skriftliga specifikationer och protokoll. När vi kommer överens om en förändring i vårt arbete så skall prototypen uppdateras för att visa detta. På så sätt har vi alltid en levande målbild utan att ständigt dokumentera varje förändringsönskemål.

Webbutveckling har kommit längre än så här idag. Utvecklingsjobbet har förskjutits från mallar och include-filer till klasser och objekt. Kvalitetskraven är högre, och enhetstester skapar komplexa arkitekturer. Och i denna förskjutning så finns en risk att tekniken får större fokus än tidigare.

Teknik är något som bara måste fungera. Det är användarna som bär nyckeln till ett lyckat projekt. Glöm inte det.