Anonim

Agility är ett buzzword som har drabbat nästan alla företag. På beslutsnivå får ämnet affärsmässig agility, dvs det smidiga sättet att arbeta för ett företag, allt viktigare. Som ett resultat försöker företag att öka sin hastighet på innovation och anpassning betydligt genom initiativ som mjukvaruutveckling. Mot utvecklingen i det lugna lilla rummet och långt borta från arbetsuppgiftsavdelningen, bör smidigheten hjälpa. Men innan projektledare blankt litar på löftena från Scrum och Kanban, är det viktigt att förstå idéerna bakom metoderna och anpassa dem till verksamheten.

Keine Softwaremethodik ist per se gut oder schlecht. Vielmehr muss es stets darum gehen, die richtige Methodik für das richtige Produkt und die gegebenen Rahmenbedingungen auszuwählen.
Ingen mjukvarumetodologi är bra eller dålig i sig. Snarare måste det alltid handla om att välja rätt metod för rätt produkt och de givna ramvillkoren.
Foto: Olivier Le Moal - shutterstock.com

Sedan början av modern programvaruutveckling finns det olika sätt att skapa programvara. De mest kända och mest utbredda metoderna under de senaste tio åren är:

• Vattenfall, dvs utvecklingen av programvara successivt i steg med feedback.

• V-modellen, som inkluderar integration av kvalitetssäkringsaspekter i vattenfallsmodellen.

• Evolutionära eller inkrementella modeller, dvs. gradvis utveckling av programvaruprodukten och

• som en vidareutveckling av nuvarande vanliga smidiga metoder som Scrum.

Under tiden blir trenden tydligt smidig som de facto-standarden för att bygga modern programvara, där Scrum och Kanban dominerar som metoder som används.

En anledning till denna utveckling är hur snabbt nya affärsmodeller och produkter och tjänster kommer in på marknaderna.

En titt på Fortune 500-företagen visar påverkan av marknadsförändringar på företag och behovet av anpassning. Och i allt kortare cykler för att överleva på marknaden. I många fall dominerar digitala infödda marknaden och har erövrat den genom moderna arbetsmodeller. Dessa företag släpper innovationer på marknaden med mycket snabbare intervaller än många av de etablerade tyska företagen.

spoods.de
  1. Produkt- och projektledare
    I allmänhet gillar inte utvecklarna det så mycket när någon vill förklara hur man gör sitt jobb. Men eftersom produkt- och projektledare ofta hanterar utvecklingsteam är det exakt vad som händer, vilket kan leda till meningsskiljaktigheter.
    DevRants David Fox har också en åsikt: "I slutändan är produkt- och projektledare i de flesta fall" ägare "av projekt och processer, utan programvaruutvecklarnas dagliga utmaningar och problem vet. "
  2. chefs
    Liksom produkt- och projektledare ansvarar utvecklings- eller teknikchefer för att leda team av utvecklare och se till att projekten genomförs i tid och budget.
    "I vissa företag kan situationer uppstå där chefen också är medlem i utvecklingsgruppen, och särskilt om chefen var en utvecklare innan han blev chef efter att ha blivit promoterad finns det potential för konflikt, " konstaterar Fox.
  3. rekryterare
    Programvaruutvecklare behöver inte ens aktivt leta efter ett jobb som ska trakasseras av rekryterare och headhunters - tack vare bristen på skickliga arbetare. Det skulle vara mycket svårt att hitta en utvecklare som ännu inte har fallit i rekryterens kopplingar.
    I synnerhet ser David Fox rekryterarens uthållighet som ett problem: "De ringer dig, e-postar dem, och de kommer bara inte att lämna dig ensam - även om du inte letar efter ett jobb, och även om du letar efter ett jobb, tenderar många rekryterare att att göra irrelevanta jobberbjudanden eller att rekommendera jobb vars profil inte alls passar - till exempel ett jobb på andra sidan landet, även om du inte är redo att flytta. "
  4. dokumentation
    Om det inte finns någon dokumentation, klagar programvaruutvecklarna. Om det är för mycket, klagar de och om de måste göra dokumentationen också. Även utvecklare klagar över hur andra människor behärskar dokumentationsuppgiften.
    Vid denna tidpunkt är slutligen alla utvecklare överens om, eftersom Fox betonar: "Programutvecklare vill ha en detaljerad, välskriven och korrekt dokumentation - men de vill inte göra det själva."
  5. möten
    Möten är inte bara ett problem för alla andra, utan också för mjukvaruutvecklare. Särskilt när det gäller helt onödiga, tidskrävande och stink tråkiga möten. Enligt Fox finns nu också hängivna artiklar som säger "Jag har överlevt ett annat möte som borde ha varit på en e-post".
  6. Medarbetarutrymmen
    Med ökningen av smidighet har plana hierarkier, samarbete och lagarbete blivit vanliga i företag - särskilt för mjukvaruutvecklingsteam. Men särskilt de som arbetar på ett öppet kontor kan knappast klara eller inte alls - säger åtminstone siffrorna från devRant.
    David Fox förklarar, "Det är bara för mycket distraktion: kollegor pratar, möten är missade, telefonsamtal missas och det finns många klagomål om kaffe på kontoret och andra bekvämligheter - eller tvärtom."
  7. kollegor
    Självförklarande: Alla har förmodligen en kollega som han särskilt uppskattar. Inte.
    När det gäller mjukvaruutvecklare beror kollegornas ogillar mest på antingen bristen på kvaliteten på deras arbete eller ett helt otillräckligt slags ego, säger David Fox.
  8. intervjuer
    Om en mjukvaruutvecklare letar efter ett jobb och är inbjuden till en jobbintervju, är det vanligtvis något att klaga om:
    "Dumma frågor eller lösningen av helt opraktiska uppgifter i jobbintervjun är lika upprörande för utvecklarna som en samtalspartner som inte ens vet vad en utvecklare faktiskt gör, " säger Fox.
  9. Fel & buggar
    Programvaruutvecklare måste hantera fel och buggar dag ut och dag in. Det är därför devRant-grundaren Fox tror att utvecklare kryssar annorlunda i den här frågan:
    "De flesta andra problem upplever inte en positiv upplösning, men buggar och buggar är fixerbara och det känns bra."
  10. Kvalitetssäkring
    Kvalitetssäkring (QA) - eller kvalitetssäkring - är en kritisk del av mjukvaruutvecklingen. Men programvaruutvecklare klagar ofta till QA-experter om samma saker som produkt- och projektledare, säger Fox.
    "QA får produkten eller projektet i sina händer när utvecklarna är färdiga, så de förstår ofta inte hinder och lösningar som utvecklarna var tvungna att hantera i utvecklingsprocessen." Det är också vanligt att QA-människor frågar utvecklarna Att omarbeta områden som de kan hantera själva. "

