HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

A szakmát közel 10 éve megosztja az a kérdés, hogy melyik módszertan szerint érdemes szoftvert fejleszteni. Most be szeretnék mutatni egy kevéssé ismert, de egyre terjedő módszert, ami egyesíti a formális és az agilis fejlesztés előnyeit.

A szakmát közel 10 éve megosztja az a kérdés, hogy melyik módszertan szerint érdemes szoftvert fejleszteni. Most be szeretnék mutatni egy kevéssé ismert, de egyre terjedő módszert, ami egyesíti a formális és az agilis fejlesztés előnyeit.

A szoftverfejlesztési alapszituációt mindenki ismeri:
- A vezetőség formális projektet akar, konkrét igényekkel és céllal
- A fejlesztők agilisan tudnának hatékonyan dolgozni
- A vezetőség az agilitásra jellemző rugalmasságot szeretné
- De közben eredményeket akar
- Szigorúan tartani kell a határidő-minőség-költségvetés kereteket
- És követni a nagyvállalati előírásokat

Könnyen belátható, hogy akár agilisan, akár formálisan fejlesztünk, valaki valahol rosszul jár. Éppen ezért fejlesztették ki 2006-ban az Agile Waterfall módszertant (vö: Fátyol vízesés vagy WetAgile), ami képes minden követelményt teljesíteni. A kecske is jóllakik, a káposzta is megmarad.

Hogyan lehetséges ez?

A módszertan lehetővé teszi, hogy a projekt a kritikus pontokon (projekt indítás illetve lezárás) formálisan haladjon, de e két pont között a fejlesztés teljesen agilisan, nagyjából a SCRUM-nak megfelelően történik.
Mivel a fejlesztőket csakis a fejlesztés érdekli, ők 90%-ban agilisnak fogják látni a fejlesztést.
A menedzsmentet a fejlesztés közvetlenül nem érdekli, csak a tervezés és a teljesítés – amit ők hagyományos módszertan szerint fognak látni.
Nincs csalás és ámítás, nincs kettős projektvezetés, nem bábozunk és nincsenek illúziók – ugyanarról a projektről beszélünk, de mégis két különböző arcát látjuk.

Habár a módszertan elnevezése kevesek számára lehet ismerős, de valószínű, hogy gyakorlatban már sokan csináltak valami hasonlót. Előfordult-e már, hogy ugyanarról a projekt az egyik résztvevő szerint vízesés szerint haladt, miközben mások szerint nagyon is iteratív/agilis volt? Ha a válasz igen, akkor az bizony Agile Waterfall volt…

Hol érdemes az Agile Waterfall-t bevezetni?
- Ahol a körülmények miatt nehéz lenne agilizálni
- Éppen meg kell menteni egy nehéz helyzetbe jutott agilis projektet
- Ahol a folyamatos eredménykényszer miatt nem lehet éveket várni egy átállásra
- Ahol az agilis fejlesztésnek tandem kell együtt dolgozni waterfall csapatokkal (waterfall-in-tandem)
- Ahol waterfall szerint dolgozó fejlesztői csapatnak kell együttműködnie SCRUM szerint fejlesztő csapatokkal (Scrum of Scrums)

Milyen vezetői hozzáállást követel az Agile Waterfall?
- A fejlesztői csapat maximális támogatása
- Közös vízió
- Az agilis alapelvek használata
- Lean módszerekkel javítjuk az eredményeket és csökkentjük a felesleges munkát

Néhány érdekes eszköz az Agile Waterfall tárházából:

Stealth Agile (Lopakodó Agile): A vezetőségnek rendszerint kevés információja van a fejlesztésről (nem is érdekli őket), ezért azt csinálunk amit akarunk. Az agilis eszközöket be lehet vezetni és alkalmazni, ameddig azok nem okoznak problémát.

SWAT team: Bajba jutott projekteknél az „IT rendőrség” és a folyamat-nácik szavát felülírja az eredményesség iránti igény. Ez a megfelelő alkalom az agilitás rajtaütésszerű bevezetésére, és élesben bizonyítani a menedzsmentnek, hogy mire vagyunk képesek.

