Software development process

Software development process

Innehåll:

Vattenfallsmetoder
SCRUM
KANBAN
Entreprenörskap - pitchning. Att starta ett företag, investeringar
SWOT : Strengths, weaknesses, opportunities, threats.
Grupparbete

________________________________________________________

Vattenfallsmodeller

Koncept som utvecklades under 70 - 80 talet. Används fortfarande, dock inte lika flitigt som vid uppkomsten.

Vid användande av vattenfallsmodellen strukturerar vi arbetet likt ett vattenfall där den samlade styrkan gör saker i olika steg. Precis som vattnet i ett vattenfall leder vi den samlade arbetskraften ner i listan av de olika momenten, vi backar aldrig några steg utan leder hela tiden arbetet framåt.

I det svenska arbetslivet används två varianter av vattenfallsmodellen fortfarande. Dessa är

PPS : TIETO
PROPS : Ericsson

Fördelar med vattenfallsmodellen:

Enkla att förstå, bra och tydlig struktur.
Varje steg planeras ett i taget, detta möjliggör att vi aldrig behöver backa i utvecklingsprocessen.
Varje steg i processen är väldefinierat.
Milstolpar används ofta.
Fungerar väl i mindre projekt.

Nackdelar med vattenfallsmodellen:

Risk att man i början inte har helt klart för sig vad som ska göras/förväntas av kunden. Därav kan det hända att man levererar något som kunden egentligen inte vill ha.

PPS

PPS utvecklades av TIETO. När man utvecklar i PPS delas projektet upp i 8 beslutspunkter (BP). Utefter det delar man upp det i tre utvecklingsfaser.

Under förberedelsen:

BP1 - Beslut om att starta projektet och initiera förberedelserna.

BP2 - Beslut om att fortsätta, avbryta eller göra om förberedelsearbetet.

BP3 - Beslut om det finns tillräckligt bra underlag för att starta projektet.

Under genomförandet:

BP4 - Beslut om att starta genomförandet.

BP5 - Beslut om att fortsätta eller förändra projekt åtagandet.

BP6 - Beslut om att godkänna leverans av projektet resultat.

Under avvecklingen:

BP7 - Beslut om att godkänna överlämning av ansvar till projektets förvaltning.

BP8 - Beslut om att avsluta projektet.

Det finns ett antal dokument som skall finnas med under ett PPS projekt. Dessa är

Projektdirektiv - Ge underlag och förutsättningar för start av projektet samt ge styrande ramar för förberedelsearbetet.

Projektplan - Identifiera, definiera och avgränsa projektets åtagande.

Statusrapport - Beskriva aktuell status och prognos för projektet.

Slutrapport - Redovisa projektets måluppfyllelse, olika deltagargruppers erfarenheter samt ge rekommendation till ett förbättrat arbetssätt. Projektets slutrapport beskrivande projektförlopp och erfarenheter.

PROPS

Här delar vi in projektet i tre olika områden.

Projektstyrningsprocess (Affären)
Projektledningsprocess (Projektledningen)
Projektets arbetsmodell

Dessa symboliseras av olika färger.

Rött är styrande
Blått är ledande
Gult är liktydigt med arbetsmodellen

PROPS har sex olika "toll-gates" dessa TG:n benämns

TG0 - Beslut att starta projektanalys

TG1 - Beslut att starta projektplanering

TG2 - Beslut att etablera projektet och starta projektgenomförandet.

TG3 - Beslut att fortsätta genomförandet enligt ursprunglig eller reviderad plan.

TG4 - Beslut att överlämna projektets slutresultat till intern mottagare och extern kund. (i förekommande fall)

TG5 - Projektets slutresultat accepterat, beslut om att starta projektavslutning.

SCRUM

En agil metod som används ofta i modern utveckling. Namnet scrum kommer från en fotbollsterm där spelarna står i en klunga.

Det finns tre olika typer av backlogs när vi arbetar i SCRUM.

