Smidig beräkning. Hur program skapas med Agile -metodiken. Nackdelar med den klassiska projektledningsmetoden

Dessa tillvägagångssätt kallas också ibland ramar eller agila metoder.

Agile har sitt ursprung i IT -miljön, men sedan spreds det till andra områden - från industriteknik till artificiell intelligens.

När vi arbetar med professionella team använder vi Scrum, oftast väljer vi en 2-3 veckors cykel med retrospektiva möten som gör att vi kan hålla allt under kontroll.

Om vi ​​pratar om vad smidigt är skulle jag begränsa mig till en sådan fras - det är en uppsättning värderingar inom vilka vi bygger vårt arbete med produkter, med processer inom organisationen.

(ScrumTrek Managing Partner Alexey Pimenov på Rusbase)

Ett ord till experterna

Vladimir Ovelyan

Ägare och generaldirektör Dostajevskij

Beroende på uppgifterna tillämpar vi olika metoder inom filosofin - agil, scrum, kanban.

Scrum låter dig utveckla de nödvändiga egenskaperna hos anställda - proaktivitet, självständighet, organisation, kommunikationskunskaper och framsynthet. Metodens huvudpunkt är att utföra uppgifter i självorganiserande team, där alla har sin egen roll och alla är ansvariga för sin del av arbetet. Med hjälp av scrum gör vi undersökningar av personal, ritar upp diagram över den förväntade hastigheten på uppgiftsutförandet.

Vi använder Agile i intern kommunikation. Vi höll nyligen en annan sprint för att eliminera anställdas senhet. Alla chefer och specialister som är involverade i projektet tillbringade hela dagen i ett möte med att diskutera prestationer, utmaningar och kommande uppgifter i den nya sprinten.

Nu introducerar vi aktivt kanbanmetoden i företaget. Målet med kanbanimplementeringen är att öka produktionsflexibiliteten, bättre anpassa sig till förändrade marknadskrav. I praktiken hjälpte metoden oss att uppnå en överensstämmelse mellan lagret och de produkter som faktiskt används i produktionen.

Vitaly Sotnikov

Kreativ chef för Bureau of Visual Communications "Chernika"

Ilya Shikhaleev

ISpring Lead Developer och Scrum Master

Scrum tillförde rytm och förståelse för vårt team - oavsett om vi är i tid eller inte i tid. Vi ser hastigheten på lagets arbete, det finns ingen känsla av konstant jävla. Tidigare fanns det situationer att innan hårda utgåvor försvann scrum någonstans och alla bara började räkna ut det - nu har vi tappat det, det finns en ständig känsla av att vi är i tid. Om risker uppstår diskuterar vi dem med PD tidigt, justerar planen eller minskar omfattningen av uppgifter på något sätt.

Arbetet blev mer transparent, arbetsdagen började passa in i 8-timmarsnormen och det kändes som att vi började göra mer. Vi förstår att när du har en känsla av att du inte mår bra känner du att du måste arbeta hårdare - detta har en mycket dålig effekt på produktiviteten, du måste bli av med det.

Evgeny Rossinsky

Teknologidirektör på ivi online cinema

För tydlighet och öppenhet i utvecklingsavdelningens arbete sätter vi upp en särskild styrelse märkt "att göra", "pågår", "granskning", "testa", "gjort", där alla gruppmedlemmar klistrar klistermärken med uppgifter ( i kolumnen "att göra"), och när de utförs flyttas de till efterföljande punkter. Och ett lyckligt slut är den "klara" slutpunkten. Detta hjälper till att få en helhetsbild och ger dig möjlighet att se vad varje deltagare arbetar med.

En mycket viktig punkt i metoden (och organisation av arbetsflödet): efter godkännande av alla uppgifter ("att göra") blockeras listan för infogning. Nya inkommande uppgifter distraherar således inte från processen och bromsar inte arbetet.

Alla deltagare utvärderar också varje uppgift när det gäller tid och materialkostnader som krävs för att slutföra. Och körsbäret på toppen är veckomöten vid en viss tidpunkt (Daily Scrum), där varje teammedlem kort berättar om vad de ska göra idag, vad de gjorde igår (och om de mötte några hinder). Detta är viktigt på vägen mot långsiktiga mål - så här kan du i tid förstå att det är dags att ändra din strategi.

"Av alla utmaningar NASA ställde inför att skicka en man till månen var kontroll förmodligen den svåraste uppgiften."

- Roger Launis, NASA -historiker

Genom historien har mänskligheten samlat en imponerande lista över framgångsrikt genomförda komplexa projekt. Från byggandet av pyramiderna i Giza till att skicka en man till månen, krävde de mest vågade mänskliga strävandena samordnat arbete av tusentals människor. Och detta innebär ett komplext projektledningssystem.

Och även om bara ett fåtal av oss kommer att ställas inför uppgifter av den här storleken, står de flesta av bloggens läsare inför projektledning på ett eller annat sätt. PMI uppskattar att det kommer att finnas 2020 - och många andra yrkesverksamma måste ofta hantera miniprojekt, åtminstone på personlig nivå.

Enkelt uttryckt handlar projektledning om att hantera och organisera allt du behöver för att uppnå ett mål - i tid och med budget, naturligtvis. Var beredd att utveckla en ny programvara, genomföra en marknadsföringskampanj eller landa en man på Mars - projektledning gör att du kan lyckas.

Alla projekt är olika. Det finns inget perfekt projektledningssystem för varje typ av projekt. Det finns inte heller något system som passar alla ledare och är bekvämt för alla teammedlemmar. Under existensen av projektledning har dock många effektiva metoder, metoder och standarder skapats som kan antas. Vi kommer att prata om de mest populära av dem idag.

De utvecklade tillvägagångssätten skiljer sig mycket från varandra. De skiljer sig åt i omfattning, detalj, självförsörjning och formalisering. Vi har kallat dem "metoder" i titeln för enkelhets skull, men i själva verket introducerar denna artikel de standarder, koncept, metoder och ramar som används i projektledning. Syftet med denna artikel är att ge den bredaste översikten över befintliga tillvägagångssätt inom projektledning.

I den här artikeln kommer vi att titta på:

• Klassisk projektledning
• Vig
• Klunga
• Mager
• Kanban
• SexSigma
• PRINCE2

Och innan vi tittar på specifika metoder, låt oss svara på den uppenbara frågan - "Varför behöver vi projektledningssystem och metoder alls?"- överväga naturligtvis kortfattat projektledningens historia och definiera de grundläggande termerna för projektledning.

Varför "projektledning"?

Namnen på Neil Armstrong och Buzz Aldrin kommer för alltid att gå till historien som symboler för en av mänsklighetens största prestationer - människans landning på månen. De största bidragsgivarna till denna händelse var dock 400 000 NASA -anställda och 20 000 företag och universitet som arbetade tillsammans på Apollo -uppdraget.

1961 satte John F. Kennedy i uppgift att landa en man på en jordsatellit och återvända honom - trots att NASA vid den tiden skickade en man ut i rymden i bara 15 minuter. Ett sådant ambitiöst mål krävde otroligt mycket resurser, samarbete, innovation och planering.

Som det sägs i NASA: s bok Managing the Moon Program var huvudproblemet inte, ” vad ska man göra?", men i det, " hur gör man så mycket på så kort tid? " Enligt Dr Max Faget, chef för teknik vid Lyndon Johnson Space Center (Lyndon B. Johnson Space Center, JSC), då hade NASA ingen aning om hur man skulle göra alla nödvändiga åtgärder på 10 år. Därför var det första steget att "dela upp projektet i hanterbara skeden."

Då var det viktigt att påskynda varje fas och se till att team och företag som arbetar i varje fas kommunicerar effektivt med varandra och levererar resultat i tid. Denna uppgift anförtrotts doktor George E. Muller, som skötte varje del av Apollo -projektet, från Vita huset till leverantören av den minsta delen. För att göra projektet lättare att kontrollera bestämde han sig för att dela upp projektet i fem områden: Programkontroll, systemteknik, testning, tillförlitlighet och kvalitet och flygdrift. Programkontrollschemat för Apollo presenteras den Figur 1.

Detta 5 -stegs system - benämnt "GEM Stages" efter Dr. Muellers initialer - var utformat "för att fokusera på att testa produkten och utveckla den så att den kommer att testas", som Mueller själv noterar. Programkontroll bestämde vad som behövde göras, hanterade budget och krav och hanterade förhållandet mellan programelement. Fältet "Systemteknik" ansvarade för utvecklingen av nya enheter och sammansättningar, "Testning" för att dessa nya element fungerar, "Tillförlitlighet och kvalitet" kontrollerade de utvecklade elementen för överensstämmelse med krav och standarder och "Flight Operation" var ansvarig för att dessa noder kommer att fungera under flygningen.

