Diagram & analysverktyg

Ett diagram i ett projekt har ett enda jobb: att få människor att förstå samma sak. Det kan vara en kund som ska se hur ett ärende vandrar genom organisationen, ett team som ska enas om vad som ska göras först, eller en styrgrupp som vill veta om sprinten håller.

De här verktygen handlar om arbetet, människorna och besluten runt systemet. Diagram för själva koden — klassdiagram, sekvensdiagram, ER-diagram, arkitektur — finns i C#-boken.

Vilket verktyg ska vi välja?

Börja med frågan: vad behöver vi förstå just nu?

Vi behöver…	Välj	Typisk situation
Se hur ett arbete går mellan personer och avdelningar	BPMN och simbanor	“Var fastnar supportärendena?”
Förstå användarens upplevelse, steg för steg	Kundresa	“Varför avbryter folk bokningen?”
Planera vilka sidor en webbplats ska ha	Sitemap	Innan wireframes och user stories
Visa vad som händer när	Roadmap, tidslinje och Gantt	Projektplan, LIA-planering, release-plan
Visa vem som ansvarar för vad	Organisationsschema	Ny i bolaget, nytt projekt
Samla idéer kring ett ämne	Tankekarta	Brainstorm vid projektstart
Se vad två eller tre saker har gemensamt	Venndiagram	Jämföra metoder, hitta MVP
Bedöma ett läge inför ett beslut	SWOT	“Ska vi satsa på det här?”
Bestämma vad som ska göras först	Prioriteringsmatriser	Backlog, att-göra-lista som växer
Hitta orsaken bakom ett problem	5 Varför	Efter en incident eller ett misslyckat release
Formulera ett mål som går att följa upp	SMART-mål	Sprintmål, personliga lärandemål
Följa upp och visa siffror	Diagram för data	Burndown, velocity, rapport till kund
Reflektera och synka i teamet	Retro och standup	Varje sprint, varje dag

Tre tumregler

1. Rita tillsammans. Ett diagram som teamet har ritat ihop vid en whiteboard är värt mer än ett snyggt som en person gjort ensam.
2. Ett diagram — en fråga. Försöker du visa allt i samma bild visar du ingenting.
3. Mallen är en start, inte ett facit. Ta bort rutor som inte hjälper er och lägg till det som saknas.