Mindenki ismeri a klasszikus gazdálkodási tankönyvekben szereplő üzem példáját, ahol minden dolgozónak joga volt leállítani a szállítószalagot egy hiba elhárítása vagy javítási javaslattétel érdekében. Ez a megközelítés képezte az agilis filozófia alapját.

Az Agile, amely 10-15 éve jelent meg kis csapatokban a szoftverfejlesztés módszereként, mára a nagyvállalatok menedzselésének új kultúrájává válik. German Gref legutóbbi előadásának köszönhetően az Agilis kifejezés minden modern orosz menedzser lexikonjában szerepel.

Mi az agilis, és miért nevezik ezt a módszert szinte az egyetlen helyesnek?

A termékek és szolgáltatások létrehozásának klasszikus megközelítése létezik, amely elsősorban az IT-iparra jellemző. Ezt a megközelítést vízesésnek vagy iteratív fejlesztési módszertannak nevezik. Az angol terminológiában ezt a megközelítést vízesés fejlesztésnek nevezik. Miért nevezik vízesésnek? Mert egy ilyen fejlesztési sémával, miután jóváhagyta egy szoftvertermék tervét, nem állíthatja le vagy módosíthatja ezt a tervet, amíg el nem hozza.

Az agilis egy új termék vagy szolgáltatás létrehozásának innovatív újragondolásának megközelítése. Nagyon alapja egyszerű ötlet: a folyamat minden résztvevőjét, ennek az „összeszerelő sornak” minden dolgozóját be kell vonni feladatai és közös ügye újragondolásának folyamatába. Mindenki megállíthatja a szállítószalagot és megteheti racionális javaslatait.

A legtöbb szervezetben a szoftvertermékek létrehozásakor a projekt egyes szakaszaiért felelős személyek nagyon eltérő, gyakran egymásnak ellentmondó részlegekben helyezkednek el. Nem titok, hogy az üzemeltetési személyzet, a tesztelők és a fejlesztők gyakran konfliktusba kerülnek egymással. És ha a termék nem működik, és nem hoz nyereséget a vállalkozásnak, akkor mindenki a másikat hibáztatja. Bár valójában ilyen esetekben általában mindenki hibás.

Az Agilis módszer magában foglalja az összes résztvevő bevonását a szoftverfejlesztési folyamatba, meghagyva a résztvevőknek a megszokott kompetenciákat. Ez a megközelítés lehetővé teszi számunkra, hogy megértsük, hogy mindannyian ugyanazért a végső célért dolgoznak – egy minőségi termékért ügyfeleik számára.

Így változik meg magának a vállalkozásnak az üzleti kultúrája. Az MBA programok keretein belül egy egész szak foglalkozik szervezeti struktúra cégek. Benne van az egyensúly fogalma, amikor a start-up cégeken, startupokon belül mindenki mindent megtesz, sokszor ezért születik ott egy baráti csapat, amely hatékonyan lép fel a piacon. A hatékonyság és az új ötletek piacra vitele szempontjából pedig ez az ideális szervezeti struktúra.

Természetesen vannak olyan szervezetek, amelyeknek egyáltalán nincs szükségük Agile-re. Például a kormányhivatalok. Tevékenységük a jogszabályokon alapul. Nem fogunk tudni kapcsolatba lépni az állammal, ha a játékszabályok naponta változnak.

Így a szervezeti infrastruktúra két radikális ellentéte van. Egyrészt - a legszigorúbb bürokratikus formalizált szervezet, amelyet bizonyos esetekben használnak, és bizonyos helyzetekben jól működik. Ennek pedig a teljesen szöges ellentéte a fiatal startupok, a hasonló gondolkodású emberek csapatai, akik valóban valami újat hoznak létre, az Agile pedig sokkal közelebb áll egy érzelmes csapat állapotához, amely a végső célért, egy működőképes minőségért (szoftverért) dolgozik. termék. Ezért a bármely szakaszban felmerülő problémák minden ember problémái, és mindenki, aki képes ezeket megoldani, részt vesz ebben a folyamatban.

A nagy klasszikus üzletág (Enterprise) átállása az Agile-re

Ez egy rendkívül fontos kérdés és nagyon érdekes. Az egész világ erről beszél, és German Gref is ezt mondta. Azt mondta: "Srácok, mi egy bank vagyunk, a versenytársaink nem bankok, a versenytársaink olyan fiatal cégek, akik a digitális világot hozzák a társadalomhoz."

