Szoftverfejlesztési módszertanok:

A “Lean” és az “agilis” kifejezésekkel mostanában sokat dobálóznak, gyakran szoftverfejlesztési módszertanokra, projektmenedzsmentre vagy szervezeti stílusokra hivatkozva.

De Önt is foglalkoztatta már a kérdés:

Mi az a Lean? Mi az agilis? Van különbség?

A Merriam-Webster szótár meghatározása szerint az agilis “gyors leleményes és alkalmazkodó jellegű, vagy a gyors és könnyű mozgásra való készség jellemzi.”

A lean meghatározása szerint egyszerűen “vékony és egészséges, vagy kevés vagy semmi zsírt nem tartalmaz.”

Ezek alapján feltételezhetjük, hogy aki lean és aki agilis, annak sok közös tulajdonsága lehet. Ugyanez igaz a szoftverfejlesztéssel összefüggésben is.

Mi az agilis? Mi a lean?

Az agilis ma már széles körben ismert a technológiai világban, mint a szoftverfejlesztést vezérlő értékek és elvek összessége. Az “Agilis kiáltvány” négy értéket és 12 alapelvet fogalmaz meg. A lényeget tekintve az Agile pontosan az, amire gondol. Ez az Agilis. A módszertan a rugalmasságot, a kommunikációt, az együttműködést és az egyszerűséget részesíti előnyben.

A Lean kevésbé ismert, és nincs egyértelmű, szakmai konszenzus által támogatott definíciója. a “Lean” kifejezést eredetileg a Toyota termelési rendszerén alapuló gyártási szervezeti modell leírására találták ki, de általában a szoftverfejlesztés agilis ernyőjén belüli alkeretnek tekintik.

Most sok a zűrzavar azzal kapcsolatban, hogy mi a Lean, mi az Agile, egy és ugyanaz-e a kettő, és melyiket érdemes használni.

Az új szoftverfejlesztési módszertanok születése

A Lean és az Agile is a meglévő tervvezérelt módszerek, például a vízesés hiányosságaira válaszul alakult ki. Az 1970-es évek óta használt módszereket a fejlesztők és a szoftverfejlesztésért felelős vezetők a 90-es évekre kezdték észrevenni a Waterfall hatékonyságának hiányosságait. A dinamikusabb piacok és a technológia iránt érdeklődő fogyasztók miatt a Waterfall nem tudott elég gyorsan reagálni a piaci igényekre, a változó technológiára, és nem tudott következetesen hibamentes szoftvereket szállítani.

A jobb modell keresése érdekében a Lean és az Agile megalkotói olyan módszertanok kidolgozására törekedtek, amelyek jobban az ügyfélre összpontosítanak. Az új módszertanok versenyelőnyként fogadták el az alkalmazkodóképességet, előnyben részesítették a korai és folyamatos tesztelést, és bevonták az emberi tényezőt a projektmenedzsmentbe és a kivitelezésbe.

Lean vs. Agilis elvek

A Lean szoftverfejlesztést (LSD) először dr. Robert Charette, mint egy módot a változás-tűrő szervezetek kialakítására, amelyek egyre inkább a szoftverektől függtek.

Ezután jött “Az agilis kiáltvány”, amely az agilis szoftverfejlesztés 12 alapelvét rögzítette.

A szoftverfejlesztési módszertanok másik mérvadó munkája Mary és Tom Poppendieck nevéhez fűződik, akik a Lean Software Developmentet adták ki: An Agile Toolkit.

Itt van az értékek és elvek egymás melletti összehasonlítása:

A Dr. Charette LSD 12 alapelvét és az Agile 12 alapelvét összehasonlítva láthatjuk, hogy feltűnően hasonlóak. A Poppendieck által javasolt hét Lean-elv kevésbé célzott, de mégis átfedésben van “Az agilis kiáltvánnyal” és Charette Lean szoftverfejlesztésével.

Itt van még néhány közös elemük:

• A vevői igényekre való gyors reagálás értéke
• Kora tesztelés
• A fejlesztés iteratív megközelítése
• MVP (Minimum Viable Product) stílusú fejlesztés a feature heavy helyett
• Együttműködés mind a vállalaton belül, mind a külső érdekeltekkel

Idővonal

