Agilis fejlesztési módszerek doc. Agilis fejlesztési módszertan. Definíció helyett. Mit is mondhatnánk az Agile-ről, amikor különböző részlegekről különböző emberek gyűltek össze

Ne veszítsd el. Iratkozzon fel, és e-mailben megkapja a cikk linkjét.

Részt vett már valaha projektekben, vagy legalább részt vett projektmunkában? Ha igen, akkor valószínűleg észrevette, hogy egy csapat munkába állítása nehéz lehet. És még ha módosítják is, fennáll annak a veszélye, hogy minden erőfeszítés hiábavaló lesz, mert a kívánt eredmény követelményei gyakran változnak.

Az Agile ("Agile" vagy "Agile") nevű rugalmas projektmenedzsment rendszer használatával azonban jelentősen leegyszerűsítheti a projekt munkáját, és megtanulhatja annak kezelését, ezáltal növelve a csapat hatékonyságát. Általánosságban elmondható, hogy röviden már beszéltünk róla (negyedik leckénkben), de most részletesebben fogunk beszélni erről a témáról.

Agilis módszer: meghatározás és rövid történelem

Bármilyen szokatlanul is hangzik, már a múlt század 70-es éveiben elkezdtek komolyan fejleszteni szoftvereket és projekteket menedzselni. Winston Royce amerikai informatikus 1970-ben írt egy dokumentumot "Nagy szoftverrendszerek fejlesztésének irányítása" címmel. Ebben bírálta a szekvenciális fejlődést, rámutatva erre a fejlődésre szoftver nem hasonlíthat egy összeszerelősor működésére (ahogyan például ez történik autóipari gyártás), ahol egymást követő szakaszokban felváltva adnak hozzá új alkatrészeket.

Ahelyett, hogy megvárta volna az egyes fázis(ok) egymás utáni befejezését, Royce szakaszos megközelítést javasolt. Lényege, hogy kezdetben összegyűjtik a projekthez szükséges összes követelményt, majd elkészül a teljes architektúra, elkészül a terv, megírják a kódot stb.

Ez alapján a 90-es években lehetőség nyílt olyan rugalmas szoftverfejlesztési módszerek készletének megalkotására, amelyek helyettesíthetik a bonyolult és időigényes módszereket. Így történt:

• 1991-ben jelent meg a módszer a RAD alkalmazások gyors fejlesztésére
• 1994-ben megjelent egy módszer a dinamikus DSDM rendszerek fejlesztésére
• 1995-ben jelent meg az agilis fejlesztés Scrum platformja (keretrendszere).
• 1996-ban bevezették a Crystal Clear agilis fejlesztési módszertant, valamint az XP Extreme programozást
• 1997-ben megjelent az FDD szoftverfejlesztés iteratív módszertana

Ezek a technikák együttesen az Agilis Szoftverfejlesztés általános név alatt állnak össze.