A fejlett vállalkozás három pilléren nyugszik: az iparágban (amelyben a vállalkozás működik) szerzett tapasztalat és tudás, termékek és szolgáltatások Agilis módszertannal történő fejlesztése, és ami a legfontosabb, az innovatív kultúra.

A vezető IT-cégek a banki termékeket és szolgáltatásokat könnyen lemásolva elkezdik felépíteni (vagy átalakítani) azokat olyan szintre, ahová a bank nem tudja eljuttatni, hiszen a hagyományos pénzintézet nem rendelkezik kellően fejlett innovációs kultúrával.

Nagyon egyszerű példa erre a mikrofinanszírozási szervezetek. Ezek olyan cégek, amelyek szó szerint egy csettintéssel hoznak létre szolgáltatást. Ma megjelent a cég, hihetetlenül magas kamattal adott ki hitelt – holnap a jövedelmezősége többszöröse egy bankénak. Az ilyen szervezetek azonnal újjáépíthetik szolgáltatásaikat és termékeiket, gyorsan beléphetnek új piacokra, kiszorítva a klasszikus bankokat.

Hasonló dolgok történnek nemcsak a bankszektorban, hanem minden iparágban és üzleti területen. A mobilszolgáltatók megkezdik a fizetési rendszerek használatát. Az Uber néhány év alatt megváltoztatta a világ körüli utazásának megközelítését, az Airbnb pedig ugyanezt tette az utazási üzletág vendéglátó szegmensében.

Rugalmas tervezés

A vízesés fejlesztésekor meg kell tervezni a következő évet. De ha valami megváltozik - például több szerverre vagy egyéb összetevőkre van szükség, akkor lehetséges egy forgatókönyv, amikor a projektet leállítják - elvégre új pályázatot kell lefolytatni, új infrastruktúrát kell vásárolni stb.

Vagyis az Agile nemcsak új szoftverek létrehozásának módszertanává válik, hanem a teljes vállalat rugalmas fejlesztéstervezési rendszerévé. Olyan infrastruktúrát kell kiépíteni, amely rugalmasan reagál a vevői igényekre és a szoftvertermék fejlesztése és működése során változó igényekre is (ez egyébként teljes átállást jelent a felhőtechnológiákra).

A rugalmas tervezéshez meg kell értenie és elemeznie kell az egyes üzleti folyamatokat. És ez már van következő szint a cég fejlesztése – digitalizálása.

Olvassa el az anyagot

Agilis fejlesztési módszertan(angol Agile szoftverfejlesztés, agilis módszerek) - a fejlesztési megközelítések sorozata szoftver használatra orientáltinteraktív fejlesztés , a követelmények dinamikus kialakítása és megvalósításának biztosítása az önszerveződő munkacsoportokon belüli folyamatos interakció eredményeként különböző területek szakembereiből áll. Az agilis fejlesztési módszerek osztályához számos technika kapcsolódik, különösen az extrém programozás, DSDM, Scrum, FDD.

A legtöbb agilis módszertan célja a kockázat minimalizálása a fejlesztés átalakításávalaz iterációnak nevezett rövid hurkok sorozatához amelyek általában két-három hétig tartanak. Minden iteráció úgy néz ki, mint egy miniatűr szoftverprojekt, és magában foglalja az összes olyan feladatot, amely a funkcionalitás mini-növekményének generálásához szükséges: tervezés, követelményelemzés, tervezés, programozás, tesztelés és dokumentáció. Bár egyetlen iteráció általában nem elegendő egy termék új verziójának kiadásához, nyilvánvaló, hogy egy agilis szoftverprojekt minden iteráció végén készen áll a kiadásra. Minden iteráció végén a csapat újraértékeli a fejlesztési prioritásokat.

Agilis technikák

Az agilis módszerek olyan agilis módszerek, mint a Lean Development, Scrum stb. Ezeket a 2000-es évek elején fejlesztették ki a nem hatékony hagyományos informatikai módszerek alternatívájaként.

Szinte minden agilis csapat egy irodában (bullpen) összpontosul. Az iroda magában foglalja a termék tulajdonosát - a vásárlót, aki meghatározza a termék követelményeit. Az ügyfél lehet üzleti elemző, projektmenedzser vagy ügyfél. Ezen kívül az irodában helyet kaphatnak felülettervezők, tesztelők, műszaki írók. Vagyis az Agilis módszerek elsősorban a közvetlen kommunikációra irányulnak.

