Agilis fejlesztés

– Szia Amigo!

– Szia, Bilaabo!

"Ma arról fogok mesélni, hogy általában hogyan készülnek a programok."

"A 20. században, amikor a modern IT még gyerekcipőben járt, úgy tűnt, mindenki azt gondolta, hogy a programozás olyan, mint az építés vagy a gyártás."

"A dolgok általában így mentek:"

" Az ügyfél elmagyarázza, milyen típusú programra van szüksége – mit és hogyan kell csinálnia."

" Az üzleti elemzők meghallgatják őt, és az általa elmondottak alapján teljes listát készítenek a programkövetelményekről."

"Akkor a projektmenedzserek ezeket a követelményeket feladatokra osztanák, és azt is meghatároznák, hogy melyik programozó milyen feladatot és milyen sorrendben végezzen."

"Akkor a programozók munkához láttak. Néha több évig(!) dolgoztak."

– Amikor elkészültek, a programot a tesztelők kapták.

"A tesztelők végignézték a program minden követelményét, hogy megbizonyosodjanak arról, hogy végrehajtották-e azokat, és hogy a program megfelelően működik-e."

"Ha valami elromlott, a tesztelők naplózták a hibákat, és elküldték a programozóknak."

"Akkor a programozók kijavítják a hibákat, és visszaküldik a javított programot a tesztelőknek. És a ciklus megismétlődik."

"Amikor a főbb hibákat kijavították, a programot megkapta az ügyfél."

– Tényleg így mentek a dolgok?

– Hát persze, sokat egyszerűsítettem, de ez eléggé közel áll ahhoz, ahogyan a dolgok történtek.

– És tényleg lehet, hogy egy projekt befejezése másfél-két évig tart?

"Néha, ha egy projekt fejlesztése nagyon hosszú volt, külön kiadásokra bontották. 3-6 havonta a fejlesztőknek létre kellett hozniuk a program funkcióinak egy-egy részét, tesztelniük kellett, kijavítaniuk az összes hibáját, és meg kellett mutatniuk a programnak. vevő."

"Először is, hogy megoszthassa benyomásait. Másodszor, és ami még fontosabb, hogy továbbra is fizessen a program fejlesztéséért."

– Fizessen tovább?

"Akkoriban a fejlesztés gyakran a tervezettnél 2-3-szor tovább tartott. És mivel a programozók gyakran órabérben részesültek, a program 2-3-szorosára drágult. Sőt, az előnyök is csökkentek. Végül is, mit akar ma az ügyfél 100 000 dollárért lehet, hogy 3 év múlva nem lesz szükség – különösen háromszoros áron."

– Gyakran megtagadták az ügyfelek a fizetést?

"Igen. Később elkezdtek büntetéseket fűzni a szerződéshez, de ez nem javított a helyzeten. A szoftverfejlesztés elhúzódott és elhúzódott. És senki nem tehetett ellene, még ha akart volna is."

"De miért?"

"Nos, először is, túl keveset tudunk a tervezési szakaszban. Leggyakrabban az elején senki sem tudta megjósolni, milyen problémákkal kell szembenézniük a programozóknak."

– De a tapasztalt programozóknak mindent előre kellett volna látniuk, igaz?

– Látod, hogy a programozás egyedülálló szakma?

"Egy hétköznapi munkás gyakran ugyanazt a munkát végzi újra és újra. Az órások órákat készítenek, a szakácsok főznek, a tanárok tanítanak, az orvosok kezelnek stb."

"E szakemberek mindegyike alapvetően ugyanazt csinálja nap, mint nap. Ennek eredményeként kezdenek egyre jobbá válni a munkájukban."

"A programozásban más a megközelítés. Amint egy programozó minden nap ugyanazzal a feladattal szembesül, ír egy függvényt, modult vagy programot a végrehajtásához, és soha többé nem tér vissza hozzá."

"Minden programozó általában egyszer old meg minden feladatot életében."

"Olyasmi, mint a tudósok vagy a tervezőmérnökök, akik feltalálnak dolgokat."

"Ah. Nos, mi a legfontosabb szerep egy projektben?"

"Hmm, hogyan válaszoljak erre. Könnyű megmondani, melyik a legfontosabb, de nehéz azonosítani a legkevésbé fontosat."

" A tesztelő (Quality A susurance, QA) elsődleges feladata a program állapotának  figyelése és a  hibák azonnali jelentése. Minél többször és korábban találja meg a tesztelő a hibákat, annál inkább javítható.  A jó tesztelő jobban befolyásolja a termék minőségét, mint egy jó programozó csinálja ."

"Miért nem tesztelhetik a programozók a saját programjaikat. Végül is ők nem tudják jobban, mint a tesztelők, hogy mi működik és mi nem?"

