Bli smidig
Agile - Svara på förändringar i osäkra situationer

Agile definieras (enligt Agile Alliance) som “Förmågan att skapa och svara på förändringar för att lyckas i en osäker och turbulent miljö.”

Agile skiljer sig från alla andra tillvägagångssätt för utveckling av programvara på grund av sitt fokus på människorna som gör jobbet och hur de arbetar tillsammans. Lösningar utvecklas snabbare och med kvalitet genom samarbete mellan tvärfunktionella team. Detta är viktigt eftersom byggprogramvara i sig kan vara oförutsägbar. Skapa programvara är en unik (skräddarsydd) process och bör inte förväxlas som råvarukompetent arbete. Metoder som möjliggör snabb återkoppling, kvalitetstest, integration och påverkan på perifera applikationer är alla områden som ingår i Agile-metoder.

Först lite historia

Innan Agile slutfördes produktutvecklingen med Vattenfall eller V-modellmetodik. Att använda denna metod för att skapa stabil programvara var minst sagt inte effektiv. Missade tidsfrister, omfattningskrypning, ofta sprängande budgetar och misslyckande helt blev vanliga resultat. Att veta att denna lösning inte fungerade, på 1990-talet presenterades en revolutionerande ny metod som erbjuder mycket mer än vad den kunde lösa, Agile hade tagit sina första steg för att hantera mjukvaruutveckling.

Agile skulle inte alls vara det universalmedel som behövs för att helt lösa alla utvecklingsproblem; men det tog upp kritiska frågor och gav en beprövad ram för att ge en mer jämn framgång än tidigare modellmetoder.

Alla Agile-metoder delar vanliga kärnidéer. Varje Agile-metod använder dessa subtilt på sitt eget sätt, vare sig det är iterativ och inkrementell leverans av kod, samarbetsfrekvens med intressenter, arbetar nära, självorganiserande team och viktigast av allt, dess förmåga att omfamna förändringar sent i projektet. Dessa varierande Agile-metoder delar många komponenter och det kan bli ganska ögonöppnande när det gäller inbäddad användning av varandras tekniker och stilar.

Fördelen med denna interoperabla Agile-design av olika metoder är att det blir väldigt enkelt att använda Agile-metoder med tanke på begreppens kompatibilitet. Tänk på det som ett smidigt smörgåsbord eller en marknad där du kan välja och välja delar efter behag.

Det finns ett smidigt manifest som ger en uppsättning riktlinjer för dem som är intresserade av att bli smidiga. Det är dock inte en uppsättning regler och definierar inte heller några processer specifikt. Med detta sagt har manifestet gett en bred definition av vad som utgör en Agile-metodik.

låt oss undersöka några Agile-metoder som finns tillgängliga idag:

Klunga

Vi listar först Scrum eftersom det fortfarande är den mest populära Agile-metoden i spel. Det har blivit "go-to" -tekniken för att behärska Agile. En del av dess framgång vilar på mängden dokumentation och förbyggda processer för tillgängliga team.

Scrum kan verka främmande för oerfarna lag. Dess största framgång fördubblas som dess största svaghet. Det fungerar bra med utbildade team som kan arbeta med snäva tidsfrister, dagliga möten och fokusera på höga utsläppskvalitetsmål med varje produkt iteration (sprints).

De framträdande rollerna i Scrum inkluderar ScrumMaster, produktägaren och teammedlemmen.

·        ScrumMaster

o  Superlagledaren (dock inte en lagmedlem)

o  Håller teamet fokuserat på målen för varje iteration

o  Säkerställer att alla agila principer följs

o  Håller eftersläpningen uppdaterad (med produktägaren) och löser problem som sätter schemat i riskzonen


·        Produktägare

o  Prioriterar kraven

o  Gör förändringar från prioritering baserat på feedback från intressenter

o  Produktägare väljer inte vilka krav som går in i en sprint. Det är baserat på efterfrågan och mängden arbete som ska slutföras i en viss sprint med eftersläp i åtanke.

·        Lagmedlemmar

o  Denna grupp designar, kodar test och producerar produkten.

o  Sprintmål kräver att teamet är tvärfunktionellt för att kunna svara på olika behov vid varje given tidpunkt.

o  Teammedlemmarna som helhet är ensamma ansvariga för att nå alla mål.

Scrum definierar sina specifika områden mycket väl i sin dokumentation. Alla områden som saknar tydlighet stöds vanligtvis genom att dra processer från andra koncept.