Az agilis módszerek fő mérőszáma a munkatermék.Előnyben részesítve közvetlen kommunikáció Az agilis módszerek más módszerekhez képest csökkentik az írásos dokumentáció mennyiségét

Főbb ötletek:

— emberek és interakciófontosabb, mint a folyamatok és az eszközök;

— működő termékfontosabb, mint az átfogó dokumentáció;

— együttműködés az ügyféllelfontosabb, mint a szerződés feltételeiben való megegyezés;

— változtatási hajlandóságfontosabb, mint az eredeti terv követése.

Agilis alapelvek:

1. Ügyfél-elégedettség értékes szoftverek korai és megszakítás nélküli ellátása révén;

2. már a fejlesztés végén is üdvözölje a követelmények változását (ez növelheti a keletkező termék versenyképességét);

3. Működő szoftverek gyakori szállítása (havonta vagy hetente vagy még gyakrabban);

4. a megrendelő szoros, napi kommunikációja a fejlesztőkkel a projekt során;

5. a projektet motivált személyek hajtják végre, akik számára biztosítottak a szükséges munkakörülmények, támogatás és bizalom;

7. a futó szoftver a fejlődés legjobb mércéje;

8. a szponzorok, a fejlesztők és a felhasználók a végtelenségig állandó tempót tarthassanak;

9. Állandó figyelem a műszaki kiválóság és a felhasználóbarát tervezés javítására;

10. egyszerűség – a felesleges munka elkerülésének művészete;

11.a legjobb technikai követelmények, a tervezést és az építészetet egy önszerveződő csapattól szerzik be;

12. állandó alkalmazkodás a változó körülményekhez.

Az Agile fő előnyei:

• Webes termékek minősége

Az ügyfél bevonása az egyes iterációk folyamatába lehetővé teszi a folyamat beállítását, ami változatlanul javítja a minőséget.

• Magas fejlesztési sebesség

Az iteráció legfeljebb 3 hétig tart, ennek az időszaknak a végére szükségszerűen megvan az eredmény.

• A kockázatok minimalizálása

Egy nagy projekt lehetővé teszi az ügyfél számára, hogy több iterációt fizessen, és a munka során megértse, hogy pontosan azt kapja meg, amit akar, időben és megfizethető áron. A vízesés-modellek (specifikáció és feladatmeghatározás használatával) nem biztosítanak ilyen lehetőséget.

A megrendelőnek mindig lehetősége van megfigyelni a fejlesztés előrehaladását, módosítani a projekt funkcionalitását, tesztelni vagy elindítani, sőt bármikor leállíthatja.

Az Agilis megértése

Az Agile egy agilis fejlesztési megközelítés, amely különböző módszertanokat (Scrum, Kanban, XP, Lean és mások) foglal magában. Sokan tudnak róla. De van tucatnyi apróság és mindenféle érdekesség, ami nem a felszínen fekszik.

Cikksorozattal készültünk mind a kezdőknek, akik még mindig agilis módszertanokkal a „te”-n vannak, és azoknak, akik már régóta barátok. Beszéljünk az alapfogalmakról (dióhéjban), és az Agile és Scrum váratlan alkalmazásáról a mindennapi életben. A mai cikk olyan, mint egy bevezető előadás arról, hogy mi is az agilis és mivel eszik.

Projektek nagy robbanása

Ha párhuzamot vonunk az Univerzum keletkezésével - ezt a szerepet az Agilisra jelöljük -, akkor a több mint száz projektmenedzsert idegösszeomlásba hozó első számú probléma lesz az Ősrobbanás - a termékkövetelmények változása. . Pontosan ez az oka a nyögő, hisztérikus felkiáltásoknak: "Miért kell nekem ez a büntetés?" és elvékonyodott haj.

A folyamatok általában belül működnek kaszkád modell(vagy vízesés modell) - minden szakaszosan és egymás után történik. Egyszerűen fogalmazva: "Látom a célt - megyek a cél felé." És ha egy ponton megváltoznak a termék követelményei, a végső cél, akkor néha újra kell csinálni. Amint egy tökéletesen csiszolt terv ütközik a valósággal, azonnal porrá omlik. Ám ahelyett, hogy a tervet és a hozzáállásukat is a kukába dobnák, a menedzserek úgy tesznek, mintha a terv működik, és ehhez még szakembereket is felvesznek. Alapvetően azért fizetnek az embereknek, hogy hazudjanak nekik.

Jeff Sutherland, a Scrum megalkotója szerint ez az SZKP Központi Bizottsága Politikai Hivatalának 1980-as évek végi magatartására emlékeztet, amely állítólag hitt a Szovjetunió összeomlásának előestéjén kapott jelentéseknek.

