Systemutveckling i praktiken Peter Vi är Peter och Olov och kommer från Codemill. Codemill är: - Design- och utvecklingsföretag i Umeå - Ca 50 personer - Specialiserade på videoteknik - Våra kunder är både små lokala startups och stora internationella broadcasters - T.ex ITV, The Guardian, ProSieben Sat.1 etc. - Jobbar både som konsulter och med och egna produkter - Driver produktbolagen http://accurateplayer.com och http://smartvideo.io. Vi är här för att prata lite grann om systemutveckling och hur vi jobbar i team hos oss. Peter, UX designer - Läste ID-programmet - Jobbat med både utveckling och design men är nu UX-designer - Processansvarig för UX, driver hur vi jobbar med UX på codemill.
Olov, operativ chef - Teknisk Datavetenskap - Jobbade som utvecklare och teamledare många år - Utvecklar vår utvecklingsprocess - Ser till att vi följer den
Hur skapar vi kvalitet i arbetslivet och i verkliga projekt? Olov Först och främst, stort tack för att vi fick komma hit Vi blev tillfrågade av Jonny Bra möjlighet för oss att prata lite grann om Codemill Ett bra sätt att nå ut till er studenter som i framtiden kommer söka jobb Förbereda er lite grann på vad som väntar i arbetslivet Vi vill berätta lite grann om hur vi omsätter allt vi lär oss på universitetet i praktiken På arbetsplatsen i team, med kollegor och med kunder Verkligheten är ofta ganska långt ifrån lab-salarna och projektarbeten på universitetet. Inspirera till frågor Inspirera till att ni kanske börjar fundera i banor kring processer, arbetssätt och teamwork Extremt viktigt för att lyckas skapa bra saker Vi är säkra på att ni är duktiga programmerare eller designers Det vi kände att vi saknade när man tog examen var just hur man jobbar tillsammans hos sin arbetsgivare Försöker lägga oss på en nybörjarnivå, så lite av informationen kanske ni har
hört förut Tåls dock att repeteras
Agenda Processer på Codemill Agil utveckling - hur och varför? Våra lärdomar Olov
Process - vad och varför? Ett antal repeterbara handlingar mot ett gemensamt mål Olov
Process - vad och varför? Hög kvalitet Tydlighet och transparens Nöjda kunder och medarbetare Team, kundkontakt, git, testning, UX, samarbete, etc... Olov Varför jobbar vi på ett visst sätt? - Slutgiltiga målet med att ha en bra process är att leverera kvalitet. - För oss är det viktigt att man förstår varför man jobbar på ett visst sätt - Att bara dirigera hur folk ska jobba är inte motiverande - Det är viktigt att allt vi gör har ett syfte. - Kvalitet för oss innebär flera saker: - Hög Användarvänlighet - vi löser rätt problem för användarna på ett så enkelt sätt som möjligt - Vältestad kod - Kod som skalar och kan underhållas - Välmående medarbetare, mindre förvirring och stress - Nöjda kunder, transparens och delaktighet - I takt med att Codemill växer blir det viktigare för oss att ha tydliga rutiner - För nyanställda för att snabbt komma in i teamen - När en anställd hoppar mellan team eller projekt - För att kunna förklara och få med kunder i processen eftersom vi vill jobba nära dom
- Vår process innehåller allt från: - Rutiner för team-arbete - Hur och varför jobbar vi agilt? - vilka roller som finns och hur de interagerar med varandra - Aktiviteter för team för att förbättra arbetet - Tekniska rutiner - Versionshantering, tester, leverans - Kundrutiner - Kundkontakt, sälj,
Minska risk genom att vara agil Peter Agilt kanske är ett ord som ni har hört många gånger - och som ni kommer få höra många gånger fler. Dominant workflow for software developers Not faster or guarantee to success Minimizes risk Allows us to fail and learn Scrum, Kanban are example of common flavors of Agile At least for me, agile has become sort of a buzzword, Being used convince ourselves or customers that we work in the right way. So just as a reminder, why do we want to work Agile? Not faster than a waterfall process Not guarantee to a successful project or product Minimize risk Allows us to fail and learn if we do it correctly
Waterfall Agile Risk Release Release Release Release Release Release Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Time Peter This picture kind of explains what I mean with reducing risk Pink is waterfall project Blue is an agile project Horizontal line is time Vertical line is risk Point with Image: Show that risk increases with long release cycles Efter en release kan teamet se till att testa, utvärdera, omvärdera. En release kan vara en eller flera sprintar - beror lite på vad som är i pipelinen. The risks Associated with this is that we re: Not meeting user needs anymore Loose track of leadership s vision We start to make bad assumptions about user behavior Leads to Bad usability Solving wrong problems
Feature creeping In the end, wasting money and lose credibility We re not truly agile until we actually learn and adapt between releases.
Ett agilt team Build it fast Build the right thing Scrum Master Developer Product Owner Agile team Developer UX Designer Developer Build the thing right Peter Tvärfunktionellt Kunna lösa uppgiften självständigt - vi behöver alla kompetenser Vi har inte ett designteam och ett backend-team t.ex. Kommunikation och samspel är för viktigt för att dela upp oss så. Jobbar som ett lag. Löser uppgifter tillsammans. Roller Individer ansvar aldrig ensamt för något enskild del Teamet är tillsammans ansvarig för kodkvalitet, användarupplevelse Alla ska känna delaktighet och få inflytande Det är viktigt för oss att vi inkluderar varandra i våra arbetsuppgifter, oavsett roll T.ex. reviews, parprogrammering, design workshops, etc. UX - Devs, PO:s - Team, Devs - Test De svarta rutorna är vad som traditionellt varit projektledare. De är uppdelade på två för att varje roll ska kunna hålla fokus. Produktägare
Fokus: bygga rätt sak Kan behövas en proxy Har final say i beslut och planering Scrummaster Fokus: bygga saken snabbt (Resten av) teamet Fokus: bygga saken rätt UX, front-end, backend, fullstack Teamledare Testare, användare, kunder
Agila rutiner Plan Retrospective Develop Release / Demo Develop some More Refine Peter Ungefär såhär ser en sprint ut på Codemill ur en utvecklares perspektiv. Teamet planerar tillsammans med Produktägare & andra Stakeholders Varje sprint har ett tydligt mål Ur en prioriterad lista (Backlog / Story map) väljer vi ett antal problem att lösa Problemen ska motsvara sprintmålet Varje dag i sprinten rapporterar vi vad vi jobbar på och hur det går med våra arbetsuppgifter Daily standup (tillsammans med team / kund) I mitten av en sprint har vi ofta ett Refinement-möte Liknar planeringen lite grann. Går igenom arbetsuppgifterna - har något ändrats, är designen okej, kommer vi hinna, måste vi skriva om kraven, etc? Viktigt i projekt som är komplexa och svåra att definiera Sedan avslutas sprinten med Release och Demo Innebär att vi deployar det som byggts Vi demar för kund Användarna får chans att använda
Vi testar det vi byggt under sprinten An important point We cannot strive to follow an agile manifest strictly by the book However a good approach when setting up a team is to start with Scrum by the book, and later change it Each team needs to find own ways to adapt to them It s not easy According to a study made by NN/g, it takes an average 9 months for an agile team to feel successful To get there faster, we can follow best practices and framework Det är viktigt att varje agilt team får äga sin egen process Syftet med agila manifest är inte att vi ska följa massa regler Dels för att alla team fungerar olika Dels för att öka motivationen Dels för att anpassa sig mot projekt eller kund Det är att hjälpa oss att minska risk och minska slöseri
Retrospektiv Viktigaste mötet för ett agilt team Gör processen inte bara iterativ utan också inkrementell Som alla lean-modeller kräver det en öppen och tolerant kultur Feedback måste ha en riktning Peter
Planering Hur vet vi vad vi ska bygga? UX Research User Storys User Story Mapping Olov Hur vet vi vad vi ska bygga när? Vi försöker basera allt vi vill göra på UX research - Ta reda på behov - Ta reda på vad som är viktigt - Testa och validera att produktägarens eller kundens idéer är bra i den mån vi kan
User Story Olov User stories är ett sätt att dokumentera allt vi ska bygga. Alla krav ska förr eller senare skrivas som user stories. När vi planerar sprintar väljer vi vilka user stories, dvs. Vilka problem vi ska lösa den kommande sprinten Ett sätt att beskriva ett problem utan att fokusera på någon teknisk lösning - Skrivs tillsammans i teamet (Oftast UX / PO:s som definierar stories) - Skrivs ur användarens perspektiv - Ju längre man kommer ju mer detailjerad blir den - Utifrån problembeskrivningen ska utvecklarna kunna göra bra tekniska val - Utifrån acc.kriterier ska utvecklarna kunna testa att lösningen löser problemet Innehåller: Titel, beskrivning, design, checklistor, acc.kriterier, estimat på komplexitet.
User Story Mapping Tvådimensionell backlog Hierarkisk karta över alla user stories Ordnad horisontellt i något slags flöde, narrative flow Ordnad vertikalt i prioritet Olov Väldigt kraftfullt grafiskt verktyg Väldigt enkel att förstå Rolig men kognitivt påfrestande att skapa, kan ta flera dagar Länktips: https://jpattonassociates.com/user-story-mapping/
Olov Väldigt kraftfullt grafiskt verktyg Väldigt enkel att förstå Rolig men kognitivt påfrestande att skapa, kan ta flera dagar Länktips: https://jpattonassociates.com/user-story-mapping/
Scrum with Staggered Sprints Fixed Length Stories & Design Stories & Design Test Stories & Design Test Stories & Design Test Test Code Code Code Code Peter Utifrån en story map vet mycket om både den UX och utv. som ska göras härnäst. UX behöver dock leverera till utv. Vilket innebär att UX måste ligga lite före. Teamet måste ha lite mer koll än bara nästa sprint Illustration över hur vi får ihop UX arbete med Utvecklingsarbete Vi kallar det Staggered sprints Syftet är att UX ska få chans att göra klart design före utveckling
Tekniska processer Arkitektur Versionshantering Git Branching-strategier Testning Enhetstester TDD Automatiska frontend-tester Olov - Processer runt systemarkitektur - UML-workshops - Data-flödes-workshops - Versionshantering - Vi kör git på allt - Antingen self-hosted, gitlab eller kundlösningar - Alla team ska köra en branching-strategi - Testning - Enhetstester - Minimum för alla nya projekt - Test Driven Development - Kör vi i vissa projekt - Skriver tester först - Hög buy-in - Låg maintenance cost i framtiden - Vi har en del maintenance-projekt med spagetti-kod - Om vi haft någon av ovanstående test-processer skulle koden varit så mycket enklare att underhålla
- Automatiska frontend-tester - Xelenium - CI - Automatiska tester på alla mergear till develop och/eller master
Git Flow Olov - Merging Strategy - Ett bra sätt att hålla ordning på alla kodbaser - Master-branchen - Stabil kod - Ska alltid fungera - Develop-branchen - Typiskt sprintens bas - Mergeas in i master före release - Feature-brancher - En per user story etc. - Mergeas in i develop när storyn är färdig - GitLab/GitHub/BitBucket har stöd för pull requests - Man kan inte merga in den själv, utan gör en merge request - Någon måste godkänna att: - Storyns acceptanskriterier är uppfylld - Koden är snygg - Koden är testad - Etc.
Kundkontakt En utvecklare eller en UX-are är en viktig representant och indirekt säljare Peter En stor del av de uppdrag vi säljer är mersälj som kunderna ber om eftersom de är nöjda med det vi levererat Sälj fungerar som en naturlig del av den dagliga kundkontakten. Vi värdesätter verkligen utvecklare och UX:are som på ett naturligt sätt bidrar till kundnöjdhet och För att göra det måste vi vara kontaktsökande, proaktiva och aktiva i vår kommunikation. Det är också viktigt för att få projekt att bli framgångsrikt: Empati med användarna - vi vill lösa reella problem för dom Förstå affärsmålen för kund För att hitta en lämplig teknisk lösning och en bra design, måste vi: Ha en gemensam bild av vad som behöver byggas Ha en förståelse för både användarbehoven och affärsmodeller Kunden har inte alltid koll på exakt vad dom behöver Vi kan hjälpa dom förstå vad dom behöver Bara genom att vara lyhörda, ställa frågor, anskaffa domänkunskap
kan vi hjälpa kunden nå målen
Viktiga lärdomar Fast scope och projektfaser Ödmjuk mot kunder (spoiler: dom är inte experterna) Vi är inte användarna Design är aldrig klar Peter Fast scope och projektfaser Dom projekt som är mest misslyckade hos oss är när Vi har ett fast scope för långt fram i tiden Vi är Agila - vi jobbar enligt agila rutiner - men vi anpassar och lär oss inte Ibland kommer det kunder till oss med hundra sidor krav Vi tror oss veta vad som kommer vara viktigt om 1 år Mycket förändras på kort tid, kunskap, beteenden, budgetar, prioriteringar Risk att slösa mycket tid att planera saker som aldrig byggs Därför vill vi ha kortare framförhållning Kanske bara planera 3-4 närmsta sprintarna Vi vet alltid att hälften kommer glömmas bort eller visa sig vara felaktigt Det går lite grann hand i hand med att ha faser i projekt T.ex. En designfas och en implementationsfas Istället försöker vi inkludera designaktiviteter i den agila utvecklingsprocessen Ödmjuk mot kunder Väldigt lätt att bli irriterad på kunder som vill breaka processen hela tiden.
Kom ihåg att ni är experterna och har som uppdrag att förklara varför processerna ser ut som dom gör. Vi är inte användarna Bara för att jag tycker att en feature vore najs, betyder det långt ifrån att majoriteten av användarna finner det användbart Bygg det inte bara för att vi kan. Det här går fort att slänga in - ofta en väldigt dålig idé. Lätt att feature-creapa - tillslut har vi 17 idéer i systemet från olika personer Leda till inkonsekvens i design Dålig transparens mot team och kund Lätt att acceptera intressanta idéer från PO:s, utvecklare Ifrågasätt - fokusera på syfte och vilka problem vi vill lösa och fråga varför minst 5 gånger Istället : Lyft idéer med PO:s och UX, gör research och ta med om 2 sprintar Design är aldrig klar Något som vi som personer och organisation fortfarande lär oss Design eller kod för den delen, är aldrig klar. Det är viktigt att leverera snabbt och ofta för att utvärdera om vi är påväg åt rätt håll Bara för att vi har levererat något betyder det inte att vi släpper det sen Design går alltid att optimera Kod går alltid att optimera Därför Principle of good enough gäller. Risken finns ändå att vi måste göra om saker sedan
Frågor! Tack för att ni lyssnat! Peter Bjuhr peter.bjuhr@codemill.se Olov Vikberg olov.vikberg@codemill.se
Testning Tack! @codemillab info@codemill.se