Négy évvel később, 2001-ben tizenhét szoftverfejlesztő gyűlt össze a Snowbirdnél, Utah államban (USA). A fejlesztési módszerek tárgyalásának eredményeként megjelent az Agilis Szoftverfejlesztési Kiáltvány (ford. angol koncepció Az „agilis” jelentése „fürge”, „fürge” vagy „gyors”, de a legtöbb esetben „agilis”-nak fordítják. Ő határozta meg az ütemet minden további szoftverfejlesztési munkához.

Agilis kiáltvány

A programozók által készített Kiáltvány a hatékony projektmenedzsment 4 alapötletét és 12 elvét tartalmazza. Bármely Agile alapú projektmenedzsment rendszer (a rendszerekről később még lesz szó) ezekre az elképzelésekre és elvekre támaszkodik, bár különböző változatokban alkalmazzák őket.

1. Az emberek és interakcióik fontosabbak, mint a folyamatok és az eszközök
2. A működő szoftver fontosabb, mint a dokumentáció
3. Az ügyfelek és a velük való együttműködés fontosabb, mint a szerződés és a feltételek megbeszélése
4. A változtatásokra való készenlét fontosabb, mint az eredeti terv

Agilis alapelvek:

1. Az ügyfelek elégedettsége a szoftver idő előtti és következetes szállításával (az ügyfelek örülnek, ha rendszeresen és rendszeres időközönként érkezik hozzájuk a működő szoftver)
2. Változtassa meg a végtermékre vonatkozó követelményeket a teljes fejlesztési ciklus során
3. A működő szoftvert a lehető leggyakrabban szállítsa (hetente egyszer, kéthetente, havonta stb.)
4. Fenntartani az együttműködést a fejlesztők és az ügyfél között a teljes fejlesztési ciklus során
5. Támogatni és motiválni mindenkit, aki részt vesz a projektben (ha sokkal jobban végzi a munkáját, mint egy csapat, amelynek tagjai elégedetlenek a munkakörülményekkel)
6. Közvetlen interakció biztosítása a fejlesztők között (a közvetlen kapcsolat lehetősége hozzájárul a sikeresebb kommunikációhoz)
7. Az előrehaladást csak működő szoftverrel mérheti (az ügyfelek csak működő és működő szoftvereket kaphatnak)
8. Folyamatos munkatempó fenntartása (a csapatnak optimális és tartós munkasebességet kell kialakítania)
9. Ügyeljen a tervezésre és a műszaki részletekre (a hatékony készségeknek és a jó tervezésnek köszönhetően a projektcsapat lehetőséget kap a termék folyamatos fejlesztésére és annak javítására)
10. Próbáld meg a lehető legegyszerűbbé tenni a munkafolyamatot, a szoftvert pedig egyszerűvé és áttekinthetővé tenni
11. Lehetővé teszi a csapattagoknak (ha a fejlesztők maguk hozhatnak döntéseket, megszervezhetik magukat és kommunikálhatnak más csapattagokkal, eszmét cserélve velük, jelentősen megnő a minőségi termék létrehozásának valószínűsége)
12. Folyamatosan alkalmazkodni a változó környezethez (ennek köszönhetően a késztermék versenyképesebb lesz)

Az agilis megértése közben az ötletek és szabályok áttekintése mellett feltétlenül nézze meg ezt a rövid videót, ahol egy szakember projektmenedzsment, Alexey Tachenkov tanácsadó és üzleti coach a rendszer alapjairól beszél.

Ahhoz, hogy a fenti gondolatokat és alapelveket valóban a gyakorlatba ültessük, több szabályt is be kell tartani. Csak így lehet hatékony az agilis projektmenedzsment.

Kulcspontok az agilis alkalmazásban

Az agilis módszertan elsősorban a vizuális ellenőrzésen alapul. Leggyakrabban a projekt résztvevői az eredmény elérése érdekében speciális színkártyákat használnak. Az egyik szín a végtermék valamely elemének tervezésének befejezését jelzi, a másik - fejlesztésének befejezését, a harmadik - a készenlétet stb. A vizuális vezérlés lehetővé teszi a csapat számára, hogy világos képet kapjon a folyamat jelenlegi állapotáról, és biztosítja, hogy minden tagja ugyanazt a jövőképet látja a projektről.

A csapattagok és az ügyfél általában együtt és egymás mellett dolgoznak. Ennek köszönhetően számos olyan munkafolyamat, amely a projektben résztvevők tájékoztatásához kapcsolódik, jelentősen felgyorsul. Emellett a közös munka hozzájárul az egészséges légkör megteremtéséhez a gyümölcsöző és eredményes együttműködéshez és a mielőbbi eredmények eléréséhez.

Ha a projektmenedzser, a csapat és az ügyfél együtt dolgozik, nem áll fenn a célok félreértése és információvesztés veszélye. Minden munkafolyamat a lehető legátláthatóbbá válik, ami azt jelenti, hogy minden felmerülő probléma szinte azonnal megoldható és megtalálható legjobb lehetőségek megoldásaikat.

Különös figyelmet kell fordítani a projektmenedzserre. Nem nevezhető balra és jobbra útbaigazító személynek. A vezető itt inkább a vezető szerepében lép fel, aki irányt szab, meghatározza az együttműködés és a munka szabályait. Más szóval, az agilis kormányzás adaptálható.

Az Agilis módszertan másik fontos pontja a projekt teljes terjedelmének több kisebb részre bontása. Ez a megközelítés nagymértékben leegyszerűsíti a fejlesztési folyamatot, és a csapat egyes csoportjai egy-egy konkrét feladatra összpontosíthatnak.

Egy cikluson keresztül a projekt résztvevői új készségeket sajátítanak el és új ismereteket szereznek, valamint elemzik a folyamat során elkövetett hibákat. Mindez majdnem nullára csökkenti annak valószínűségét, hogy a jövőben (a következő ciklusokban és más projektekben) hasonló hibákat kövessenek el.

És végül, a megközelítés utolsó jelentős eleme a sprintek és a napi találkozók. A sprintek időkorlátos (határidős) időszakok, amelyek során a csapatnak van ideje bizonyos feladatok elvégzésére. A sprinteknek köszönhetően a csapat láthatja tetteik eredményét.

Ha a projektre szánt összes időt felosztjuk több sprintre, akkor ezekből meghatározott számút kapunk; legyen 15. Minden sprint például két hétig tart. Ez alatt a két hét alatt (a sprintre szánt idő) minden nap találkoznak a résztvevők, hogy megvitassák a folyamatot és az előrehaladást.

A napi megbeszélések nem haladhatják meg a 15 percet. Úgy vannak megszervezve, hogy a csapat minden tagja ugyanazt a választ adja három kérdésre:

• mit csináltam tegnap?
• mit fogok csinálni ma?
• Mi akadályoz meg abban, hogy dolgozzak?

Az ezekre a kérdésekre adott válaszok lehetővé teszik a folyamat irányítását, megértheti, hogy az egyes csapattagok melyik szakaszban vannak, és kiküszöbölheti a lehetséges problémákat a cél felé vezető úton. Összefoglalva, az Agilis módszertan megvalósítása több feltétel teljesülése esetén lehetséges:

1. A projekt értelme egyértelműen meg van jelölve
2. Az ügyfél aktívan részt vesz a megvalósítás folyamatában
3. A munka teljes mennyisége lépésről lépésre történik
4. Konkrét eredményre kell összpontosítania
5. Egy munkacsoport létszáma: 7-9 fő

Az Agile támogatásával megvalósuló projektmenedzsment jelenleg leginkább az informatikai szférában elterjedt, azonban az üzleti szféra kezdi elsajátítani. Ezt a rendszert képzésben, marketingben, üzleti életben használják. A rugalmas projektmenedzsmentet számos vállalat és kormányzati szerv alkalmazza.

Példák: Új-Zéland kormánya, Nigéria kormánya, Norvég Nyugdíjalap, Return Path (szoftver), Oreo (kekszcég), Aviasales (a legnagyobb repülőjegy-kereső), Hewlett-Packard (Amerika legnagyobb informatikai vállalata), Sberbank "( Valószínűleg tudod, mi az).

Ezek és sok más szervezet használja a legtöbbet különböző módszerek Agile alapú projektmenedzsment. És ezekről a módszerekről beszélni ugyanolyan fontos, mint maga a módszertan.

Népszerű projektmenedzsment technikák

Számos projektmenedzsment módszert használnak különbözőek modern cégek... De a leghíresebb és legnépszerűbb köztük a Scrum (Scrum) és a Kanban (Kanban).

Scrum módszer

Az Agile Scrum rendszer összes módszere között abban különbözik, hogy a munkafolyamat minőség-ellenőrzésére összpontosít. A japán szakértők, akik először leírták stratégiai menedzsment Hirotaka Takuechi és Ikujiro Nonaka tudomány és technológia professzora „rögbi megközelítésnek” nevezi a módszert, ahol a Scrum „harc a labdáért”.

A módszer abban áll, hogy a projekt fejlesztését sprintekre osztják, amelyek végén a kliens továbbfejlesztett szoftvert kap. A sprintek szigorúan időzítettek, és 2-4 hétig tarthatnak. A munkafolyamat egy sprintben több szakaszból áll:

• A munkakör meghatározva
• Minden nap 15 perces megbeszéléseket tartanak, hogy a csapattagok módosíthassák munkájukat és számba vegyék a közbenső eredményeket
• A kapott eredményeket bemutatjuk
• A sprinteket megvitatják, hogy megtalálják a jó és rossz döntéseket és cselekedeteket

A legtöbb esetben a Scrumot komplex szoftverekkel való munkavégzésre, valamint növekményes és iteratív módszerekkel történő termékfejlesztésre használják. Ennek köszönhetően jelentősen megnő a csapat produktivitása és a ráfordított idő.

A Scrum javítja az eredményeket, segít a projektet a változásokhoz igazítani, pontosabb becsléseket ad kevesebb elemzési ráfordítással, és hatékonyabb ellenőrzést tesz lehetővé a munka szakaszai és a projekt forgatókönyve felett. Mindez a legjobban illeszkedik az üzleti célokhoz.

Kanban módszer

A Kanban egy másik módszer, amely hatékonyabbá és hatékonyabbá teszi a csapatmunkát. Jelentése abban rejlik, hogy a fejlesztési folyamatot a lehető legátláthatóbbá tegyük, és egyenletesen osszuk el a terhelést a projekt résztvevői között. A Kanban másik fontos jellemzője, hogy állandó együttműködésre, fejlődésre és tanulásra motiválja az embereket.

A Kanban munka több elvre épül. Először is, a projekttel kapcsolatos összes információt megjeleníteni kell, ami lehetővé teszi az átfedések, hibák és hiányosságok megtekintését és azok aktív kiküszöbölését. Másodszor, egy feladaton az egész csapatnak egyszerre kell dolgoznia - ez segít egyensúlyban tartani az erőfeszítéseket és az elért eredményeket, kiküszöböli a terhelés egyenetlen eloszlását. Harmadszor pedig az összes feladat elvégzéséhez szükséges időt szigorúan ellenőrzik, ezáltal optimalizálják a folyamatot és időt takarítanak meg.

A Scrummal ellentétben a Kanban sokkal később vált népszerűvé, de ez semmiképpen sem csökkenti érdemeit, és nem teszi kevésbé hatékonyvá. A módszer IT területen és üzleti területen egyaránt hasznos.

Ezek csak példák az alapvető Agile-alapú projektmenedzsment technikákra. De ne hanyagoljon el más módszereket sem, mint például a PRINCE2, a Lean, Hat Szigma, XP, CCPM, ECM, Waterfall és mások. Ezenkívül az Agile-nek van néhány hátránya az előnyei mellett.

Az Agile előnyei és hátrányai

Az Agilis megértésekor fontos, hogy tisztában legyünk ennek a módszertannak a pozitív és negatív oldalaival egyaránt. Kezdjük a profikkal.

Először is érdemes megjegyezni, hogy az agilis menedzsment nagyon rugalmas. Ha például a hagyományos módszertan konkrét munkaszakaszokat jelöl meg, akkor az Agilis könnyen alkalmazkodik a végtermék fogyasztójához és a vevő igényeihez.

Valójában a hibák száma minimálisra csökken a végtermékben, mivel ez egy alapos minőségellenőrzés eredménye, amelyet minden sprint szakasz végén elvégzünk.

Ezenkívül az Agile gyorsan indul, könnyen reagál a változásokra, és lehetővé teszi a fejlesztőcsapat és az ügyfelek számára a folyamatos valós idejű kommunikációt. Az előnyök nyilvánvalóak, de beszéljünk a hátrányokról is.

A módszertan hátránya, hogy egyrészt az állandó Visszacsatolás oda vezethet, hogy a projekt határideje folyamatosan tolódik, ami veszélybe sodorja a munka végtelen folytatását. Ha az ügyfél például csak az eredményeket látja, de fogalma sincs az eléréséhez szükséges erőfeszítésekről, akkor folyamatosan fejlesztéseket fog követelni.

A második hátrány a változó projektkörülményekhez való alkalmazkodás szükségessége projektdokumentáció... Ha a csapatot nem tájékoztatják megfelelően a változásokról vagy további szolgáltatásokról, előfordulhat, hogy a funkcionális követelmények vagy az architektúra dokumentumok nem naprakészek.

Az Agile harmadik jelentős hátránya a gyakori találkozások szükségessége. Ezek természetesen hozzájárulnak a munka hatékonyságának növeléséhez, de ennek ellenére a csapattagok folyamatos elterelése negatívan befolyásolhatja a folyamatot, mert az emberek figyelme szisztematikusan megoldandó feladatokat hagy maga után.

Ebbe beletartoznak olyan dolgok is, mint az ügyfél állandó jelenlétének igénye, a hosszú távú tervek készítésének képtelensége, valamint a motivált és magasan képzett szakemberek iránti igény. Ez utóbbi egyébként nagymértékben vonatkozik az Agilis menedzsment megvalósítására is a szervezet tevékenységében. És az Agile megértéséhez meg kell ismerkednie a megvalósítás témájával is.

Agilis megvalósítás

Az Agilis megvalósításra nagyon sok példa van a cégek munkájában. És gyakorlatilag mindegyik azt mondja, hogy ehhez fontos intézkedések egész sora szükséges.

Először egy konkrét módszert választanak ki, amely a projekt feltételeitől függ. Ezután meghatározásra kerülnek a feladatok és a célok, a sprintek fő határideje és időpontja, a csapat létszáma és a projekten végzett munka egyéb összetevői. Fontos, hogy olyan módszert válasszunk, amely megfelel a maximális számú követelménynek.

Mint mondtuk, az Agile megvalósításához szakembercsapat szükséges. Minden tagnak ismernie kell a módszertan alapgondolatait és elveit, és tudnia kell azokat alkalmazni. Ha a cégnél nincsenek ilyen emberek, akkor az alkalmazottakat ki kell képezni. Az Agile használatára való átállás mellett döntõ cég vezetõségének is világosan tudnia kell, hogy a szervezet készen áll-e a változásra, alkalmazható-e a rendszer a projektjeire stb. Leggyakrabban az Agilis szakértőkhöz kell fordulnia, hogy megválaszolja ezeket a kérdéseket.

A következő szakaszban egy olyan személyt hívnak meg, aki tapasztalattal rendelkezik a rendszerben. Bemutatja, elmagyarázza a sprintek és akciók lényegét, a leendő csapattagok funkcióit, a köztük lévő interakció sajátosságait és egyéb kérdéseket. És csak azután alakul ki új csapat, szerepek, feladatok és felelősségek vannak kiosztva, eszközöket választanak ki az elemzésekhez, jelentésekhez stb.

Az utolsó szakasz az első élmény lesz az Agile-val, i.e. az első projekt, amely ezt használja. Meg kell értened, hogy a hibák, hiányosságok, következetlenségek, elmaradások elkerülhetetlenek. El kell hagynia néhány eszközt, és le kell cserélnie másokkal, talán - hogy megváltoztassa a szerepeket a csapatban. Az első tapasztalat az alkalmazkodás folyamata, az alkalmazkodás pedig kétirányú: a vállalat hozzászokik a módszertanhoz, a módszertan pedig alkalmazkodik a vállalathoz.

Következtetés

Összefoglalva ezt az áttekintést, emlékezzünk arra, hogy az elmélet és a gyakorlat két különböző dolog. Az új módszerek és technológiák, illetve azok megvalósítása egyfajta kihívást jelentenek a csapat számára, a nagyobb hatékonyság elérése pedig mindig egyéni kérdés. Az agilis nem csodaszer és nem garancia a sikerre, de lehetővé teszi a helyes irány meghatározását és útközbeni tereptárgyak megtalálását.

Bármely projekt megvalósításához feltétlenül változtatnia kell valamit, új megoldásokat kell keresnie. Csak a folyamatosan változó munkakörülményekhez és az ügyfelek igényeihez igazodva találhatja meg a megfelelő cselekvési módot. Az agilis projektmenedzsment módszertan Az agilis hűséges asszisztenssé válhat ebben a kérdésben.

Elmagyarázzuk, mi a mögöttes módszertan, feltárjuk az alapfogalmakat, elmagyarázzuk, hogyan működik egy agilis csapat és hogyan értékelik a hatékonyságát.

Az Agile az agilis projektmenedzsment módszertanok egész családja. Érdekes, hogy maga az irányítás fogalma itt nem teljesen helyes. Helyesebb lenne a következő képletet használni: „Az agilis a csapat interakciójának egyik módja, amely lehetővé teszi a termékek közös létrehozását”. A vertikális, hierarchikus kapcsolatok erejéhez azonban túlságosan hozzászoktunk, ezért itt is stabilizálódott a „menedzsment” szó használata.

Kellemetlen kérdések

• Hogyan biztosíthatja, hogy az egyik osztályon bekövetkező késés ne akadályozza meg a többit?
• Hogyan lehet megbirkózni azzal a ténnyel, hogy a projektterv kidolgozása a teljes végrehajtási volumenből nem veszi el az idő 30%-át?
• Hogyan lehet végül követni ezeket a terveket?

Az alacsony szintű vezetőktől a vállalati igazgatókig és kormányzati tisztviselőkig minden szintű vezetők évtizedek óta küzdenek ezzel. Amíg azonban a többé-kevésbé ellenőrzött termékek létrehozásának és projektek fejlesztésének egyetlen ismert módja a szakaszos – lépésről lépésre, egymás után – ezekkel a felhívásokkal nem lehetett mit kezdeni.

Annak érdekében, hogy minőségileg új szintre lépjen tervezési munka, alapvető paradigmaváltásra volt szükség.

Kiderült, hogy ezekre a fájdalmas kérdésekre egyszerűen nem kell választ keresni. Ezeket el kell távolítani, és lehetőség szerint el kell törölni azokat a fogalmakat, amelyekből ezek születtek. Így a szakaszos vízesésfejlesztés helyett agilis módszertanok jelentek meg.

Tedd meg azonnal!

Az Agile hatékonyságának fő mércéje a termék. Míg mások még csak a dokumentációt készítik elő, addig az agilis csapatok szívesen bemutatnak egy működőképes prototípust. Ez – ahogy a híres motiváló képletben is szerepel: „jobb az elkészült, mint tökéletes”. Valósítsa meg az első függvényt, és kezdje el tesztelni a következő létrehozásával, és újra és újra - ez a fő szabály.

Az Agile fejlesztési szakaszát, ezt "időről időre", iterációnak nevezik. Az iterációk a projekt során azonos időtartamúak, átlagosan két hétig tartanak. Egy külön iteráción belül egy konkrét feladatot hajtanak végre, melynek fő tulajdonsága, hogy megoldásának új verzióra kell frissítenie a terméket vagy növelnie kell annak hatékonyságát. Ennek alapján választják ki az ilyen feladatokat.

Hogyan biztosít rugalmasságot az iteratív megközelítés? Annak köszönhetően, hogy az egyes folyamatok párhuzamosan és egymástól függetlenül futhatnak. Igen, be kell vallanom, hogy ez megnövelheti a fejlesztés határidejét az ötlettől a teljesen kész termékig. A helyzet azonban az, hogy egy működő, működő és már képes a versenytársakkal való találkozásra és a felhasználók örömére, egy termék sokkal korábban készül az Agile-ben, és a fejlesztések ciklikussága lehetővé teszi az ilyen funkciók és képességek sokkal jobb kidolgozását, ami a tervezett munka során nem érte volna a kezedbe.soha.

Vízszintes szervezés

Az agilis csapat az önszerveződés és az összes résztvevő viszonylagos egyenlőségének elveire épül. Még az is, akit sokan a projekt vezetőjeként, terméktulajdonosként képviselnek, valójában csak a termékkel szemben támasztott követelmények megszemélyesítése. Tudáshordozóként viselkedik az elvárásokról végeredmény, de semmiképpen sem a szokásos értelemben vett menedzser. Mivel a hierarchia szokását nehéz felszámolni, sok csapatban sajnos a terméktulajdonosnak kell irányítási funkciókat felvállalnia. De az agilis fejlődés eszménye a csapattagok egymás iránti kollektív felelőssége.

Az agilis csapatépítés alapelvei projektenként változnak. Például a Spotify zenei szolgáltatásban ezek a következőképpen épülnek fel:

Az agilis csapatok másik fontos értéke a tudás áthatolása. A csapattagnak nem szabad a saját szűk területére korlátozódnia, törekednie kell a keresztdiszciplinaritásra. Ez nem azt jelenti, hogy a programozónak értékesítőnek, a tervezőnek pedig marketingesnek kell lennie.

De elengedhetetlen az agilis fejlesztés kapcsolódó szakterületeinek alapismerete.

Kezdetben azt feltételezték, hogy ez egyszerűen csak növeli a munka hatékonyságát és a kölcsönös megértés szintjét a csapatban, de mára az idegtudományok fejlődésével világossá vált, hogy ez a megközelítés biztosítja az agy karbantartását is. jó formában és új idegi kapcsolatok dinamikus létrehozásában. Az Agilis tudásnak ezt a keresztbeporzását t-alaknak nevezik. Az alábbi ábra minden szónál jobban megmagyarázza, miért van ez így.

Hogyan valósítsuk meg az Agile-t?

Fájdalmas lehet az átmenet a sok szervezetben még mindig megszokott vízesés-fejlesztésről az agilis projektmenedzsmentre.

Először, fel kell számolni a hierarchiát, és egyben biztosítani kell, hogy a folyamatok minden résztvevője egyenlően osztozzon az eredményért.

Másodszor, Az iteratív fejlesztésre való átállás arra kényszeríti Önt, hogy arra összpontosítson, hogy minden egyes szakasz garantáltan hozzon valami újat a termékbe. Nem könnyű, a tervezett fejlesztés tehetetlensége az első hónapokban kísérteni fogja.

12 alapelvből áll. Természetesen az Agilis szemlélet bizonyos rendelkezései már korábban is megjelentek, de ezeket csak ez a dokumentum rendszerezte és rögzítette kellő mértékben a használatra. Minden évben új cégek, informatikusok és projektmenedzserek írnak alá a kiáltványra. Az agilis fejlesztési rendszer új módszerei, módosításai jelennek meg.

Mi az agilis módszertan?

Az agilis egy iteratív fejlesztési modell, amelyben a szoftvereket a projekt kezdetétől fokozatosan hozzák létre, szemben a vízesés modellekkel, ahol a kód a munkaciklus végén kerül átadásra.

Az Agile lényege, hogy a projekteket kis munkadarabokra, úgynevezett felhasználói történetekre bontja. A feladatok prioritás szerint rövid, kéthetes ciklusokban (iterációk) valósulnak meg.

Az agilis módszertan 12 alapelve 4 fő gondolatra osztható:

• Az emberek és a kommunikáció elsőbbsége az eszközökkel és folyamatokkal szemben;
• A működő termék elsőbbsége a teljes dokumentációval szemben;
• Az ügyfelekkel való együttműködés elsőbbsége a szerződés jóváhagyásával szemben;
• A változtatási hajlandóság előnyben részesítése az eredeti terv betartásával szemben.

Az Agilisban jelenlévő módszerek:

A "Scrum" elnevezés a rögbinek köszönhető, amelyben ez a szó csapatjátékos módszert jelent, amelyben minden ellenfél három vonalat húz, és megpróbálja elkapni a labdát. A sikeres elfogáshoz nemcsak jó fizikai erőnlétre van szükség, hanem minden egyes résztvevő összetartására és a cél világos megértésére is.

A módszert olyan cégek alkalmazzák sikerrel, mint a Microsoft, a Yahoo, a Siemens Healthcare, sőt az Amazon projektvezetője a megszerzett tapasztalatok alapján ismertette is.

Mivel a Scrum egy fejlesztési keretrendszer, minden következő példában jelentősen eltérhet az előzőtől.

Jeff Sutherland, a szerző 8 lépést vázolt fel a technika használatához:

1. Kérlek, válassz terméktulajdonos- ismeri a projekt célját és a várható eredményt.
2. Gyűjt parancs- legfeljebb 10 fő, akik rendelkeznek a működőképes termék létrehozásához szükséges ismeretekkel.
3. megtalálja scrum mesterek- figyelemmel kíséri a projekt előrehaladását, segíti a projektcsapatot a nehézségek megküzdésében.
4. Smink termek elmaradas- Az Agilis táblán minden termékkövetelmény prioritást ad. Ebben fontos szerepet játszik a terméktulajdonos, aki összegyűjti a termékre vonatkozó kívánságokat a lemaradási csapat általi értékelésre.
5. Terv sprintek(iterációk) - egy adott feladatsor végrehajtásának időtartama.
6. Szervez napi tizenöt perces "gumi"- 3 kérdést tegyél fel mindegyik csapatnak: mit csináltál tegnap, mi lesz ma, mi akadályoz meg a feladat elvégzésében.
7. Tedd termék működő alkatrészek véleménye- az érintettek bevonásával az áttekintésbe, megvitatásba.
8. Tölt visszatekintő- a probléma megbeszélése és a megoldás keresése minden sprint után. Hajtsa végre az eredményül kapott változtatási tervet a következő sprintben.

Agilis retrospektív

A Scrumnak 4 kulcseleme van:

• Termek elmaradas- a projekt követelményeinek listája
• Sprint elmaradás- azoknak a követelményeknek a listája, amelyeket a következő sprintben teljesíteni kell
• Sprint cél- sprint cél
• Sprint Burndown Chart- egy diagram, amely a feladatok befejezésekor frissül. Könnyen megérthető a csapat dinamikája és előrehaladásának szintje a projektben.

(XP)

A módszertan kidolgozója, Kent Beck egy extrém programozási módszert készített, melynek célja a szoftvertermékekkel szemben támasztott folyamatosan változó követelmények megbirkózása és a fejlesztés minőségének javítása.

Kizárólag a szoftverfejlesztés területén alkalmazható, és 4 folyamat köré épül:

1. kódolás- a csapatban érvényes egységes tervezési szabványok szerint;
2. tesztelés- a teszteket maguk a programozók írják, mielőtt megírják a tesztelendő kódot;
3. tervezés- mind a végső build, mind az egyes iterációk. Ez utóbbira átlagosan kéthetente kerül sor.
4. meghallgatás- mind a fejlesztő, mind az ügyfél, amely során eltűnnek a kétértelműségek, meghatározzák a követelményeket és az értékeket.

Módszertanok

A projektmenedzsment hazai nyílt terein kevéssé ismert módszertancsaládot Alistair Cockburn, az Agilis Szoftverfejlesztési Kiáltvány egyik szerzője dolgozta ki. Cockburn azt javasolja, hogy a szín szerinti besorolást a csapat létszámának kritériuma szerint végezzék el: 2-től (Crystal Clear) 100-ig (kristályvörös). Nagyobb projekteknél a gesztenyebarna, kék és lila színek kiemelve vannak.

A kristályprojekteknek 3 fő mutatónak kell megfelelniük:

1. működő kód gyors kézbesítése- az Agilis fejlesztés iteratív modelljének ötletének kidolgozása.
2. tökéletesség a reflexión keresztül- az új szoftververziót az előzőről szóló adatok alapján javítják.
3. "Ozmotikus" kölcsönhatás- Az Alistair innovációja, a szoftverfejlesztők közötti kommunikáció és információcsere metaforája egy szobában.

Dinamikus szoftverfejlesztési módszer (DSDM)

A DSDM fejlesztésén nem egy ember, de nem is egy csapat dolgozott, hanem egy 17 angol cégből álló konzorcium. A DSDM-et az extrém programozáshoz hasonlóan elsősorban szoftverfejlesztésre használják.

Különös szerepet kap a végfogyasztó (felhasználó) részvétele a fejlesztési folyamatban. Ezen elv mellett az alapelvek a következők:

• a termék működő verzióinak gyakori kiadásai
• a fejlesztők autonómiája a döntéshozatalban
• tesztelés a teljes munkaciklus alatt.

A DSDM verziókra oszlik, amelyeket a technológiák fejlődésével frissítenek, és új követelmények jelennek meg a szoftverfejlesztéssel szemben. Az utolsó mára a DSDM Atern, amely 2007-ben jelent meg, bár az előző (2003) még mindig szolgálatban van.

Kezdetben a csapat megvizsgálja az alkalmazásfejlesztés valóságát és az alkalmazás hatókörét. Továbbá a munka három, egymással összefüggő ciklusra oszlik:

1. funkcionális modell ciklus- elemző dokumentáció és prototípusok készítése.
2. tervezési és kivitelezési ciklus- a rendszer működőképes állapotba hozása.
3. végrehajtási ciklus- rendszer kiépítése.

Funkcióvezérelt fejlesztés (FDD)

Olyan módszertan, amely még az Agilis Szoftverfejlesztési Kiáltványt is megelőzi.

Bár az FDD iteratív fejlesztési modellt is használ, ez a következőkben különbözik az Agile-től:

• nagyobb hangsúly az előmodellezésen
• megnövekedett (az Agile-hez képest) a jelentések és diagramok összeállításának jelentősége
• vállalati fejlesztésre irányul.

A funkcióvezérelt fejlesztés a következő ciklikus szakaszokból áll:

1. Általános modell készítése- előzetes adatok alapján a projekt jövőképe.
2. Ingatlanlista tervezése- a termékhátralék analógja a Scrum módszerben.
3. Tervezés ingatlanok szerint- a tulajdonságok összetettségének becslése a csapat minden tagja által.
4. Minden ingatlanhoz- műszaki tervezés és kivitelezés - az utolsó szakasz, melynek végén a tulajdonság a termékbe kerül és a ciklus megismétlődik.

Szoftverfejlesztés

A karcsú szoftverfejlesztés valószínűleg nem egy módszertan, hanem a lean gyártási elvek halmaza, amelynek célja a fejlesztési folyamat hatékonyságának növelése és a költségek minimalizálása.

A készlet a következő 7 alapelvet tartalmazza:

1. megszabadulni a veszteségektől- bármi, ami nem növeli a termék értékét a végfelhasználó számára.
2. folyamatos tanulás- a csapat folyamatos fejlesztése növeli a feladatok hatékony elvégzésének képességét.
3. a lehető legkésőbbi döntés meghozatala- nem a spontán, hanem a megszerzett ismeretek alapján kialakított, átgondolt döntések a prioritások.
4. gyors szállítás- lényegében az iteratív modell alapja.
5. csapat erősítése- a "Kiáltvány ..." egyik alapelve kimondja, hogy az emberek és az interakció fontosabbak, mint a folyamatok és az eszközök. A projektcsapat az alapja a feladatok sikeres elvégzésének.
6. integritás és minőség- kezdetben jó minőségű terméket kell készítenie, hogy ne pazarolja az időt és az erőforrásokat a további tesztelésre és a hibák eltávolítására.
7. a teljes kép látása- egy projektet nem lehet külön részekre bontani a fejlesztés alatt álló szoftver jelenlegi fejlesztési állapotának, céljainak, koncepciójának és stratégiájának ismerete nélkül.

Különféle agilis fejlesztési módszerek

Agilis modellezés (AM)

Az Agilis Modellezés a szoftvermodellezés értékeinek, elveinek és gyakorlatainak összessége.

Az AM egy teljes értékű szoftverfejlesztési módszertan részeként használatos – például extrém programozás vagy Rapid Application Development.

Az agilis modellezés alapelvei a következők:

• hatékony interakció a projektben érintettek között
• törekszünk a lehető legegyszerűbb, minden igényt kielégítő megoldás kidolgozására
• állandó visszajelzés
• bátorság a döntések meghozatalára és a felelősségvállalásra
• megértve, hogy nem tud abszolút mindent.

Agilis egységes folyamat (AUP)

Az AUP egy másik szoftverfejlesztési módszertan – a Rational Unified Process (RUP) – egyszerűsített változata. 2012 óta a Disciplined Agile Delivery (DAD) váltotta fel, de az AUP még mindig megtalálható néhány helyen.

A módszertan szerzője, Scott Ambler az Agilis Egységes Folyamat alábbi kulcspozícióit emelte ki:

• Csapata tudja, mit csinál;
• Az egyszerűség az első.
• Az agilis fejlesztési módszertan elveinek való megfelelés.
• Összpontosítson azokra a tevékenységekre, amelyek értékesek a projekt számára.
• Függetlenség az eszközök megválasztásában.
• Az AUP egyedi testreszabása egy adott projekt igényeihez.

Agilis adatmódszer (ADM)

Az ADM iteratív agilis szoftverfejlesztési módszertanok összessége, amelyek a követelmények és a projektdöntések kialakítását hangsúlyozzák az egyes csapatok együttműködésén keresztül. Az AUP-hoz hasonlóan ez sem egy önellátó technika.

Az Agile Data Method lényegét hat pont határozza meg:

1. Adat- bármely alkalmazás létrehozásának alapja.
2. Problémák a projekttel- csak a projekt céljának és koncepciójának világos megértése mellett találhatók meg.
3. Munkacsoportok- a közvetlen fejlesztő csapaton kívül vannak olyan vállalkozási csoportok, amelyek más munkacsoportokat támogatnak.
4. Egyediség- nincs ideális módszertan, minden projekthez különböző módszertanokból származó eszközöket kell kombinálni.
5. Csapatmunka- a csapatmunka sokkal hatékonyabb, mint egyedül.
6. "Édes hely"- a probléma optimális megoldásának keresése ("sweet spot"), kerülve a szélsőségeket.

Essential Unified Process (EssUP)

Ivar Jakobson svéd tudós által kifejlesztett, a Rational Unified Process javítására tervezték.

Az EssUP a gyakorlat fogalmával működik, amely magában foglalja:

• használati eset – a rendszer viselkedésének leírása.
• iteratív fejlesztés - működő kódrészletek létrehozása rövid, többhetes ciklusokban.
• csapatgyakorlatok - a csapat egyesítését és hatékonyságának növelését célozzák.
• olyan eljárási gyakorlatok, mint a „Gondolkodj nagyban, kezdj kicsiben” vagy „Az érdekelt felek bevonása az üzleti folyamatokba”.

Minden gyakorlat megtalálható ilyen vagy olyan formában a RUP, CMMI és Agile fejlesztési módszertanokban.

Realizálás (GR)

Hatékony módszertan startupoknak és kezdő csapatoknak, amely a kis projektek és cégek jellemzőinek maximális kihasználását javasolja: mobilitás, rugalmasság, új megoldások keresése, merev, zavaros hierarchia hiánya stb. Jason Freed és David Hansson, a 37signal (jelenleg Basecamp) alapítói a Getting Realt valódi problémák megoldásának rendszereként határozták meg: a lehető legegyszerűbb, érthető és működőképes.

A GR egy tucatnyi Agilis fejlesztőeszköz előregyártott halmaza, amelyek a következők minimalizálására szolgálnak:

• lehetőségeket
• opciók és beállítások
• szervezeti struktúra
• találkozók
• ígéreteket.

A szokatlan koncepciót nem alkalmazták széles körben, bár egyes elemek eltérő technikákat alkalmaznak.

OpenUP (OUP)

Eszközfüggetlen szoftverfejlesztési módszertan merev szerkezet nélkül, amely a következő gyakorlatokat tartalmazza:

• a csapat sebességének mérése;
• napi megbeszélések és visszatekintések tartása az iterációk befejezése után;
• a mikrolépés fogalma és a korai tesztelés ellenőrző listák segítségével;
• Agilis Modellezési Technika (AMDD).

A gyakorlatok végrehajtása négy alapelv alapján történik:

Agilis mérőszámok

Tekintettel az Agilis eszközeinek, gyakorlatainak, módszereinek és módszereinek sokféleségére, olyan eszközt kell választania, amely segít meghatározni mindegyikük hatékonyságát. A mérőszámok ilyen eszközök.

A legtöbb projekthez 4 mérőterület elegendő:

1. Teljesítmény- ide tartozik a Velocity és a WIP. Az első nem minden projekthez alkalmas, mivel az iterációnként elvégzett feladatok számát mérik, és ezek nem egyenlőek. A Folyamatban lévő munka mérőszáma meghatározza a feladatok határát a különböző szakaszokban: minél magasabb, annál rosszabb;
2. Előrejelzés- kapacitásmérő: a következő sprintben elérhető ideális órák számának meghatározása. Ennek megfelelően megértheti, hogy mennyi időt kell dolgoznia, milyen hatékonyan hajtják végre a feladatokat, és hogyan kell egy sprinthez;
3. Minőség- például a követelmények stabilitásának mutatója, amelyet a = ( Teljes összeg eredeti üzleti követelmények + Az eddigi követelmények száma + Hozzáadott követelmények száma + Eltávolított követelmények száma) / (eredeti követelmények összesen). A mérőszám határozza meg a feladatok átdolgozására fordított időt;
4. Értékek- minden esetben egyedileg kerül kiszámításra, a projekt formátumától függően. Az induló AirBnb például a feltöltött jó minőségű fényképek számát választotta olyan mérőszámként, amely meghatározza egy termék végső értékét a felhasználók számára. Növekedésükkel arányosan nőtt a fogyasztók száma.

A metrikákra ugyanazok a szabályok vonatkoznak, mint a többi Agilis eszközre.

Nincs egyetlen mérőszám, amely megfelelő vagy szükséges a projekthez.

Ezeket folyamatosan felül kell vizsgálni, elavulni kell, és szükség szerint újakat kell hozzáadni. Érthetőnek és az egész csapat számára elérhetőnek kell lennie, nem pedig öncélúnak kell lennie. A metrika a metrika kedvéért rossz döntés.

Mítoszrombolók: Agilis

Az Agile család népszerűsége becsapott rajta egy trükköt, sőt a szakosodott portálokon is vannak mítoszok az Agile egyik vagy másik aspektusáról. Majd kitaláljuk!

1. mítosz: Az agilis minden projektnél működik.

A legkitartóbb téveszme. Egyetlen Agilis módszer sem képes önmagában hozzáadni egy termék értékét vagy motiválni a csapatot.

2. mítosz: Agilis versus dokumentáció.

Az agilis fejlesztés nem a dokumentálás, hanem a dokumentálás mint öncél ellen szól. De amikor a dokumentációt választja kommunikációs eszközként, az Agile valóban az élő kommunikációt részesíti előnyben.

3. mítosz: Az agilis és a tervezés összeegyeztethetetlen.

A napi ütemezés 10 perces stand-upokkal, kéthetente ismétlődő ütemezés, sprinttalálkozók stb. cáfolja ezt a mítoszt.

4. tévhit: Az agilis sok újramunkát igényel.

Az agilis szoftverfejlesztésben az átdolgozásnak két formája van: átdolgozási követelmények (a felhasználók megértik, mire van valójában szükségük) és szoftver (a fejlesztőcsapatok jobb módszereket találnak az alkalmazások megírására és tervezésére). De ezzel más módszerekkel is foglalkozni kell! Sőt, az átdolgozás negatív hatásának csökkentése érdekében szükség van egy iteratív modellre, ami az Agile jellemzője.

Az Agile használatának előnyei és hátrányai

Előnyök:

1. az érintettek bevonása- a csapatnak több lehetősége van megérteni az ügyfél kívánságait. A korai és gyakori szoftverszállítás pedig megerősíti az érdekelt felek bizalmát a projektcsapatban, és még jobban részt vesz a projektben.
2. korai és kiszámítható szállítás- a fejlesztési modell iterációkon keresztül (rövid időközönként 1-6 hétig) rugalmasságot ad, felgyorsítja a termék megjelenését.
3. az üzleti értékre összpontosítva- Az ügyféllel való együttműködés révén a csapat megérti, hogyan lehet a terméket a lehető legértékesebbé tenni a fogyasztó számára.
4. folyamatos minőségfejlesztés- az egyes iterációk során végzett tesztelés, a végső build külön működő kódrészekre osztása lehetővé teszi számunkra, hogy javítsunk és kezeljük a szoftverhibákat a végtermék megjelenése előtt.

Mínuszok:

• megnövekedett követelmények a csapattal és az ügyfelekkel szemben- a projektcsapat és a felhasználók közötti szoros interakció nélkül lehetetlen magas értékű, kiváló minőségű terméket elérni. Az Agile eszközeinek és technikáinak bősége pedig tapasztalt csapatot igényel a megvalósításhoz.
• kiszervezésre nem alkalmasés olyan projektek, ahol a résztvevők csak online lépnek kapcsolatba egymással.
• annak kockázata, hogy soha nem adják ki a szoftver végleges verzióját- ez a mínusz, furcsa módon, az iteratív fejlesztésből és a folyamatos termékfejlesztésből adódik - az Agile előnyei.
• nem működik a projekt üzleti céljainak világos elképzelése nélkül- mivel az Agilis csapat az érintettekre koncentrál, a fejlesztés nem lehetséges célok és termékkoncepció kidolgozása nélkül.

Alkalmazások

Projektek kezeléséhez Nem minden projektmenedzsment szolgáltatás vagy program alkalmas az Agile számára, mert mindegyiknek megvan a maga sajátossága.

Ha a vállalkozásod amarketing és reklám, design, seo ill digitális ügynökségek majd a saas szolgáltatást az egész csapat egészének munkájára alkalmazható. Nekünk ajánlott .

Íme néhány life hack az Agile beállításához

1. testreszabhatja a címkéket és az állapotokat, amelyek a cége munkájához szükségesek.
   Az állapotok a következők lehetnek: folyamatban, ellenőrzés, kész, munkát igényel, kritikus, jellemző, fizetés.
   A címkék gyakran így néznek ki: elrendezés, tesztelés, gyártás, koncepció, kód.
2. hozzon létre egy hátralékos projektetés projekt tavasz.
3. feladatokat készíteniés előzetes ellenőrző listák, vázlatok és egyebek a lemaradásban.
4. a mit-ups meghatározni tavaszi feladatokés áthelyezni őket a lemaradásból a sprintbe.
5. használat ügyfél vendég hozzáférés feladatokhoz, hogy mindig következetes és naprakész észrevételei legyenek a projekttel kapcsolatban.
6. ünnepel feladatokért felelős hogy minden kolléga ismerje a felelősségi területét, és érezze magát a sprint eredményében.

Ítélet

Az agilis szoftverfejlesztéssel a kis projektcsapatok maximalizálják a hatékonyságot. Az Agile más agilis módszerekkel valósítható meg: Scrum, XP, Lean stb.

Lehetetlen egy csapásra, egy tapasztalatlan csapat által, rövid időn belül megvalósítani. de az Agile bevezetése javítja az IT és az üzlet közötti interakciót, felgyorsítja a piacra kerülést, és növeli a termék értékét a végfelhasználó számára.

V modern menedzsment Az agilis menedzsment modellt három különböző kontextusban vizsgáljuk, amelyek (mindegyik a maga módján) meghatározzák, hogy mi is az agilis.

Az agilis jelentés három köre

Az első, szűkebb értelemben ezt a kifejezést a szoftverfejlesztés területén kezdték használni a 2000-es évek eleje óta, amikor az iparági szakértők összegyűltek az amerikai Utah államban, egy hegyi üdülőhelyen, hogy megvitassák a létrehozás módszereit és gyakorlatát. szoftver termékek követelte végfelhasználó... Ennek a találkozónak az eredménye a szoftverfejlesztés Kiáltványa (Agile Manifesto) 12 alapelvvel, amely elsősorban a szerzők tevékenységi körének szűk körét érintette, de esetleg más üzleti projektekre is kiterjeszthető.

A kifejezés második, tágabb értelmében az agilis elveket szinte minden vállalkozás működtetésére alkalmazzák, és komponensként használják, például a „lean Startup” (lean Startup) koncepcióban. Ebben az értelemben az Agilis Modell alatt egy agilis projektfejlesztési módszertan követését értjük, egy tipikus sémát követve több lépésben.

1. A projekten végzett munka iterációkban – rövid ciklusokban (sprint) történik. (Szoftverfejlesztés esetén ezek a ciklusok 1 héttől 1 hónapig terjednek.)
2. Minden ciklus végén megjelenik egy termék, amely már használható az üzleti életben. Szoftvernél egy ilyen termék lehet egy alkalmazás, vagy annak csak egy része, de a gyakorlatban még a "nyers" szoftvereket is ki lehet és érdemes kipróbálni.
3. A terméket az ügyfél vagy a felhasználók értékelik, akik folyamatos visszajelzést adnak a fejlesztőkkel. Ügyfélközpontú megközelítést alkalmaznak a projekt során (minden iteráció).
4. Bármilyen megjegyzést gyorsan beépítenek a felülvizsgálatba, és örömmel fogadjuk azokat a változtatásokat, amelyek lehetővé tették a termék fejlesztésének azonnali korrekcióját, mivel ez lehetővé teszi a globális rendszerhibák felhalmozódását.

Egy harmadik, még tágabb értelemben az Agile a Toyota gyáraiban alkalmazott irányítási modell része, és ma már szinte minden sikeres gyártásban az irányítás egyik alapeleme. Az Agile alapjai ebben az összefüggésben hasonlóak a technológia megértésének alapjaihoz más kontextusokban.

Bármely dolgozó, aki kezdeményezni tudta a szállítószalag leállítását, és a gyártási ciklus finomhangolását célzó módosítások szerzője, gyors visszajelzést adott a Toyota gyáraiban a gyártás végső formátumának beállításához. A termelés egészére kiterjedő Agilis átalakítás újraszerszámozáshoz vezethet termelési tevékenységekáltalában, ha a termék az ügyfél aktuális igényeire adott élénk válasz eredménye. Tehát, ha a gyár műanyag dobozokat gyártott, és a vásárlói visszajelzések azt mutatják, hogy van szükség vödrökre, akkor gyors alkalmazkodás az árnyalatok párhuzamos beállításával (fogantyú alakja, mérete, színe) pont az Agilis menedzsment stílusában lesz (ha a többi alapelvet betartják).

Agilis gazdálkodási alapelvek

Az Agile projektmenedzsmentben, mint üzleti folyamatirányítási modellben csapatok ezrei használják szerte a világon, és a következők mindenhol jelen vannak megkülönböztető tulajdonságok ez a megközelítés:

1. A termék testreszabása szempontjából kulcsfontosságú a fogyasztó és az eredmény létrehozásában való részvételének mértéke.
2. A döntéshez a csapatoknak rendkívül hatékonynak és összetartónak kell lenniük.
3. A szakaszos és ciklikus munka válik a folyamat alapjává. A projekt kis részekre oszlik, amelyek a projekt egészének befejezése előtt meghatározott időpontig fejeződnek be.
4. A teljesítményértékelés középpontjában a köztes projektállapotok gyakori bemutatása áll.
5. Munkájuk során a csapat a Pareto-törvényre támaszkodik, amely szerint az erőfeszítések 20%-a adja a hatékonyság 80%-át, ami lehetővé teszi, hogy ne minden egyes ciklust tökéletesítsenek, mielőtt az eredményt bemutatják a fogyasztónak. A termék minden új iterációval természetesen javul.
6. Feltételezzük, hogy az egyik szakaszt be kell fejezni, mielőtt a következőre lépnénk.

A „rugalmas” megközelítés számos, egymástól eltérő, de az Agile gondolatait is magába foglaló módszertani gyakorlat alapja lett: Scrum, Kanban, Lean, Crystal stb. A Scrum módszertan például szinte mindig együtt jár. Agilis as egy rendszer szoftverfejlesztési projektmenedzsment.

A Scrum bemutatja, hogyan lehet az „agilis megközelítést” konkrét műveletekben a gyakorlatba átültetni. Így például a projektkövetelményekkel való munka négy „műtermék” használatával valósul meg:

• A terméklemaradás magában foglalja egy követelménylista kialakítását, amelyet egyetlen sablon (User Story) alapján készítenek el, és prioritás szerint rendezik. Ha nincsenek követelmények, a projekt véget ér.
• A sprint hátralék a legközelebbi sprint (szakasz) követelményei, feladatokra osztva anélkül, hogy a sprint során új követelményeket lehetne hozzáadni. Egy Agilis vezetési típussal rendelkező csapat következő mérföldkő iránti elkötelezettsége egy táblára van írva (úgynevezett Kanban).
• Sprint cél – Az általános sprintcél iránymutató az alternatív döntések meghozatalakor.
• Sprint Burndown Chart - "égési diagram". Megmutatja, mennyit fejlődött a csapat a szakasz során.

Az agilis projektmenedzsment formátum nem mindenki számára megfelelő, és nem mindig. Azok az állami struktúrák, amelyek tevékenysége változatlan jogszabályokon alapul, céljaik és végrehajtása tekintetében konzervatívak, nem szorulnak ilyen optimalizálásra.

Gyakori agilis megvalósítási hibák és hiányosságok

Ugyanaz a tényező, amelyet bizonyos esetekben a megközelítés erősségének tekintenek, más esetekben problémákhoz vezethet. Tehát a "rugalmasság" gyakran a fókusz elmosódását okozza. Módszertani alap hiányában a referenciapontok elvesztése, az elsődleges helyettesítése a másodlagossal történik. Az ilyen „torzulások” megelőzésére kész módszertanokat vagy saját fejlesztéseket alkalmaznak, amelyek a projekt megvalósítása során szigorúbban szabályozzák a műveletek tartalmát és sorrendjét. Ennek ellenére ebben az esetben is előfordulhatnak hibák az Agilis menedzsmentben.

A gyakori megvalósítási hibák a következők:

A rugalmas megközelítés bevezetése általában véve minden bonyolultság ellenére hatékonyabb, mint a hagyományos „ügyetlen” iparágak, amikor egy új, ügyfélközpontú termék gyors létrehozásáról van szó. Míg a hagyományos gyártás megrekedt a bürokratikus bürokráciában, az Agilis megközelítés lehetővé teszi a természetes mozgást közvetlenül a projekt elindítása után.

2017. október 18

Ha belenézel a valóságba orosz cég 30 év felettiek és több mint ezer alkalmazottal, és kimondják az Agilis szót, akkor a reakció legalább óvatos lesz. Az ottani emberek már hallottak olyan történeteket, mint "Hogyan mondd el a nagymamának" vagy "Hogyan mondd el a nagyapának", és megnézték Gref összes beszédét, egy hét alatt tucatnyi javaslatot kaptak a rugalmasság bevezetésére, néhány alkalmazott egy évig a Scrummal is dolgozott, de egy kérdés marad:

"Mit csinálunk ezzel, csak a programozásból van honlapunk?"

Ennek eredményeként a cégek körülbelül 100%-a számára az Agile trükközésnek tűnik.

De itt van a paradoxon – a világon az Agile-t projektekben használó cégek 77%-a egyáltalán nem foglalkozik szoftverfejlesztéssel.

* A VersionOne nagy éves vállalatok felméréséből

Definíció helyett. Mit is mondhatnánk az Agile-ről, amikor különböző részlegekről különböző emberek gyűltek össze

Az agilis nem szoftverfejlesztési módszer. A Wikipédia definícióit rosszul értelmezik, hacsak nem vagy fejlesztő.
Ezek a projekttevékenységek szervezésének alapelvei, és minden területen alkalmazhatók. A gyakorlatban az emberek számára a legérzékenyebb különbség a hierarchiától való eltérés és a pontosan leírt feladatok generáló központjának eltűnése. azt csapatmunka szerepekkel, a teljes eredményért való felelősséggel és az interakciók lapos szerkezetével.

A csapat a játékban "Mi? Hol? Mikor?" az Agile elvei szerint létezik. Az interakcióknak kulcsszerepe van. A kapitány a termék vásárlójának szerepét tölti be (helyes válasz), 2-3 polihisztor válogat az információtömbök között, valaki követi az időt, van aki elemzi, kérdez, kommunikációra ösztönöz, bárki megszólalhat. ki és eredményre vezet, vagy mindent elbukik, a külső játékok a debriefing (retrospektív).

Az Agile ellensúlya egy csővezetékes (lépcsőzetes) módszer, amely merev hierarchiával és a SMART-hoz lehető legközelebb álló pontos célkitűzésekkel rendelkezik. Ezen elvek szerint a "Mi? Hol? Mikor?" a kapitánynak pontos problémákat kellene kiadnia - ki milyen irányba gondolja, és válaszul próbálja összeszedni. Minden résztvevőnek ügyelnie kell a tisztességre, és meg kell szólalnia, amikor sorra kerül. Sikertelenség esetén valakinek csökkentenie kell a motivációját, vagy ki kell rúgnia, és ezt a döntést a kapitány hozza meg.

Az Agile megjelenésének és fejlődésének fő oka az, hogy minden több projektet nincs 100%-os megértése arról, hogy mi legyen a végén. Egyszerűen lehetetlen pontosan leírni a feladatokat. És úgy döntöttünk, hogy a szabad interakciók fontosabbak, mint az utasítások, és a változtatásokra való készenlét fontosabb, mint a tervek.

Az agilis módszertanok választ adnak a bizonytalanságra; nem teljesen ismert, hogy mit kell tenni, és mi legyen az eredmény. Úgy tűnik, de mi az, ami érthetetlen például egy weboldal fejlesztésében vagy egy házépítésben, vagy egy hamburger főzésében a McDonald's-ban? Ezek a projektek beindulnak, hol a bizonytalanság?

De... Még ha Ön egy webstúdió, és ez az ezredik webhely az Ön számára, ez az első alkalom egy ügyfél számára. És a vágyai a végsőkig bizonytalanok maradnak. Sok stúdió 3-4 verziót készít a főoldalról, és egy héten belül váratlan fejlesztésekre vár. Mindenki, akit ismerek, iterációkra bontott munkája van, amit egy bemutató és megbeszélés követ. Az ügyféllel való kommunikáció fontosabb, mint az aláírt szerződés.

A ház építésénél van egy projektterv, az anyag- és munkaerőköltségek számítása. De valamiért mindig késnek a határidők. Előfordulhat, hogy az alap lebeg, vagy az esztrich kiszárad, valami repedezni kezd, vagy a fa nedves, vagy a tégla túl porózus, vagy rossz márkájú cementet vittek be, vagy az ügyfél meggondolta magát és úgy döntött, hogy most fürdőház lenne. Az elöljáró férfi zenekar, mindent eldönt, ami felmerül, az eredmény érdekében folyamatosan eltér a tervtől. Egy normális otthon sokkal fontosabb, mint a leírás.

Oké, nincs bizonytalanság a McDonald's hamburger elkészítésében. Az eljárást 70 éven keresztül dolgozták ki, és 125 országban reprodukálták. Igen, ez egy futószalag, ahol jobb, ha nem illeszkedik rugalmasan. Az agilis nem alkalmazható az évek során jól bevált folyamatokra. Igaz, egy új étterem nyitása nagyon precíz franchise keretében mindig egyedi projekt. Ahol az iteratív megközelítés, az iterációk csökkentése, a szerepek elosztása, nyílt interakció, a projekt Agilis táblán való megjelenítése, retrospektív, napi tervezési értekezletek megfelelőek.

Összes agilis alapérték (kiáltvány):

• szabad csapat interakció
• projekt teljesítmény (nagyszerű termék)
• partner kommunikáció az ügyféllel
• változtatási hajlandóság

Mik azok a szerepcsapatok?

Egy ismerős csapatban két szerep van: Főnök és Beosztott, egyik okos a másik bolond. Az Agilisban három alapvetően fontos: termék vásárló, metodista, csapattag.

Egyszerűsített formában:
Vevő- elmondja, milyen termékre van szükség, mire van szükség, megbeszéléseket szervez a piaci igények körül, dönt a prioritásokról.
metodista- ügyel arra, hogy az ügyfél ne váljon főnökké. No meg egyéb gyakorlatok megvalósítására is, például azért, hogy minden feladatot osztályozzanak, vagy hogy a feladatsorok ne haladják meg a rendelkezésre álló idő 80%-át, ha van ilyen megállapodás.
Parancs- értékeli, elosztja és végrehajtja a feladatokat. Mindig a termék verzióját mutatja be, nem az egyes darabokat, amelyeket már kiviteleztek.

A teljes leegyszerűsítés érdekében az Agilisban olyan személyre van szükség, aki gondoskodik arról, hogy a csapat a lehető legtöbb információt megkapja a kívánt termékről minden részletben a különböző oldalakról, és elfogadja. Aktív részvétel a végrehajtás módjáról szóló vitában. A feladatot nem direktívaként kaptam felülről, hanem leírást és megértést, hogy mit kell tenni a felhasználóért a termék fejlesztésekor.

Kívülről egy rugalmas csapat éppen az úgynevezett narratív együttműködés meglétében vagy hiányában különbözik az ismerős csapattól. Ha megvitatásra kerül a "Hogyan kell megvalósítani egy terméket?" minden szinten azt jelenti, hogy a csapat rugalmas. Ha azt keresik, hogy ki a hibás, amiért nem fejezték be a konkrét feladatok listáját, akkor minden a megszokott módon zajlik.

A fő kérdés a következő: "Hogyan kezeli az erőforrásokat, amikor minden olyan rugalmas?"

Mindezek a felelős csapatokról és a módszer kialakulásának történetéről szóló történetek teljes szemétnek tűnnek, ha nincs válasz a kérdésekre:
– És hogyan lehet pontosabban kezelni az erőforrásokat? Az Agile-ről csak ezt a kérdést lehet feltárni.

Meg kell jegyezni, hogy általánosságban az egész Agile kifejezetten az erőforrások kérdésének kezelésére készült "Hogyan lehet hatékonyan kezelni az erőforrásokat egy projektben kiszámíthatatlanul" A módszertan nem született volna meg, ha a fő feladat a kényelem és a szabadság emberek a csapatban.

Számos olyan fontos elv és módszer létezik, amelyek egyértelműen kifejezetten az erőforrás-előrejelzésre irányulnak:

1. A szükséges erőforrások láthatósága. Az agilis táblák elválaszthatatlanul kapcsolódnak a módszertanhoz. Ekkor a feladatok oszlopokra vannak osztva, és az oszlopok határozzák meg a bennük lévő feladatok szakaszát. Ez a legvizuálisabb eszköz a projekt állapotának megjelenítéséhez. Ideális esetben minden külső személy számára világosnak kell lennie, hogy a projekt melyik szakaszában van, és mennyi van még hátra a végéig. Ha hirtelen mindenki számára nyilvánvalóvá válik, hogy nincs elég forrás, vagy a prioritásokon változtatni kell, az magától megtörténik.
Az eredmények kiszámíthatóságának és a prioritások kezelésének kérdései a láthatóságon keresztül érhetők el.

2. Prioritások és lemaradás... A tervezésnél figyelembe kell venni, hogy nem lehet minden feladatot lezárni a megadott időn belül. Mindig van egy lista, hogy mit kell tenni, és mit lenne jó megtenni (ez a lemaradás). A prioritásokat a csapat határozza meg a termék belső vásárlójával egyeztetve. Ha úgy adódik, hogy marad idő, a másodlagos fontosságú feladatokat megoldják, ha nincs idejük még a Kötelező (kritikus) jelölésű feladatok elvégzésére sem, akkor a csapat tovább feszül.

3. Rövid iterációk(sprint). Ez a megközelítés lehetővé teszi a vállalatok számára, hogy máshoz hasonlót próbáljanak ki az Agile-ből. A vezetőség beleegyezik egy pár hét alatti köztes eredménybe anélkül, hogy belekötne és mindenkinek feladatot osztana ki. Lehetetlen lenne beleegyezni egy ilyen üzemmódba hat hónapig.
A sprint (iteráció) több hétig tart. Általában 2 hetünk van. A sprintben a legfontosabb annak meghatározása, hogy milyen köztes eredményt kell elérni. Ezt az eredményt célszerű iterációnak nevezni, például "Jogokkal rendelkező táblák kiadása" vagy "Tesztelési hely kiadása". Ha a munka időintervallumon keresztül halad, de minden intervallum nem vezet konkrét eredményre, akkor ez már nem iteratív megközelítés.

4. Feladatok értékelése pólóméretekben. Az emberek nem szeretnek precízen felmérni a problémákat, de a legtöbbnek megfelelő, ha hozzávetőlegesen, nagy, közepes, kicsi skálán értékel. Az alábbiakban bemutatjuk a világ problémáinak nagy pontosságú értékelésének legnépszerűbb módjait. A használati gyakoriság százalékával.

Mi a harmadikat használjuk, de csak 1h, 2h, 4h, 8h osztályok vannak.

A megközelítés lényege, hogy elkerüljük azt, hogy valakit munkájuk pontatlan értékelésein próbáljunk elkapni. Már a kezdetektől példaértékűek. A hangsúly azon van, hogy az egyes sprintek mire törekednek a maximális számú pont megszerzésére, amelyek nagyjából időfüggőek.

5. Leégési diagram(égési ütemterv)
Egy nagyon egyszerű dolog egy kétsoros diagram; az első - mennyi idő égett le, és ez mindig egyenes, a második -, hogy erőforrások tekintetében hány feladat van lezárva, és itt ingadozások lehetségesek. Valójában ez egy grafikus válasz arra a kérdésre, hogy egy csapat a tervek szerint halad, vagy lemarad.

Itt csak általános megközelítések szerepelnek részletek nélkül, érdemes lehet külön anyagot írni az erőforrás-gazdálkodás részleteivel. De ha itt összefoglalja két sorban, akkor a következőket kapja:

• A leggyakoribb hiba az, hogy nagyon pontosan próbálnak belemenni a becslésekbe, a csapat leáll az eredményért
• a legsikeresebb megközelítés az idő lefoglalása, az erőforrások 80%-ának tervezése

Bennfentes Oroszország legnagyobb, legrégebbi és leghíresebb SEO stúdiójából- két alkalommal rakják le a készletet az erőforrásokba, az elsőt a megrendelővel való egyeztetéskor, a másodikat a belső tervezéskor.

Az 5 legnépszerűbb Agilis gyakorlat, amelyet mindenki megért

Az alap Agile ismét egyszerű. Nincsenek olyan rendkívül bonyolult technikák, amelyek megtanulása sok időt vesz igénybe. Alább látható például az 5 legnépszerűbb gyakorlat (a VersionOne ugyanazon felmérése szerint)

Mindegyik alkalmazható bármely terület projektjére, és elég egyszerű az azonnali használathoz. Mindegyiket az iteratív megközelítés közös ötlete egyesíti.

1. Iteratív tervezés- sprintek (a csapatok 90%-a használja)
Jó gyakorlat a kis versenyek köztes eredménnyel való lefutása. A sprint néhány hét. A túl rövid vagy túl hosszú szakaszok rosszak. Ugyanaz az intervallum minden alkalomra szintén nem megfelelő. A sprintnek legyen a legpontosabb célja, ez alapján kerül meghatározásra az időtartam.
A leggyakoribb hiba, hogy a csapatok megszokják, hogy kéthetente egyszerűen ütemezzék a feladatokat, elvesznek a köztes célok kitűzésének és a végén az összegzésnek a folyamatai. A munka a szokásos feladatok közé tartozik, minden sprintben frissítéssel. A módszertanosnak kell megoldania a problémát.

2. Napi tervezési értekezletek(a csapatok 88%-a használja)
A feladat az, hogy a csapat minden nap megerősítse az összes résztvevő egyetlen mozgási irányát. A klasszikus leírás szerint a csapat minden tagja három kérdést fed fel:

• Mi történt eddig a sprintből?
• Mi a terv mára?
• Milyen problémákkal találkozott, vagy mi akadályoz meg?

Gyakorlatunkban ez gyorsan zavarja a csapatokat, és rutinszerű vagy formális jelentésté válik. Mi segít:
Módosítsa a találkozó időpontját - 6 hónap. reggel, 6 hónap. este.
Minden alkalommal, amikor a tervezési értekezlet vezetőjét cserélik, ne legyen olyan személy, akinek beszámolnak. Kiváló lehetőség, ha a vezetőt sorsolással húzzák ki. Termék vásárló, ossza meg vásárlói történetét a tervezési értekezlet elején. Beszélje meg az általános témákat, és csak ezután térjen át a kérdésekre. A csapattagokon kívül senkit ne engedjen el a tervezési értekezletre.

3. Retrospektívák(a csapatok 83%-a használja)
Találkozó az iteráció végén. Beszélgetés arról, hogy mi működött és mi nem. A legfontosabb cél az, hogy következtetéseket vonjunk le a változtatás módjáról.
A termék megrendelőjének - arról, hogyan lehet jobban megmutatni a felhasználók elvárásait, a módszertanosnak - arról, hogyan lehet párbeszédet kiváltani és a választott megközelítési módok megállapodásait teljesíteni, a csapatnak - arról, hogyan lehet figyelembe venni az új, felmerülő tényezőket az értékeléseknél. A retrospektívek általában szórakoztatóak – az iterációnak vége, kilélegezheti és megvitathatja az eredményeket. Jó gyakorlatok valamit inni vagy enni a folyamat szüneteiben.

4. Iteratív benyomások(a csapatok 81%-a használja)
Ez egy demonstráció a csapat részéről a projekt eredményeinek többszöri ismétlésében, általában beszéd formájában. A lényeg az, hogy legyen egy "session", és nem baj, ha úgy néz ki, mint a vezetőség felé történő jelentéstétel. A fő nehézség az, hogy a csapaton kívül valaki más is összejön, és megértse a történések értelmét. Gyakorlatunkban ez csak nagyon menő vezetés mellett gyökerezik.

5. Rövid iterációk(a csapatok 71%-a használja)
A lényeg az, hogy folyamatosan meg kell próbálnia lerövidíteni a kis köztes eredmények megszerzésének ciklusát. Ha nem, a ciklusok természetesen növekedni fognak vagy állandóak lesznek, függetlenül a köztes céloktól. Minél rövidebb a ciklus, annál kevesebb hiba történik az iteratív tervezésben. Ez a módszertanos feladata, félévente legalább egyszer érdemes emlékezni rá.

Hogyan lehet megérteni, hogy egy projekt folyamatban van-e Agilis módszertan használatával vagy még nem?

A diagram, hogy hány vállalat változtatja az Agile-t saját magának, így néz ki:

A megközelítés rugalmassága magára a megközelítésre is kiterjed. Ez az első dolog, amit egy csapatnak meg kell tanulnia, ha rugalmas akar lenni. Nem lehetsz 100%-ban agilis, ha betartod az összes előírást. Senki sem tartja be szigorúan a szabályokat tiszta forma, a gyakorlatban minden cégnek megvannak a maga módosításai.

A legnépszerűbb Agilis módszerek könnyen megvalósíthatók, eredményeket hoznak, és nem forgatják fel a céget. Ez az oka annak, hogy az Agile-t használók 98%-a azt mondja, hogy a megközelítések sikeresek.

Ha például a reggeli tervezési értekezletekkel kezdi, akkor semmi szörnyű nem fog történni a csapatban, de az emberek egyszerű napi párbeszéde a projekten belül rugalmasabbá teszi a folyamatot.

A rugalmasság és a merevség kombinációja mindig egyéni és sok tényezőtől függ: a vezetőtől, a projekt összetettségétől, a csapat méretétől, a költségvetéstől stb. De ha legalább egy megközelítést értelmesen megvalósítanak, akkor ez a cég az Agilis módszertan szerint dolgozik, és nem lesz felesleges erről büszkén beszámolni a csapaton belül.