Az agilis módszereket arra tervezték, hogy ezt a rugalmasságuk rovására leküzdjék. Elmondhatjuk, hogy az Agile több megközelítés összetett kavargója, amelyet arra terveztek, hogy egy sor alapelv alapján minimalizáljon mindenféle kockázatot. Pontosan ezeket az elveket és 4 fő gondolatot gyűjtöttük össze a 2001-ben kelt Agilis Kiáltványban.

Agilis kiáltvány

Ha leegyszerűsítjük a megfogalmazást, hogy "kristályosítsuk" azokat a szempontokat, amelyek mindenkit irányítanak, aki az agilison dolgozik, akkor valami ilyesmit kapunk:

• Az emberek a legfontosabbak, nem a dolgok
• A dokumentáció (amit még senki más nem olvas) nem zavarhatja senki munkáját
• Együttműködjön, ne olvassa el újra a szerződést
• Élj, lélegezz, változz – amilyen gyorsan csak lehet

Hogyan működnek a folyamatok

Lássuk, hogyan tudsz agilisan dolgozni. Vegyük például a Scrumot – ez ma a legnépszerűbb agilis technika. Jeff Sutherland, a Scrum szerzője találta ki ezt a technikát a klasszikus projektmenedzsment hiányosságainak kezelésére.

1. Válassza ki a termék tulajdonosát- ez az a személy, aki látja, milyen célt fog elérni, és mit akar a végén elérni.

2. Dönts a csapat mellett- 3-10 ember, akik olyan képességekkel rendelkeznek, amelyek lehetővé teszik az eredmény (azaz működőképes termék) elérését.

3. Válassz egy Scrum Mastert- Ez a személy követi a projekt előrehaladását, és segít a csapatnak megbirkózni a nehézségekkel.

4. Hozzon létre egy termékhátralékot- Gyűjtsd össze egy helyen (lehetőleg egy Agilis táblán) a termék összes követelményét, és állítsd be a prioritásokat. A termék tulajdonosának át kell gondolnia és össze kell gyűjtenie az összes kívánságot. A csapatnak ezután értékelnie kell a lemaradást, hogy megtudja, hogy mindez megoldható-e, és mennyi ideig tart.

Így néz ki egy agilis tábla a Yandexben, -.

5. Tervezze meg a sprinteket- az az időtartam (egy-két hét), amely alatt a csapat egy meghatározott feladatsort végez. A sprintek rendszeresek lesznek: például 15 alkalommal két hétig, amíg készterméket nem kapunk.

6. Legyen napi 15 perces találkozó (és egy perccel se tovább)- három kérdés szerepel a napirenden, amelyekre mindegyik röviden válaszol: mit csináltam tegnap, mit fogok csinálni ma és milyen akadályok akadályoznak abban, hogy „magasságot vegyünk”.

7. Csinálj véleményeket- a sprint eredményei alapján a csapat elmondja, hogy mit sikerült, és bemutatja a termék működőképes részeit. Bárki jöhet véleményezésre: a termék tulajdonosa, a fő vásárló, vagy akár a potenciális vásárlók is.

8. Végezzen visszatekintést- minden sprint után az Agilis csapat megbeszéli a problémákat és megoldásokat keres. Legyen egy változtatási terv, amit a csapat azonnal végrehajt – a következő sprintben.

A Scrum bevezetésével és a csapat teljesítményének javításával kapcsolatos további információkért olvassa el ezt a cikket.

A Scrum több, mint egy csapatmunka módszer. A Scrum felgyorsítja minden emberi törekvés ütemét. Nem számít, mi a projekt vagy a probléma, a Scrum minden olyan törekvésben használható, amely növeli a termelékenységet és jobb eredményeket ér el.

Ismerje meg az Agilt látásból

Az agilis gyakorlatokat könnyű azonosítani olyan kulcsjellemzők alapján, mint a „jelzőfények”.

1. A kockázat minimalizálása minden agilis megközelítés fő célja.
2. Iteratív fejlesztés – rövid ciklusokban történő munkavégzés.
3. Az emberek és a kommunikáció a legfontosabb.

Figyelembe véve az Agile-t a folyó mindkét partjáról – az ügyféltől és a csapattól – ez a megközelítés mindenki számára logikus.