Product backlog

En lista av saker som ska göras. Det finns alltid en prioriterad arbetslista samt en tidsuppfattning av varje moment. Backloggen ägs av product ownern i projektet. Product owner värderar risk, värde, ansträngning och behov. Den är ständigt under förändring och skall uppdateras kontinuerligt.
De saker som är högst prioriterade i backloggen finns det mest information om. Detta för att man skall kunna arbeta med det direkt från backloggen. De som inte är lika prioriterade har mindre information och flyttas sedan fram utefter prioriteringslistan.
En product backlogs uppgifter bryts isär så att de olika delarna blir hanterbara och lättare att utveckla.
Definition of done är ett begrepp som används flitigt. Detta är en överenskommelse av när saker är färdiga. Hur markerar vi när något är färdigt och när tycker vi att det är färdigt? Att ha en DoD ökar konflikthanteringen.

Sprint backlog

En lista av vad som ska göras denna sprint
Den redigeras bara under sprint planning mötet. Till skillnad från PB

Increment

En del av projektet som mött DoD
Som en "stepping stone" mot projektets slutmål.

Roller

I ett SCRUM-projekt finns tre olika roller. Vi har en Product Owner, Scrum Master och ett Development Team. Dessa roller och deras arbetsområden är följande.

Product Owner (PO)

En person, kan inte vara ett delat ansvar.
Äger och hanterar "Product Backloggen"
Prioriterar vilket arbete som ska göras när.

Scrum Master (SM)

Ser till att vi följer SCRUM arbetssättet.
Håller ordning på när mötena ska hållas och ser till så att alla deltar.
Finns för nytta till Product Ownern, Teamet och Organisationen.
Scrum Mastern är som domaren i en fotbollsmatch.

Development Team (DT)

Medarbetarna i teamet som för arbetet framåt.
Ingen i Teamet har ledande roll utan detta bestäms sedan innan tillsammans med product ownern.
En prioriterings punkt per person.
Mellan 3 - 9 personer.
Ansvarstagandet i teamet är delat, det är allas ansvar att saker levereras i tid.

Time Boxning

Innebär att en maxtid för durationen av en uppgift sätts. Krävs en viss lärdom och erfarenhet för att göra korrekta tidsuppfattningar. Fokuserar deltagarna på att skapa det bästa resultatet på rimlig tid.

Sprint

Den tidsperiod vi jobbar på projekt. En sprint är 30 dagar eller färre.

Detta limiterar risken att vi slösat tid på en felaktig kravspec t.ex. Det skapar också fokus och en realistisk horizont, samt minimerar att man är oförberedd på en stor förändring. Det är vanligt att de är något kortare. Alla sprintar har samma längd och de startar och avslutas på samma dagar. Detta sätter takten i företaget och ger en rutin. Vi har ett mål.

Velocity

Hur mycket tid kan vi lägga på varje sprint? Vi tar lärdom av tidigare projekt för att få ett omfång av vilken tidsåtgång som kan väntas. Som prognoser. I varje sprint antecknas och sparas tidsregister. Ofta mäter vi tid i Units of work och en unit är i de flesta fall timmar.

Det finns fyra typer av SCRUM möten eller Scrum Events.

Sprint planning

2 timmar avsätts per vecka av sprinten. Tar tid men det är värt det.
Hela SCRUM teamet är med.
Förutsätter att det finns en product Backlog som har prioriteringsordningen.
Skapar en Sprint Backlog. Toppen av prioriteringarna i Product Backlog blir sprint backlog. Kan ett mål sättas?
Skapar en tidsfångst för sprinten, hinner alla med?
Sprinten påbörjas.

Daily Scrum

Regelbundet möte varje dag samma tid.
3 frågor besvaras. Vad gjorde du igår? Vad ska du göra imorgon? Har du några hinder framför dig?

Sprint Review

