Smidig planleggingsmetodikk. Smidig utviklingsmetodikk

Toyota-anleggssystemet har allerede blitt en klassisk og vellykket styringsmodell. Hver ansatt i bedriften hadde muligheten til å stoppe transportøren når som helst for å eliminere en defekt, funksjonsfeil eller komme med sitt eget rasjonaliseringsforslag. Det er på denne tilnærmingen Agile-filosofien er basert. Opprinnelig var Agile metodikk for ca. 10-15 år siden en metode for å utvikle programvare i små team. PÅ dette øyeblikket Agile metodikk er en ny kultur for å lede store bedrifter. I dag vet enhver progressiv manager hva Agile er.

Produkter og tjenester opprettes som regel i henhold til en enkelt klassisk ordning. Dette gjelder spesielt for IT-bransjen. Et slikt opplegg kalles en foss, eller iterativ utviklingsmetodikk, og i engelske språk- fossefall ("foss"). Hvorfor heter ordningen slik? Poenget er at hvis du allerede har godkjent en programvareproduktplan, kan du ikke suspendere den eller gjøre justeringer før implementering. Den har et helt annet prinsipp. Smidig metodikk. Foss er et konsept som ikke gjelder for det. Dette er en kvalitativt ny tilnærming til produktutvikling. Metodikken er basert på en enkel idé – hver deltaker har mulighet til å komme med nyttige forslag for å optimalisere prosessen, stoppe transportøren for å tenke nytt om oppgavene og den felles sak.

Agil metodikk har et rammeverk utstyrt med en rekke egenskaper. Blant dem:

• Rask respons på endringer.
• Uavhengig organisering av produksjonsprosessen.
• Forutsigbarhet.
• Tilstedeværelsen av kontinuerlig og konstant tilbakemelding.
• Separasjon av risikoer.

I mange bedrifter, når man utvikler produkter, er spesialister som løser viktige oppgaver for produksjonen fordelt på forskjellige avdelinger, ofte i konflikt med hverandre. Dette gjelder spesielt ansatte i driftsavdelingen, utviklere og testere. Dersom produktene ikke selges forsvarlig og får inntekter fra dette, skylder de motstridende partene på hverandre. Samtidig er det som regel alle som har skylden i slike situasjoner.

Smidig metodikk – en tilnærming som innebærer tilstedeværelse av alle som utvikler seg programvare. Samtidig gjør hver spesialist jobben sin. Smidig metodikk gjør det mulig å se at alle deltakerne i prosessen er forent av ett mål - å skape kvalitetsprodukter for sine kunder.

Når smidig metodikk brukes, endres hele forretningskulturen i selskapet. MBA-programmene inneholder et fullverdig kurs om organisasjonsstrukturen til en virksomhet, hvor man i studiet kan komme over begrepet «likevekt», når alle ansatte og deltakere i oppstart og oppstart løser vanlige problemer. Praksis viser at det er ved slike virksomheter at teamene er mer samlet, jobber med høy effektivitet og effektivitet. Når det gjelder å bringe nye ideer til markedet og øke effektiviteten, er Agile metodikk det beste verktøyet.

Noen selskaper trenger selvfølgelig ikke Agile metodikk. Vi snakker for eksempel om offentlige avdelinger, siden grunnlaget for deres virksomhet er lovgivende normer. Samhandling med staten er umulig dersom spillereglene endres regelmessig.

Det vil si at den organisatoriske infrastrukturen kan presenteres i to versjoner, radikalt forskjellige fra hverandre. Den første er et strengt byråkratisk selskap som overholder en rekke formaliteter. Dette alternativet har rett til å eksistere og fungerer fint under visse forhold. Den andre typen er oppstartsbedrifter som samler mennesker med samme ståsted og felles mål, som skaper noe fundamentalt nytt. Agile metodikk er selvfølgelig nærmere det emosjonelle teamet som jobber med produksjonen av et kvalitetsprodukt. Hvis det oppstår problemer på noen av stadiene, løses de innenfor rammen av Agile-metodikken av alle spesialister i bedriften eller oppstartsdeltakere.

Grunnleggende prinsipper for smidig metodikk

Det er et Agile manifest som snakker om de grunnleggende prinsippene for metodikken:

1. Det viktigste er å levere et verdifullt produkt regelmessig og på forhånd, og dermed tilfredsstille kundens behov. I samsvar med dette prinsippet om smidig metodikk, er produktskapere forpliktet til ikke bare å implementere kravene som er angitt i prosjektdokumentene, men også å fortelle forbrukeren så tidlig som mulig hva slags produkt det vil være, med hvilke funksjoner og egenskaper. Hvis produktet ikke tilfredsstiller kunden, er det presserende nødvendig å korrigere det, under hensyntagen til kommentarene. Siden, bringe inn i markedsmiljøet Nytt produkt, det er stor risiko for å gjøre en feil, det er logisk å bruke tekniske krav til etableringen av et minimum levedyktig produkt (MVP), hvis hovedoppgave er å sjekke hvor mye nøkkelkvaliteter som etterspørres blant kjøpere og å vurdere etterspørselsnivået.
2. Krav kan endres, og dette vil oppfattes positivt hvis vi snakker om å forbedre konkurransekvalitetene til produktet. Vanligvis endres de på slutten av det siste utviklingsstadiet. Dette prinsippet om smidig metodikk er svært viktig i dag, fordi produktene fra høyteknologiske industrier i så snart som mulig blir foreldet og viker for en ny. Du kan stille en rekke krav til produktet allerede på slutten av opprettelsen. Dette er vanligvis forårsaket av endringer i markedet eller i konkurransemiljøet. Merk at implementeringen av dette prinsippet er umulig hvis vi snakker om en kaskadestyringsmodell, eller den er ekte, men det vil koste sponsoren en rund sum. Men jo flere teknologier smelter sammen, jo mer relevant vil det være å forberede neste versjon av produktet for å ligge i forkant av konkurrentene.
3. Teamet og kunden må kontinuerlig samhandle på alle stadier av produktskapingen. Denne regelen er omtrent den samme som kundens ønsker. Det er viktigst. Hvis det ikke er konstant samhandling, er det vanskelig å nå de oppsatte målene.
4. Agil metodikk sier at kun motiverte fagfolk skal involveres i gjennomføringen av prosjekter. Ta vare på å skape de rette forholdene og stol på ekspertene. I dette tilfellet er sannsynligheten for gjennomføring av prosjektet av høy kvalitet svært høy. moderne vitenskap tyder på at det er vanskelig å stimulere til intellektuelt arbeid med økonomiske insentiver. Derfor bør du bare samarbeide med de spesialistene for hvem hovedmotivasjonen er selve prosjektet. Alt de trenger er å kunne jobbe under akseptable forhold og få tillit fra kunden.
5. Den beste måten kommunikasjon er personlig kontakt. Det er ønskelig at alle personer involvert i prosjektet er lokalisert på et felles territorium. La det være én bygning. Ideelt sett bør også kunden selv være der.
6. Prosjektet går videre hvis produktet fungerer. Kunden er interessert i et ferdig produkt med visse egenskaper. Nok et vellykket trinn i prosessen betyr ingenting for ham. Kunden skal se at produktet er i utvikling, og viktigst av alt, det fungerer og oppfyller de krav som er stilt. Hvis formen og innholdet er nær ønsket modell, jobber utviklerne effektivt.
7. Sponsorer, kunder og utviklere må sørge for å sikre et konstant aktivitetstempo. Hvis alle deltakerne i prosessen opererer i en stabil rytme, slutter de å bekymre seg for sannsynligheten for en hastejobb eller manglende overholdelse av tidsfrister.
8. Oppmerksomhet bør også rettes mot teknisk fortreffelighet og designkvalitet. Agile metodikk sier at utviklingen av et prosjekt skal være fleksibel, uten å gå på bekostning av kvaliteten på produktet og forenkle dets egenskaper. Merk at dette ofte brukes for å fremskynde prosessen med å lage et prosjekt og optimalisere det.
9. Ikke glem prinsippet om enkelhet. Ved å bruke den reduserer du sannsynligheten for å utføre unødvendige handlinger til et minimum. Poenget er ikke å forenkle produktets egenskaper, men å kvitte seg med unødvendige operasjoner og ikke inkludere i prosjektet noe unødvendig for den tiltenkte bruken.
10. Selvorganiserende team genererer alltid de beste arkitektoniske, tekniske og andre ideene. Forfatterne av Agile Manifesto er overbevist om dette. Derfor må alle teammedlemmer utvikle krav og ta beslutninger sammen. Hvis teammedlemmer har felles interesser og felles mål, blir selvorganisering mer effektiv.
11. Ytre forhold er i stadig endring. I denne forbindelse bør man hele tiden analysere og tilpasse seg situasjonen, se etter måter å forbedre effektiviteten til aktiviteter. Smidig metodikk er spesifikt fokusert på fleksibiliteten til utviklere. Det er dette du bør strebe etter.

Ekspertuttalelse

Perspektiver av smidig metodikk i Russland

Andrey Kocheshkov,

Sjefanalytiker i OAO Publishing House Prosveshchenie

Smidig metodikk har en rekke fordeler, hvorav de viktigste er fleksibilitet og evnen til å tilpasse seg, tilpasse seg ethvert miljø og organisatorisk prosess. Smidig metodikk - beste alternativet for prosjekter der slutten er "åpen". Det kan være opprettelsen av et dataspill, operativsystem eller internetttjeneste. Samtidig kan du på grunn av fleksibilitet etter hvert miste fokus og redusere forutsigbarheten.

Det er ekstremt viktig å skille feilene ved bruken av en smidig tilnærming fra manglene ved Agile-metodikken. Det vil ta litt tid før fordelene med metodikken blir realisert. Det er nødvendig å tilpasse tilnærmingen til den nåværende situasjonen i en bestemt virksomhet, og i løpet av denne perioden er det mulig å gjøre mange feil. Men faktum gjenstår: Smidig metodikk er i ferd med å bli et av de mest populære paradigmene både i Russland og rundt om i verden.

Agile metodikker: Agile, Lean, Scrum og andre

Agile Manifesto definerer spesifikke prinsipper. Basert på dem er det dannet en smidig utviklingsmetodikk Agile.