Megvizsgáltuk azokat a vízválasztó eseményeket és publikációkat, amelyekből ezek a terminológiák megszülettek, hogy megnézzük, hogyan váltak népszerűvé. Nézze meg az alábbi, a fejlődést részletező idővonalunkat, és vegye fel ezeket az olvasmánylistájára, ha van kedve hozzá!

A Lean és az Agile eredete

Amint az idővonalból láthatja, a Lean kifejezést először Womack et. al. használták 1990-ben a Toyota termelési rendszer leírására a The Machine That Changed The World című könyvükben. Dr. Robert Charette később a korábbi publikációkban leírt Lean-ötleteket adaptálta a “Lean Software Development” című művéhez.

Az Agilis kifejezés csak 2001-ben, az “Agilis Kiáltvány” (The Agile Manifesto) megjelenéséig terjedt el széles körben. Az Agile és a Lean kifejezéseket egyaránt nyugati technológiai szakemberek vagy akadémikusok alkották meg, akik a Toyota termelési rendszerére hivatkoztak (erről később).

Meglehet, hogy némi visszhangot kapunk, ha ezt mondjuk, de ezt szem előtt tartva a Lean és az Agile kifejezések valójában nem olyan fontosak. Az, hogy két kifejezés ugyanabból az elvből ered, valójában hozzájárul a témával kapcsolatos zűrzavarhoz. Ettől függetlenül ez az a terminológia, amelyet az iparág elfogadott, így a jövőben továbbra is ezeket fogjuk használni.

Az idővonal szintén a zűrzavar forrása. Dr. Robert Charette a 90-es évek elején és közepén mutatta be a Lean szoftverfejlesztéssel kapcsolatos elképzeléseit. Lean Development megközelítésének taktikai célját és 12 alapelvét 1998-ban írta le “Lean Development” című cikkében, közel három évvel a “The Agile Manifesto” előtt. A Lean és az Agile közötti átfedés bizonyítéka, hogy ezt a cikket Jim Highsmith írta, aki később az Agile mozgalom egyik fő alapítója lett. Highsmith cikkét azonban nem terjesztették széles körben, és csak 2003-ban írta meg maga Charette a lean fejlesztési megközelítése mögötti mélyebb magyarázatot a “Challenging the Fundamental Notions of Software Development” című kutatási jelentésben.”

Egy e-mailváltásban dr. Charette gyorsan rámutatott, hogy a Lean Developmentről alkotott elképzelését a szoftverek területén belüli szervezeti szintre szánta:

Az enyém a szervezet számára az IT üzleti/feladatérték javításának stratégiai és működési igényéből fakadt, és ezt a kockázatkezelés szempontjából közelítettem meg.
-Dr. Robert N. Charette

Ez némileg különbözik az Agile-tól, amelyet először szigorúan a “szoftverfejlesztés jobb módjaként” javasoltak, de ma már különböző projektekre és irányítási módszerekre alkalmazzák.

2003-ban Poppendieckék is megjelentették a Lean Software Development című könyvüket: An Agile Toolkit. Ez a könyv a Lean fejlesztés hét alapelvét részletezte, amely közvetlenül korrelál a Lean gyártás hét pazarlási formájával.

A Poppendieckek könyve egyszerre erősítette a Lean-t mint szoftverfejlesztési módszertant, és elmosódott a Lean és az Agile közötti különbségtétel, mivel a Lean-t az Agile-n belül kiegészítő módszerként javasolta. A könyvet a megjelenés idején a The Agile Software Development Series legújabb kiadványaként árulták.

Most a Poppendieck-ék több, a témával foglalkozó művét a Lean és a “leanre törekvő” szoftverfejlesztők alapvető olvasmányának tekintik.

Eltérés az alkalmazásban

Dr. Charette szerint a Lean és az Agile közötti egyik fő különbség az, hogy az Agile alulról felfelé halad, míg a Lean felülről lefelé. Ez a Lean végponttól végpontig (E2E) tartó struktúrájában és a Poppendieck által javasolt See the Whole (Lásd az egészet) elvében nyilvánul meg. Az alábbiakban ezeket az elveket az értékáram-térképezés gyakorlatában mutatjuk be.

Értékáram-térképezés