Många reagerade inledningsvis med skepsis på den metod som Mueller föreslog, men till slut lyckades han övertyga medlemmarna i programmet att följa denna algoritm. Detta system har visat sin effektivitet - projektet slutfördes framgångsrikt, och man kan till och med säga triumferande före de tillkännagivna tidsfristerna. Detta möjliggjordes bara genom att bryta ett storskaligt projekt i hanterbara, repeterbara steg som tillät flera enskilda företag och specialister i en enda rytm. Så visade projektledning sin effektivitet i rymdloppet.

En kort historik om projektledning

Projektledningen uppfanns inte av NASA och Dr Mueller. De egyptiska pyramiderna och Kinesiska muren är produkter från projektledning från förhistorisk tid. Tyvärr finns det inga dokumentära bevis för hur dessa projekt genomfördes och hanterades, och den nuvarande projektledningen är skild från kunskapen från tidigare århundraden.

Det mest uppenbara sättet att genomföra ett projekt är att dela upp det i faser eller separata uppgifter. Som ett kulinariskt recept - du köper ingredienserna, blandar dem korrekt, förbereder dem och serverar dem. Det enklaste projekthanteringsverktyget är en checklista över åtgärder som måste vidtas för att nå ett mål. Enkelt och effektivt.

Men om du är kock och lagar mer än en maträtt, men flera, till exempel en sallad (som består av tre steg) och en dessert (som bara behöver serveras), behöver du ett verktyg som låter dig spåra tiden som spenderas på var och en av elementen och tiden när de ska vara klara. Och här kommer ett av de första moderna projekthanteringsverktygen till undsättning: Gantt -diagrammet, presenterat den figur 2.

Uppfunnet oberoende av K O Korol Adameckis och Genry L. Gantts roll i början av 1900 -talet, ett Gantt -diagram visar ett projektschema baserat på uppgifternas slutförande och slutdatum. Uppgifter, deras varaktighet och relationer anges i den, och sedan beräknas den kritiska vägen - den längsta kedjan av sammanhängande uppgifter som bestämmer projektets längd. Förhållandet mellan att börja och avsluta olika uppgifter är mycket viktigt - du kan inte servera soppa till dina gäster innan du har lagat det, eller hur?

Så ett typiskt projekt är mycket likt ett projekt för att förbereda och servera en middag, bara det har många fler uppgifter, relationer, deadlines och typer av resurser. För projekt med snäva deadlines hjälper Gantt -diagrammet dig att bestämma när du ska starta vissa uppgifter för att förkorta implementeringstiden. Och för projekt med starka resursbegränsningar ger Gantt-diagrammet möjligheten att bygga en händelsedriven processkedja för resursplanering.

Olika projekt behöver olika nivå kontrollera. Till exempel, om du publicerar en serie artiklar i, är snäva deadlines inte så viktiga. Mycket viktigare är en tydlig process där det är möjligt att strukturera varje artikel, skissa varje artikel, få feedback, redigera, avsluta artikeln, korrekturläsa och publicera. Istället för att hantera tid och resurser kontrollerar du processen.

Agila projektledningstekniker och relaterade tillvägagångssätt som Lean, Kanban och andra är bättre lämpade för sådana projekt. Det finns också metoder som låter dig hantera både arbetsflöde och tid och resurser - 6 Sigma och Scrum.

Populära projektledningssystem

Under hela projektledningens historia har många olika projektledningsmetoder skapats för nästan alla behov. Även om du inte kommer att skicka en person till månen och inte har samma mängd resurser, hittar du fortfarande ett lämpligt verktyg för dig själv. Nyckeln är att förstå vad som är viktigast för ditt projekt - tidsfrister, resurser, efterlevnad av processen eller flera faktorer samtidigt - och sedan välja en projektledningsmetod som är inriktad på att uppnå denna indikator.

Innan vi börjar titta på de mest populära metoderna, låt oss definiera några viktiga termer.

Grundläggande villkor för projektledning

Vig: En flexibel iterativ-inkrementell strategi för projekt- och produkthantering, fokuserad på dynamisk kravbildning och säkerställande av deras genomförande som ett resultat av ständig interaktion inom självorganiserande arbetsgrupper bestående av specialister från olika profiler. Det finns många metoder baserade på agila idéer, de mest populära är Scrum och Kanban.

Kritisk väg: En kontinuerlig sekvens av aktiviteter och händelser från början till slut, vilket tar längst tid att slutföra.

Händelsekedja av processer (EPC -diagram): ett diagram som visar ordningen för genomförandet av projekt baserat på tillgången och utnyttjandet av resurser

Tidsreserv: Den tid då arbetets start kan skjutas upp utan att påverka projektets totala varaktighet. Således kommer reserven för arbeten på den kritiska vägen att vara lika med noll.

Milstolpe (kontrollpunkt,milstolpe): En nyckelhändelse som markerar till exempel slutet på en etapp. Indikeras på Gantt -diagrammet är en uppgift med noll varaktighet.

Projektledare (projektledare,projektchef,PM ): Projektgruppsledaren, ansvarig för projektledning (planering, genomförande och avslutning av projektet).

Resurser: Element som krävs för genomförandet av projektet. Resurser är tid, utrustning, material, anställda och så vidare.

Sprint (Sprinta): En iteration (arbetscykel) i Scrum, som varar från en vecka till en månad, under vilken en fungerande version av en produkt eller dess värdeelement för kunden skapas.

"Klassisk" eller "traditionell" projektledning: Den mest använda projektledningsmetoden är baserad på den så kallade "vattenfall" eller kaskadcykeln, där uppgiften överförs sekventiellt i steg som liknar ett flöde.

Klassisk projektledning

Det mest uppenbara sättet att göra ditt projekt mer hanterbart är att bryta ner genomförandeprocessen i successiva steg. Det är på sådana linjär struktur traditionell projektledning är baserad. I den meningen liknar det datorspel- du kan inte gå till nästa nivå utan att slutföra den föregående. Arbetsflödesschemat visas i Figur 3.

Detta tillvägagångssätt är inriktat på projekt där det finns strikta begränsningar för sekvensen av uppgifter. Till exempel bygga ett hus - du kan inte bygga väggar utan en grund.

Vanligtvis finns det fem steg av klassisk projektledning, men ytterligare steg kan läggas till om projektet kräver det.

5 stadier av traditionell förvaltning:

Steg 1. Initiering. Projektledaren och teamet definierar kraven för projektet. I detta skede hålls ofta möten och brainstorming -sessioner, där det bestäms vad produkten ska bli av projektet.

Steg 2. Planering. I detta skede avgör laget hur det ska nå målet som sattes i föregående etapp. I detta skede förtydligar och beskriver teamet projektets mål och resultat, liksom omfattningen av arbetet med det. Baserat på denna information bildar teamet kalenderplan och budget, bedömer risker och identifierar intressenter.

Steg 3. Utveckling. Denna etapp är inte implementerad för alla projekt - som regel är den en del av planeringsfasen. I utvecklingsfasen karakteristisk för tekniska projekt, konfigurationen av det framtida projektet och / eller produkten och de tekniska sätten att uppnå det bestäms. Till exempel, i IT -projekt, väljs ett programmeringsspråk i detta skede. ( I hemlig praxis är denna fas vanligtvis inte belyst, och termen "utveckling" används inte - ca. per.)

Steg 4. Implementering och testning. I denna fas sker själva huvudarbetet med projektet - att skriva kod, bygga en byggnad och liknande. Efter de utvecklade planerna börjar innehållet i projektet, som bestämts tidigare, skapas, kontroll utförs enligt de valda mätvärdena. I den andra delen av denna fas testas produkten, den kontrolleras för att uppfylla kraven från kunden och intresserade parter. När det gäller tester identifieras och korrigeras produktbrister.

Steg 5. Övervakning och genomförande av projektet. Beroende på projektet kan denna fas bestå av en enkel överföring av projektresultaten till kunden eller en långvarig process av interaktion med kunder för att förbättra projektet och öka deras tillfredsställelse och stödja projektresultaten. Det senare gäller projekt inom kundservice och mjukvara.

Det som beskrivs ovan är basen att bygga på olika metoder projektledning. Olika projekt behöver olika implementeringsfaser - för vissa räcker tre faser, andra mycket mer. Ibland används det så kallade "iterativa vattenfallet", där varje steg är ett delprojekt, under vilket uppgifter genomförs i fasta iterationer. Men essensen förblir densamma - projektet är uppdelat i etapper som utförs i en strikt definierad sekvens.

På grund av det faktum att klassisk projektledning är strikt kopplad till utförandetiden av uppgifter, som regel, förutbestämda i planeringsstadiet, är schemaläggnings- och nätverksplaneringsverktyg utmärkta för att genomföra projekt inom detta tillvägagångssätt. Det vanligaste schemaläggningsverktyget är det tidigare nämnda Gantt -diagrammet. Det finns många verktyg för att bygga det, från enkla kalkylblad som Excel och Smartsheet till professionella mjukvarupaket som Microsoft Project och Primavera.