• Smidig modellering (AM). Modelleringsprosedyrer (inkludert verifisering med modellkode) og dokumentasjon under programvareutvikling brukes her. Mindre oppmerksomhet rettes mot prosedyrene for utforming og bygging av diagrammer i UML. Det står ikke om områder som utvikling, testing, prosjektledelse, utplassering og vedlikehold.
• Agile Unified Process (AUP) er en enhetlig versjon av RUP (IBM Rational Unified Process) metodikken, som ble dannet av Scott Ambler. AUP definerer programvareutviklingsmodellen for forretningsapplikasjoner.
• Agile Data Method (ADM) er en iterativ metodikk for smidig programvareutvikling i et kompleks, som legger vekt på utvikling av løsninger og krav. Ulike tverrfunksjonelle team samarbeider med hverandre.
• Dynamic Systems Development Method (DSDM) er en inkrementell og iterativ metode basert på Rapid Application Development (RAD). Det legges vekt på å maksimere involveringen av sluttforbrukeren i produksjonen av produkter.
• Essential Unified Process (EssUP). Forfatteren av tilnærmingen er Ivar Jakobson. Tilnærmingen er utstyrt med metoder for iterativ programvareutvikling. Det legges vekt på produktarkitektur og teamets beste praksis hentet fra RUP, CMMI og Agile Development. Essensen av ideen er å bruke bare de metodene og teknikkene som brukes i et bestemt tilfelle. Det er deres valg som er grunnlaget for å bestemme målprosessen. Denne tilnærmingen skiller seg fra RUP med innbyrdes relaterte metoder og praksiser. Det er også fleksibilitet og muligheten til å isolere de nødvendige elementene fra alt som er tilgjengelig.
• Ekstrem programmering (XP), eller ekstrem programmering. Essensen av metoden er å bruke de eksisterende beste teknikkene innen programvareutvikling og forbedre dem. Denne tilnærmingen og vanlig praksis skiller seg fra hverandre, spesielt ved at i sistnevnte tilfelle utfører programmereren en sekvensiell sjekk av koden skrevet av sin kollega. Ekstrem programmering innebærer parallell testing, noe som fører til raskere produktutgivelser, men også øker risikoen.
• Funksjonsdrevet utvikling (FDD). Som en del av å bruke metoden er det stort forbud, som består i at implementeringen av hver funksjon skal utføres innen to uker og ikke mer. Ideelt sett utvikles den på én gang. Hvis dette ikke er mulig, deles funksjonen i flere og implementeres problemfritt.
• Getting Real (GR) - når du bruker metoden, ikke ty til prosedyrene for funksjonelle spesifikasjoner som brukes for webapplikasjoner. Utviklingen starter fra baksiden, det vil si at de først tenker på design og grensesnitt, og deretter på det funksjonelle innholdet.
• OpenUP (OUP) - RUP er grunnlaget for utviklingen av tilnærmingen. Metoden definerer en iterativ-inkrementell måte å lage programvare på. Som en del av tilnærmingen sies det om Livssyklus utvikling (faser av lansering, foredling, utvikling og overføring til kunden). Metoden implementeres i flere stadier, kontrollerer visse kontrollpunkter, noe som bidrar til å øke effektiviteten av kontroll og overvåking av gjennomføringen av prosjektet. Alle beslutninger som gjelder prosjektet tas i tide.
• Lean programvareutvikling. Tilnærmingen er basert på konseptet lean manufacturing company management (lean production, lean manufacturing).
• Scrum er en av de mest ettertraktede smidige programvareutviklingsmetodene og definerer reglene for å styre produksjonsprosessen ved hjelp av velkjente metoder. Det er i dette tilfellet lagt vekt på involvering av kunden i utviklingen (når neste trinn er gjennomført, er det mulig å endre eller avklare kravene til produktene som lages). Dette lar deg identifisere mangler og rette opp produktet.

Agile Scrum-metodikk er en av de populære teknologiene

Nesten den vanligste Agile-metodikken er Scrum ("Scrum"). Navnet kommer fra rugby. Dette er for tiden navnet på den mest strukturerte Agile utviklingsmetodikken. "Scrum" på idrettsbanen er en intens laghandling rettet mot å oppnå målet - å få ballen for det påfølgende angrepet av motstanderen.

Scrum-perioden er kort. De beste idrettsutøverne med utmerket trening deltar i denne fasen av rugby, siden det er ganske traumatisk. Hvis det ikke er trente og sterke spillere, blir Scrum rett og slett ikke gjennomført. Scrum-metodikken i Russland blir mer og mer utbredt. La oss dvele ved det mer detaljert.

Scrum er basert på sprint. Dette er navnet gitt til kortsiktige faste handlinger for å skape og gi forbrukeren et fungerende produkt med nye egenskaper. Dens evner overgår samtidig de som var tidligere. Termen for "sprinten" er fast, og forutsigbarheten og fleksibiliteten til skapelsesprosessen avhenger av den. Hvis tidsrammen er kort, blir avlesningene av fleksibilitet og forutsigbarhet høyere, men den relative kostnaden for hver iterasjon, samt tiden brukt på organisering og møte med kunden og teammedlemmer, øker også.

Et viktig element i metodikken er produktetterslepet. Dette er en liste over krav til det endelige resultatet. Kravene her er tydelig strukturert etter viktighetsnivå. Det er fra listen at oppgaver tas for påfølgende spurter. Listen kan endres og suppleres i løpet av klargjøringen av produktenes egenskaper og salg.

Det er et planleggingsstadium der nye funksjonelle kvaliteter til det opprettede produktet bestemmes for neste sprint. Etter å ha løst problemet, kompileres en sprintbacklog (Sprint Backlog). Den forblir uendret hele veien.

Metodikken definerer også strukturerte roller i prosjektet:

• Scrum Master er et mellomledd mellom teamet og klienten.
• Produkteieren representerer kunden, danner, prioriterer Product Backlog og aksepterer mellomresultatene av arbeidet.
• Team - et prosjektteam hvor det ikke er separate roller. Det er et selvorganiserende system som inkluderer motiverte fagfolk på tvers av funksjoner.

Metodikken gir finansfolk en rekke fordeler, nemlig:

• gir en mulighet til å spare penger ved å ikke jobbe gjennom prosjektdokumenter på lenge;
• lar deg kontrollere budsjettet til prosjektet fullt ut;
• gjør det mulig å foreta justeringer uten vesentlige økonomiske tap for foretaket;
• lar deg lansere produkter tidlig og få den første inntekten fra det.

Hovedproblemet i dette tilfellet er spørsmålet juridisk registrering denne typen aktivitet og samhandling med det eksterne utviklingsteamet.

Hvorfor du trenger en smidig ledelsesmetodikk

• Systemet lar deg føle deg bra i en kriseperiode og i usikre situasjoner, tjene penger, beskytte virksomheten din, bruke tilgjengelige ressurser og muligheter kompetent.
• Agile metoder er foretrukket som store bedrifter som implementerer agile ledelsesmetoder samt små selskaper. For den nyeste Agile-metodikken er det beste alternativet. Vi snakker om serveringssteder. tannklinikker og kontorer, bilforhandlere; i tillegg lar Agile metodikk deg "tune" forretningsprosesser på områder som organisasjon utenlandsk økonomisk aktivitet, bygge salgssystemer og krisehåndtering.
• Agil metodikk brukes i ledelse, markedsføring, finansnæring, personalledelse. Takket være det kan du oppnå ultrarask prosjektgjennomføring og utmerkede resultater.
• Agil metodikk er først og fremst fleksibel tenkning og først deretter verktøy. For å bruke den med hell, må du visse endringer inn i mentaliteten, kulturen for å jobbe med prosjekter i bedriften.
• Agile har mange metoder. De mest populære i dag er Scrum og Kanban.
• Smidig metodikk bidrar til å bringe virksomheten din til et nytt nivå, og tar hensyn til eksisterende evner, ressurser og praktiske ferdigheter til ansatte.
• Agile metodikk passer for enhver bedrift som fokuserer på å generere mer inntekt og øke innflytelsen i markedsmiljøet.
• Agile metodikk gir søk og introduksjon av nye teknologier assosiert med et gjennombrudd, utvikling av interne gründervirksomhet, kreativitetstilnærming og tenkning i store organisasjoner.

Alt det ovennevnte er bare begynnelsen. Mange forretningseksperter og ledere av store bedrifter er sikre: Smidig metodikk er fremtiden til den moderne økonomiske industrien.

Ekspertuttalelse

Implementering av smidig metodikk for å forbedre personalets effektivitet

Maria Onuchina,

Direktør for Asset Management-avdelingen ved Becar Asset Management Group, Moskva

Vi har endret kontorlokalene våre for å gå mot smidig ledelse:

Trinn 1.Organisering av arbeidsplasser.

I løpet av en måned studerte vi arbeidsplassene til personellet, identifiserte avdelingene hvor effektiv drift fullstendig stillhet er nødvendig (dette er for eksempel regnskap), trakk oppmerksomheten til avdelingene der spesialister jobber, som konstant er borte og bruker ikke mer enn 3 timer om dagen på kontoret. Vi mottok en tidsplan som viser antall ansatte og spesifikke arbeidsoppgaver. Basert på mottatt informasjon startet vi rekonstruksjonen av kontoret.

For ansatte som har en fast tilstedeværelse på jobb, er det utstyrt med faste plasser. Mobilt personale fikk midlertidig plass i friområdet. Du kan komme dit, ta favorittstedet ditt og slå på fjerntilgang. Vi tok også hensyn til uformelle områder: rom for rekreasjon, forhandlinger og en fungerende kafé.

Vi prøvde å organisere plassen på kontoret slik at ansatte har mulighet til å endre plassering når som helst:

• om nødvendig, vær alene;
• komme sammen i minigrupper;
• holde et møte mellom avdelinger i enhver sammensetning.

Antall slike soner i prosjektet ble påvirket av hvor stor andel av virksomheten prosessen tilhører.

Trinn 2.Tilpasning av arbeidere.

Videre ga vi bistand til spesialister i tilpasning. Mange er redde for endringene som Agile-metodikken innebærer, selv om de er til det bedre. Etter at det hadde gått noen uker ble det klart at arbeiderne likte alt, og de forlot kontorene. På dette stadiet er det verdt å la personalet forstå at i fravær av endringer i forretningsprosesser, risikerer bedriften å forlate markedsplassen.

Trinn 3.Innføring av uvanlige løsninger.

Vi introduserte en rekke funksjoner: vi organiserte en kino i fellesområdet, hvor presentasjoner vises under arbeid, og filmer vises om kveldene, samt en vegg med et bilde av et tre hvor verdiene til selskapet er skrevet.

Det nye kontoret er uvanlig, men komfortabelt. Vi utstyrte den med møbler på flere nivåer: barkrakker, bønneposer, skinn- og stoffsofaer, glassbord. Smidig ledelse er preget av detaljer som:

• moderne tekniske løsninger;
• IT-infrastruktur;
• komfortable møbler;
• overflater for opptak av ideer under forhandlinger osv.

Design og reparasjonsarbeid ble gjennomført i to måneder. I løpet av denne perioden utførte selskapets spesialister arbeidsoppgaver på territoriet til det gamle kontoret. Reparasjonskostnadene var omtrent det samme som kostnadene for en typisk rekonstruksjon. Prisen ble kun påvirket av møbler og den nyeste teknologien.

Resultat. Noen måneders opphold på det forbedrede kontoret viste at arbeidet har blitt et team, og kommunikasjonen mellom spesialister fra ulike avdelinger har blitt bedre. Klarte å spare på husleien. I gjennomsnitt er det 12-40 m 2 per person på kontoret til en storstilt organisasjon. Tidligere hadde vi 10 m 2, og dette tallet ble redusert til 6 m 2, noe som effektivt fordelte arbeidsplasser. Tilbakebetalingstiden for prosjektet var 1,5 år.

Vi har utstyrt alle møterom med Wi-Fi og konferansesamtaler. Så vi ble kvitt behovet for å leie konferanserom for å kunne holde eksterne møter i dem. Komfortable forhold tiltrekker seg ansatte, takket være at de bruker mer tid på jobben og utfører oppgaver mer effektivt.

Hvilke problemer kan oppstå når en Agile metodikk brukes

Oppgave 1.Rollevane.

Spesialister i prosjektteamet går først, med liten vilje, videre til å utføre arbeid som er uvanlig for dem, og innser til og med at det vil bli bedre på denne måten. For eksempel liker analytikere ofte ikke å teste et system, selv om hvem, hvis ikke de, vet alt om funksjonene til dets funksjon? Slike problemer er enkle å oppdage i et team og er vanligvis enkle å fikse.