Extrem programmering (XP)

Tanken bakom den här var att utnyttja programmeringsmetoderna på bästa sätt och ta dem till ‘extrem’. Även om inget av de enskilda koncepten för XP är nytt, är deras tillämpning och kombination det som gör XP idealiskt unikt. Det uppnådde sin högsta popularitet på 2000-talet.

XP: s huvudkoncept är ett av anpassningsförmåga; att erkänna att varje projekt kommer att möta utmaningar och att använda metoder för att lösa utmaningen för ett kanske inte fungerar för andra. Konceptet gör det möjligt att välja vilken som ska fortsätta framåt medan man kasserar andra. Det är inte ovanligt att se delvis XP i spel på ett projekt som huvudsakligen körs enligt en Scrum-metodik.

I likhet med Scrum omfattar XP också standarder som korta iterationsperioder. De går vidare till nästan omedelbar och regelbunden testning, nära intressenter på plats med direkt feedback och teammedlemmar som har ansvar för framgång eller misslyckande.

Testning tas till det yttersta med så många tekniker som behövs och så ofta som möjligt. Om det är praktiskt rekommenderas dagligen integrationstest. Om inte, kommer det att vara minst en gång i veckan. Det är här XP: s förmåga att anpassa visar dess användning.

Att tänka på att två huvuden är bättre än ett, är parprogrammering en del av XP. En person kodar medan den andra observerar, ger feedback, upptäcker potentiella hinder samtidigt som den stora bilden i åtanke. Det är en bra teknik förutsatt att paren byts ut med relativ frekvens för att undvika att par blir för bekväma med varandra och faktiskt förvandlar två huvuden tillbaka till ett.

Kanban

Den här är unik eftersom den är smidig utan att vara iterativ. Kanban tittar på helheten i att programvaran utvecklas i en stor utvecklingscykel. Det verkar motsägelsefullt som en Agile-lösning, men Kanban uppfyller alla tolv Agile Manifesto-principerna eftersom det ses som mer inkrementellt än iterativt.

Principen för Kanbans inkrementella process för att möta Agiles iterativa likhet är via Kanbans begränsade genomströmning. Kanbans-projekt har inga definierade start- och stoppslutpunkter för enskilda arbetsobjekt. Varje start och stopp oberoende utan att arbetstiden ingår. Fokus här är på varje fas av livscykeln som har en begränsad förmåga att arbeta åt gången. Genom att kontrollera antalet aktiva aktiviteter samtidigt kan utvecklare se projektet som stegvis eftersom ett arbetslag inte kan gå framåt förrän någon kapacitet öppnas framåt.

Det finns fler

Var och en kritisk i sig, följande används utanför de tre viktigaste Agile-metoderna som diskuterats ovan.

DSDM Atern

·        Sätter kvalitet och schemaläggning först

·        Använder MoSCoW som metod för prioritering

o  Måste ha

o  Borde ha

o  Hade kunnat

o  Kommer inte att ha den här gången

·        Åtgärdar begränsningar av Scrum genom att inkludera utvecklingsfaser före och efter, vilket gör detta till en verklig projektledningsprocess.

Disciplinerad Agile Delivery (DAD)

DAD utökar sitt ramverk till att omfatta områden som ligger utanför programvaran till hela produktprocessen.

·        Använder självorganiserande, tvärfunktionella team. (aka generaliserade specialister)

·        Främjar en miljö för att inkludera lärande användarnas behov, hur man förbättrar processer och tillväxt i teknisk kunskap.

·        Efterlevnad av det smidiga manifestet

·        Användning av kompletterande Agile-metoder som kan anpassas till det aktuella projektet (Scrum, XP, Kanban)


Agile Unified Process (AUP)

·        Projektledning är en viktig disciplin i denna process.

·        Mer ‘uppriktig’ lastad – kräver avsevärd modellering innan implementeringen börjar.

Feature Driven Development (FDD)

·        Den här är fortfarande diskutabel om det faktiskt är en smidig process.

·        FDD implementeras iterat, inte i enlighet med affärsbehov som beslutats av produktägaren. Behovet bestäms istället av det funktionella området.

Lean Software Development

·        Mindre av en process och mer av en uppsättning principer att leverera med.

·        Principer kan läggas på de flesta större Agile-metoder.

·        Identifiering och eliminering av slösaktigt arbete til