• A vásárlónak legalább egy minimálisan hatékony terméket kell időben megkapnia (nem számít, hogy szoftverről vagy más folyamatokról, jelenségekről beszélünk), változtatni kell a feltételeken, miközben nem marad fánklyuk a zsebében - ez már kockázatbiztosítás kérdése.

• A csapat számára előnyös a vevővel és a kollégákkal való kommunikáció (hogy e nélkül: "Félreértettél - gyorsan csinálj újra mindent. És igen, tegnap kellett!"), A folyamatok átláthatósága, ami csökkenti a meglepetések esélyét, a problémák gyors megoldása. Nos, sokan értik, hová megy az idő, és hol akad el a munka. Apróság (igazából nem), de szép.

Ráadásul javul a csapaton belüli kommunikáció. Mindenki egy közös gondolatra koncentrál, nincsenek titkok egymás előtt, mindenki vállal egy ígéretet (társadalmi kötelezettségeket - hol nélküle). A cseresznye a tortán alkalom arra, hogy kényelmes tempóban, bár gyorsan (legalábbis a szokásosnál gyorsabban) dolgozz.

Az agilis káoszból rendbe vezet. Tanulmányok készültek: kiderült, hogy azok a projektek, ahol agilis megközelítés keretében zajlottak a munka, 3-szor sikeresebbek voltak, mint azok, ahol a folyamatok a standard paradigmában épültek fel. És ez egészen logikusnak tűnik: az ügyfél azt kapja, amit akar, minimális idő- és erőforrás-befektetéssel.

Kinek nem tetszhet?

Megalakulása óta a Scrum koncepciója képezte az alapját a technológiai iparágak számára készült új szoftvertermékek tervezésének. A Szilícium-völgyben a szoftver- és új hardver projektmenedzserek körében elismert és sikereket szerzett Scrum azonban továbbra is kevéssé ismert módszertan az általános üzleti gyakorlatban.

Ez minden mára. Legközelebb a Scrum Scrumról fogunk beszélni, és arról, hogyan működnek az agilis módszertanok az orosz valóságban. Ne válts.

P.S.Minden héten szeretne kapni hasznos tippeket a legérdekesebb üzletről és marketingről szóló könyvek, új termékek megismerése és kedvezmények? Iratkozzon fel hírlevelünkre. Az első levél ajándékot tartalmaz.

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 2000-es évek eleje óta kezdték használni a szoftverfejlesztés területén, amikor az iparági szakértők az Egyesült Államok Utah államában, egy hegyi üdülőhelyen gyűltek össze, hogy megvitassák a szoftvertermékek létrehozásának módszereit és gyakorlatát. a végfelhasználó követeli meg. 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ásra 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. Az üzem 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 egy gyárban műanyag dobozokat gyártanak, és a vásárlói visszajelzések szerint a vödrök szükségesek, akkor a gyors adaptáció az árnyalatok párhuzamos beállításával (nyél alakja, mérete, színe) az Agilis menedzsment stílusában történik (ha a többi elv is megfelel). követte).

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 ennek a megközelítésnek a következő jellegzetességei mindenhol megtalálhatók:

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 projekt köztes állapotainak 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 iteráció során természetesen fejlődik.
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. az Agile szoftverfejlesztés egységes projektmenedzsment rendszerével.

A Scrum bemutatja, hogy az „agilis megközelítés” hogyan alkalmazható a gyakorlatban konkrét műveletekre. Így például a projektkövetelményekkel való munka négy „műtermék” használatával valósul meg:

• A termékhátralék egy követelménylista kialakítását feltételezi, 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. A következő mérföldkő iránti elkötelezettség, amelyet az Agilis menedzsment típusú csapat vállal, fel van írva a táblára (ún. 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. Állami struktúrák amelyek tevékenysége változatlan jogszabályokon alapul, céljait és végrehajtását tekintve konzervatív, nincs szükség ilyen optimalizálásra.

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

Ugyanaz a tényező, amelyet bizonyos esetekben figyelembe vesznek erősség megközelítés, másoknál problémákhoz vezethet. Tehát a "rugalmasság" gyakran a fókusz elmosódását okozza. Módszertani alap hiányában irányvesztés következik be, az elsődleges helyettesítése a másodlagossal. 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, az Agilis menedzsmentben, előfordulhatnak hibák.

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

A rugalmas megközelítés bevezetésének általános nehézségei ellenére hatékonyabb, mint a hagyományos „ügyetlen” iparágak, amikor egy új, vevőorientált 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.

Ezeket a megközelítéseket néha keretrendszereknek vagy agilis módszertanoknak is nevezik.

Az agilis informatikai környezetből származik, de aztán más területekre is átterjedt – az ipari mérnököktől a mesterséges intelligenciáig.

Amikor Scrumot használunk professzionális csapatokkal való munkavégzés során, leggyakrabban 2-3 hetes ciklust választunk retrospektív találkozókkal, amelyek lehetővé teszik, hogy mindent kézben tarthassunk.

Ha arról beszélünk, hogy mi az agilis, akkor erre a kifejezésre korlátoznám magam - ez egy értékrend, amelyen belül a termékekkel, a szervezeten belüli folyamatokkal építjük fel munkánkat.

(A ScrumTrek ügyvezető partnere, Alekszej Pimenov a Rusbase-en)

Egy szó a szakértőknek

Vlagyimir Oveljan

A feladatoktól függően különböző módszereket alkalmazunk a filozófián belül - agilis, scrum, kanban.

A Scrum lehetővé teszi az alkalmazottakban a szükséges tulajdonságok – proaktivitás, függetlenség, szervezettség, kommunikációs készségek és előrelátás – fejlesztését. A módszer lényege, hogy önszerveződő csapatokban végezzünk feladatokat, ahol mindenkinek megvan a maga szerepe, és mindenki felelős a munka saját részéért. A scrum segítségével munkatársi felméréseket végzünk, grafikonokat készítünk a feladatvégzés várható sebességéről.

A belső kommunikációban az Agile-t használjuk. A közelmúltban újabb sprintet tartottunk, hogy kiküszöböljük az alkalmazottak késését. A projektben részt vevő összes főnök és szakember egy egész napot töltött egy megbeszélésen, ahol megbeszélték az új sprintben elért eredményeket, kihívásokat és az előttünk álló feladatokat.

Most aktívan bevezetjük a kanban módszert a cégnél. A kanban megvalósítás célja a termelési rugalmasság növelése, a változó piaci igényekhez való jobb alkalmazkodás. A gyakorlatban a módszer segített abban, hogy megfeleltetést érjünk el a raktári készlet és a termelésben ténylegesen felhasznált termékek között.

Vitalij Szotnyikov

Ilja Shikhaleev

A Scrum ritmust és megértést hozott csapatunkba – akár időben vagyunk, akár nem. Látjuk a csapat munkájának gyorsaságát, nincs állandó kurvakodás érzése. Korábban voltak olyan helyzetek, hogy a hard releases előtt a scrum eltűnt valahol, és mindenki csak kezdett rájönni - most elvesztettük, állandó az az érzés, hogy időben vagyunk. Ha kockázatok merülnek fel, azokat korán megbeszéljük a PD-vel, módosítjuk a tervet, vagy valamilyen módon csökkentjük a feladatok körét.

Átláthatóbbá vált a munka, a munkanap kezdett beleférni a 8 órás normába, és úgy érezte, hogy kezdünk többet csinálni. Megértjük, hogy amikor úgy érzi, hogy nem tesz eleget, úgy érzi, hogy keményebben kell dolgoznia – ez nagyon rossz hatással van a termelékenységre, meg kell szabadulnia tőle.

Jevgenyij Rossinszkij

A fejlesztési osztály munkájának áttekinthetősége és nyitottsága érdekében egy speciális táblát helyeztünk el „teendő”, „folyamatban”, „felülvizsgálat”, „teszt”, „kész” felirattal, amelyre a csapat minden tagja matricát ragaszt a feladatokkal ( a „teendő” oszlopban), és végrehajtásuk során a következő bekezdésekbe kerülnek. A happy end pedig a „kész” végpont. Ez segít az átfogó kép kialakításában, és lehetőséget ad arra, hogy lássa, min dolgoznak az egyes résztvevők.

A módszer (és a munkafolyamat szervezése) nagyon fontos pontja: az összes feladat jóváhagyása („to do”) után a lista letiltásra kerül a beszúráshoz. Így az új beérkező feladatok nem vonják el a figyelmet a folyamatról, és nem lassítják a munkát.

Minden résztvevő értékeli az egyes feladatokat az elvégzéséhez szükséges idő- és anyagköltségek tekintetében. A tetején pedig a heti megbeszélések egy meghatározott időpontban (Daily Scrum), ahol minden csapattag röviden elmondja, hogy mit fog ma csinálni, mit csinált tegnap (és hogy szembesült-e akadályokkal). Ez fontos a hosszú távú célok felé vezető úton – így értheti meg időben, hogy ideje változtatni a stratégiáján.