Oppgave 2Dokumentasjonsvane.

Først venter utviklerne på kravene fra kunden - prosjektdokumentasjon med en forklaring på alle problemstillinger. Denne metoden for å sende informasjon er ikke den mest effektive, og derfor er det bedre for utviklere å venne seg til direkte kommunikasjon med klienten. Over tid, etter å ha kommunisert med kunden, vil det bli lettere for utviklere å fordype seg i forviklingene i virksomheten og løse åpenbare problemer. Selv om de gjør en feil, vil klienten raskt merke det på slutten av iterasjonen, og feilen kan rettes opp i tide.

Oppgave 3.Nytt lag.

Prosjektlederen risikerer å møte vanskelighetene ved å jobbe med et nytt team. Deltakerne kan fortsatt ikke kommunisere ordentlig med hverandre, det er ingen kontakt mellom dem, de er flaue over å be om hjelp og er redde for å kritisere noen for en feil avgjørelse. Prosjektleder er ansvarlig. Han er forpliktet til å hjelpe teammedlemmer med å etablere uformelle relasjoner, hvis eksistens er antydet av Agile-metodikken. Det kan være nyttig å organisere en felles tur til en restaurant, et teambuilding-arrangement eller en idrettskonkurranse.

Oppgave 4.Kommunikasjonsproblemer.

Oppgaven til prosjektlederen i den innledende fasen er å holde stevner med teammedlemmer for å oppnå produktive og effektive aktiviteter.

Oppgave 5.Tidspress.

Ofte legger kunder press på utviklere, forhaster dem. Kunder ønsker å motta ønsket produkt på kortest mulig tid. Teamet må implementere kravene nøyaktig uten å ofre kvaliteten. Ellers, i det lange løp, vil hastigheten på opprettelsen avta, da kostnadene for endringer på grunn av dårlig kvalitet vil øke. I tillegg har mangelen på kvalitet en negativ innvirkning på motivasjonen til utviklerne. Prosjektlederen bør jevnlig minne mentees på behovet for å opprettholde høy kvalitet.

Oppgave 6.Kreativitet.