Styrkor i klassisk projektledning

Idag sägs det ofta att det klassiska vattenfallet är föråldrat, men det tänker inte ens ge upp sina positioner. Den stora fördelen med detta tillvägagångssätt är att det kräver att kunden och företagets ledning bestämmer vad de vill få, redan i projektets första etapp. Tidig integration ger projektet en viss grad av stabilitet och planering hjälper till att effektivisera genomförandet av projektet. Dessutom innebär detta tillvägagångssätt övervakningsindikatorer och tester, vilket är absolut nödvändigt för riktiga projekt av olika storlekar.

Potentiellt gör det klassiska tillvägagångssättet möjligt för dig att undvika stress på grund av att det finns ledig tid i varje steg, på plats vid eventuella komplikationer och insikt av risker. Dessutom, med planeringsfasen rätt, vet projektledaren alltid vilka resurser han har. Även om denna uppskattning inte alltid är korrekt.

Svagheter klassisk projektledning

Den klassiska projektledningens största svaghet är intolerans mot förändringar. Toyotas chefer är kända för att bygga system som Lean och Kanban, och kritiseras ofta för att de tar det klassiska tillvägagångssättet för att utveckla programvara för sitt företag, och just för deras brist på flexibilitet.

Grundpelaren i det klassiska tillvägagångssättet nu är bygg- och konstruktionsprojekt, där projektets innehåll är praktiskt taget oförändrat under hela projektet. Men om resurser och tid inte är de viktigaste begränsningarna i ditt projekt och projektets innehåll kan ändras kan du behöva titta på andra projektledningssystem.

Vig

Som nämnts tidigare kan inte alla projekt struktureras på ett sådant sätt att de genomförs enligt den klassiska designmetoden. Återgå till vårt exempel med kocken: beredningen av en maträtt faller helst på "vattenfall" -metoden, men det blir nästan omöjligt att förbereda och servera en fyra-rätters middag i tid om du måste vänta varje gång på slutet av en maträtt för att börja laga en annan.

Och det är där Agile spelar in - en familj av flexibla, iterativa -inkrementella metoder för att hantera projekt och produkter. Enligt detta tillvägagångssätt är projektet inte uppdelat i sekventiella faser, utan i små delprojekt, som sedan "monteras" i färdig produkt... Arbetsschemat visas på Figur 5.

Således genomförs initiering och planering på hög nivå för hela projektet, och de efterföljande stadierna: utveckling, testning och andra utförs för varje miniprojekt separat. Detta gör att du kan överföra resultaten av dessa miniprojekt, de så kallade inkrementerna, snabbare och starta ett nytt delprojekt (iteration), du kan göra ändringar i det utan höga kostnader och inverkan på resten av projektet.

Trots att Agile relativt nyligen har blivit på modet är tanken på iterativ utveckling inte ny. (om utseendets historiaAgile går att läsa - ca. översättning). Familjen agila metoder fick sitt nuvarande namn 2001 med publiceringen av Agile Manifesto, som förankrade kärnvärdena och principerna för agil mjukvaruutveckling, som bygger på - lagarbete och anpassning, till och med "kärlek" till förändring.

Agile i sig är inte en projektledningsmetod. Det är snarare en uppsättning idéer och principer för hur projekt ska genomföras. Redan på grundval av dessa principer och bästa praxis separata flexibla metoder utvecklades eller, som de ibland kallas, ramverk (ramverk): Scrum, Kanban, Crystal och många andra. Dessa metoder kan skilja sig ganska mycket från varandra, men de följer samma principer.

StyrkorVig

Agiles största styrka är dess flexibilitet och anpassningsförmåga. Det kan anpassa sig till praktiskt taget alla organisations miljö och processer. Detta är det som avgör dess nuvarande popularitet och hur många system för olika områden som har skapats på grundval av detta.

En av principerna för Agile: "Att svara på förändringar är viktigare än att följa planen." Det är en snabb och relativt smärtfri reaktion att ändra som är anledningen till att många stora företag strävar efter att göra sina processer mer flexibla. Dessutom är Agile perfekt för öppna projekt som att lansera en tjänst eller en blogg.

Agiles domän är utvecklingen av nya, innovativa produkter. Det finns en hög grad av osäkerhet i projekt för utveckling av sådana produkter, och information om produkten avslöjas när projektet fortskrider. Under sådana förhållanden blir det omöjligt att genomföra projektet "vattenfall" - det finns ingen information för planering.

SvagheterVig

Till skillnad från PRINCE2 och PMBOK är Agile varken en metod eller en standard. Agile är en uppsättning principer och värderingar. Den svaga punkten är att varje team självständigt måste komponera sitt eget ledningssystem, styrt av Agiles principer. Detta är en svår och tidskrävande process som kräver förändringar i hela organisationen, från procedurer till kärnvärden. Detta är en taggig väg och inte alla organisationer kan göra det.

Denna väg kommer att kräva att ledaren inte bara förändrar kunskap och uthållighet, utan också seriösa administrativa resurser och kostnader. Lyckligtvis finns det out-of-the-box-övningssatser som underlättar den agila omvandlingen av en organisation. Dessa uppsättningar inkluderar Scrum -ramverket, Kanban -metoden och många andra - Crystal, LeSS, SAFe, Nexus.

Klunga

Det agila ramverket, som skapades 1986, anses vara det mest strukturerade av Agile -familjen. Den skapades 1986 och kombinerar element i den klassiska processen och idéerna om en smidig projektledning. Resultatet är en mycket balanserad kombination av flexibilitet och struktur.

Efter Agils föreskrifter bryter Scrum upp projektet i delar som omedelbart kan användas av kunden för att få värde, kallad produktbacklog. Och trots att "produktunderlag" är en ganska korrekt översättning och används i yrkeslitteratur, i rysk praxis används oftast bara "eftersläpning". Sedan prioriteras dessa delar av produktägaren - kundens representant i teamet. De viktigaste "bitarna" väljs först för körning i Sprint - det här är Scrum -iterationerna som varar från 2 till 4 veckor. I slutet av sprinten presenteras för kunden en arbetsökning av produkten - de mycket viktiga "bitarna" som redan kan användas. Till exempel en webbplats med en del av funktionaliteten eller ett program som redan fungerar, om än delvis. Därefter fortsätter projektteamet till nästa sprint. Sprintens längd är fast, men teamet väljer det oberoende i början av projektet, baserat på projektet och dess egen produktivitet.

För att säkerställa att projektet uppfyller kundens krav, som tenderar att förändras över tid, innan varje Sprint startas, omprövas projektinnehållet som ännu inte har slutförts och ändringar görs i det. Alla är involverade i denna process - projektteamet, Scrummästaren (Scrummästaren, projektteamledaren) och produktägaren. Och ansvaret för denna process ligger hos alla.

Som redan nämnts är produktägaren kundens representant i projektet eller personifierar alla klienter i det framtida projektet om det inte finns någon kund. För att göra detta måste han känna till deras behov och sätt att tänka, samt förstå produkten och dess tillverkningsteknik. Scrum Master är utformad för att hjälpa projektdeltagare att bättre förstå och acceptera värderingar, principer och normer för Scrum -övning. Han är ledare och medlare mellan världen utanför och laget. Hans uppgift är att se till att ingen stör teamet självständigt och bekvämt med de tilldelade uppgifterna. Teamet är ansvarigt för att se till att alla nödvändiga uppgifter i slutet av sprinten är slutförda och leveranserna är klara.

Den grundläggande strukturen för Scrum -processer kretsar kring fem huvudmöten: Sekvensering av eftersläpning, planering av sprinten, dagliga sammanfattningar, summering av sprint och sprint retrospektiv.

Scrum kan tyckas svårt att implementera för många - ny process, nya roller, mycket delegering och en helt ny organisationsstruktur. Men detta är ett flexibelt och samtidigt strukturerat tillvägagångssätt för genomförandet av projekt, som, i motsats till det vaga och generella principer Agile förhindrar att arbetet går fel.

StyrkorKlunga

Scrum har utformats för projekt som kräver snabba vinster i kombination med en tolerans för förändringar. Dessutom är denna ram lämplig för situationer där inte alla gruppmedlemmar har tillräcklig erfarenhet inom det område där projektet genomförs - konstant kommunikation mellan gruppmedlemmar möjliggör brist på erfarenhet eller kvalifikationer hos vissa anställda på grund av information och hjälp från kollegor .

Online -tv -kanalen Netflix är ett bra exempel på snabb leverans av resultat. Webbplatsen för resursen uppdateras varannan vecka tack vare Scrum, som inte bara låter dig arbeta i hög hastighet, utan också samlar användarupplevelse och gör det möjligt att identifiera de viktigaste sakerna för kunder.