A See the Whole elvének megvalósítása érdekében a Poppendiecks részletesen bemutatja az értékáram-térképezés módszerét, amely a végponttól végpontig tartó fejlesztési folyamat során feltárja az értéknövelt és a nem értéknövelt tevékenységeket.

Az értékáram-térképezés a fejlesztési ciklust elemzi a követelmény beérkezésétől az ügyfélnek történő átadásig. A cél az ülő készlet és a várakozás (késedelmes gyártás) pazarlásainak azonosítása, valamint a folyamatban lévő munka (WIP) és az átfutási idő csökkentése érdekében új gyakorlatok feltárása.

Poppendieck szerint az értékáram feltérképezése egyszerű gyakorlat, amelyhez csupán egy ceruzára és egy darab papírra van szükség. A folyamat a következő:

1. Térképezze fel a jelenlegi értékáramlását (kezdve egy követelménnyel és a teljesítéshez vezető út cselekvéseinek idővonalával)
2. Analizálja a pazarlás legnagyobb okát (Mi hátráltatja a folyamatban lévő munkát?)
3. Készítsen tervet ennek a pazarlásnak a felére csökkentésére
5. Készítsen egy jövőbeli értékáram-térképet

A “The Agile Manifesto”-ban lefektetett agilis paradigma a rövid iterációs ciklusokat és a gyakori átadásokat részesíti előnyben a holisztikus végponttól végpontig tartó szemlélettel szemben. Az E2E fókusz ezért egyedülálló a Lean számára. Valójában az E2E-konstrukció miatt a Lean (és nem az Agile) gyakrabban alkalmazott szervezeti struktúra és vezetési stílus.

A végponttól végpontig tartó szemlélet megköveteli, hogy az egész szervezet részt vegyen a pazarlás kiküszöbölésében. Ez visszhangozza Dr. Charette eredeti Lean Development koncepciójának kinyilvánított célját:

A Lean Development egy filozófia, egy látásmód és gondolkodásmód az informatikáról és annak a szervezethez való viszonyáról, éppúgy, mint egy fejlesztési megközelítés.

Lean Kanban Vs. Agilis Kanban

A Lean és az Agilis is átvette a TPS Kanban rendszert, kisebb eltérésekkel. A Toyota Kanban rendszerét úgy tervezték, hogy korlátozza a folyamatban lévő munkát.

A hagyományos “push gyártással” szemben, amely a készletet a folyamat következő lépésére tolja, a Kanban csak akkor húz új anyagot a termelésbe, ha az aktuális darabot már feldolgozták, és az alkatrészeket pótolni kell.

A Kanban kártyák utánpótlási rendelésekké válnak, és visszakerülnek a termelés előző lépéséhez. Ennek eredményeképpen a folyamatban lévő munka minimálisra csökken, és a kihasználatlan készlet csökken.

A szoftverfejlesztésben ahelyett, hogy a Kanban-kártyákat az egyik gyártási lépésből visszaadnák az előzőnek, egy Kanban-táblát használnak. Öntapadós jegyzeteket használnak, leggyakrabban a folyamatban lévő követelmények ábrázolására.

A Modern Software Engineering Concepts and Practices című könyv Kai Petersen által írt fejezet szerint: Advanced Approaches, mind az Agile, mind a Lean a követelmények rangsorolt listáját használja a feladatok húzásához.

Az Agile-tól eltérően, amely fix időtartamú iterációs ciklusokat használ a fejlesztés idejének korlátozására és a Kanban tábla szabályozására, a Lean korlátozza az egy adott időpontban megengedett feladatok számát. Ez lehetővé teszi a Lean számára, hogy teljesítse elsődleges célját, a WIP korlátozását, ugyanakkor pontosabban mérje az átfutási időt és azonosítsa a termelésben keletkező pazarlást. Amint egy feladat befejeződött, egy új feladat húzható a priorizált listáról. Míg a Lean a folyamatos áramlás koncepcióját használja, az Agile minden új iterációt egy új táblával kezd.

Egyes csapatok felismerik mindkét megközelítés előnyeit, és kezdik alkalmazni a scrumban nevű hibrid módszert.

Ez csak két finom különbség a Lean és az Agile megközelítésében a közös célok elérése érdekében. Egy másik, a Codementoron megjelent cikk a Lean és az Agile további felhasználási és alkalmazási lehetőségeit vizsgálja.