Skunk work (Vakondmunka): Szakértők kis csoportja, akiket a szokásos üzletmenetből kiszedve gyorsan és titokban végeznek kutatási vagy stratégiai fejlesztéseket, illetve bizalmas projekteken dolgoznak. A feladat bizalmas jellege miatt nem követik a hagyományos folyamatokat, kívül esnek az auditokon és a többi bürokratikus rémálmon.

Az Agile Watefall 10 sikertényezője:

1) Erős Executive Champion
2) Kapcsolatépítés
3) Backlog használata
4) Ugorj a dolgok sűrűjébe (ne félj, a dolgok rendbe jönnek)
5) A szükséges minimumra összpontosítsunk
6) A waterfall projektvezetőket vonjuk be az agilis tervezésbe
7) Folyamatos ellenőrzés és adaptáció
8) Felfelé agilizálj
9) Kerüld a rossz szokásokat
10) Mindenkit vonj be a projektbe

Kik azok a cégek, akik már használják az Agile Waterfall-t? Nálunk az európai leányvállalatnál van ilyen. Nagy amerikai IT cégeknél ez a választott módszertan. Egyes felmérések szerint Amerikában a nagyvállalatok közel 12%-a hivatalosan alkalmazza, 35%-uknál van Agile Waterfall fejlesztés, és 45%-uknak szüksége lenne rá.

Magyarországon sajnos nincs tudomásom bevezetésről, és csak egyetlen olyan céget ismerek, akik elérték az Agile Waterfall konzultációhoz, oktatáshoz szükséges szintet.

Címkék: waterfall módszertan agile

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr585211429

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

activer 2010.11.04. 06:16:34

Furcsa, de ha megrendelésre készülő mainstream (értsd logisztikai, pénzügy stb.) vállalati alkalmazásokról beszélünk, én szinte csak olyan cégeket ismerek, akik kb. 20 éve "agile waterfall" szerint dolgoznak, csak nem tudnak róla. Az élet, a valóság, a korlátok rákenyszerítik a megrendelőt és a kivitelezőt egyaránt. Azért jön létre, mert a megrendelő pontosan leadja a vállalkozónak, hogy mik az üzelti folyamatai és ezek támogatásához mit szeretne az informatikától (kisebb projekteknél ez min. 80-100 oldal), plusz megmondja mikorra kell készen lenni. (A rászánt összeg a pályáztatás során kiderül.) A kivitelező cégre (projekt manager, műszaki felelős, vezető fejlesztő stb.) van bízva, hogy milyen ütem szerint halad, amely persze követi az ésszerűséget, tisztában van a lehetőségekkel és korlátokkal. Rugalmas időközökben (naponta 2x -> kéthetente) a megbízó és a kivitelező leülnek közösen, beszámoló, bemutató, értékelés (részteljesítés, részfizetés) van. Közben a projekt elején a megrendelő által beadott dokumentáció hibáira is fény derül, azzal kapcsolatban is döntések születnek. Halad szépen a munka, a megrendelő azt látja, hogy ez előzetes terve szépen működő valósággá válik, a fejlesztők pedig nagyrészt maguk osztják, ütemezik a feladataikat. Ez agile waterfall? Lehet akárhogy nevezni a dolgokat, de a lényeg a rugalmasság, a kommunikáció és a kölcsönösség.

Ismeretlen_102125 2010.11.04. 10:28:43

@Activer: ott a pont!!

András 2010.11.22. 21:32:39

A cégnél, ahol dolgozom, most éppen ennek a módszertannak a megvalósítása történik. Én a minöségmenedzsment részleg vezetöjeként a részleg felépítésével párhuzamosan Scrum Masterként sikeresen bevezettem a Scrumot, erre leváltották egy volt Accenture-ös figurára a CIO-t. Mivel az Accenture is fixösszegü szerzödésekkel dolgozik, ezért ök is csak a vízesést használják, így rögtön ezzel kapcsolatos kérdések garmadát kellett megválaszolnom az elsö napon. Elég hamar világossá vált, hogy amíg megvannak a KPI-k, addig a projektek ugyanúgy mehetnek tovább Scrum szerint. Ezáltal jobban átláthatóvá is váltak a projektek, így nem volt nehéz elfogadni ezt a hibridet. Érekesek és jól fogalmazottak a cikkek - legjobbakat, András
süti beállítások módosítása