Under varje iteration lägger utvecklarna till och testar nya webbplatsfunktioner och tar bort de som inte användes av klienter. Enligt Netflix -teamet är den främsta fördelen med Scrum att det låter dig "ta fel snabbt". Snarare än att ta lång och dyr tid att förbereda en stor utgåva, är Scrum -leveranserna två gånger i veckan små. De är lätta att spåra och om något går fel kan de snabbt korrigeras.

SvagheterKlunga

Scrum är mycket noga med projektteamet. Den ska vara liten (5-9 personer) och tvärfunktionell-det vill säga teammedlemmar ska ha mer än en kompetens som krävs för att genomföra projektet. Till exempel måste en mjukvaruutvecklare ha kunskap om tester och business intelligence. Detta görs för att en del av teamet inte ska "stå på" i olika stadier av projektet, liksom för att anställda kan hjälpa och ersätta varandra.

Dessutom måste lagmedlemmar vara ”lagspelare”, aktivt ta ansvar och kunna organisera sig. Det är väldigt svårt att hitta ett så moget lag!

Scrum är inte lämpligt för alla team och organisationer också eftersom den föreslagna processen kanske inte är lämplig för utveckling av en specifik produkt - till exempel en industrimaskin eller att bygga en byggnad.

Mager

Agile berättar för oss att bryta ner i små, hanterbara arbetspaket, men det berättar inte hur vi ska hantera utvecklingen av det paketet. Scrum erbjuder oss sina processer och procedurer. Lean lägger i sin tur till ett arbetsflöde till principerna för Agile så att varje iteration utförs lika bra.

I Lean, precis som i Scrum, är arbetet uppdelat i små leveranspaket som implementeras separat och oberoende. Men i Lean finns det ett arbetsflöde för utvecklingen av varje leveranspaket med steg som liknar de som skapades för Apollo -projektet. Precis som i klassisk projektledning kan dessa vara stadierna av planering, utveckling, produktion, testning och leverans - eller andra steg som är nödvändiga för högkvalitativt genomförande av projekt.

Mager faser och deras flexibilitet gör att du kan vara säker på att varje del av projektet genomförs efter behov. Lean innehåller inga tydliga gränser för etapper, som Scrum gör för Sprints. Dessutom, till skillnad från klassisk projektledning, tillåter Lean dig att samtidigt utföra flera uppgifter i olika skeden, vilket ökar flexibiliteten och ökar hastigheten på projektets genomförande.

Precis som Agile är Lean mer ett begrepp, ett sätt att tänka, snarare än något stenat. Med hjälp av magra idéer kan du självständigt skapa ett system som uppfyller dina projektledningskrav.

StyrkorMager

Om du gillar agila idéer, men projektet kräver mycket konsekvent kvalitet och exakt utförande, tillhandahåller Lean en uppsättning verktyg för att uppfylla dessa krav. Lean kombinerar flexibilitet och struktur, som Scrum, men på ett lite annorlunda sätt.

SvagheterMager

Inte alla delar av projektet kräver samma detaljerade och noggranna studie och uppmärksamhet. Men Lean antar exakt detta tillvägagångssätt för varje uppgift och steg. Detta är den största nackdelen med att använda Lean för stora och heterogena projekt.

Till skillnad från Scrum ger Lean inte heller ett tydligt arbetsflöde för implementeringen av "bitarna" i projektet, vilket bidrar till att projektets tidsfrist förlängs. Detta problem kan lösas med effektivt ledarskap och tydlig kommunikation - det viktigaste att komma ihåg är detta.

Kanban

Lean ser lite abstrakt ut i sig, men i kombination med Kanban blir det mycket lättare att använda det för att bygga ett eget projektledningssystem. Kanban skapades av Toyota -ingenjören Taiichi Ono 1953 och liknar mycket ett industriellt produktionsschema. Vid ingången till denna process kommer en metallbit in, och vid utgången erhålls en färdig del. Även i Kanban skickas produktökningen framåt från steg till steg, och i slutet erhålls en färdig föremålsartikel.

Dessutom inspirerades skaparen av Kanban av stormarknader, nämligen deras princip - "behåll bara det som kunden behöver på hyllorna." Därför är det i Kanban tillåtet att lämna en oavslutad uppgift i ett av stadierna om dess prioritet har ändrats och det finns andra brådskande uppgifter. Ett oredigerat blogginlägg, hängande utan bokningsdatum, eller en funktionskod som kanske inte ingår i produkten är bra för Kanban -arbete.

Kanban är mycket mindre strikt än Scrum - det begränsar inte sprinttider, det finns inga andra roller än produktägaren. Kanban tillåter till och med en teammedlem att utföra flera uppgifter samtidigt, vilket Scrum inte gör. Möten om projektets status regleras inte på något sätt - du kan göra det som du vill, eller så kan du inte göra det alls.

För att arbeta med Kanban måste du definiera arbetsflödessteg. I Kanban representeras de som kolumner och uppgifter representeras av specialkort. Kortet rör sig genom stadierna, som en del i en fabrik som går från maskin till maskin, med en högre procentsats för slutförande i varje steg. Som ett resultat får vi ett produktelement redo för leverans till kunden. En tavla med kolumner och kort kan vara antingen verklig eller elektronisk - även här lägger Kanban inga restriktioner på användarna.

Ditt eget Kanban -system kan vara så flexibelt som du vill - på många sätt är Kanban en visualisering av en Agile idé. Men Kanban har fyra pelare som stöder hela systemet:

1. Kort: För varje uppgift skapas ett individuellt kort, där all nödvändig information om uppgiften anges. All nödvändig information om uppgiften finns därför alltid till hands.
2. Begränsa antalet uppgifter i ett skede: Antalet kort i ett skede är strikt reglerat. Detta gör det omedelbart klart när en "trängsel" uppstår i arbetsflödet, som snabbt löses.
3. Kontinuerligt flöde: Uppgifter från eftersläpningen går in i strömmen i prioritetsordning. Därmed slutar arbetet aldrig.
4. Kontinuerlig förbättring ("kaizen" (kaizen)): Begreppet kontinuerlig förbättring uppstod i Japan i slutet av 1900 -talet. Dess väsen är i ständig analys produktionsprocess och hitta sätt att förbättra produktiviteten.

StyrkorKanban

Precis som Scrum fungerar Kanban bra för ett lagom sammansvetsat team med bra kommunikation. Men till skillnad från Scrum har Kanban inga tydliga deadlines, vilket är bra för motiverade och erfarna lag.

När Kanban är korrekt konfigurerad och hanterad kan det vara till stor nytta för projektteamet. Noggrann beräkning av arbetsbelastningen på teamet, korrekt placering av restriktioner och fokus på ständiga förbättringar - allt detta gör att Kanban på allvar kan spara resurser och passa in i deadlines och budget. Och allt detta kombineras med flexibilitet.

SvagheterKanban

Du kan ofta höra att i Kanban, till skillnad från Scrum, kan du arbeta med nästan vilket team som helst. Men det är inte så. Kanban är bäst för lag vars medlemmars kompetens överlappar varandra. På så sätt kan de hjälpa varandra att övervinna svårigheter att lösa problem. Utan det kommer Kanban inte att vara så effektivt som det kan vara. Som redan nämnts är Kanban också bättre lämpad när det inte finns några snäva deadlines. För snäva deadlines är det klassiska tillvägagångssättet eller Scrum bättre.

6 Sigma (Six Sigma)

Motorola, tillsammans med Toyota, har också bidragit till utvecklingen av global projektledning. Bill Smith, ingenjör på detta företag, skapade 6 Sigma -konceptet 1986. Detta är en mer strukturerad version av Lean än Kanban, som lägger till mer planering för att spara resurser, förbättra kvaliteten och även minska skrot och problem.

Det slutliga målet med projektet är kundnöjdhet med produktens kvalitet, som kan uppnås genom en kontinuerlig förbättringsprocess för alla aspekter av projektet, baserat på en grundlig analys av indikatorer. 6 Sigma fokuserar på felsökningsproblem som uppstår.

För detta har en 5-stegsprocess föreslagits, känd som DMEDI:

• Definition (Definiera): Den första etappen är mycket lik de tidiga stadierna av andra projektledningssystem. Den bestämmer projektets innehåll, samlar in information om projektets förutsättningar, sätter upp mål.
• Mätning (Mäta): 6 Sigma fokuserar på att samla in och analysera kvantitativa projektdata. I detta skede bestäms vilka indikatorer som kommer att avgöra projektets framgång och vilka data som behöver samlas in och analyseras.
• Studie (Utforska): Under forskningsfasen beslutar projektledaren hur teamet kan nå målen och uppfylla alla krav i tid och inom budget. I detta skede är det mycket viktigt för projektledaren att tänka utanför boxen när de löser de problem som uppstått.
• Utveckling (Utveckla): I detta skede genomförs de planer och beslut som tagits i de föregående stadierna. Det är viktigt att förstå att det i detta skede behövs en detaljerad plan som beskriver alla åtgärder som krävs för att uppnå de uppsatta målen. Även i detta skede mäts projektets framsteg.
• Kontrollen (Kontrollera): En viktig milstolpe i 6 Sigma -metoden. Dess huvudsakliga uppgift är att långsiktigt förbättra projektimplementeringsprocesser. Detta steg kräver noggrann dokumentation av de lärdomar, analys av de insamlade uppgifterna och tillämpning av den kunskap som erhållits både i projekt och i hela företaget som helhet.