A gyakorlatban lényegtelen, hogy a csapata az úgynevezett “agilis” vagy a “lean” megközelítést alkalmazza. Ami fontos, az a megfelelő gyakorlatok megtalálása a munkafolyamatok optimalizálásához és az ügyfelek számára történő következetes értékteremtéshez, amit mindkét módszertan végső célként tekint.

A TPS kapcsolat

Szóval mi köze mindennek a Toyota Production Systemhez? Nagyjából mindenhez. Mind az Agile, mind a Lean alkotóira nagy hatással volt a TPS, ahogy azt Womack et. al. leírja a The Machine That Changed the World című könyvében. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. A vállalat nem remélhette, hogy a tömegtermelés detroiti modelljét követve fennmaradhat.

Ezek között a körülmények között Taiichi Ohno és Kiichiro Toyoda a termelésben keletkező pazarlás kiküszöbölésével, az átfutási idő csökkentésével, valamint a Just-in-Time (JIT) gyártás néven is ismert, csak azt gyártva, amire a vevőknek szükségük van.

A pazarlás megszüntetése érdekében Ohno elhatározta, hogy csak azt gyártja, amire, amikor és amilyen mennyiségben szükség van rá.

A Lean és az Agile iteratív folyamata, amely a funkciók fejlesztésének minimalizálására és a frissítések szállításának maximalizálására összpontosít, közvetlenül tükrözi a Toyota Just-in-Time gyártását.

Jidoka

A jidoka (自働化) emberi érintéssel történő automatizálásnak fordítható, néha “intelligens automatizálásnak” is nevezik. A Jidoka jelentős szerepet játszik a termelésben keletkező pazarlás kiküszöbölésében azáltal, hogy a gépeket függetlenebbé teszi, ami felszabadítja az embereket, hogy aktívabb szerepet játsszanak a termelésben, és felszabadítja az emberi kreativitást.

A Jidoka intelligens gépekre támaszkodik, amelyek szabálytalanság esetén automatikusan leállnak. Az emberi dolgozók ekkor odamehetnek és kijavíthatják a problémát, megakadályozva, hogy a hibák továbbadódjanak a gyártási folyamat során.

A Jidoka emellett minden alkalmazottat feljogosít arra, hogy megállítsa a gyártósorokat, ha problémát észlel. Az elv egy négylépcsős folyamatot tartalmaz a hibás termékekből származó pazarlás kiküszöbölésére:

1. A rendellenesség észlelése
2. A termelés leállítása
3. A közvetlen állapot javítása vagy kijavítása
5. A kiváltó ok kivizsgálása és a helyzet orvoslása

A Jidoka koncepciót láthatjuk a Lean és Agile összpontosításában a korai és gyakori tesztelésre a hibák kiszűrése érdekében, valamint az ügyfélkonzultáció hangsúlyozásában a felhasználói fájdalmak feltárása érdekében.

A TPS pazarlásai a szoftverfejlesztés kontextusában

A JIT gyártás eléréséhez Taiichi Ohno a pazarlás hét kiküszöbölendő formáját vázolta fel. A nyolcadik szám később került hozzá. Ha közelebbről megnézzük az Agile és a Lean értékeit, céljait és elveit, láthatjuk, hogy ezek a TPS nyolc pazarlása ellen hivatottak védekezni. A 2003-as Lean Software Development című könyvükben: An Agile Toolkit című könyvében Poppendieckék a TPS-pazarlásokat szoftverfejlesztési kontextusban mutatták be.

1. A túltermelés pazarlása. A túltermelés pazarlása az egyik legnagyobb oka annak, hogy a vízesés-módszert elhagyták. A túltermelést olyan funkciók extra kódolásának tekintik, amelyeket nem kértek, és amelyeket az ügyfél esetleg nem is akar.

Ezt tükrözik a következő elvek:

Agile ⟶ egyszerűség
Charette Lean⟶ minimalizmusa
Poppendiecks Lean ⟶ a pazarlás kiküszöbölése

2. A várakozás pazarlása. A JIT-gyártásban a tétlen gépen vagy munkáson való várakozás pazarlás. A szoftverfejlesztésben a pazarlás a felesleges kapacitással rendelkező csapatra való várakozás. Ha a termelésben olyan késések vannak, amelyek miatt egy csapat készenlétben van, vagy az ügyfélnek várnia kell a szállításra, akkor pazarlásról van szó.