Oppgaver i prosjektet er både interessante og lite. Utviklere liker ofte å ta beslutninger som skader prosjektet, men som er teknisk interessante. Her er det verdt å huske prinsippene til KISS (keep it simple, stupid) og YAGNI (you ain't gonna need it). La hovedkarakteristikken for designbeslutninger være enkelhet. Du bør ikke gjøre det som ikke er spesielt nødvendig for øyeblikket.

Hva bør gjøres for å få teamet til å ta enkle beslutninger? Noen ganger er det nyttig å la spesialister gjøre en engangsfeil, slik at de senere kan analysere den nøye og la utviklerne forstå hva som bør og ikke bør gjøres. Nesten ethvert prosjekt suppleres på en eller annen måte med forskningsoppgaver (nye teknologier og ingeniørfelt kunnskap). Det er her du må prøve og eksperimentere.

Oppgave 7.Tidsestimat.

Ved å bestemme tidspunktet for å løse problemet, tar eksperter i betraktning kun å skrive kode. Og samtidig inkluderer oppgaven i det minste opprettelsen av design og testing. Helt i starten av prosjektet tror utbyggerne at de blir ferdige med prosjektet tidligere enn mulig. På slutten av prosessen noterer eksperter feil og trekker konklusjoner for fremtiden. Tiden går, og teamet lærer å vurdere situasjonen riktig. Vanligvis, etter 3-4 iterasjoner, forbedres nivået av nøyaktighet og ytelse.

Oppgave 8.Ledelsesproblem.

Forventningene til ledelsen er tilgjengeligheten av visse funksjoner innen den angitte tiden. Men smidig metodikk garanterer ikke implementeringen av planer med 100 %. Det er bare logisk å vente på at de prioriterte oppgavene skal løses. Det er nyttig å koordinere planer på utsettingsnivå med ledelsen. Det høye nivået på utgivelsesplanen lar lederen variere omfanget av utviklingen av selv individuelle egenskaper ved systemet innenfor en ganske lang tidsramme. For eksempel kan oppgaven med å lage et søkedelsystem inkludere regnskap for morfologi. Besparelser er mulig på dette stadiet.

Oppgave 9.Problemer med ikke-teamadferd.

I prosessen med å implementere Agile-metodikk er det ikke utelukket neste situasjon. Det er rally, og plutselig reiser en av deltakerne seg og begynner å snakke om ideene sine. Han godtar ikke innvendinger, men etter en tid snakker han om avgjørelsen som ble tatt, og tilbyr å begynne behandlingen av det andre spørsmålet. Teamet tok selvfølgelig ingen avgjørelse. Faktisk gjorde det det dette medlemmet tar det fra henne med en gang.

Det er flere alternativer her. Det er mulig at personen rett og slett var i en altfor entusiastisk tilstand, som snart skulle gå over. Men ofte er det de som rett og slett ikke kan være en del av teamet på grunn av sin natur.

Smidig metodikk uten feil

Feil 1.Toppledere forstår ikke hva Agile metodikk er og til hvilket formål den skal implementeres.

Det krever en nøyaktig forståelse av hvilket resultat vi er interessert i, hvilke tidsfrister og budsjett vi har. Uklare mål og vakre formuleringer, som «Bli nummer én i ditt felt» eller «Bli mer effektiv» er ikke egnet. La oppgavene uttrykkes i tall. For eksempel: "Oppnå en omsetning på 3 milliarder dollar i 2018", "Reduser tiden for å lage et produkt til 3 måneder", etc.

Feil 2.Feil diagnose.

Ofte, når en bedrift introduserer en Agile-metodikk, ønsker å løse en rekke spesifikke problemer, for eksempel overprisede kostnader eller dårlig kvalitet på varer. Men du må finne ut i detalj hvor det er hull. Ellers vil lederen vente på at Agile-metodikken skal endre alt. Her risikerer han imidlertid bare å forverre situasjonen.

Feil 3.Innføringen av Agile bare i et eget område av forretningsprosesser.

Dette er en logisk fortsettelse av den andre feilen beskrevet ovenfor. Årsaken til hennes innrømmelse er den samme: mangel på forståelse av problemet og hvor det skjuler seg. Alle grener av foretaket må endres: produksjons- og markedsføringsdeler, regnskap og salg. Ellers vil ingenting fungere. Hvis du introduserer endringer kun i markedsføring og ikke venter på ønsket effekt, vil du ha en sterk oppfatning av at Agile-metodikken er ineffektiv.

Feil 4.Nedtoner viktigheten av å involvere alle ansatte i bedriften.

Du må være allierte med kollegene dine. Hvis dette ikke er tilfelle, er det bedre å spare ressurser, tid og ikke gjøre noe. Agil metodikk innebærer initiativ, mobilisering og ansvar fra alle som deltar i prosessen, i hvert fall lederne i virksomheten. Hvis disse menneskene er sterke og autoritative ledere, i stand til å oppnå god disiplin i å løse problemer og innføre nye regler på jobben, så vil alt ordne seg. I følge statistikk har 85 % av virksomhetene ikke sterke ledere med tilstrekkelig faglig opplæring.

Feil 5.Illusjonen om at alt er mulig bare takket være menneskelig innsats.

Kompetansen, motivasjonen og faglige nivået til personalet er selvsagt viktig for å nå målene. Men oppmerksomhet bør også rettes mot riktig teknisk utstyr til selskapet, programvare, ved hjelp av hvilken styring og planlegging av aktiviteter blir mer effektiv. I denne forbindelse, enten du liker det eller ikke, må du investere i kjøp av maskiner, utstyr og programvare.

Feil 6.Motvilje mot å bytte rammer.

Nesten 90 % av suksessen avhenger av teamet til bedriften. Fortsatt oppmerksomhet bør rettes mot utvikling, opplæring og riktig motivasjon ansatte. Mange spesialister er ikke klare til å jobbe i henhold til Agile metodikk, de er ikke interessert i ny kunnskap og muligheter, mestrer forretningsprosesser. Omtrent 25-30 % av selskapets ansatte ønsker ikke å yte sitt beste og streber etter høy inntjening. Det er bedre for slike ansatte å si: «Farvel». Svake lenker kan være ganske vanskelig å identifisere, og derfor gjør ofte ikke HR-ledere dette.

Feil 7.Tap av interesse og medvirkning av toppledere.

Det tar vanligvis 8-16 måneder å gjennomføre et prosjekt. I 70 % av situasjonene, etter tre måneder, synker interessen til deltakerne. Som et resultat ønsker teammedlemmer rett og slett ikke å være en del av prosjektet. Hvis dette er tilfelle, vil du selvfølgelig ikke være i stand til å løse problemet.

Smidig metodikk: eksempler på mislykket applikasjon

Agil metodikk tiltrekker seg mange fagfolk, og til dags dato har en rekke verdenskjente selskaper forsøkt å implementere den. Men nesten ingen klarte å oppnå ønsket resultat.

Eksempel: i 2015 på Børs i New York ble det holdt auksjoner som måtte stanses i hele 4 timer. Først ble det forklart med et nettangrep. Men som det viste seg senere, var problemet en feil i prosessen med neste oppdatering. Selvfølgelig ga 4 timers nedetid for verdenshandelssenteret milliarder av dollar i tap.

Og dette eksemplet er ikke det eneste. Det er lettere for meglere: de tapte, og så tjente de dobbelt så mye. Situasjonen er mer komplisert for flyselskapene. Omtrent den samme situasjonen skjedde med Delta-luftfartsselskapet etter en enkel programvareoppdatering. Utsendelsessystemet sluttet å motta data, noe som førte til tvungen kansellering av flyreiser. Selskapet led ikke bare tap, men betalte også med sitt rykte.

Den mest profilerte feilen i Agile-metodikken er assosiert med lanseringen av Obama Care-sykeforsikringssystemet i USA. Betydningen av programmet var som følger: visse kategorier av amerikanske borgere ble utstyrt med gratis forsikringer. For å oppnå en slik rettighet måtte en person fylle ut et spørreskjema på nettstedet og vente på avgjørelsen fra visse tjenester. Selvfølgelig hastet millioner av mennesker for å fylle ut spørreskjemaene. Men problemet var at de var i stand til å fylle ut spørreskjemaet, men de kunne ikke sende det, det var en slags serverfeil. Obama Care-systemet ble avsluttet omtrent 6 måneder etter lanseringen. For å få jobben gjort, hentet interessentene inn en spesialist utenfra som vurderte situasjonen. Konsulenten har kommet langt, med start fra slutten - "produksjon", sette sammen delene og klart å oppnå riktig funksjon av systemet.

Ekspertuttalelse

Eksempel på vellykket implementering ENgil-kontroll

Sergey Buchik,

Generaldirektør i NPM Group, Novosibirsk

Selskapet, inkludert alle avdelinger, har gått over til Agile metodikk i 1,5 år. Tidligere har HR-avdelingen bestått av: en HR-spesialist, en opplæringsleder og en rekrutterer. Ledelsen av avdelinger, valg av nytt personell eller gjennomføring av opplæring, fylte ut søknader i et stort antall. Nå har hver avdeling i bedriften sin egen HR. I utviklingsteam som jobber med Scrum-metodikken er denne plassen reservert for Scrum Master. Produktene her er en personaltjeneste, og teammedlemmer er interne forbrukere.

Den nye ledelsesstilen etter Agile metodikk har slått godt rot i rekrutteringsfeltet. Kunden kan planlegge sine aktiviteter, under hensyntagen til kandidatens exit på nøyaktig det angitte tidspunktet. I løpet av 9 sprints på 2 uker klarte vi å redusere antall forfalte stillinger med 2 ganger. En enkel ledig stilling (for eksempel en trinse) er nå stengt om 20 dager, en gjennomsnittlig (serviceingeniør) - 32 dager, en sjelden spesialist (teknolog for plaststøping) - 51 dager. Etter å ha fullført den første spurten ble det klart for rekruttererne at det viktigste for avdelingsledere ikke er hastigheten på søket, men de transparente fristene for å stenge ledige stillinger og tiden de kan bruke på å velge en medarbeider med etterutdanning . For øyeblikket forteller lederen kunden om tidspunktet og stadiet for søket etter søkeren. Det er også rekrutterernes ansvar å "pumpe" den tekniske kompetansen som trengs for å effektivt rekruttere produksjonsjobber, for eksempel å lære å lese tegninger.

La oss gi et eksempel: ledelsen av avdelingen innser ikke hva slags ansatt den trenger, eller dette problemet bestemmes av spesialister fra flere avdelinger samtidig. La oss si at en bedrift trenger en lagerholder som skal jobbe i et verktøylager. I dette tilfellet bestiller produksjonsavdelingen og logistikktjenesten en ledig stilling. Det er rekruttererens ansvar å ta hensyn til kravene fra disse avdelingene til søkeren. Produsenter trenger en teknisk spesialist som kjenner det moderne perfekt skjæreverktøy i metall. Logistikkere ønsker å se enhver profesjonell med erfaring og som vet perfekt hva lagerlogistikk er. Kundene har ennå ikke bestemt seg og har ikke utledet en fellesnevner, men rekruttereren ser allerede etter en kandidat, med tanke på søkere. Etter å ha valgt den beste, etter hans mening, søker, fører han dialog med alle kunder. Dersom det ikke er mulig å komme til enighet etter intervjuet, gjør rekruttereren endringer i stillingens tekst.

For øyeblikket kommer avdelingene frem til at målgruppen bør inkludere tekniske mestere med utmerket kunnskap om verktøyet. Rekruttereren søker igjen, velger ut passende søkere og møter dem. Dette fortsetter til stillingen stenger.

Agile prosjektledelsesmetodikk: 6 regler for effektivitet

Regel 1 Arbeid med prosjektplanen og svar på følgende spørsmål: hvilke oppgaver er prioritert, hvilke ressurser kreves for dette, hva er tidsrammen for å oppnå resultatet?

Langsiktige planer har en ganske lav nøyaktighet, så planlegg i tre plan:

• en langsiktig plan som indikerer alle oppgavene som kreves for å fullføres og større planlegging av tidspunktet for implementeringen av viktige milepæler;
• månedlige målplaner, basert på den generelle planen (gjennomføringen deres skal ikke være mindre enn 90%);
• definer innen en måned de mest detaljerte målene, og beskriver tydelig resultatene av oppnåelsen deres.

Regel 2 Involver teamet i gjennomføringen av prosjektet, informer de ansatte om det. Alle spesialister skal forstå og dele målene til organisasjonen, vite hva som skal til for å løse oppgavene, selv om disse ansatte ikke oppfyller dem innenfor rammen av prosjektet.

Regel 3 Møt med implementeringsteamet fra tid til annen. Møtefrekvensen er 1-2 ganger i måneden. Dette er nødvendig for å bestemme løsningen av oppgaver og problemer, rettidig justering av planen i tilfelle problemer med implementeringen. Men for å regulere akutt konfliktsituasjoner følger ikke med under møtet, som er berammet om en uke. Fullmakten skal være klar og rask.

Regel 4 Ikke stopp prosjektet hvis du ser at det ikke gir positiv effekt. Problemer oppstår som regel på grunn av misnøyen til teamet, hvis medlemmer må forlate komfortsonen og stille inn på en kreativ måte. Husk at de første resultatene vanligvis måles etter å ha fullført 80 % av hele banen.

Regel 5 Si «farvel» til ansatte med dårlige resultater hvis du ser at smidig metodikk ikke er i nærheten av dem.

Regel 6 Ikke sett deg opp for perfekt problemløsning første gang. Omtrent 95 % av effektive verktøy og ideer ble oppnådd etter mange iterasjoner og justeringer etter flere iterasjoner.

1. Andrew Stellman, Jennifer Green "Understanding Agile".

Boken snakker om de fire hovedalternativene der Agile-metodikken presenteres. Beskrivelsen deres er ganske interessant og detaljert. Takket være manualen blir det enkelt og underholdende å mestre kunsten å bruke teknikker.

Boken avslører essensen av de mest populære Agile-metodene: Scrum, XP (ekstrem programmering), Lean (lean programmering) og Kanban (Kanban); forteller hvordan du bruker dem til å lage kvalitetsprogrammer og nå dine mål. Manualen forklarer hvordan Agile-metodikken bidrar til å endre tankegangen til prosjektdeltakere, forene dem og strebe etter forbedringer sammen. Formålet med publikasjonen er å snakke om smidige metoder, verdier og prinsipper, takket være hvilke team som kan endre strategien for å jobbe med prosjekter fullstendig og tilnærme den annerledes. Manualen vil være av interesse for både prosjektledere og ledere, og bare de som er glad i den fleksible Agile utviklingsmetodikken.

2. Boris Volfson "Fleksibel prosjekt- og produktledelse".

Boken kombinerer teori og praksis. Den beskriver ulike aspekter ved konseptet Agile metodikk, produktutvikling, ledelse og analyse. Den teoretiske delen om prosjekt- og produktledelse inneholder informasjon om den nåværende tilstanden til Scrum og Kanban. I det praktiske snakker det om kravstyring, team, risikoer, forretningsmodellering, kravanalyse, tidsestimater, ingeniørpraksis for produktutvikling (hovedsakelig ekstrem programmering), kvalitetskontroll og -sikring, implementering og skalering av Scrum.

3. Jeff Sutherland Scrum. revolusjonerende metode prosjektledelse".

Jeff Sutherland har sin egen metodikk, som han utviklet i et forsøk på å overvinne manglene ved klassisk prosjektledelse. Det er ofte vanskelig for spesialister i ulike virksomheter å få til effektivt, raskt og godt koordinert arbeid. De klarer ikke å fullføre de fleste planene sine på grunn av mangel på tid og ressurser, og avdelinger og team løser eller gjentar ofte oppgaver som har motsatt mening.

Scrum har eksistert i 20 år, og i løpet av denne tiden har ikke bare programvareutviklere, men også bilprodusenter, farmasøyter, FBI og vanlige folk som planlegger sin tid og muligheter brukt teknikken med hell.

Ved å lese denne boken vil du se annerledes på prosjektledelse og forstå hvordan du løser oppgaver som virket uoppnåelige før. Det spiller ingen rolle hva planene dine er: Å åpne en oppstart, endre utdanningssystemet, introdusere ny teknologi eller mer effektiv teamledelse. Takket være Scrum vil du til tider øke produktiviteten din. Manualen er perfekt for prosjektledere, ledere og IT-spesialister.

4. Roman Pikhler Produktledelse i Scrum.

Manualen vil være av interesse for alle som studerer Agile metodikk, spesielt de som eier teknologien. Boken forteller hvilken rolle produkteieren tar, hvordan man best kan administrere den, hva som er hovedmåtene å gjøre dette på. Vi snakker om å visualisere produktet, lage og forbedre backlog, planlegge og spore utgivelser og effektivt bruke Scrum.

5. Kenneth S. Rubin "Fundamentals of Scrum".

Fra boken vil du lære alt om Scrum, vilkårene for denne metodikken og forstå hvordan du kan dra nytte av dens anvendelse. Hvis du er interessert i Agile metodikk, vil guiden fortelle deg hva som skal til for å oppnå gode resultater. Boken er skrevet av en ledende Scrum-treningsspesialist. Forfatteren beskriver nøkkelprinsippene, verdiene og normene for praksis, og berører fleksible tilnærminger, hvis effektivitet har blitt bekreftet av tid.

Informasjon om eksperter

Andrey Kocheshkov, Sjefanalytiker i OAO Publishing House Prosveshchenie. "Enlightenment" - sovjetisk, og senere russisk spesialisert forlag for pedagogisk og pedagogisk litteratur.

Maria Onuchina, direktør for avdelingen for facility management i Becar Asset Management Group, Moskva. Becar-Exploitation LLC (Becar Asset Management Group). Aktivitetsfelt: en systematisk løsning på problemene med å administrere objekter (eiendomsforvaltning), prosjekter (prosjektledelse) og investeringer (meglervirksomhet, evaluering). Antall personell: 5000. Territorium: frontkontorer - i Moskva og St. Petersburg; tre kontorer og 55 egne underavdelinger- i forskjellige byer i Russland.

Sergey Buchik, Administrerende direktør i NPM Group, Novosibirsk. NPM LLC (NPM Group). Virksomhetsfelt: produksjon av utstyr til drikkevareindustrien; utvikling av IT-løsninger for integrasjon med utstyr, mobilapplikasjoner. Antall ansatte: over 300. Markedsandel: 95 % av utstyret for tapping av øl og kullsyreholdig drikke i Russland. Antall patenter for egne produkter: over 80.

Alle kjenner eksemplet på en fabrikkenhet inkludert i klassiske ledelseslærebøker, der hver ansatt hadde rett til å stoppe transportøren for å eliminere en defekt eller komme med et rasjonaliseringsforslag. Det er denne tilnærmingen som dannet grunnlaget for Agile-filosofien.

Agile, som dukket opp som en metode for programvareutvikling i små team for 10-15 år siden, er nå i ferd med å bli den nye kulturen for å lede store selskaper. Takket være en nylig tale av tyske Gref, er begrepet Agile inkludert i leksikonet til alle moderne russiske ledere.

Hva er Agile og hvorfor kalles denne metoden nesten den eneste riktige?

Det er en klassisk tilnærming til å lage produkter og tjenester, som først og fremst er karakteristisk for IT-bransjen. Denne tilnærmingen kalles en foss eller iterativ utviklingsmetodikk. I engelsk terminologi kalles denne tilnærmingen waterfall development (fra engelsk - waterfall). Hvorfor kalles det en foss? For med et slikt utviklingsopplegg, når du har godkjent en programvareproduktplan, vil du ikke kunne stoppe eller endre denne planen før den er opprettet.

Agile er en innovativ tilnærming til å revurdere etableringen av et nytt produkt eller en tjeneste. Den er basert på veldig enkel idé: hver deltaker i prosessen, hver ansatt i denne "transportørforsamlingen" bør være involvert i prosessen med å revurdere sine oppgaver og den felles sak. Alle kan stoppe transportøren og komme med egne rasjonelle forslag.

I de fleste organisasjoner, når de lager programvareprodukter, er de ansvarlige for visse stadier av prosjektet i forskjellige, ofte motstridende, avdelinger. Det er ingen hemmelighet at driftsansatte, testere og utviklere vanligvis er i konflikt med hverandre. Og hvis produktet ikke fungerer og ikke gir fortjeneste til virksomheten, prøver alle å skylde på den andre. Selv om faktisk alle i slike tilfeller som regel har skylden.

Agile-metoden involverer involvering av alle deltakere iessen, og etterlater deltakerne med kjent kompetanse. Denne tilnærmingen gjør det klart at de alle jobber for det samme sluttmålet – et kvalitetsprodukt for kundene sine.

Så det er en endring i forretningskulturen til selve bedriften. Som en del av MBA-programmene er det et helt kurs som omhandler organisasjonsstrukturen i bedriften. Det er et begrep om likevekt i det, når alle gjør alt i oppstartsselskaper og oppstartsbedrifter, og det er ofte grunnen til at et vennlig team blir født der som effektivt opptrer på markedet. Og når det gjelder effektivitet og å bringe nye ideer til markedet, er dette den ideelle organisasjonsstrukturen.

Selvfølgelig er det organisasjoner som ikke trenger Agile i det hele tatt. For eksempel offentlige avdelinger. Deres virksomhet er basert på lovgivning. Vi vil ikke kunne samhandle med staten hvis spillereglene endres hver dag.

Dermed har vi to radikale motsetninger til organisatorisk infrastruktur. På den ene siden er det den strengeste byråkratiske formaliserte organisasjonen, som brukes i visse tilfeller og fungerer godt i visse situasjoner. Og den fullstendige motsatte av det er unge startups, team av likesinnede som virkelig skaper noe nytt, og Agile er mye nærmere tilstanden til et emosjonelt team som jobber for det endelige målet, en brukbar høykvalitets (programvare) produkt. Og derfor er problemene som oppstår på ethvert stadium problemene til alle mennesker, og alle som er i stand til å løse dem er involvert i denne prosessen.

Overgangen fra en stor klassisk virksomhet (Enterprise) til Agile

Dette er et ekstremt viktig spørsmål, og det er veldig interessant. Hele verden snakker om dette, sa tyske Gref det samme. Han sa: "Gutter, vi er en bank, våre konkurrenter er ikke banker, våre konkurrenter er unge selskaper som bringer digitalt til samfunnet."

En avansert virksomhet er basert på tre pilarer: erfaring og kunnskap i bransjen (der virksomheten opererer), utvikling av produkter og tjenester ved bruk av Agile-metodikken, og viktigst av alt, en innovativ kultur.

Ledende IT-selskaper, som enkelt har kopiert bankprodukter og tjenester, begynner å fullføre (eller transformere) dem til et nivå som banken ikke kan bringe dem til, siden den tradisjonelle finansinstitusjon ikke har en tilstrekkelig utviklet innovasjonskultur.

Et veldig enkelt eksempel er mikrofinansorganisasjoner. Dette er firmaer som bokstavelig talt skaper en tjeneste med et knips med fingrene. I dag dukket selskapet opp, utstedte et lån til en utrolig høy rente - i morgen vil det ha en lønnsomhet mange ganger større enn en bank. Slike organisasjoner kan umiddelbart gjenoppbygge sine tjenester og produkter, raskt gå inn i nye markeder og fortrenge klassiske banker.

Lignende ting skjer ikke bare i banknæringen, det skjer i alle bransjer og forretningsområder. Mobiloperatører begynner å forholde seg til betalingssystemer. Uber har endret tilnærming til passasjertrafikk verden rundt på noen år, og Airbnb gjorde det samme med hotellsegmentet i reisebransjen.

Fleksibel planlegging

Med fossefallsutbygging må du planlegge et år frem i tid. Men hvis noe endres - for eksempel kreves det flere servere eller andre komponenter, så er et slikt scenario mulig når prosjektet stoppes - det vil tross alt være nødvendig å gjennomføre et nytt anbud, kjøpe ny infrastruktur osv.

Det vil si at Agile ikke bare blir en metodikk for å lage ny programvare, men et system med fleksibel planlegging for utvikling av hele selskapet. Det bør bygges en slik infrastruktur som også fleksibelt svarer på forespørsler fra kunder og krav som endres under utviklingen av et programvareprodukt og driften av det (dette innebærer forresten en total overgang til skyteknologier).

Smidig planlegging krever forståelse og analyse av hver forretningsprosess. Og dette er neste trinn i utviklingen av selskapet – digitaliseringen.

Les materialet

En dag ankom en toppsjef til Russland til bilmonteringsfabrikken til det berømte Toyota-konsernet.

Reisen hans var lærerik. Han skulle lære ledergruppen det grunnleggende om lean manufacturing, å skape effektivt team og selvfølgelig riktig montering av moderne, kule biler.

Agil metodikk var kjernen i alt. Men det han så på møtet sjokkerte ham ...

Det skjedde på følgende måte. Generaldirektøren lyttet til rapporten fra avdelingslederne, gjorde notater til seg selv.

Når det gjaldt å diskutere planer for fremtidig utvikling og fikse problemer, inviterte direktøren avdelingslederne til å gi uttrykk for sine ideer.

Det ble surr, diskusjoner, krangling. Markedssjefen begynte å krangle med salgssjefen.

Så det gikk 15 minutter. Og så ropte regissøren "Demokratiet er over, nå diktatur igjen!" begynte å gi ordre, som underordnede begynte å flittig skrive ned i dagbøkene sine.

Gjesten fra Japan var i stand til å si bare én setning fra det han så: «Men dette er ikke smidig prosjektledelse.

Tross alt, på vårt anlegg kan enhver arbeider stoppe transportøren under drift og gjøre justeringer i arbeidet.

Jeg snakker ikke om ideer på planleggingsmøter ...". Hvortil generalen svarte: «Ja, dette er ikke smidige prinsipper! Slike fleksible metoder fungerer ikke i Russland!".

Vel, de fungerer ikke...

Mest sannsynlig snurrer spørsmålet også i hodet ditt nå: "Hva slags mystisk frase er dette?".

Så, i denne artikkelen, la oss finne ut hvordan prinsippene for smidig ledelse gjelder for Russland, for små bedrifter og hvordan de vil hjelpe deg med å øke salget.

Programmererne har skylden

Vet du hvordan et programvareprodukt ble utviklet før? Hel. Selvfølgelig, selv nå lager de det, men ikke avanserte selskaper.

Det vil si at det tidligere var en viss struktur, etter å ha passert som det endelige programvareproduktet ble født. Hun så slik ut:

1. Idé;
2. Teknisk oppgave;
3. Design opprettelse;
4. Programmering;
5. testing;
6. Lansering av den endelige versjonen.

Det var imidlertid betydelige hull i disse 6 trinnene. Alle vanskeligheter oppsto på grunn av den stive sekvensen til denne strukturen og umuligheten av å introdusere nye ideer på noen av stadiene.

Som et resultat, når du designer eller programmerer, måtte nye ideer ganske enkelt ignoreres.

Ellers ville det være nødvendig å gjøre om hele den tekniske oppgaven på nytt, noe som forlenget arbeidsvilkårene betydelig eller betydelig økte kostnadene for prosessen.

Og så begynte programmererne å endre tilnærmingen til arbeid: de begynte å gjennomføre minitester for å få tilbakemelding på hvert trinn for å gjøre endringer med en gang, selv i et uferdig produkt.

De begynte også å be om tilbakemelding fra kunden allerede før levering av det endelige produktet til ham.

Eksperimentene viste utmerkede resultater og ble anerkjent som ekstremt vellykkede (kvaliteten på produktene ble mye bedre, kundene var fornøyde, og programmererne begynte å møtes før tidsplanen).

Denne tilnærmingen til arbeid begynte å bli kalt "fleksibel" for det faktum at det på ethvert stadium av arbeidet var mulig å gjøre endringer i opprettelsen av produktet for å oppnå den ideelle løsningen.

For å bringe alle tilnærminger til prosjektledelse (og på den tiden var det allerede mer enn et dusin av dem) til en fellesnevner, kom hele grunnleggerteamet (17 personer) som utviklet og implementerte forskjellige "smidige metoder" sammen.

De fant ut at selv om de ser prosessen med produktutvikling på forskjellige måter, var ideen om at den skulle være fleksibel, synlig for alle.

Det var dette møtet i fjellandsbyen Snowbird i februar 2001 som regnes som fødselen til smidig metodikk (noen kaller det til og med filosofi).

Siden de fleste av disse menneskene var programmerere, var resultatet av møtet utgivelsen av Agile Manifesto og Agile-prinsippene.

Etter hvert som programmerere begynte å få veldig gode resultater ved å bruke denne filosofien og prinsippene, begynte mange organisasjoner å bytte til å bruke disse tilnærmingene.

Kort og saklig

Som enhver filosofi har smidig metodikk sine egne verdier. Ikke alle vil i virkeligheten være enige med dem, men hvis du opprettet et drømmeselskap, vil det definitivt følge denne filosofien:

1. Mennesker og samhandling er viktigere enn prosesser og verktøy;
2. Et fungerende produkt er viktigere enn omfattende dokumentasjon;
3. Samarbeid med kunden er viktigere enn å bli enige om vilkårene i kontrakten;
4. Å være klar for endring er viktigere enn å holde seg til den opprinnelige planen.

Prinsipper nevnt i Agile Manifesto. Bare les den, forstå litt videre.

• Kundetilfredshet gjennom tidlig og uavbrutt levering av verdifull programvare;
• Hyppig levering av fungerende programvare (hver måned eller uke, eller enda oftere);
• Og mange flere liker det.

«Hva i helvete leste jeg nettopp? Jeg forsto ikke et ord!" Jeg tror det er det du tenker akkurat nå.

For å være ærlig, hva som er Agile som metodikk (samt det som står i manifestet) forsto jeg ikke umiddelbart, bøker og artikler ga en overfladisk beskrivelse før jeg så alt dette i praksis.

Derfor vil jeg spare deg enormt mye tid og fortelle deg kort og konkret.

Smidig er navnet på metodikken der stort prosjekt Den er delt inn i flere små deler, som hver får tildelt sin egen ferdigstillelsesdato.

Denne tilnærmingen minner meg mye, bortsett fra én ting. Dekomponeringen tar ikke hensyn til involvering av hele teamet.

Eksempelet er klart

For å gjøre det lettere for deg å forstå alt, ved å bruke eksemplet på et bakeri, vil jeg vise forskjellen.

For å gjøre dette vil jeg først snakke om et anlegg som ikke har en metodikk, og deretter om et anlegg som har implementert denne forvaltningsmetoden. La oss gå videre til et eksempel.

Vanlig bakeri i Russland

Konsernsjefen instruerer teknologen om å utvikle en ny type brød. I beste fall vil teknologen gå til dem for å forske.

Men som regel oppstår slike ideer ikke fra forbrukernes ønske basert på markedsundersøkelser, men fra ønsket til direktøren selv.

Etter forskningen vil teknologen utvikle brødet etter sin smak og bringe det til regissøren.

Han prøver et nytt produkt og bestemmer seg for å belønne teknologen med ordene «Godt gjort. Hold bagelen" eller si "Nei. Ombygg."

Etter godkjenning får bakerne flytskjemaer for å sette produktet i produksjon. Deretter selgere for salg - bakt brød.

Dette er den vanlige tilnærmingen i Russland, ansatte mottar ganske enkelt instruksjoner, og en (noen ganger flere) personer gjør vurderingen.

Smidig bakeri i Russland

Konsernsjefen kommer på ideen om å utvikle en ny type brød. Og det er her mirakler begynner.

Ikke bare en teknolog og markedsføring vil være involvert i etableringen av et produkt, men også selgere, logistikkere, kokker / konditorer og ... til og med ekte kjøpere.

I denne kommandoen vil det ikke være noe hierarki i det hele tatt (unntatt administrerende direktør) og resultatet av arbeidet vil ikke være belønning av en bestemt ansatt, men mottak av en ny type brød, som vil bli kjøpt opp av kjøpere.

I tillegg, under hele prosessen, evaluerer alle ansatte resultatet og gir tilbakemelding for å forbedre det.

IMPLEMENTERE ELLER SEND

Kort oppsummert er det største pluss at denne tilnærmingen hjelper selskapet til raskt å gjenoppbygge og skape et konkurransedyktig produkt som kundene trenger og liker.

Som et resultat vil det ha god effekt på salget, spare mye tid og ta unna feil.

Etter å ha lest første halvdel av artikkelen kan man imidlertid konkludere med at den smidige metodikken kun passer for IT-selskaper.

Men dette er grunnleggende ikke sant. I Russland brukes denne metodikken aktivt av:

• Bank "Alfa-bank";
• Nettverk av pizzeriaer "Dodo Pizza";
• Regnskapstjeneste "Knapp".

Og hvis alt er klart med Alfa-Bank, et stort selskap, har de ressurser og folk til å introdusere innovasjoner i systemet sitt.

Så med "Dodo Pizza" og "Button" er alt mye mer interessant, fordi selskapene er små. Og etter min mening har denne tilnærmingen blitt en av faktorene for deres suksess.

Som et resultat av implementeringen av agile kan du få mange plusser (mer om minusene senere) som vil hjelpe deg å bli markedsleder. Her er noen av disse fordelene:

1. Takket være bruken av "fleksible" tilnærminger øker kvaliteten på de oppnådde resultatene;
2. Resultatene oppnås mye raskere og mer effektivt, og sparer dermed tid og kostnader;
3. Bedriften er bedre tilpasset endringer (selv uforutsette) og konkurranse;
4. Opprettelsen av prosjekter er mer planlagt og kontrollert;
5. Et selskap kan lage produkter som forbrukerne vil vente og kjøpe.

Indre arbeid

Det eneste spørsmålet jeg har lett etter svar på lenge er hvordan fungerer arbeid i en smidig bedrift.

Det er tydelig at hver ansatt jobber for resultatet, og kommer med egne forslag. Men hvordan ser det hele ut fra innsiden? Du kan ikke forstå dette fra bøker.

La oss gå tilbake til favorittbakeriet vårt. Og til deres gamle oppgave - å gi ut en ny type brød. For å utføre oppgaven hadde de følgende sekvens:

1. Inndata. Direktøren forteller hva slags brød han ideelt sett ser, og forteller også beregningen for det, som er økonomisk gunstig for bedriften.
2. Idédiskusjon. Et team bestående av en teknolog, kokker, logistikkere, markedsførere og selgere begynner å diskutere dette prosjektet.

   Kokker, teknologer og logistikkere tilbyr lønnsomme produkter, markedsførere snakker om konkurrenter, og selgere forteller hva kjøpere vanligvis uttrykker sine ønsker.

3. Testing. Alle ideer og kunnskap er oppsummert i en testoppskrift. Denne oppskriften er bakt i et lite prøveparti for å få tilbakemelding på den ved en lukket smaksprøve blant vanlige kjøpere (!!!).
4. Samler tilbakemeldinger. Kundene spiser brød og uttrykker sine ønsker. På bakgrunn av dette gjøres endringer og forbedringer i testoppskriften. Finalen.

Disse stadiene kan fortsettes igjen og igjen til en perfekt type brød er oppnådd, som alle vil være fornøyd med: markedsførere, kokker, logistikkere, teknologer, selgere, kjøpere og, selvfølgelig, anleggsdirektøren selv.

Ja, alt er bra nå

Jeg vil ha meg selv

Etter å ha lest artikkelen har du kanskje et ønske (spesielt hvis du er engasjert i produksjon) om å introdusere fleksible prosjektledelsesmetoder i virksomheten din.

Og du tror at smidig er det du trenger. Tross alt kan du på denne måten skape noe nytt, et virkelig innovativt produkt.

Da vil jeg umiddelbart advare deg og svare på noen spørsmål du har.

Dette er de 5 beste spørsmålene som alle eiere stiller seg når de ser denne metodikken.

Egnet for små bedrifter? Hvis du ikke stadig slipper nye produkter eller ikke hele tiden implementerer nye prosjekter, men jobber med det "gamle", så er det mest sannsynlig NEI.

Er det lett å implementere? Jeg vil svare på spørsmålet med et spørsmål: Er det lett å lære fremmed språk? Filosofi kan ikke raskt introduseres i en bedrift. Det må implementeres steg for steg og over en ganske lang periode.

Forretningsprosesser i selskapet vil endre seg? Ja, fullstendig og drastisk. Avdelinger og personer i dem vil endre seg, planleggingsmøter vil endre deres vanlige karakter, jobbansvar vil bli helt annerledes.

Hvordan vil folk jobbe? Helt annerledes. Har de tidligere bare jobbet med én oppgave, må de nå jobbe og ta del i hele prosessen, opptil flere prosjekter.

Og dette betyr utelukkende teamarbeid og et bredere syn.

Hvem skal være sjefen? Så rart det enn høres ut, smidige selskaper har ikke sjefer.

For det første er dette assisterende kuratorer som organiserer folk i felles team for mer effektivt arbeid.

Svarte ikke på spørsmålet ditt? I dette tilfellet er det kommentarer nedenfor, skriv det der og jeg vil gi deg en anbefaling gratis. Det er viktig for oss at du er 100 % fornøyd.

VI ER ALLEREDE MER ENN 29 000 mennesker.
SLÅ PÅ

Undervanns steiner

Som med alle forretningsforbedringsverktøy, er det fallgruver. Og ved første øyekast er de ikke så merkbare.

De realiseres av selskaper først etter implementering. Derfor, på forhånd, "Vennligst" for å spare deg fra å kaste bort penger og tid.

Agile er ikke et verktøy

Agile er ikke engang en metodikk, selv om jeg ofte kalte det det i teksten. Dette er filosofien som selskapet godtar å leve etter.

Og for implementering av filosofi i livet trengs regler, mønstre og verktøy. De kalles rammer.

Dette inkluderer eller Scrum (administrasjonsverktøy). Selvfølgelig vil vi skrive artikler om hvert verktøy i fremtiden, men du må forstå at smidig er først og fremst filosofien som er tatt i bruk i selskapet.

Team

For de fleste i landet vårt (jeg snakker om den vanlige russiske virksomheten) vil teamarbeid være uvanlig.

De er vant til å motta individuelle instruksjoner og være ansvarlige for implementeringen. Følgelig må KPIen til hver spesifikke spesialist med introduksjonen av agile kanselleres.

Og det er teamet som skal evaluere bidraget fra hver spesifikk spesialist til prosjektet. Og dette er veldig vanskelig hvis du ikke har toppspesialister innen ditt felt.

noen andres nese

Det er ikke mer personlig plass i selskapet. Fra serien - Jeg klatrer ikke til deg og du klatrer ikke til meg. Dette er ikke mer.

Hvis det er teamarbeid, kan brødselgere stille spørsmål om hvorfor han la til dette eller det tilsetningsstoffet til sorten, fordi kjøperne ikke liker det.

Dette er både dårlig (uvanlig) og bra, fordi øynene dine ofte er uskarpe.

innbetaling

Det mest interessante. I agile er det ikke vanlig å betale folk en fast lønn, siden suksessen til selskapet avhenger av graden av deltakelse fra hver enkelt ansatt.

Lønna, hvis noen, er mer fra serien slik at en person ikke dør av sult. Alt annet er resultatet.

Omsetning

Det vil være betydelig. I vårt samfunn er det ikke vanlig å jobbe i team og få betalt for spesifikke resultater (selv om dette har endret seg i det siste).

Derfor må du prøve å finne spesialister som deler filosofien implementert i din bedrift.

Kort om det viktigste

Hvem er smidig prosjektledelse for? For store eller små selskaper? Faktisk for dem og for andre.

Store bedrifter «blir yngre» av dem, blir mer mobile og mindre byråkratiske, samtidig som de gir små bedrifter et kraftig gjennombrudd.

Tross alt slutter du å jobbe på den gamle måten, og de ansatte slutter å tenke (og jobbe) som de fleste av konkurrentene dine.

Agile krever også at ansatte er involvert. Og selv under forutsetning av at alle skal være involvert i arbeidet, med store prosjekter på slutten vil du fortsatt få tidsbesparelser og økt produktkvalitet.

Men jeg gjentar, forutsatt at du hele tiden implementerer nye produkter eller prosjekter.

Det ser ut til at relevansen i ansiktet. Jeg foreslår at du går den andre veien. Ikke skyt fra skulderen.

Begynn å implementere smidige prinsipper som vi gjør, gradvis. Begynn å involvere ulike spesialister i gjennomføringen av ulike prosjekter. Og vi kan si fra egen erfaring at effektiviteten vår har økt merkbart.

Side 2 av 2

Agile prosjektledelsesmetode (Agil)

For prosjekter som inkluderer en betydelig programvarekomponent, kan den tradisjonelle prosjektstyringsmetoden ikke være like effektiv da kravene kan være vage og foranderlige. Alternativt kan du bruke metoden Agile Project Management (APM), som har vunnet popularitet i markedet for ikke så lenge siden. Denne metoden er en ganske iterativ og periodisk prosess, der utviklere og prosjektdeltakere aktivt jobber sammen for å forstå omfanget, samt identifisere behov som skal implementeres og prioritere funksjonalitet.

Fleksible metoder brukes når følgende forhold er til stede:

• meningen med prosjektet er tydelig angitt,
• oppdragsgiver er aktivt involvert gjennom hele prosjektet,
• klient, designer og utviklere er i nærheten
• mulig trinnvis utvikling, basert på funksjoner
• visuell dokumentasjon er akseptabelt (postkort på veggen i motsetning til formell dokumentasjon). Se fig. 3

Smidig utvikling består av mange raske iterative planleggings- og utviklingssykluser, som lar utviklingsteamet kontinuerlig evaluere det utviklende produktet og få umiddelbar tilbakemelding fra brukere og prosjektinteressenter. Teamet studerer og forbedrer produktet så vel som måten det fungerer på i hver vellykket syklus. Etter veletablert planlegging, behovsidentifikasjon og løsningsskisse avsluttes stadiet, mens prosjektet går gjennom iterasjoner med mer detaljerte prosesser med planlegging, behovsanalyse og gjennomføring, i form av bølger. Denne tilnærmingen lar deg gjøre umiddelbare endringer i produktet når nye krav kommer. En smidig metode krever et team med folk som jobber på full kapasitet, hvor også klienten eller brukeren må delta, og utviklerne må jobbe på samme sted, ved siden av klienten.

Agilt prosjektledelse-applikasjonsmiljø

Agil utvikling gjøres i samarbeid med et lite team lokalisert i samme bygg. Kjerneteamet består vanligvis av to utviklere som skriver kode i par (full kvalitetsstyring) av klient/bruker, IT-arkitekt(er), forretningsanalytiker – og prosjektleder. Arbeidet utføres over en serie økter hvor teamet skriver koden, tester deretter arbeidsmodulene til systemet, og deretter gjentas prosessen. Samtidig holdes dokumentasjonsnivået på et minimum, siden teamet i hovedsak kun er avhengig av uformell kommunikasjon innad i teamet.

Igjen er dette forskjellig fra den tradisjonelle tilnærmingen, hvor det brukes betydelig tid på planlegging og omfattende dokumentasjon av behov og krav opprettholdes. Det smidige teamet identifiserer og prioriterer funksjonene som utvikles basert på deres verdi for virksomheten, og når de kritiske systemkomponentene er på plass, jobbes det med de som har høyest prioritet. Denne tilnærmingen er egnet hvis det foreslåtte produktet kan leveres til kunden trinn for trinn. I tilfelle dette ikke er mulig, kan funksjoner og funksjoner fortsatt utvikles og deretter integreres i den originale versjonen av systemet.

Flex-metodekomponenter

Det er flere nøkkelelementer, som er grunnlaget for den fleksible forvaltningsmetoden. Disse teknikkene kan også brukes i den tradisjonelle metoden for å forbedre ytelsen:

1. Visuell kontroll. Denne planleggingsmetoden er basert på kort på veggen for å hjelpe teamet med å organisere arbeidsflyten. For eksempel plasserte et vellykket team kort i forskjellige farger og design på veggen for å representere elementer av det endelige produktet. De elementene som ble planlagt, utviklet, testet og allerede utgitt var av én farge, og de som var planlagt, utviklet, testet, men ennå ikke utgitt (samtidig allerede klar for utgivelse) hadde en annen farge. Teamet var i stand til enkelt å undersøke tingenes tilstand for hvert sett med elementer. Visuell kontroll sikrer samme visjon av prosjektet for hver av deltakerne.
2. Høypresterende lag side om side. En smidig utviklingsmetode innebærer at alle teammedlemmer er lokalisert i nærheten, inkludert klient/bruker, gjerne i samme arbeidsrom. Denne tilnærmingen forbedrer kvaliteten på koordinering og kommunikasjon betydelig. Dette kan imidlertid skape en viss kulturell endring for utviklere, siden prosjektledere er ansvarlige for å sette sammen et team med høy ytelse, må medlemmene kunne samarbeide.
3. Testdrevet utvikling. I tilfeller hvor det er vanskelig for oppdragsgiver å fastslå sine krav og behov, bruker utviklingsteamet ofte en metode basert på produkttester. Det krever mange trinn mellom behovsdefinisjon, planlegging, utvikling og testing. Teamet utvikler nesten alltid testplanen mens de definerer kravene parallelt – hvis et krav ikke kan testes, er det underutviklet. Denne tilnærmingen kan brukes i den tradisjonelle utviklingsmetoden, noe som gjør kravene komplette, presise og testbare.
4. Tilpasningsdyktig ledelse. Alle teammedlemmer tilpasser seg hele tiden forholdene. På grunn av det dynamiske miljøet bør prosjektlederen være en leder, ikke en person som gir ordre. I stedet for å stille strenge krav til gruppen, bør han etablere et teamarbeidsforhold ved å fastsette spilleregler og retningslinjer for samarbeid. Teammedlemmer vil tilpasse seg hverandre gjennom hele prosjektet, samtidig som de bruker kunnskapen som er oppnådd i forrige syklus og derved forbedrer metoder, noe som helt sikkert vil ha en positiv effekt på prosjektet.
5. Felles utvikling. Agile utviklingsmetodikk er basert på samarbeid mellom alle teammedlemmer for å oppnå gode resultater, objektive meninger og implementering av all tilegnet kunnskap i neste utviklingstrinn. Dette er en av fordelene denne metoden- konstante objektive meninger og forbedringer. Prosjektlederen fullfører den innledende planleggingen, og forretningsanalytikeren identifiserer og prioriterer elementene i produktet under utvikling, sammen med oppdragsgiver og spesialister. Deretter samarbeider prosjektteamene for å designe, utvikle, teste og omarbeide versjonen fra hver forrige fase. Et slikt samarbeid med kunden fører til et vellykket prosjekt.
6. Utvikling basert på elementene i produktet som utvikles. Dette utviklingssystemet reduserer prosjektkompleksiteten betydelig og lar team fokusere på hvert element individuelt. For eksempel jobber et team med ansatte med element #4 – og det er alt de bryr seg om. De bryr seg ikke om ting #1-3. Dette er forretningsanalytikerens og prosjektlederens bekymring, som sørger for at neste punkt på listen har høyeste prioritet basert på forretningsverdi og risikonivå. Ofte utvikles høyrisikokomponenter eller sentrale deler av infrastruktur først, og deretter prioriteres alt annet basert på forretningsverdi. Målet er å bygge komponenter basert på funksjonalitet, men ha en enveisavhengighet av hovedsystemet, så spesialiserte komponenter er uavhengige av hverandre og kan bygges i hvilken som helst rekkefølge eller parallelt.
7. Å lede og samarbeide i motsetning til å kommandere og kontrollere. Prinsippet om smidig utvikling er tidsuavhengig og er nært knyttet til ledelse. Det gir flere trinn for å etablere lederskap enn den tradisjonelle metoden for ledelse. Prosjektlederen samarbeider med kunder, spesialister og prosjektdeltakere for å sikre at de er klar over prosjektets status. I tillegg fjerner prosjektlederen alle barrierer mellom teamene i prosjektet.
8. Flytte fokus fra kostnader til fortjeneste. Elementer prioriteres ut fra betydning for virksomheten, f.eks. høy level inntekt og markedsandel. Det er forretningsanalytikerens ansvar å sørge for at prosjektutviklingsteamet ikke kommer for dypt inn i utviklingen av et nytt produkt. Hvis dette skjer, kan prosjektet overstige de planlagte kostnadene og koste mer enn verdien. Mens prosjektlederen bryr seg om kostnadene, fokuserer forretningsanalytikeren på den totale kostnaden for totalt eierskap av produktet, som ikke bare inkluderer kostnadene for selve produktet eller installasjonen av det, men også den påfølgende bruken av systemet etter installasjon.
9. Lære leksjoner. Etter hver syklus må teamet assimilere alle ferdighetene og kunnskapene som er oppnådd for å forbedre prosessen i neste syklus. Mens de lærer, tilpasser medlemmene seg til andre kollegers arbeid og jobber sammen for å forbedre teamytelsen.

Foreslåtte fordeler med smidig prosjektledelse

Den tradisjonelle tilnærmingen til prosjektledelse er lineær, hvor alt gjøres i én syklus. Du planlegger alt i detalj, og så snart alt er klart og utviklet overleverer du hele prosjektet. Denne tankegangen har spredt seg fra programvareutvikling til andre prosjekter også – og dette er forskjellen mellom den tradisjonelle tilnærmingen og den smidige.

Ved smidig prosjektledelse planlegger du bare så mye du trenger. Mens hver del av systemet utvikles, samler teamet inn all erfaringen, samt tilbakemeldinger fra kunder. Siden klienten ser og/eller opplever en fungerende prototype, vil det være lettere for ham å definere eller redefinere kravene og beskrive for utviklingsteamet hva organisasjonen egentlig trenger. Denne metoden innebærer endringer som gir verdi og reduserer kostnader gjennom iterativ utvikling. Endringer i en liten modul er billigere enn endringer i et stort system utviklet.

Er det mulig å bruke metoden fleksibel prosjektledelse?

I kjernen har prosjektledelse, enten tradisjonell eller smidig, et primært fokus på kundetilfredshet. Poenget er å styre teamet, å levere målbare resultater. Mange praktiske ferdigheter kan implementeres i de fleste organisasjonsstrukturer av kommandotype. Noen fagfolk i prosjektledelsesmiljøet kan imidlertid ignorere disse prinsippene for smidig prosjektledelse i tilfelle de ikke kan bruke alle ferdighetene og komponentene - men dette vil ikke være en feil. Hva skjer for eksempel hvis de ikke får brukeren til å være på arbeidsrommet med utviklingsteamet hele tiden? Dette betyr ikke at de ikke kan bruke andre smidige prinsipper som visuell inspeksjon og tilrettelagt utvikling. I tillegg, selv om brukeren kanskje ikke er helt involvert, er mange brukere villige til å delta i teamet, spesielt under testingen og vareprioriteringsprosessen. Resten av tiden kan forretningsanalytikeren representere brukerens interesser, mens teamet er fullt gitt felles arbeid.

Implementering av smidige ledelsesteknikker i prosjekter gir fokus på fordelene med hvert element. I den tradisjonelle tilnærmingen må team fullføre prosjektet i tide og innenfor budsjett, samtidig som de mister oversikten over fordelen for organisasjonen som prosjektet er ment å oppnå. Det er viktig å huske at strategien er å forbedre prosjektet i henhold til økningen i totalkostnaden for produktet og dets videre bruk, og ikke bare kostnaden for prosjektet - i dette tilfellet vil fordelene med prosjektet være tydelige. uttrykt, uavhengig av om teamet lager et produkt eller utvikler et nytt.

Alle som noen gang har drevet med prosjektledelse vet hvor vanskelig det er å organisere et godt koordinert arbeid i et team, og i møte med stadig endrede krav til resultatet av et prosjekt, kan all innsats som gjøres bli forgjeves. Agile prosjektledelsesmetode er ideell for å jobbe med slike prosjekter.

Agile prosjektledelsesmetode er en serie arbeidsstadier definert av harde tidsfrister – sprints, som lar teamet hele tiden evaluere resultatene av arbeidet som er utført og motta tilbakemeldinger fra kunden og andre prosjektdeltakere. Denne tilnærmingen lar deg gjøre umiddelbare endringer i produktet når nye krav kommer.

Historien om Agile

Evolusjonær prosjektledelse og adaptiv programvareutvikling dukket opp på begynnelsen av 1970-tallet. I 1970 presenterte Dr. Winston Royce en artikkel med tittelen "Managing the Development of Large programvaresystemer”, som kritiserte sekvensiell utvikling. Han argumenterte for at programvare ikke bør utvikles som en bil på et samlebånd der hver del legges til i påfølgende faser. I slike påfølgende faser må hver fase av prosjektet fullføres før neste fase kan starte. Dr. Royce anbefalte å bruke en trinnvis tilnærming, der utviklere først samler inn alle kravene til prosjektet, og deretter fullfører hele arkitekturen og designet, og deretter skriver all koden, og så videre.

På 1990-tallet ble en rekke smidige programvareutviklingsmetoder utviklet som svar på de rådende tungvektmetodene. Disse inkluderer: siden 1991 - RAD (rask applikasjonsutvikling); siden 1994 - Dynamic Systems Development Method (DSDM); siden 1995 - Scrum; Siden 1996, Crystal Clear and Extreme Programming (XP); Og siden 1997 - Funksjonsdrevet utvikling (FDD). Selv om de oppsto før publiseringen av Agile Software Development Manifesto, blir de samlet referert til som Agile Software Development.

I februar 2001 møttes sytten programvareutviklere på Snowbird Resort i Utah for å diskutere lette utviklingsteknikker. Sammen publiserte de Agile Manifesto.

Agile manifest

Agile Manifesto består av 4 kjerneideer og 12 prinsipper. Hver Agile-metodikk bruker disse ideene forskjellig, men de er alle avhengige av dem for å administrere prosjekter så effektivt som mulig.

4 smidige ideer

1. Mennesker og samhandling er viktigere enn prosesser og verktøy.
2. Fungerende programvare er viktigere enn dokumentasjon.
3. Samarbeid med kunder er viktigere enn å forhandle vilkårene i kontrakten.
4. Vilje til å gjøre endringer i prioritering fremfor å holde seg til den opprinnelige planen.

12 prinsipper for smidighet

1. Kundetilfredshet gjennom tidlig og kontinuerlig programvarelevering. Kunder er mer fornøyde når de mottar fungerende programvare med jevne mellomrom.
2. Gjør endringer i produktkrav gjennom hele utviklingsprosessen.
3. Hyppig levering av fungerende programvare (hver måned, hver fjortende dag, ukentlig osv.).
4. Samarbeid mellom interessenter (kunde og utviklere) gjennom hele prosjektet.
5. Støtte, tillit og motivasjon fra de involverte. Motiverte team er mer sannsynlig å levere på sine beste jobben enn ansatte som er misfornøyd med arbeidsforholdene.
6. Samhandling ansikt til ansikt. Kommunikasjon er mer vellykket når utviklingsteam er i stand til å kommunisere direkte.
7. Fungerende programvare er hovedmålet på fremgang. Å levere funksjonell programvare til klienten er den ultimate faktoren som måler fremgang.
8. Opprettholde et konstant arbeidstempo. Teamene etablerer en repeterbar og vedvarende driftshastighet der de kan levere fungerende programvare.
9. Oppmerksomhet på tekniske detaljer og design. De rette ferdighetene og god design la teamet opprettholde momentum, kontinuerlig forbedre produktet og jobbe med endring.
10. Enkelhet.
11. Selvorganiserende team oppmuntrer til utmerket arkitektur, krav og design. Kvalifiserte og motiverte teammedlemmer som har myndighet til å ta beslutninger, kommuniserer regelmessig med andre teammedlemmer og utveksler ideer som vil sikre etableringen av et kvalitetsprodukt.
12. Konstant tilpasning til endrede forhold, som vil bidra til å gjøre produktet mer konkurransedyktig i markedet.

Grunnlaget for Agile-metoden

Grunnlaget for den smidige prosjektledelsesmetoden er en rekke nøkkelelementer:

1. Visuell kontroll. Prosjektdeltakere bruker kort i ulike farger og typer under arbeidet med prosjektet, som signaliserer hvilket element av sluttproduktet som allerede er utviklet, planlagt, gjennomført mv. Dermed har teamet en visuell representasjon av dagens tilstand. Visuell kontroll sikrer samme visjon av prosjektet for hver av deltakerne.
2. Alle prosjektdeltakere jobber side om side, inkludert oppdragsgiver. Denne tilnærmingen setter ikke bare fart på mange av prosessene knyttet til å informere deltakerne arbeidsgruppe men skaper også en gunstig atmosfære for samarbeid og effektivt arbeid.
3. Tilpasningsdyktig ledelse. Prosjektlederen er ikke en person som gir instruksjoner, men en leder som bestemmer de grunnleggende reglene for arbeid og samarbeid.
4. Samarbeid. Teamet, prosjektlederen og klienten jobber sammen, noe som eliminerer muligheten for tap av informasjon og misforståelser av mål. Gjennomsiktigheten til alle prosesser lar deg også umiddelbart eliminere nye problemer og finne vellykkede løsninger og forbedringer.
5. Arbeid basert på inndeling av prosjektets totale omfang i dets komponenter. Dette arbeidssystemet reduserer kompleksiteten til prosjektet betydelig og lar teamene fokusere på hver del separat.
6. Arbeid med feil. I løpet av arbeidet med en syklus lærer teamet nye ferdigheter og analyserer feilene som har oppstått, noe som utelukker at de oppstår i neste syklus.
7. Sprint og daglige møter. Sprints – tidsperioder der team fullfører en rekke oppgaver – lar deg tydelig se resultatene av arbeidet. For å dele opp arbeidstiden med prosjektet i spurter får vi for eksempel 10 spurter, hver i to uker. Og daglige møter på ikke mer enn 15 minutter vil hjelpe hvert teammedlem med å svare på tre spørsmål for seg selv: hva gjorde jeg i går, hva skal jeg gjøre i dag, hva hindrer meg i å jobbe?

Dermed er innføringen av en smidig metode mulig under følgende forhold:

• meningen med prosjektet er tydelig angitt,
• oppdragsgiver er aktivt involvert gjennom hele prosjektet,
• mulig trinnvis gjennomføring av prosjektets totale omfang,
• resultatet av arbeidet er viktigere enn dokumentasjonen,
• arbeidsgruppen er ikke mer enn 7-9 personer.

For øyeblikket er Agile-metodikken utbredt i IT-feltet og begynner å mestre forretningsområdet, spesielt markedsføring, ledelse, opplæring osv. Den agile prosjektledelsesmetoden brukes av mange bedrifter og offentlige etater, f.eks. regjeringer i Norge og New Zealand bruker Agile. I Russland mestrer Sberbank Agile for kommersiell sektor.

Prosjektstyringssystemer basert på Agile

Det er mange metoder basert på ideen om Agile, de mest populære av dem er Scrum og Kanban.

SCRUM

Scrum er en prosjektledelsesmetodikk som fokuserer på kvalitetskontroll av arbeidsprosessen. Hirotaka Takeuchi og Ikujiro Nonaka, de første som beskrev Scrum-tilnærmingen, forklarte den som "rugby-tilnærmingen", der scrum kjemper om ballen. Selve metoden er en utviklingsprosess delt inn i små iterasjoner - sprints, på slutten av disse får brukerne en forbedret versjon av programvaren. Sprint er stivt fastsatt i tid, og varigheten er fra 2 til 4 uker. Arbeid innenfor en sprint består av flere stadier:

1. Planlegging av arbeidsomfanget for en sprint.
2. Daglige møter i 15 minutter for å korrigere arbeidet til teamet og oppsummere mellomresultater.
3. Demonstrasjon av resultatene av arbeidet.
4. En sprintretrospektiv som gjennomgår suksessene og fiaskoene til den siste spurten.

Scrum brukes oftest til å administrere kompleks programvare og produktutvikling ved å bruke iterative og inkrementelle metoder.

Scrum øker produktiviteten betraktelig og reduserer tiden til en fordel i forhold til klassiske «fossefall»-prosesser. Scrum-prosesser lar organisasjoner sømløst tilpasse seg raskt skiftende krav og lage et produkt som oppfyller endrede forretningsmål. Scrum lar deg:

• Forbedre kvaliteten på resultatene;
• Bedre å håndtere endring;
• Gi mer nøyaktige estimater, bruk mindre tid på å lage dem;
• Det er bedre å kontrollere prosjektscenarioet og stadier av arbeidet.

Kanban

Kanban er en prosess utviklet for å hjelpe team til å jobbe mer effektivt sammen. Oversatt fra japansk betyr kanban «billboard, signboard», og selve metoden er hentet og tilpasset fra Toyotas produksjonssystem. Essensen av Kanban er å gjøre utviklingsprosessen så transparent som mulig og fordele belastningen jevnt mellom teammedlemmene. Kanban fremmer kontinuerlig samarbeid og oppmuntrer til aktiv, kontinuerlig læring og forbedring.

Kanban er basert på tre prinsipper:

1. Visualisering av oppgaver: synligheten av all informasjon om prosjektet vil bidra til å se mangler, feil og overlegg.
2. WIP (work in progress) kontroll og begrensning: Dette hjelper til med å balansere trådingstilnærmingen slik at teamene ikke starter og gjør for mye arbeid på en gang.
3. Kontroller tiden for å fullføre oppgaven og optimaliser arbeidet for å spare tid.

Fordeler og ulemper med Agile

Enhver metodikk har fordeler og ulemper. Vurder fordelene og ulempene med Agile.

Fordeler

1. Mer fleksibilitet sammenlignet med Waterfall-metodikken.

Den tradisjonelle metodikken til fossen dikterer klart stadiene i arbeidet. Med Agile-metodikken er tidsplan og kostnad hoveddeterminantene, og dette er et område som endres for å møte kravene til kunder og forbrukere av produktet.

2. Færre feil i sluttproduktet.

Dette er et resultat av kvalitetskontroller utført på hvert trinn av arbeidet. Den kontinuerlige prosessen med "utvikle, bygge og teste" reduserer også defekter ettersom iterasjonssyklusene fortsetter.

ulemper

1. Kontinuerlig mottak av tilbakemelding fører til en konstant utsettelse av prosjektets sluttdato.

På grunn av den umiddelbare tilbakemeldingen som Agile gir, er det fare for langt arbeid. Sluttbrukere som ser at disse kravene kan oppfylles "enkelt" (de ser bare resultatet, ikke innsatsen) vil be om tilleggsfunksjoner. Hvis prosjektlederen og utviklerne ikke kan administrere forventningene, vil sluttbrukerne fortsette å be om mer til hele teamet er overveldet av ekstra arbeid.

2. Dokumentasjon

På grunn av den fleksible karakteren til Agile, må dokumentasjonen følge raskt skiftende prosjektforhold. En endring eller funksjonsforespørsel kan diskuteres i detalj og avtales med sluttbrukere, utviklere og testere, men hvis teamet ikke ble informert, ville et kritisk dokument som en brukermanual, arkitekturdokument eller funksjonskravdokument bli foreldet.

3. Hyppige møter

Mens Agile anbefaler at disse møtene holdes daglig for å holde alle oppdatert om hverandres fremgang, tar bærekraften til denne praksisen en toll på fremdriften i iterasjonen. Utviklere er fokusert på det de gjør. Å trekke dem ut til et møte som kan distrahere dem fra å gjøre selve arbeidet er ikke noe de med glede vil akseptere.

Agil implementering

1. Valg av metodikk. Det finnes ulike fleksible metoder som utvikles under visse forhold. Det første trinnet i arbeidet med Agile er å bestemme målene for arbeidsoppgaven, tidsfrister, antall ansatte og mye mer og velge en så fleksibel prosjektledelsesmetodikk som vil møte alle krav.
2. Opplæring. Opplæring er nødvendig slik at ansatte forstår de grunnleggende prinsippene for Agile og vet hvordan de skal jobbe med dem. Det er på dette stadiet at fallgruvene som kan redusere effektiviteten til Agile identifiseres. Er laget klar for endring? Er selskapets prosjekter egnet for smidig praksis? Disse og mange andre spørsmål besvares vanligvis av smidige forretningscoacher. Det skal blant annet også utarbeides en opplæringsliste og en plan, hvor implementering av Agile i bedriften skal gjennomføres.
3. Smidig demo. En slags Agile prøvekjøring, som utføres under tilsyn av en spesialist og viser alle stadier av arbeidet, forklarer funksjonene til roller, samhandling i teamet og mellom team, etc.
4. Opprettelse av et team. I tillegg til valg av ansatte, inkluderer opprettelsen av et team også definisjon av ansvar, fordeling av oppgaver, opprettelse av en møteplan, etc. Hver av metodene er designet for et visst antall personer i teamet.
5. Verktøyvalg nødvendig for fordeling av oppgaver, rapportering, analyser og mer.
6. Første prosjekt med Agile. I det første prosjektet vil det være feil, inkonsekvenser, avvisning av noen verktøy og valg av andre. Enhver teknikk krever en slags tilpasning til egenskapene til selskapet der den implementeres.

Hvis du finner en feil, merk en tekst og klikk Ctrl+Enter.