6 Sigma liknar mycket Kanban, bara med etablerade milstolpar - planering, uppsättning av mål och testning av kvalitet. Mest troligt kommer det att bli betydligt fler teammöten med 6 Sigma än med Kanban, men processen för projektimplementering är mer strukturerad och det är svårare för laget att gå vilse. Och precis som Kanban kan 6 Sigma relativt enkelt skräddarsys efter behoven hos ett visst företag eller team. Ett strikt krav är endast noggrann mätning och kontroll av projektindikatorer i implementeringsstadierna - utan detta är kontinuerlig långsiktig förbättring av projektgenomförandeprocesser omöjlig.

Styrkor på 6 Sigma

6 Sigma ger en tydlig ram för projektimplementering och kontinuerlig processförbättring. Genom att definiera mål och sedan noggrant analysera och revidera dem får du kvantitativa data för en djupare förståelse av projektet och bättre beslutsfattande. Samtidigt som det kan ta lite tid att samla in, analysera data och extrahera lektioner, kommer det att förbättra och optimera projektimplementeringsprocesser och därmed spara resurser i framtiden.

6 Sigma lämpar sig för svåra projekt med många nya och komplexa verksamheter. Detta tillvägagångssätt låter dig implementera projektelement, lära av misstag och förbättra kvaliteten i framtiden.

Svagheter med 6 Sigma

Problemet med 6 Sigma är att även om det huvudsakliga deklarerade målet är att sänka kostnaderna och öka effektiviteten, tas ofta kundnöjdheten fram. Med tanke på vissa skillnader i mål i olika stadier av ett projekt har team ofta förvirring om prioriteringar, och det är inte lätt att undvika.

Dessutom är huvudtemat för 6 Sigma: ”Du kan alltid göra det ännu bättre”. Detta kan demotivera anställda som inte känner sig nöjda med det arbete de har utfört. Om projektet dessutom är en engångsperiod och företaget inte planerar att genomföra liknande projekt i framtiden kan alla kostnader för analys och lärdom av lärdomar vara förgäves.

PRINCE2

NASA är inte den enda statliga myndigheten som har bidragit till utvecklingen av projektledning. Den brittiska regeringen har länge uppskattat projektledningens effektivitet, och 1989 skapades den brittiska PRINCE2 -metoden. Namnet kommer från förkortningen " PR förkastar I C onrolled E miljöversion 2 ", Vilket översätts till" Projekt i en kontrollerad miljö version 2 ". Till skillnad från agila metoder tar PRINCE2 inte en iterativ inställning till projektet. Om du jämför PRINCE2 med andra produkter, kan det jämföras med en hybrid av det klassiska tillvägagångssättet projektledning och fokus på 6 Sigma -kvalitet.

PRINCE2 -metoden innehåller, till skillnad från till exempel PMBOK -kunskapsgruppen, inte:

• Specialiserade aspekter av projektledning, såsom branschspecifika;
• Specifika metoder för projektledning och verktyg som Gantt -diagram, WBS, etc.

PRINCE2 fokuserar på projektets ledningsaspekter, uttryckta i 7 principer, 7 processer och 7 projektteman.

• 7 principer definierar generella regler projektledning enligt PRINCE2, definiera grunden för metodiken;
• 7 processer definierar stegen för att gå igenom projektcykeln;
• 7 ämnen - aspekter som kontrollen utförs för att uppnå projektets framgång.

I början av projektet inbjuder PRINCE2 oss att definiera tre huvudaspekter av projektet:

• Affärsaspekt (Kommer detta projekt att medföra fördelar?)
• Konsumentaspekt (vilken produkt behövs, vad ska vi göra?)
• Resursaspekt (Har vi tillräckligt för att nå målet?)

PRINCE2 har en tydligare definierad projektteamstruktur än de flesta projektledningsmetoder. Detta beror på att PRINCE2 är inriktat på storskaliga statliga projekt och stora organisationer.

Enligt PRINCE2 har varje teammedlem en distinkt roll i var och en av de sju processerna:

• Projektstart (Starting uppa projekt): Under denna process utses en projektledare och de övergripande kraven på produktprestanda bestäms. Projektledaren, vars huvudansvar är uppmärksamhet på detaljer, rapporterar till projektstyrkommittén, som ansvarar för den övergripande projektledning. Det är styrkommittén som ser till att projektet inte går ur kurs, och det är också fullt ansvarigt för projektets framgång.
• Initiering av projekteta projekt): Under denna process förbereder projektledarenn, som innehåller projektplanen efter etapp. Stegen kan pågå under olika lång tid, men som i det klassiska tillvägagångssättet följer de strikt efter varandra.
• Projektledning (Directing a projekt): Denna process ger en möjlighet för styrkommittén att ha det övergripande ansvaret för projektets framgång utan att gå in på detaljer som ligger inom projektledarens område.
• Stegkontroll (kontrolllånga a skede): Under genomförandet av projektet, även under idealiska förhållanden, kommer vissa ändringar att göras. Stegkontrollprocessen implementerar en av PRINCE2 -principerna - principen om kontroll genom undantag. Projektledarens ansvar är att övervaka under genomförandet av scenavvikelserna från projektets planerade parametrar när det gäller tid, innehåll, budget etc. vägar ut ur situationen.
• Produktskapandehantering (Hantera Produkt Leverans): Product Creation Management -processen är interaktionen mellan projektledaren och teamchefen för att skapa en av projektets produkter. Projektledarens ansvar i denna process inkluderar delegering av produktskapande auktoritet till teamchefen och acceptans av den skapade produkten.
• Steggränshantering (Managing a skede gräns): Under denna process ger projektledaren styrkommittén all information den behöver för att utvärdera resultaten av det passerade skedet och besluta om övergången till nästa steg.
• Avsluta projekteta projekt): En av skillnaderna mellan PRINCE2 är att processen för att slutföra ett projekt inte är uppdelad i ett separat stadium eller steg, som i det klassiska tillvägagångssättet, utan utförs som en del av det sista steget för att skapa en produkt. Syftet med processen är att bekräfta att projektets produkt har accepterats eller att projektet inte längre kan ge något användbart.

PRINCE2 kan anpassas för projekt av alla storlekar och alla ämnesområden. Metoden ger specifika rekommendationer för att ändra projektets livscykel, förebild och uppsättning nödvändiga dokument i enlighet med projektets behov.

Styrkorna hos PRINCE2

• Anpassningsförmåga till organisationens särdrag;
• Ha en tydlig beskrivning av roller och ansvar;
• Betoning på projektets produkter;
• Vissa ledningsnivåer;
• Fokus på ekonomisk lönsamhet;
• Efterföljande designarbete;
• Betoning på att fånga upp erfarenhet och ständiga förbättringar.

Svagheter med PRINCE2

• Brist på branschpraxis;
• Brist på specifika verktyg för att arbeta med projektet.

Det bästa projektledningssystemet ... för dig!

Projektledning är en vetenskap, men vetenskap är inte den mest exakta. På detta område finns det inga orubbliga fundament och universella lösningar. Om du kan hitta en metod som passar ditt projekt perfekt, anser dig själv ha tur, eftersom de flesta mindre lyckliga ledarna måste anstränga sig för att skapa och anpassa sina egna projektledningssystem. Dessa system kan bestå av element i befintliga system, eller till och med skapas helt från grunden, som i fallet med Apollo -uppdraget. Det viktigaste är att använda något som ger dig åtminstone lite struktur och inte kommer att glömma vad som är viktigt för ditt projekt.

Hur får man ett internationellt certifikat i Agile?

För dem som vill få en systematisk förståelse för Agile, för att förstå fördelarna och nackdelarna med ett smidigt tillvägagångssätt för projekt och produkter, för att hitta områden för bästa användning av Agile och för att få en internationell ICAgile Certified Professional - vår utbildning

Agil utvecklingsmetodik(Engelska Agile mjukvaruutveckling, agila metoder) - en serie metoder för mjukvaruutveckling med fokus på användninginteraktiv utveckling , dynamisk kravbildning och säkerställande av deras genomförande som ett resultat av ständig interaktion inom självorganiserande arbetsgrupper bestående av specialister inom olika områden. Det finns flera tekniker relaterade till klassen av agila utvecklingsmetoder, särskilt extrem programmering, DSDM, Scrum, FDD.