Az ehhez illeszkedő elvek a következők:

Agile ⟶ gyakori ciklusok
Charette Lean ⟶ ⅓ az időből (az LSD célja), 80%-os megoldás ma
Poppendieck Lean⟶ a lehető leggyorsabban szállít

3. A szállítás pazarlása. A szoftverfejlesztésben a szállítást “feladatváltásként” fordítják le. A túl sok átadás-átvétel vagy a több csapatba beosztott munkatársak túlzott multitasking igényével nem hatékony és pazarlás.

Megfelelő alapelvek:

Agile ⟶ érdekeltek együttműködése, önszerveződő csapatok, a
bizalom, a támogatás és a motiváció kultúrája
Charette Lean ⟶ csapatmunkája
Poppendieck Lean ⟶ felhatalmazza a csapatot

4. A túlfeldolgozás pazarlása. Ez egyszerűen olyan extra folyamatokat jelent, amelyekre valójában nincs szükség ahhoz, hogy értéket szolgáltassunk az ügyfélnek. Az elsődleges példa erre a dokumentáció. A rugalmatlan folyamatok túlzott dokumentációja nem lesz értékes, ahogyan a túlságosan részletes felhasználói kézikönyvek sem, amelyeket egy-két oldalban össze lehetne foglalni. A dokumentáció időigényes, mégis korlátozott értéket nyújt a végfelhasználónak.

Megfelelő elvek:

Agile ⟶ egyszerűség, működő szoftver mint mérce
Charette Lean ⟶ minimalizmus
Poppendiecks Lean ⟶ pazarlás megszüntetése

5. A leltározás pazarlása. A készletpazarlás olyan Folyamatban lévő munka, amelyre beruházás történt, de a befejezésig nem rendelkezik értékkel. Más szóval a befejezetlen szoftver nem nyújt értéket a felhasználónak. A Lean és az Agile értékeli a gyors és gyakori szállítást, hangsúlyt fektetve a gyakori iteratív ciklusokra és a működő szoftver leszállítására.

Megfelelő elvek:

Agile ⟶ vevői elégedettség (korai és gyakori vevői
szállítás révén)
Charette Lean ⟶ 80%-os megoldás ma
Poppendieck Lean ⟶ a lehető leggyorsabban szállítani

6. A mozgás pazarlása. A mozgás pazarlása az információ megszerzéséhez vagy a kérdések megválaszolásához szükséges felesleges erőfeszítés. Ez akkor gyakori, ha a csapatok nincsenek együtt, ha a feladatokat befejezik, és az eredményeket nem teszik azonnal elérhetővé minden érintett fél számára, vagy ha az érdekeltek nem könnyen elérhetőek konzultációra.

Megfelelő elvek:

Agile ⟶ az érdekeltek együttműködése, személyes kommunikáció
Charette’s Lean ⟶ az ügyfelek részvétele, csapatmunka
Poppendieck Lean ⟶ a pazarlás megszüntetése

7. A hibák pazarlása. A gyártáshoz hasonlóan a hibás vagy hibás szoftverek előállítása is elpazarolt befektetést jelent a vállalat számára. Minél gyorsabban észlelhető egy hiba, annál valószínűbb, hogy a pazarlás mérséklődik. Számos agilis és Lean elv arra törekszik, hogy megállítsa a hibákból eredő pazarlást. A hibák csökkentése érdekében mindhárom módszertan nagy hangsúlyt fektet a korai és gyakori tesztelésre.

Megfelelő elvek:

Agile ⟶ technikai kiválóság, működő szoftver mint mérőeszköz
Charette Lean ⟶ ügyfélelégedettség
Poppendiecks Lean⟶ felerősíti a tanulást

8. A kihasználatlan munkavállalói kreativitás pazarlása. A szoftverfejlesztésben a kihasználatlan kreativitás a merev ütemtervből és az emberi együttműködés hiányából fakad. A Jidokához (自働化) hasonlóan az Agile és a Lean is az emberi együttműködés és az innováció maximalizálására törekszik, hogy a technológiából a legjobb eredményeket hozza ki.

Megfelelő alapelvek:

Agile ⟶ érdekelt felek együttműködése, csapatreflexió
Charette Lean ⟶ “íratlan” 13. elve az elégedettség a
munkán keresztül
Poppendiecks Lean ⟶ felerősíti a tanulást

TPS értékek a szoftverfejlesztési módszertanban

A TPS-t alkotó alapértékek közül sokan az Agile és Lean szoftverfejlesztési módszertanokban is megjelennek.

A kaizen (改善) jelentése folyamatos fejlesztés. A rugalmas, iteratív, ügyfélközpontú modellekkel a folyamatos fejlesztés az Agilis és a Lean szoftverfejlesztési módszertanok talán legfontosabb értéke.

Hansei (反省) önreflexiót jelent. A hatékonyság javításának eszközeként az Agilis kiáltvány közvetlenül a csapat önreflexióját fogadja el 12. alapelvként. Lean Development modelljének bemutatásakor Dr. Charette arra hívja fel az olvasókat, hogy a jobb folyamatok megtalálásának első lépéseként gondolkodjanak el az összes jelenlegi feltételezésen, amelyek az általuk használt folyamatokat diktálják. Poppendieck-ék amplify learning elve is Hansei elvének tekinthető.

Az emberek tisztelete (尊重) mindhárom paradigma központi eleme. Az “Agilis kiáltvány” első értéke, hogy “értékeljük az egyéneket és az interakciókat a folyamatokkal és eszközökkel szemben.”

Az emberek tisztelete megjelenik Dr. Charette állításában is, miszerint fontos, hogy az egyének elégedettséget tapasztaljanak a munka által, valamint Poppendieck Lean-elvében a csapatok felhatalmazása. Ez az érték elismeri, hogy ha az egyének részt vesznek a döntéshozatalban és a munkakörnyezetük javításában, akkor innovatívabb és hatékonyabb munkavállalók lesznek.”

A szeiri (整理) elv a pazarlás tükre. A szeiri azt diktálja, hogy ami felesleges, azt el kell távolítani. Ez magában foglalja a TPS mind a hét eredeti pazarlását, amelyekkel párhuzamos pazarlást már azonosítottunk a szoftverfejlesztési környezetben.”

Gengchi Genbutsu (現地現物) szó szerint fordítva “tényleges hely, tényleges dolog”. A gyakorlatban ez azt jelenti, hogy “ellenőrizni, hogy megértsük”. Ha a gyártási folyamatban probléma merül fel, a vezetőnek a forráshoz kell mennie, hogy megértse a problémát, és meghatározza, hogyan lehet megoldani.

A szoftverfejlesztésben ez az érték a rövid iterációs ciklusok, a korai tesztelés és a vevői együttműködés hangsúlyozásában nyilvánul meg, hogy a szoftvermérnökök olyan működő szoftvert építhessenek, amelyet a felhasználók valóban akarnak.

Összegzés

Amint e bejegyzés nyitó bekezdéseiben említettük, a Lean módszertan kevésbé ismert, és gyakran agilis gyakorlatnak tekintik. A Lean talán egyszerűen a szélesebb körű alkalmazásai miatt kevésbé jól definiált.

A Lean közvetlenebb kapcsolatban áll a Toyota termelési rendszerével, és először az üzleti menedzsmentben alkalmazott módszerek és gyakorlatok szervezeti halmazaként javasolták, és csak később alkalmazták a szoftverfejlesztésre. Az agilis módszertant ezzel szemben kifejezetten a szoftverfejlesztés számára fejlesztették ki a terület elkötelezett szakemberei.

A két módszertan közös hátterének és általános elveinek részletezése után láthatjuk, hogy a két paradigmában több a közös pont, mint a különbség.

A “The Agile Manifesto” egyik fő szerzője, Martin Fowler, aki szintén szorosan együttműködött Poppendieckékkel, rámutatott, hogy a Lean és az Agile nem zárják ki egymást:

A Lean és az Agile mélyen összefonódik a szoftverek világában. Nem igazán beszélhetünk arról, hogy alternatívák lennének….nem Agile vagy Lean, hanem Agile és Lean.

1. A Charette-féle Lean szoftverfejlesztés 12 alapelvét valójában először Jim Highsmith “Lean Development” című cikkében írta le 1998-ban. Ezt később Dr. Charette saját “Challenging the Fundamental Notions of Software Development” című cikkében dolgozta ki ︎

.