Share
Agile eller Agile Development - vi hör dessa ord oftare dessa dagar. Men vet vi verkligen vad det handlar om? Hur kan det hjälpa oss att bli effektivare, samtidigt som det har mycket roligt utvecklingsprogram? Hur kan vi använda den för att kommunicera med affärsmän och göra denna kommunikation enkel och konstruktiv för båda sidor?
Det fanns en massa mycket begåvade och erfarna killar som utvecklade en seriös programvara. Dessa utvecklare observerade andra företag och utvecklingsgrupper, och hur deras processer gjorde sitt arbete enklare. De sammanställde sina observationer för att skapa Agile Manifesto. Och de sa:
Vi upptäcker bättre sätt att utveckla programvara genom att göra det och hjälpa andra att göra det. Genom detta arbete har vi kommit att värdesätta:
Det vill säga, medan det finns värdet i objekten till höger, värderar vi objekten till vänster mer.
I denna artikel kommer jag att presentera tolv teorier och tekniker för Agile Development. Detta är bara det första steget till den nya världen av mjukvaruutvecklingsprocessen.
Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull men inte fullfjädrad programvara. Det innebär att vi utvecklar programvara och lägger till minst en funktion per iteration.
Låt oss föreställa oss att vi vill skapa en bloggmotor; det kan vi göra med hjälp av följande process:
Det är ett enkelt tillvägagångssätt, men kunden ser den verkliga utvecklingen av sin programvara och ger dig omedelbar feedback om varje ny funktion. Det kan vara perfekt eller kräva tweaking, men du kan snabbt reagera på förändringar: en win-win-situation.
Ännu sent i utvecklingscykeln möjliggör Agile processer dig att välkomna förändringar för kundens konkurrensfördel.
Kunden vill att projektet ska slutföras snabbt och så nära designen som möjligt. Detta uppnås enkelt genom att bara lyssna på deras inmatning och vara redo för ändringar. Om vi snabbt kan reagera på förändrade krav är vi förmodligen det bästa valet som kunden någonsin har gjort. Agile handlar om kommunikation och förändringar. Vi gör sakerna som vi uppmanas att göra, vilket gör att mjukvaruutvecklingsprocessen blir snabbare. Detta uppnås eftersom vi utvecklar små bitar av programvara, och en förändring av kraven påverkar inte oss verkligen.
Vi bör leverera uppdateringar från ett par veckor till ett par månader. desto kortare är tidsperioden.
kunder känner sig mer självsäker i oss och vår produkt som den är uppdaterad
Från mina erfarenheter känner kunderna mer självsäkerhet i oss och vår produkt som den uppdateras - vilket är viktigt för vårt förhållande till dem. En annan fördel är återkopplingen från vår klient; tillåter oss att reagera genom att ändra klasser, funktioner, moduler eller till och med arkitekturen. Vi kommer inte vakna efter dagar eller månader av arbete, bara för att se att allt går in i papperskorgen. Låt oss överväga en hypotetisk situation:
Du har blivit ombedd att skapa en modul som visar en viss enkel text i en innehållshanterare. Plötsligt ändras kraven och du måste lägga till ett formulär som ska skicka ett mail till en konfigurerad adress. Dessutom ska formuläret anpassas så att användaren kan lägga till nya fält och definiera validatorer. Så, du måste i princip glömma det ursprungliga enkla textkravet. Hur snart vill du veta om denna förändring?
Om du arbetar med ett projekt med din klient och levererar ofta, kommer du att känna till dessa förändringar snabbare och förändringar som det här blir enklare för er båda.
Det kan visa sig vara den svåraste principen att bli van vid, om du har utvecklat programvara i den gamla vattenfallsstilen. Du som utvecklare talar vanligtvis inte samma språk som din klient, men du kan hitta sätt att upprätthålla meningsfull kommunikation med dem. Ett av de bästa sätten är enligt min mening att beskriva allt med en enkel historia som berättar för oss, utvecklaren, för vilken funktionen är, vad ansvaret är och varför vi behöver det alls. Självklart blir det lättare ju mer vi jobbar med vår klient. Ett annat bra tillvägagångssätt är Behavior Driven Development (BDD), men det är ett ämne för en annan artikel.
Ge de människor du arbetar med miljö och stöd de behöver, och framför allt lita på att de ska få jobbet gjort.
Det är viktigt att skapa en engagerande atmosfär och alla verktyg som behövs för att skapa bra programvara. Företagen förlorar sina bästa arbetare för det mesta eftersom de inte bryr sig om dem själva. Tron på att utvecklare kan skriva, testa och distribuera programvara på vissa servrar med hjälp av en FTP-klient och redigera levande produktionsfiler gick vilse någonstans. Om du inte har fördömt de gamla skolvanorna, gör du det bättre nu.
Att behålla anställda är bara en fördel; Du kan också utveckla bättre och större programvara i en snabbare takt. Tänk bara på det: Att skriva om återanvändbar kod, automatiska tester och automatiserad utplacering på någon server (bland annat) kan påverka utvecklingstiden positivt. Vi tror oftast att vi saktar ett projekt eftersom vi måste lära oss att använda användbara verktyg, som Jenkins, GIT, SVN, Gerrit, Behat etc. Vi gör det franklyst, men vi kan sedan återanvända dessa verktyg och koncept i framtida projekt.
Det är den mest effektiva och effektiva metoden att förmedla information till våra kunder och utvecklingsteam.
Vem har inte blivit överväldigad och / eller arg genom att se 6 255 384 e-postmeddelanden i din inkorg, eftersom ditt företag kräver att alla samtal är "på papper"? Jag har personligen sett det några gånger i mitt liv, och jag rekommenderar inte att arbeta i ett företag med sådana vanor. Ansikts-konversationer gör kommunikationen enklare och mjukare och tillåter oss att ge mer information. Vi kan använda verbala och nonverbal sätt att kommunicera för att visa våra lagkamrater vad vi tänker. Det är uppenbarligen snabbare än att maila varandra.
Men framför allt måste vi lita på varandra; tillit är lätt att vinna i en miljö som uppmuntrar ansikte mot ansikte kommunikation.
Detta är en av mina favoritregler det låter oss arbeta fritt enligt våra egna processer. Programutvecklare är annorlunda än andra anställda; så naturligtvis bör de behandlas som sådana. Från min personliga erfarenhet har jag lärt mig att inte döma någon från utvecklingslaget så länge jobbet är gjort. Utvecklare vill inte skapa dålig programvara, och de är mindre benägna att göra det om vi låter dem arbeta enligt sina egna preferenser. När allt kommer omkring är kunden lycklig så länge det arbete de beställde är gjort korrekt. de bryr sig inte hur det gjordes.
Agila processer främjar hållbar utveckling, vilket möjliggör en konstant takt att bibehålla obestämd tid.
Agile mest kända fördelar (såsom acceptans av förändrade krav, snabb reaktion på feedback etc) uppskattas mycket, men den bästa fördelen är enligt min åsikt möjligheten att exakt bestämma hur länge ett projekt eller en funktion kommer att konsumera. Efter några leveranser kommer dev teamet att producera det mest värdefulla affärsnummeret: kapacitet. Kapaciteten är den mängd arbete laget kan göra i en iteration. Kapacitetsnumret är stabilt efter några iterationer, och vi kan undvika de löjliga deadlines och tidsberäkningar som "dras ut ur en hatt" och presenterar vårt företags erbjudande till kunden.
Många säger att det är omöjligt och schemaläggning visar sig vara mer exakt. Jag håller inte med; Schemat förutsätter att det inte kommer bli några misstag eller oundvikliga förseningar.
Det är en perfekt plan för ett perfekt lag, och det finns inte.
Kontinuerlig uppmärksamhet på vår bransch ökar smidigheten.
Vi förväntas utvecklas och göra framsteg. Vi måste fortsätta att lära oss varje dag, eftersom branschen rör sig i en så snabb takt. Eftersom både hårdvara och mjukvara blir bättre måste vi hålla oss uppdaterade. annars kommer vi att bli förlorade i "Nya havet" och det blir svårt att komma tillbaka på rätt spår.
Refactoring är lösningen på de flesta problem. Genom ständigt refactoring (vid behov) kan vi enkelt tillämpa nya tekniker och bättre vår mjukvaruarkitektur.
Bill Gates sa en gång:
Om jag har något komplicerat arbete att göra, ska jag ge det till den skönaste personen jag har, för att de kommer att hitta det enklaste sättet att göra det.
Enkelhet är den gyllene regeln. Det betyder inte att du måste vara lat, men det innebär att utvecklare komplicerar sitt eget arbete större delen av tiden. Om du bara gör jobbet vill kunden, utan några ytterligare funktioner och förbättringar, kommer din arbetsbelastning att tända och du kommer att uppnå dina mål. I slutändan är det all kunden bryr sig om.
De bästa arkitekturerna, kraven och mönsterna kommer fram från självorganiserande team.
Vi är bara människor; Vi kan inte förutsäga allt.
Har du någonsin varit i en situation där du utvecklade en stor och tidskrävande ansökan, och efter att ha spenderat otaliga timmar framför skärmen skrev tusentals kodrader och läste artiklar, handledningar och böcker, satte du dig ner och tittade på några dåliga (men fungerande) kodtänk, "Nu vet jag hur man skriver det bättre"? Jag tror att vi alla har haft dessa ögonblick.
Det här är den elfte regeln som kommer in. Vi har ett team av utvecklare som kan följa principerna för testdriven utveckling (TDD), där refactoring är en del av processen. På något magiskt sätt är vår programvara användbar, vacker, välskriven, testad och skapad snabbt. Vi är bara människor; Vi kan inte förutsäga allt.
Allt detta kommer från idén om ett självorganiserande lag, där varje medlem har en roll - inte given eller tvungen - men en som har uppstått efter en viss tid arbetat tillsammans. Det är skönheten i lagarbete.
Med jämna mellanrum behöver ditt dev-team reflektera över hur man blir effektivare och justerar sitt beteende i enlighet med detta.
Det kan kräva några utvecklingscykler, men laget kommer att fungera i perfekt harmoni. Även att lägga till nya personer till det här laget skulle inte vara skadligt. Ett agile utvecklingsteam handlar om att få jobbet gjort. Om de arbetar i en vänlig miljö kommer de att hitta "arbetsmelodi" och du ser hur snabbt programvaruutveckling kan vara.
Det finns några metoder som härleds från och bygger på agila principer. Jag kommer inte att beskriva dem alla eftersom varje metodik kan omfattas av sin egen artikel. Jag kommer emellertid att skissera några av de mer välkända Agile-metoderna. En sak att komma ihåg är att det inte finns någon metod för att styra dem alla. Välj en som passar dina behov bäst, och till och med "konfigurera" den så att den passar dina specifika krav.
SCRUM är skapad av Ken Schwaber och Jeff Sutherland, en affärsinriktad ram för hantering av mjukvaruutvecklingsprocesser. Det finns många olika typer av SCRUM; kom bara ihåg att huvudmålet är att arbeta effektivt, effektivt och inte hålla sig till reglerna.
Skapad av Kent Back är XP en lista över bästa praxis som utvecklare ska följa när du skapar programvara. Det kallas ofta "förlängningen av SCRUM". Denna metod för utvecklingsorienterade regler föddes, på grund av att SCRUM var ganska affärsorienterad.
Två av Leans huvudprinciper är: DALAP (Bestäm så sent som möjligt) och DAFAP (Lever så fort som möjligt). Jag rekommenderar personligen att läsa mer om denna metodik, eftersom det kan vara mycket användbart.
Det finns flera metoder inom agile familjen; Jag har helt enkelt refererat till de mest populära alternativen. Om du väljer att använda Agile i din utvecklingsprocess behöver du veta vad dessa metoder är för att välja rätt för dig.
Fungerar Agile tekniker verkligen?
Fungerar Agile tekniker verkligen, och är metoderna så magiska som alla säger? Inte alltid.
Det problem som jag stötte på i företag, där Agile-metoder inte gav resultat (eller till och med gjort sämre), var en dåligt utvald metodik och brist på övertygelse bland sina användare (företagsledamöter, utvecklingsgruppen, etc.). Därför måste du, enligt den här författarens åsikt, vara säker på att alla som är involverade i processen förstår reglerna och de vet "vad det handlar om".
Tack för att du läser!
Accentsconagua