De flesta smidiga metoder syftar till att minimera risken genom att konvergera utvecklingtill en serie korta slingor som kallas iterationer som vanligtvis varar två till tre veckor. Varje iteration i sig ser ut som ett miniatyrprogram och innehåller alla uppgifter som är nödvändiga för att generera en ministigning i funktionalitet: planering, kravanalys, design, programmering, testning och dokumentation. Även om en enda iteration vanligtvis inte är tillräcklig för att släppa en ny version av en produkt, antas det att det smidiga mjukvaruprojektet är klart att släppas i slutet av varje iteration. Vid slutet av varje iteration utvärderar teamet utvecklingsprioriteringar.

Smidiga tekniker

Agila metoder är sådana agila metoder som Lean Development, Scrum, etc. De utvecklades i början av 2000 -talet som ett alternativ till ineffektiva traditionella IT -metoder.

Nästan alla agila team är koncentrerade till ett kontor (bullpen). På kontoret ingår produktägaren - kunden, som definierar kraven för produkten. Kunden kan vara affärsanalytiker, projektledare eller kund. Dessutom kan kontoret innehålla gränssnittsdesigners, testare, tekniska författare. Det vill säga agila metoder riktar sig främst till ansikte mot ansikte kommunikation.

Huvudmåttet för smidiga metoder är arbetsprodukten.Genom att gynna kommunikation ansikte mot ansikte minskar agila metoder mängden skriftlig dokumentation framför andra metoder

Viktiga idéer:

— människor och interaktionviktigare än processer och verktyg;

— fungerande produktviktigare än omfattande dokumentation;

— samarbete med kundenviktigare än att komma överens om villkoren i kontraktet;

— vilja att förändraviktigare än att följa den ursprungliga planen.

Agila principer:

1.Kundnöjdhet genom tidig och oavbruten leverans av värdefull programvara;

2. välkomnar ändringar av kraven även i slutet av utvecklingen (detta kan öka den resulterande produktens konkurrenskraft).

3. Frekvent leverans av fungerande programvara (varje månad eller vecka eller ännu oftare);

4. nära, daglig kommunikation av kunden med utvecklarna under hela projektet;

5. projektet genomförs av motiverade personer som får nödvändiga arbetsförhållanden, stöd och förtroende;

7. Körning av programvara är det bästa måttet på framsteg;

8. sponsorer, utvecklare och användare bör kunna hålla en konstant takt på obestämd tid;

9. kontinuerlig uppmärksamhet på att förbättra teknisk kvalitet och användarvänlig design;

10. enkelhet - konsten att inte göra onödigt arbete;

11. de bästa tekniska kraven, design och arkitektur erhålls från ett självorganiserat team;

12. ständig anpassning till förändrade omständigheter.

De viktigaste fördelarna med Agile:

• Webbproduktkvalitet

Att involvera kunden i processen för varje iteration gör det möjligt att justera processen, vilket alltid förbättrar kvaliteten.

• Hög utvecklingshastighet

Iterationen varar högst 3 veckor; vid slutet av denna period finns det nödvändigtvis ett resultat.

• Minimera risker

Ett stort projekt gör att kunden kan betala för flera iterationer och under arbetets gång förstå att han kommer att få exakt vad han vill i tid och till ett överkomligt pris. Vattenfallsmodeller (med specifikationer och tekniska specifikationer) ge inte sådana möjligheter.

Kunden har alltid möjlighet att övervaka utvecklingen, justera projektets funktionalitet, testa eller starta det, han kan till och med stoppa det när som helst.

Doktorand i Netology Maxim Pimenov berättar om Agile - en smidig metodik för mjukvaruutveckling.

Om du skriver ett komplext program utan en plan kommer det inte att bli något av det. Det är som att sätta ut en bil: du måste välja en motor, studera marknaden, träna strukturen, skapa en design och montera allt på ett transportband. När du inte vet vad du ska göra och i vilken ordning startar varken bilen eller programmet.

För att processen med att skapa ett program ska gå rätt använder programmerare metoder. En metod är en samling strategier och sätt att skapa en produkt. Det finns många av dem och nybörjaren vet inte vad han ska välja: RUP, XP, Waterfall eller en annan uppsättning bokstäver.

Tillbaka till sprinten. Under det arbetar teamet på en modell nära ett vattenfall. Varje ny funktion är utformad och programmerad och sedan testad och dokumenterad. När sprinten är klar har teamet en användbar, användbar och förbättrad version av produkten.

Inför nästa sprint planerar laget nästa sprint. I detta skede kan kunden lägga till uppgifter som inte fanns tidigare. Agile uppmuntrar det som är otänkbart för ett vattenfall: "Kravändring är välkommen, även i senare utvecklingsstadier." I slutet av projektet kan produkten skilja sig mycket från vad som planerades vid starten.

Par "plan - sprint" går efter varandra, medan projektet lever.

Teamet fungerar som det vill

Intern och extern kommunikation för det agila teamet är så demokratiskt som möjligt. En av anledningarna till att metoden praktiskt taget inte fungerar i Ryssland är att chefer inte förstår hur man "upplöser teamet i så stor utsträckning". Enligt Agile är ett team en självorganiserande enhet. Ingen har rätt att ange hur hon löser problem inom sprinten. Om de vill, låt dem gå på huvudet.

Ett team är en enda helhet som inte är indelad i specifika personer. Ansvaret ligger på hela laget: om de straffas eller belönas, då på en gång. Det viktigaste i arbetsflödet är kommunikation. Teamet sitter i ett rum utan partitioner och "kuber" och kommunicerar ständigt med varandra. Kommunikation med kunden sker också dagligen.

I slutet av varje sprint diskuterar teamet hur man arbetar mer effektivt. Detta kallas en retrospektiv. Kärnan i Agile är inte bara ständig förbättring av produkten, utan också ständig förbättring av lagarbete.

Egentligen är det inte alla som älskar Agile.

Agile har motståndare som inte delar samma spänning. Metodens huvudproblem är kaos på avstånd. Efter varje sprint ändras prioriteringar och nya uppgifter dyker upp, så teamet har ingen vision om slutprodukten.

För två veckor sedan ville kunden ha en webbutik, men nu insåg han att det skulle vara ett socialt nätverk för enskilda företagare. Teamet accepterar chatt och gillar för sprintuppgifter. Nästa gång kunden ser att en ny James Bond -film har sprängt Internet. Det lägger till online -biofunktionalitet till Sprint. Som ett resultat sprids projektets arkitektur och produktens användbara effekt blir suddig.

Ett annat problem är dålig kod. Agile predikar det maximala antalet fördelaktiga produktförändringar per tidsenhet. Eftersom målet är användbara förändringar har programmerare inte uppgiften att göra koden så tillförlitlig och begriplig som möjligt.

Agile får dig att tro att det faktum att en funktion fungerar är mycket viktigare än hur den implementeras. På avstånd leder detta tillvägagångssätt till problem. Den enda försäkringen är ett överdisciplinerat och organiserat team.

Om du glömmer filosofi kommer ingenting att hända.

Det finns ett annat problem som författarna till Agile inte är skyldiga till: metoden har blivit för populär och till och med pop. Folk säger att de arbetar i Agile utan att ens förstå dess väsen. De delas upp i små lag, skär upp projektet i små uppgifter, planerar sprints, släpper dem regelbundet, men antalet fattiga projekt minskar inte.

Kommer du ihåg att jag i början av denna artikel pratade om principer? Trots deras naivitet är principer det mest värdefulla i Agile. Först måste du inse dem och först sedan använda verktygen och metoderna.

Människor och interaktioner är viktigare än processer och verktyg.

En fungerande produkt är viktigare än omfattande dokumentation.

Samarbete med kunden är viktigare än att komma överens om villkoren i kontraktet.

Att vara redo för förändring är viktigare än att följa den ursprungliga planen.

Människor följer tanklöst instruktioner och glömmer att Agile är en ideologi och en filosofi. Och vi får inte glömma: om du inte blir genomsyrad av metodologi, kommer ett "vattenfall" att bryta igenom det, i hälften med anarki och byråkrati.

Agil är ett tankesätt, inte en uppsättning råd. Acceptera Agile och träna först då.

Består av 12 principer. Visst förekom vissa bestämmelser i det agila tillvägagångssättet före det, men endast detta dokument systematiserade och satte ner dem i tillräcklig omfattning för användning. Varje år anmäler nya företag, IT -specialister och projektledare sig till manifestet. Nya metoder och modifieringar av det smidiga utvecklingssystemet dyker upp.

Vad är Agile Methodology?

Agile är en iterativ utvecklingsmodell där mjukvara skapas stegvis från början av ett projekt, till skillnad från vattenfallsmodeller, där kod levereras i slutet av en arbetscykel.