Sker i slutet av sprinten.
1 timme per vecka av sprinten.
Scrum teamet och alla som vill se
Visar upp vad som har skapats.
Frågeställning till åskådare "Vad tycker ni"
Feedbacken läggs in i product backlog.

Sprint Retrospective

Hela SCRUM teamet deltar
Har sprinten gått bra?
Behöver vi ändra på DoD
Åttag nya beteenden och standarder.

Product Backlog Grooming

Hur jobbar vi med Product backlog? Detta är PO:s och DT:s ansvar, en pågående process som fortgår regelbundet. 10% av Sprintens tid ska gå till denna aktivitetet. DT:et är ansvariga för alla tidsuppskattningar och PO:n är ansvarig för alla värde uppskattningar. Vad har det för värde för produkten/kunden.

Product Backlog Regler

Tillgänglig för alla som vill se den inom företaget. Vart ligger mina förslag i prioriteringsordningen t.ex. Är inte product backloggen klar ställs Sprint planeringen in.

DT:s Regler

Registrerar hur lång tid man har kvar på sin uppgift, hur många tider är det kvar. Görs dagligen.
Var med / delaktig i Daily scrum
Se till att ansvara för arbetet.
Se över DoD, är det rimligt?
Produktiviteten sparas i varje sprint som Velocitet.

PO:s Regler

Maximerar värdet av produkten och arbetet som läggs.
PO: är alltid ansvarig för prioriteringen av product backlog.
Måste respekteras av organisationen för att SCRUM ska funka.
Ser till att Product Backlog är färdig för varje sprint planering.

SM:s Regler

Se till att möten hålls
Bestämmer inte över arbetet
Coachar teamet till högre nivå.
Det är en chefsposition som inte 'delegerar' uppgifter.

Burn Down Chart, Planning Poker

En burndown chart visar mängden pågående uppgifter från backloggen minimeras. Detta gör att man på ett grafiskt och tydligt sätt kan se att man möter rätt tid fångst. Planning poker är ett sätt att visualisera tidsåtgång samt olika delar av development teamets själv-uppskattade möjligheter att slutgöra olika uppdrag.

KANBAN

Är en agil metod som fått sitt namn från japanskans kan "visuellt" ban "kort". I industrin är ett "kanban" ett orderkort. Det används för att fylla på något i tid. Det reducerar inventariet och förbättrar produktionsflödet. Kanban introducerades för första gången av Taiichi Ohno som en del av Toyotas produktionssystem.

Kanban eller Kanban metoden hänvisar till processen, en kanban däremot är ett kort, tecken eller token som används i en process.

En implementation av kanban kan resultera i:

Förbättrad arbetskvalité.
Snabbare hantering av arbets förfrågningar.
Identifiering och eliminering av "bottlenecks". Dvs begränsningar
Reducerar kötider
Förbättrat lagarbete.
Reducering i slösad tid och engagemang.

Kanbans två grundprinciper innebär att vi

Visualiserar arbetet
Limiterar mängden uppgifter som utförs av en person / team på samma gång (WIP)

Varför visualisera arbete?

Tillåter dig själv och andra att se vad du gör
Reducerar stress
Reducerar risken att du glömmer något
Ger insikt
Förbättrar din förmåga att ta bra val, t.ex:

Vad ska jag jobba på just nu?

Hur mycket mer kan jag ta på mig ansvaret för?

När borde jag säga nej till nya förfrågningar?

Vad kan jag inte jobba med för tillfället?

Hur lång tid lägger jag på allt?

Varför ska vi limitera WIP?

Reducerar slösande av resurser.
Förbättrar kvalité
Förbättrar flow/genomströmningen
Little's Law ( längden på kön = Ankomst Hastigheten * Medel Väntetiden )
Väntetid (wait time) ( Längden på kön / Ankomst Hastigheten )
Cycle Time

Cycle time är den effektiva arbetstiden och lead time är totala tiden.

