KanBan-flöde i EA

I enterprise architect finns det stöd för att definiera ett kravs tillstånd. De fördefinierade tillstånden är; approved, implemented, mandatory, proposed och validated. Om man inte tycker dessa passar det egna arbetssättet så kan man enkelt ändra dessa till något eget.

Välj först settings => project types => general types

Sedan kan du lägga till, ta bort eller ändra de befintliga tillstånden efter behag. Det går också att tilldela respektive tillstånd en färg som man kan visa i diagrammet genom att gå in på: Tools => Options => object => show status colors in diagram.

Vill man arbeta mer kanban-orienterad skulle man till exempel kunna använda sig av tillstånden;

  1. Ej klar för utveckling
  2. Klar för utveckling
  3. Klar för test
  4. Klar för driftsättning
  5. Driftsatt

Gör vad du vill förutom att arbeta…

Idag var vår första ”gör vad du vill förutom att arbeta -dag ”.  Konceptet var enkelt, alla skulle samlas på kontoret och vara där hela dagen, ingen ”fick” arbeta med sina uppdrag. Istället skulle man göra något roligt,  något som man velat göra men inte hunnit med under sin ordinarie arbetstid. Var och en valde själv.

Otroligt kul! Fullt med folk på kontoret, och jag tror aldrig det varit så tyst. Alla var så uppe i det man gjorde att man glömde bort tid och rum. Ämnena varierade, några provade att utveckla mobilappar, några lärde sig mer om olika verktyg som clearcase och visual studios debugger. Någon tittade på responsive web design, någon testade att utveckla på dokumentdatabaser. Någon gjorde den där hårddisk back-upen som man inte hunnit med tidigare, men alltid haft dåligt samvete för. Några kunde inte riktigt hålla sig, utan smygjobbade åt kunden…

Själv tittade jag på Enterprise architect och hur man kan skapa egna UML-profiler och mallpaket. Mer om det senare.

Vi avslutade dagen med middag på Allmänna Galleriet.

En agil kravhanteringsprocess

Att arbeta agilt med krav har ingenting med vilken ”mall” man använder för att dokumentera kraven, utan beror på förhållningssättet man har till kraven. Oavsett om man arbetar med user stories eller användningsfall är nedanstående process att rekommendera.

  1. Ta reda på problemet som ska lösas (dvs definiera vilket slags system som ska byggas).
  2. Sätt problemet i sitt sammanhang och förstå hur verksamheten fungerar (t.ex. genom att skissa upp systemkartan, domänmodeller och/eller verksamhetsprocessen)
  3. Identifiera de som berörs av arbetet (kalla det intressenter, roller, aktörer eller vad du vill).
  4. För varje ”mänsklig” intressent, fundera på vad det är för typ av människa; stresstålig, IT-kunnig, domänkunskap, språk, arbetsmiljö?
  5. För varje intressent (människor och system): ta reda på vad han/hon/den/det värderar. Kalla det värdeobjekt, user stories, användarmål eller användningsfall.
  6. Prioritera
  7. Gå igenom och diskutera varje värdeobjekt med både verksamhet och IT
  8. Prioritera igen…

Om UMLs associationer

Vad betyder egentligen pilhuvudet på associationen mellan aktör och användningsfall i UMLs användningsfallsdiagram.

Nedan är klippt från UML Superstructure 2.3, sid 18.

6.4.2 Diagram format
The following conventions are adopted for all metamodel diagrams throughout this specification:
• An association with one end marked by a navigability arrow means that:
• the association is navigable in the direction of that end,
• the marked association end is owned by the classifier, and
• the opposite (unmarked) association end is owned by the association.

Inte mycket hjälp där alltså, kanske därför det tolkas så olika av olika människor… Dokumentera därför alltid vad du menar med det!

Att knyta ihop user stories med systembeskrivningen

En artikel om att knyta ihop user stories med mer tekniska systembeskrivningar. 

En user story har formatet; Som X vill jag Y för att Z. Systembeskrivningen kan ha formatet; Komponent A gör åtgärd B.C.D genom att E.F När G inträffar.

Ett exempel: Komponent ”A” gör åtgärden ”uppdatera.användare” genom att ”lista befintliga användare.databasen” när ”sessionen avslutas”.

Länk: InfoQ: Active Architecture for Agile Projects.

Heuristisk utvärdering av användbarheten

En heuristisk metod är enligt Nationalencyklopedin:
heuristisk metod, sokratisk metod, undervisningsmetod där eleven stimuleras att genom av läraren ställda frågor självständigt nå fram till kunskap och insikt.

Inom användbarhetsdisciplinen har jakob Nielsen definierat frågeställningar för expertutvärdering av ett system. Det sägs att ca 80% av användbarhetsproblemen för ett system kan identifieras med denna utvärdering…

  1. Systemets status ska vara synlig för användaren.
  2. Systemet ska uttrycka sig på användarens ”språk” och följa konventioner som finns i verkligheten.
  3. Användaren ska själv kunna styra vad han/hon gör, dvs systemet ska tillhandahålla sätt att avbryta den pågående transaktionen, återkalla kommandon och göra om ett kommando. Det ska dessutom vara ”svårt” att utföra oåterkalleliga handlingar.
  4. Systemet ska vara konsekvent och standardiserat.
  5. Systemet ska förebygga fel.
  6. Användargränssnittet ska vara utformat så att användaren känner igen sig, snarare än tvingas memorera det.
  7. Systemet ska vara flexibelt och effektivt att använda.
  8. Designen ska vara estetisk och minimalistisk.
  9. Systemet ska hjälpa användaren att förstå varför ett fel uppstått, vad det beror på oc hur man åtgärdar problemet.
  10. Det ska finnas tillgång till bra hjälp i systemet.

Jämför 15 webb-gränssnitt

Link: http://www.webanalysts.info/webanalytics/a-fun-game-guess-the-outcome-of-15-tests/

Lars johansson har satt ihop 15 a/b-tester på olika webb-siter. Det intressanta här är att det finns ett facit. Testerna består av den ursprungliga designen och den nya. Man har dessutom mätt effekterna av förändringarna. Gör testet! Fundera sedan på om du förstår varför utfallet blev som det blev. Detta är användbarhet i praktiken.

Hur lång tid tar det att verksamhetsmodellera?

Det korta svaret på ovanstående fråga är givetvis en motfråga – hur långt är ett snöre?

Man hinner alltid med att verksamhetsmodellera i ett systemutvecklingsprojekt, däremot hinner man inte alltid ta fram en fullständig verksamhetsmodell, detaljera den fullt ut och förankra den i verksamheten så att den kan implementeras.

Dock så behöver man kanske inte alltid göra allt det. Som kravanalytiker behöver man förstå hur det tänkta systemet passar in i verksamheten. Den förståelsen får man bäst med hjälp av en liten verksamhetsmodellering. det behöver inte ta mer än en timmes intervju + 30 minuters dokumentation.

Dokumenterar man för sin egen förståelse är inte kraven lika stora som om man dokumenterar för kundens VD… Dokumenterar man för sin egen förståelse behöver man heller inte allting, det räcker ju att dokumentera precis så mycket att man själv förstår hur allt hänger ihop…