Kärnan i Agile är att bryta ner projekt i små arbetsstycken som kallas användarberättelser. Enligt prioriteten löses uppgifterna inom korta tvåveckorscykler (iterationer).

De 12 principerna som utgör Agile Methodology kan delas in i 4 huvudidéer:

• Människors prioritet och kommunikation framför verktyg och processer;
• Arbetsproduktens prioritet framför den fullständiga dokumentationen;
• Prioritet för samarbete med kunder framför godkännande av kontraktet;
• Prioriterar vilja att förändra över att följa den ursprungliga planen.

Metoder som finns i Agile:

Termen "Scrum" är skyldig sitt namn till rugby, där detta ord betyder en metod för lagspel i form av att dra tre linjer av var och en av motståndarna och försöka fånga bollen. För en framgångsrik avlyssning behövs inte bara god fysisk kondition, utan också varje deltagares samstämmighet i matchen och en tydlig förståelse av målet.

Metoden tillämpas framgångsrikt av företag som Microsoft, Yahoo, Siemens Healthcare och projektledaren på Amazon beskrev till och med den baserat på de erfarenheter som gjorts.

Eftersom Scrum är ett utvecklingsramverk kan det i varje efterföljande exempel skilja sig väsentligt från det föregående.

Jeff Sutherland, författare skisserade 8 steg för att använda tekniken:

1. Vänligen välj produktägare- han vet om syftet med projektet och det förväntade resultatet.
2. Samla kommando- upp till 10 personer med de färdigheter som krävs för att skapa en användbar produkt.
3. Hitta scrummästare- han övervakar projektets framsteg, hjälper projektgruppen att hantera svårigheter.
4. Utgöra produkt eftersläpning Prioritera varje produktkrav på Agile -kortet. Produktägaren spelar en viktig roll i detta och samlar in önskemål för produkten för utvärdering av eftersläpningsteamet.
5. Planen sprintar(iterationer) - tidslängd för att slutföra en specifik uppsättning uppgifter.
6. Organisera dagliga femton minuters "mit-ups"- ställ tre frågor till var och en i teamet: vad gjorde du igår, vad kommer att hända idag, vad hindrar dig från att slutföra uppgiften.
7. Do produktarbetsdelar recensioner- med deltagande av intressenter vid granskning och diskussion.
8. Spendera retrospektiv- diskussion av problemet och sök efter en lösning efter varje sprint. Implementera den resulterande ändringsplanen i nästa sprint.

Smidig retrospektiv

Scrum har fyra nyckelelement:

• Produktbacklog- lista över projektkrav
• Sprint Backlog- en lista med krav som måste uppfyllas i nästa sprint
• Sprintmål- sprintmål
• Sprint Burndown Chart- ett diagram som uppdateras när uppgifterna är klara. Det är lätt att förstå dynamiken och utvecklingsnivån för teamet i projektet.

(XP)

Metodens utvecklare, Kent Beck, skapade en extrem programmeringsmetod, vars mål är att klara de ständigt föränderliga kraven för mjukvaruprodukt och förbättra kvaliteten på utvecklingen.

Den är exklusivt tillämplig inom mjukvaruutveckling och är byggd kring fyra processer:

1. kodning- enligt enhetliga designstandarder i teamet;
2. testning- tester skrivs av programmerarna själva innan de skriver koden som ska testas;
3. planera- både den slutliga konstruktionen och individuella iterationer. Det senare sker i genomsnitt en gång varannan vecka.
4. hörsel- både utvecklaren och klienten, under vilken oklarheter försvinner, krav och värden bestäms.

Metoder

En familj av metoder, lite kända inom de inhemska öppna utrymmena för projektledning, utvecklades av Alistair Cockburn, en av författarna till Agile Software Development Manifesto. Cockburn föreslår att klassificeringen efter färg utförs enligt kriteriet för antalet personer i laget: från 2 (Crystal Clear) till 100 (Crystal Red). För större projekt markeras färgerna Maroon, Blue och Violet.

Kristallprojekt måste uppfylla tre huvudindikatorer:

1. snabb leverans av arbetskod- utveckling av idén om en iterativ modell för agil utveckling.
2. perfektion genom reflektion — en ny version Programvaran förbättras baserat på data från den föregående.
3. "Osmotisk" interaktion- Alistairs innovation, en metafor för kommunikation och informationsutbyte mellan mjukvaruutvecklare i ett rum.

Dynamisk mjukvaruutvecklingsmetod (DSDM)

Inte en person eller ens ett team arbetade med utvecklingen av DSDM, utan ett konsortium med 17 engelska företag. DSDM, liksom extrem programmering, används främst för mjukvaruutveckling.

En särskild roll tilldelas slutkonsumentens (användarens) deltagande i utvecklingsprocessen. Förutom denna princip inkluderar de grundläggande:

• frekventa utgåvor av arbetsversioner av produkten
• utvecklarnas autonomi när det gäller beslutsfattande
• testning under hela arbetscykeln.

DSDM är uppdelat i versioner som uppdateras allt eftersom tekniken utvecklas, nya krav på mjukvaruutveckling dyker upp. Den sista för idag är DSDM Atern, som släpptes 2007, även om den föregående (2003) fortfarande används.

I början undersöker teamet verkligheten för applikationsutveckling och tillämpningens omfattning. Vidare är arbetet uppdelat i tre sammanhängande cykler:

1. funktionell modellcykel- skapande av analytisk dokumentation och prototyper.
2. design- och konstruktionscykel- att få systemet att fungera.
3. genomförandecykel- systemdistribution.

Feature Driven Development (FDD)

En metod som till och med föregick Agile Software Development Manifesto.

Även om FDD också använder en iterativ utvecklingsmodell skiljer den sig från Agile i följande:

• mer betoning på förmodellering
• ökat (jämfört med Agile) betydelsen av att bygga rapporter och diagram
• syftar till företagsutveckling.

Feature Driven Development består av följande cykliska stadier:

1. Skapa en allmän modell- projektvision baserad på preliminära data.
2. Utforma en lista med egenskaper- en analog av produktens eftersläpning i Scrum -metoden.
3. Planering efter fastigheter- utvärdering av fastigheternas komplexitet av varje medlem i teamet.
4. För varje fastighet- teknisk design och implementering - det sista steget, i slutet av vilket fastigheten går in i produkten och cykeln upprepas.

Mjukvaruutveckling

Lean Software Development är mer sannolikt inte en metod, utan en uppsättning lean -tillverkningsprinciper, som syftar till att öka effektiviteten i utvecklingsprocessen och minimera kostnaderna.

Uppsättningen innehåller följande sju principer:

1. bli av med förluster- allt som inte tillför produkten något värde för slutanvändaren.
2. fortsatt lärande- kontinuerlig utveckling av teamet ökar förmågan att effektivt slutföra uppgifter.
3. fatta ett beslut så sent som möjligt- prioriteringen är inte spontana beslut, utan tankeväckande, utvecklade på grundval av den förvärvade kunskapen.
4. snabb leverans- i huvudsak grunden för den iterativa modellen.
5. lagförstärkning- en av principerna i "manifestet ..." säger att människor och interaktion är viktigare än processer och verktyg. Projektgruppen är ryggraden i ett framgångsrikt slutförande av uppgifter.
6. integritet och kvalitet- du måste till en början göra en produkt av hög kvalitet för att inte slösa tid och resurser på ytterligare tester och bli av med buggar.
7. vision av hela bilden- Att dela upp projektet i separata delar är omöjligt utan att förstå den nuvarande utvecklingsstatus, mål, koncept och strategi för den programvara som utvecklas.

En mängd olika smidiga utvecklingsmetoder

Agil modellering (AM)

Agil modellering är en uppsättning värden, principer och metoder för programvarumodellering.

AM används som en del av en fullfjädrad metod för mjukvaruutveckling - till exempel extrem programmering eller snabb applikationsutveckling.

Agila modelleringsprinciper är följande:

• effektiv interaktion mellan projektets intressenter
• strävar efter att utveckla det enklaste av möjliga lösningar lämplig för alla krav
• konstant feedback
• mod att fatta och ta ansvar för beslut
• förstå att du inte vet allt.

Agile Unified Process (AUP)

AUP är en förenklad version av en annan metod för mjukvaruutveckling - Rational Unified Process (RUP). Sedan 2012 har den ersatts av Disciplined Agile Delivery (DAD), men AUP finns fortfarande på vissa ställen.

Författaren till metodiken, Scott Ambler, lyfte fram följande nyckelpositioner i den agila enhetliga processen:

• Ditt team vet vad de gör;
• Enkelhet kommer först.
• Överensstämmelse med principerna för agil utvecklingsmetodik.
• Fokusera på aktiviteter som är värdefulla för projektet.
• Oberoende i valet av verktyg.
• Individuell anpassning av AUP för behoven hos ett specifikt projekt.

Agile Data Method (ADM)