Man kan också säga att kundens helhetsupplevelse kommer matcha lead time. Alltså från att kunden skickar in sin ticket (el. dylikt) tills att hens ärende påbörjas tills att det är klart. Medan vi som arbetar eller tar emot ärendet kommer uppleva den totala tiden som cycle time. Från att vi påbörjat ärendet tills att det är klart. Värt att ha i åtanke.

Det finns två sätt att minska Cycle time.

Jobba fortare
Minska WIP

Value Stream mapping

Värdeströmskarta, hur mycket tid går åt att arbeta och hur lång tid går till spillo?

När vi räknar på effektiviteten så ställer vi den faktiska tiden som gått åt att lösa en ticket mot den totala tiden.

Summering:

Kanban möjliggör en visualisering av arbetet
Kanban används frekvent i arbetslivet
Produktionsprocessen borde optimeras för att maximera flöde, inte kapacitet.
De två viktigaste principerna är Visualisera arbetet och Limitera WIP (work in progress)
Little's law visar hur responstiden förbättras direkt med en reduktion av WIP.
Value Stream Maps är användbara verktyg för att identifiera slöseri och kvantifiera (mäta) processens effektivitet.

Personlig Kanban

Det är ett faktum att majoriteten av mänskligheten blir mer och mer upptagna med diverse uppgifter dagligen. Där kan man använda KANBAN som ett verktyg för att förbättra organisering och workflow.

Personlig kanban etablerar två simpla regler och tillför många alternativa tillvägagångssätt för att organisera ditt arbetsflöde.

Att visualisera sitt arbete görs enklast med tre listor eller anslagstavlor.

Redo att göras, görs, klart. Sedan kan vi enkelt flytta olika uppgifter mellan de tre tavlorna.

Detta gör också att vi kan reflektera på ett enklare sätt. Vad har vi gjort, vad kunde vi ha gjort annorlunda.

Hur kommer man igång?

Samla material:

Post It Lappar, whiteboards, suddbara pennor t.ex.

Etablera din value stream:

Uppgift / Pågående / Klar
Fokusera på att göra klart en uppgift i taget, spendera inte för lång tid på att organisera.

Etablera en WIP Limit:

Du kan ändra detta i efterhand. Börja t.ex med att ha max 3 uppgifter i "pågående"

Flytta dina lappar till "klar"

Gör klart och flytta så många lappar till "klar" som möjligt.
När du flyttat bort en lapp till klar, flytta en ny från "uppgift" till pågående och börja jobba.

Reflektera

Hur hanterar vi blocks?

En block är när en uppgift blir blockerad. Den kanske är beroende av någon annan medarbetare eller ett visst datum / tillfälle etc. Då kan det behövas en fjärde value stream eller kolumn. Där kan man också föra information om när uppgiften kan lösas. T.ex om den är bunden till ett visst datum.

Om det finns för mycket i uppgiftslistan:

Organisera enkelt genom att lägga till en "dagens" tabell. Där kan du flytta över uppgifter som är lämpliga att göra dagen till ära.

Tre ledord, Productive, efficient, effective.

Productive:

Få saker gjorda
Genom att limitera WIP och säkerställa att något blir klart hjälper Kanban oss att genomföra mer.

Efficient:

Att jobba smartare inte hårdare
Fokusera mer på value stream. Personlig Kanban motiverar oss att hitta sätt att göra saker med mindre ansträngningar.

Effective

Få rätt saker gjord i rätt tid.
Ger en kontext som tillåter en JIT prioritering. Personlig Kanban hjälper oss att göra informerade val, detta gör oss i sin tur mer effektiva.

(JIT = Just In Time)

KANBAN i Team

Funkar som ett löpande band. Om vi visualiserar Value Streams som olika delar av en fabrik. Där en del av fabriken representeras av en stream location, antingen i upstream eller downstream. Då levereras först delarna till fabriken. Produktionen påbörjas kanske med att det monteras hjul på bilarna. Sedan ställs de i "lager" innan nästa steg i processen påbörjas. Nästa steg kanske är att montera alla bilens rutor. Skulle det då ha blivit något fel med bilens däck kan den komma att behöva skickas tillbaka i processen.