Vattenfall som ett smutsigt ord

Mot denna bakgrund betraktas "vattenfall" nästan som ett svär ord och ett tecken på att företag som fortfarande använder denna metod för mjukvaruutveckling ännu inte har kommit fram i modern tid. Observera dock:

1. Ingen mjukvarumetodologi är bra eller dålig i sig. Snarare måste det alltid handla om att välja rätt metod för rätt produkt och de givna ramvillkoren. Det har alltid varit så. Tyvärr är det ofta så att ingående kunskaper om de olika metoderna och deras implementering inte är tillgängliga. Dessutom verkar hoppet om "en metod" som löser allt leda till oönskade förenklingar.

2. Vattenfall beskrivs ofta muntligt på följande sätt: "I månader registreras krav, sedan byggs programvaran i månader, och först då ser specialavdelningen programvaran som en del av testet." I detta scenario skulle enligt kritikerna avdelningarna få programvaran presenterad mycket för sent, förändringar skulle vara mycket dyra och flexibilitet skulle inte verkligen existera. Mot denna bakgrund lönar det sig att läsa vad vattenfallsmetoden verkligen säger. 1970 publicerade Winston W. Royce sitt papper "Hantera utvecklingen av stora mjukvarusystem", han anses vara en av grundarna till vattenfallsmetoden. När man läser är det slående: Dokumentation är en absolut nyckelfaktor i utvecklingen av programvara för Royce. Detta verkar strida mot dagens smidiga metodik. Här bör emellertid följande beaktas:

• Å ena sidan talar det välkända Agile Manifesto inte om att det inte krävs dokumentation utan väger helt enkelt "arbetsprogramvara" högre än "omfattande dokumentation".

• Å andra sidan beror den nödvändiga dokumentationsnivån alltid på typen av system som ska utvecklas.

Royces arbete innebar att skapa programvara för planering, genomförande och analys av rymduppdrag. Man kan föreställa sig att sådana system kräver en mycket hög grad av dokumentation.

Det är också anmärkningsvärt att Royce erkände riskerna med sin vattenfallsmetodik vid den tiden och i sitt papper föreslår också hur denna risk kan minimeras, nämligen av

• Skapande av en vision och en initial design av den målprodukt som ska nås i början av projektet,

• Skapa en tidig prototyp i betydelsen av körbar programvara som ständigt utvecklas, och

• Slutkundens delaktighet i varje fas i utvecklingsprocessen.

Alla dessa saker skulle tillskrivas idag snarare till "agilisternas" läger.

Det bör också komma ihåg att många av koncepten bakom dagens smidiga tillvägagångssätt inte nödvändigtvis är nya. För huvudramens bröllop samverkade utvecklarna vanligtvis direkt med avdelningarna och nya produktversioner visades live i små cykler. Tyvärr har emellertid många industrialiserade och CMMI-åldrar införts många hierarkiska strukturer och processer som har tagit bort utvecklaren allt längre från slutanvändaren.

Smidiga principer

För att vara tydlig är de smidiga principerna viktiga för dagens verksamhet. Åldern för den industrialiserade mjukvaruutvecklingen har lett till många överskott som har korrigerats av den smidiga rörelsen. Detta är grundläggande, korrekt och en grundläggande förutsättning för att implementera det faktiska ämnet - nämligen att göra företaget som en helhet "smidig" - och att öka sin egen innovativa hastighet avsevärt.

Det är emellertid viktigt att inte falla i fällan och lita blint på en metod som Scrum eller SAFe. Principerna bakom att förstå dem och anpassa metodologin till situationen med erfarna människor är mycket mer avgörande än metodiken. Och smidig programvaruutveckling är i sin tur bara en liten byggsten för ett verkligt smidigt företag.