ADM är en uppsättning iterativa smidiga mjukvaruutvecklingsmetoder som betonar kravbildning och projektbeslut genom samarbete mellan enskilda team. Precis som AUP är det inte en självförsörjande teknik.

Kärnan i Agile Data Method definieras av sex punkter:

1. Data- grunden för att skapa en applikation.
2. Problem med projektet- de kan bara hittas med en tydlig förståelse för projektets syfte och koncept.
3. Arbetsgrupper- förutom direktutvecklingsteamet finns det företagsgrupper som stöder andra arbetsgrupper.
4. Unikhet- det finns ingen idealisk metod, för varje projekt måste du kombinera verktyg från olika metoder.
5. Lagarbete- lagarbete är mycket mer effektivt än ensamt.
6. "Skön plats"- sök efter den optimala lösningen på problemet ("sweet spot"), undvik extrema.

Essential Unified Process (EssUP)

Utvecklad av den svenska forskaren Ivar Jakobson, utformad för att förbättra den rationella enhetliga processen.

EssUP arbetar med begreppet övning, vilket inkluderar:

• use case - en beskrivning av systemets beteende.
• iterativ utveckling - skapa kodbitar i korta cykler på flera veckor.
• teampraxis - syftar till att förena laget och öka dess effektivitet.
• procedurmetoder som "Tänk stort, börja i det lilla" eller "Engagera intressenter i affärsprocesser."

Alla metoder finns i en eller annan form i utvecklingsmetoderna RUP, CMMI och Agile.

Bli verklig (GR)

En effektiv metodik för nystartade och nybörjarteam som erbjuder maximal användning av funktionerna i små projekt och företag: mobilitet, flexibilitet, sökning efter nya lösningar, frånvaron av en stel förvirrande hierarki etc. Jason Freed och David Hansson, grundare av 37signaler (nu Basecamp), definierade Getting Real som ett system för att lösa problem i verkligheten: så enkelt, förståeligt och funktionellt som möjligt.

GR är en prefabricerad hodgepodge med ett dussin agila utvecklingsverktyg som används för att minimera:

• möjligheter
• alternativ och inställningar
• företagsstruktur
• möten
• löften.

Det ovanliga konceptet antogs inte allmänt, även om vissa element använder olika tekniker.

OpenUP (OUP)

En verktygsoberoende mjukvaruutvecklingsmetodik utan en styv struktur som innehåller följande metoder:

• mäta teamets hastighet;
• hålla dagliga möten och återblickar efter avslutade iterationer;
• begreppet mikrostegning och tidig testning med hjälp av checklistor;
• Agil modelleringsteknik (AMDD).

Metoderna genomförs utifrån fyra principer:

Agila mätvärden

Med tanke på de olika verktygen, metoderna, metoderna och metoderna i Agile måste du välja ett verktyg som hjälper dig att avgöra effektiviteten för var och en av dem. Mätvärden är ett sådant verktyg.

För de flesta projekt räcker det med fyra mätområden:

1. Prestanda- detta inkluderar Velocity och WIP. Det första är inte lämpligt för alla projekt, eftersom antalet slutförda uppgifter per iteration mäts och de är ojämlika. Metoden Work-in-Progress bestämmer gränsen för uppgifter för olika stadier: och ju högre det är, desto värre;
2. Prognos- kapacitetsmått: bestämma antalet ideala timmar tillgängliga i nästa sprint. Följaktligen kan du förstå hur mycket tid du har att arbeta, hur effektivt uppgifterna slutförs och hur du gör för en sprint;
3. Kvalitet- till exempel indexet för kravstabilitet, som beräknas med formeln = ( Totala summan ursprungliga företagskrav + Antal krav som har ändrats vid den här tiden + Antal tillagda krav + Antal borttagna krav) / (totalt antal ursprungliga krav). Mätvärdet bestämmer hur mycket tid som används för omarbetning av uppgifter.
4. Värden- i varje fall beräknas det individuellt, beroende på projektets format. Till exempel valde start AirBnb antalet foton av hög kvalitet som laddades upp som ett mått som bestämmer slutproduktets värde för användarna. Med deras ökning ökade antalet konsumenter proportionellt.

Samma regler gäller för mätvärden som för andra Agile -verktyg.

Det finns inget enda mått som är rätt eller behövs för ditt projekt.

De måste ständigt granskas, föråldras och nya läggas till efter behov. Det ska vara förståeligt och tillgängligt för hela laget, inte bli ett mål i sig. Metriska för metriska skull är ett dåligt beslut.

Mythbusters: Agile

Agile -familjens popularitet har spelat ett grymt skämt om den, och även specialiserade portaler har myter om en eller annan aspekt av Agile. Vi kommer att ta reda på det!

Myt # 1: Agile fungerar för alla projekt.

Den mest ihållande vanföreställningen. Ingen agil metod kommer i sig att tillföra värde till en produkt eller motivera ett team.

Myt # 2: Agil kontra dokumentation.

Agil utveckling är inte mot dokumentation, det är mot dokumentation som ett mål i sig. Men när man väljer dokumentation som kommunikationsmedel prioriterar Agile verkligen livekommunikation.

Myt # 3: Rörlighet och planering är oförenliga.

Daglig schemaläggning med 10-minuters stand-ups, iterativ schemaläggning varannan vecka, sprintmöten etc. är en motbevisning till denna myt.

Myt # 4: Agile kräver mycket omarbetning.

I smidig mjukvaruutveckling finns omarbetning i två former: krav på omarbetning (användare förstår vad de verkligen behöver) och programvara (utvecklingsteam hittar bättre sätt att skriva och designa en applikation). Men du måste hantera detta i andra metoder också! För att minska den negativa effekten av omarbetning behövs dessutom en iterativ modell, som är en egenskap hos Agile.

För- och nackdelar med att använda Agile

Fördelar:

1. intressenternas engagemang- teamet har fler möjligheter att förstå kundens önskemål. Och tidig och frekvent leverans av programvara stärker intressenternas förtroende för projektteamet och engagerar sig ytterligare i projektet.
2. tidig och förutsägbar leverans- utvecklingsmodellen genom iterationer (korta intervall från 1 till 6 veckor) ger flexibilitet, påskyndar frisättningen av produkten.
3. med fokus på affärsvärde- Samarbete med kunden ger teamet en förståelse för hur man gör produkten så värdefull som möjligt för konsumenten.
4. kontinuerlig kvalitetsförbättring- testning under varje iteration, genom att dela upp den slutliga byggnaden i separata bitar av arbetskod gör att vi kan förbättra och hantera programvarubuggar innan den slutliga produkten släpps.

Minus:

• ökade krav på teamet och kunderna- utan nära interaktion mellan projektteamet och användarna är det omöjligt att uppnå en högkvalitativ produkt med högt värde... Och överflödet av verktyg och tekniker i Agile kräver ett erfaren team för implementering.
• inte lämplig för outsourcing och projekt där deltagarna bara interagerar med varandra online.
• risken att aldrig släppa den slutliga versionen av programvaran- detta minus kommer märkligt nog från iterativ utveckling och kontinuerlig produktförbättring - fördelarna med Agile.
• fungerar inte utan en tydlig vision av projektets affärsmål- eftersom Agile -teamet är fokuserat på intressenter är utveckling omöjlig utan utveckling av mål och ett produktkoncept.

Ansökningar

Att hantera projekt med Alla tjänster eller program för projektledning är inte lämpliga för Agile, eftersom alla har sina specifika egenskaper.

Om ditt företag tillhörmarknadsföring och reklam, design, seo eller digitala byråer sedan saas -tjänsten kan tillämpas på arbetet i hela teamet som helhet. Vi rekommenderas .

Här är ett par livshackar att ställa in Agile i

1. anpassa etiketter och statuser, som är nödvändiga för ditt företags arbete.
   Statusser kan vara följande: pågår, kontrollerar, gjort, behöver arbete, kritisk, funktion, lön.
   Taggar ser ofta ut som: layout, testning, produktion, koncept, kod.
2. skapa ett eftersläpsprojekt och projekt våren.
3. skapa uppgifter och preliminära checklistor, skisser, etc. i eftersläpningen.
4. på mit-ups definiera vårens uppgifter och överföra dem från eftersläpningen in i sprinten.
5. använda sig av kundgäståtkomst till uppgifter för att alltid ha konsekventa och aktuella kommentarer om projektet.
6. fira ansvarig för uppgifter så att varje kollega känner sitt ansvarsområde och känner sig delaktig i resultatet av sprinten.

Dom

Med smidig mjukvaruutveckling maximerar små projektteam effektiviteten. Agile implementeras genom andra agila metoder: Scrum, XP, Lean, etc.

Det är omöjligt att genomföra det på ett slag, av ett oerfaret team, på kort tid. men implementeringen av Agile kommer att förbättra interaktionen mellan IT och verksamheten, påskynda time-to-market och öka produktens värde för slutanvändaren.