"Egy jó programozó egyszerűen képtelen jó tesztelő lenni. A programozó nagyon jól tudja, hogyan működik a program, ezért mindig egy bizonyos módon használja. Ellentétben a hétköznapi felhasználókkal, akik úgy használják a programot, ahogy akarják. "

"Ráadásul a tesztelők nem tesztelik azt, ami még nem működik. A tesztelő a program azon funkcionalitását vagy részeit teszteli, amelyek a programozó szerint már szinte tökéletesen működnek."

"És amikor a tesztelő rengeteg hibát talál ebben a funkcióban, és a programozó kijavítja azokat, akkor a termék valóban közelebb kerül a tökéletességhez."

" A programozó ( Softverfejlesztő mérnök  ,  D fejlesztő ,  SDE ) elsődleges feladata az új funkcionalitás megvalósítása. Vagy egyszerűbben fogalmazva a rá rendelt feladatok végrehajtása. Amikor a programozókat új funkciókkal látják  el . , végrehajtják azokat. Amikor hibákat rendelnek hozzá, kijavítják a hibákat."

"De néha vannak nagyobb kihívást jelentő feladatok, például a program vagy annak egyes részei architektúrájának kidolgozása. Minél jobb a javasolt architektúra, annál könnyebb lesz a dolgokat elvégezni a jövőben."

"A probléma az, hogy az architektúrát már a legelején meg kell választani, de csak a fejlesztés kellős közepén derül ki, hogy a megfelelő architektúrát választotta-e."

"Továbbá, ha az architektúra sikeres, és a program nagyszerűnek bizonyul, akkor az ügyfél valószínűleg ezt fogja használni a program új verzióinak alapjaként."

– Itt a célom.

"Bármilyen architektúrát is választ, mindig lesz egy csomó változtatás, kiegészítés és új funkció, amivel az architektúra nem veszi figyelembe."

– Itt van egy jó példa.

"Egy ügyfél azt kéri, hogy építsen egy 5 emeletes épületet, így Ön megtervezi az építészetet és megépíti a házat."

"Ezután az ügyfél kéri, hogy adjon hozzá egy másik történetet, majd egy másikat, és így tovább."

"De az első emelet falait nem tervezték ekkora súlyra, és az alapozást sem. Szóval mindent újra kell csinálni."

"De miután elkészült az 5 emeletes épület, mi van akkor, ha az ügyfél azonnal úgy dönt, hogy egy 50 emeletes épületet akar?"

"Könnyebb lenne lebontani a meglévő szerkezetet és mindent a semmiből újjáépíteni..."

– De van egy tanácsom az építészettel kapcsolatban.

"Egy alkalmazás architektúrájának mindenekelőtt rugalmasnak kell lennie, ami azt jelenti, hogy nem kell a nulláról kezdenie, ha úgy dönt, hogy újra elkészíti az alkalmazás felét. Az ilyen típusú architektúrát általában rugalmasnak és modulárisnak nevezik . "

" A projektmenedzser elsődleges feladata a döntéshozatal. A projektmenedzser az, aki átlátja a teljes képet, és ennek alapján hoz döntéseket."

"Tegyük fel, hogy a fejlesztés során világossá válik, hogy egy bizonyos feladat nem a tervezett módon fog elkészülni. A projektmenedzser ekkor:

" a)  próbáljon tárgyalni az ügyféllel a feladat módosításáról"

" b)  több időt szánni a feladatra"

" c)  hozzon be tapasztaltabb programozókat más projektekből."

– És sok más lehetőség is van.

"Minden lehetőség megköveteli, hogy feláldozzon valamit, és a menedzser feladata az, hogy minimalizálja az ebből az áldozatból származó teljes veszteséget. "

"Például tegyük fel, hogy a versenytársak úgy lopják el a vezető programozót, hogy kétszer annyi pénzt kínálnak neki."

"A projektmenedzser a következőket teheti:"

" a)  ne tegyen semmit. A programozó elmegy, és a projekt valószínűleg lemarad, és büntetést von maga után."

" b)  megduplázza a fizetését. Akkor a csapat többi tagja is emelést akar majd kérni. Ha mindegyiküknek több pénzt adsz, akkor a projekt költségei megnőnek, és veszteségessé válhat."

" c)  valami más lehetőség, amit kitalálsz."

"Látom."

"Rossz projektmenedzserrel egy jó csapat általában meghosszabbítja a projektet, de nem mindig."

"Egy jó menedzser egy csapat átlagos programozóval szinte mindig gyorsabban hajt végre egy projektet, mint egy rossz menedzser egy csapat kiváló programozóval."

"Látom."

– Oké, tartsunk egy kis szünetet, aztán folytatjuk.