Upstream representerar i det här fallet producenten av produkten.

Downstream däremot är kunden som konsumerar produkten.

I fabriken flyttas inga bilar eller delar utan att ha en Kanban (ticket/order). Något som är defekt eller inkorrekt monterat flyttas ALDRIG downstream utan kan bara flyttas tillbaka i processen Upstream antalet pågående Kanbans minimeras för att öka flödet i "fabriken". Målet är att ha så få kanbans igång som möjligt, samt mängden kanbans som rör sig i motströms i vår fabrik.

Recept för att lyckas med Kanban I team eller utvecklingsmiljöer

Fokusera på kvalité:

Kvalité varierar stort i IT branchen.
Hela teamet måste acceptera att kvalité är en viktig faktor i projektet.
Om du har en process som producerar fel är din process felaktig
Väldefinierade ärenden som går bra att åtgärda
Minska antalet WIP ökar kvalité

Reducera mängden WIP:

Ju längre tid ett ärende tar desto större risk är det att det blir defekt
Fokus går förlorat

Leverera ofta:

"Leverera fungerande mjukvara ofta"- The agile Manifesto
Reducerad WIP kortar ner "lead time"
Kortare "lead time" bidrar till mer frekvent producering
Frekvent producering leder till förtroende.

Balansera efterfrågan mot genomflöde:

Matcha kapaciteten i ditt team med den pågående mängden efterfrågan.
"Flaskhalsar" synliggörs och slack skapas i viss mån. Detta ger utrymme för reflektion och förbättring.
Optimera för flöde snarare än att konstant vara upptagen.

Prioritera:

Prioritering kan ligga utanför "teamets" kontroll.
Teamet kan dock påverka detta. Men för att få möjlighet att påverka krävs tillit.
Prioritera företagets värde.

Attackera källor där det finns utrymme för variation för att förbättra förutsägbarheten:

T.ex att olika kanbans har olika storlek. Bryt ner dem i liknande storlek för optimering.
Prioritera uppgifterna rätt.
Viss policy kan resultera i skillnad på leveransfrekvens. Med bättre regler och policys kan vi öka regelbundenhet.

Hur implementerar vi Kanban i Team:

Var börjar processen, hur sker överlämnanden av kanbans?
Identifiera de olika typerna av arbete som kommer behövas.
Gör value streams och definiera deras namn och funktion.
Skapa en maxgräns på WIP // kort mängd.
Skapa köer och buffertar.

Trello, Planner, AgileZen, LeanKit, och TargetProcess kan användas för kanban i arbetslivet.

SWOT : Analys

Står för

Strengths
Weaknesses
Opportunities
Threats

Med hjälp av en sådan analys kan vi definiera projektets styrkor, svagheter, möjligheter och hot redan innan vi påbörjar ett projekt.

Entreprenörskap

Att sälja projekt internt handlar om att göra våra argument anpassade efter mottagaren.

Beskriv affärsnyttan
Beskriva lösningen översiktligt
Ha en uppskattning av projektets kostnad
Tänk på vem som är mottagare

Finansiering

Cash flow, vad är företagets likviditet?
Abonnemang är oftast mer attraktiva för nystartade företag.
Avskrivningar, ett köp över 10000 kr som kommer användas i mer än 10 år. T.ex möbler, servrar osv. Ses som en tillgång under många år fast vi gjort ett utlägg för allt direkt.

Olika investeringar beroende på företagets läge

I vissa fall är det viktigare med en billig lösning som ger resultat snabbt.
I andra fall är det viktigare att leverera snabbt oavsett pris. T.ex konkurrensmötande saker.
I andra fall är långsiktiga lösningar viktigare.

Hur prioriterar vi detta? Gör en analys av företagets likviditet och läge.