– Szóval az Agile- ről és a Scrumról szeretnék mesélni .
"A 21. század elején az emberek gondolkodása a programozásról a feje tetejére állt."
"Mindenki meg volt győződve arról, hogy a hosszú távú tervezés nem működik, ezért úgy döntöttek, hogy teljesen felhagynak vele."
– Hogy csinálták?
"Itt van, hogyan."
"A lehető legrugalmasabb projektmenedzsment megközelítést találták ki."
Íme az agilis fejlesztés mögött rejlő fő gondolatok :"
- az emberek és a kommunikáció fontosabbak, mint a folyamatok és az eszközök;
- a működő termék fontosabb, mint a kimerítő dokumentáció;
- az ügyféllel való együttműködés fontosabb, mint a szerződés feltételeinek teljesítése;
- a változtatási hajlandóság fontosabb, mint az eredeti tervhez való ragaszkodás.
Íme a gyors fejlődés alapelvei:
- a vevő elégedettsége értékes szoftver korai és folyamatos szállításával;
- üdvözli a követelmények változását a fejlesztés végén is (ez növelheti a végtermék versenyképességét);
- működő szoftvert gyakran szállítani (havonta vagy hetente vagy gyakrabban);
- szoros napi kommunikáció az ügyfél és a fejlesztők között a teljes projekt során;
- a projekten motivált személyek dolgoznak, akik számára biztosítottak a szükséges munkakörülmények, támogatás és bizalom;
- az információközlés előnyben részesített módja a személyes (szemtől szembeni) beszélgetés;
- a működő szoftver a fejlődés legjobb mércéje;
- a szponzoroknak, a fejlesztőknek és a felhasználóknak képesnek kell lenniük arra, hogy határozatlan ideig állandó tempót tartsanak fenn;
- állandó összpontosítás a műszaki kiválóság és a felhasználóbarát tervezés javítására;
- az egyszerűség annak művészete, hogy ne végezzünk felesleges munkát;
- a legjobb műszaki követelmények, tervezés és architektúra egy önszerveződő csapattól származik;
- állandó alkalmazkodás a változó körülményekhez.
"A szoftverfejlesztés fő problémája az volt, hogy egyik résztvevőnek sem volt teljes körű információja arról, hogy mit kell tennie."
"Az ügyfél elmondhatja, hogyan képzeli el a programot, de valamit kihagy, vagy természetesnek vesz."
"A menedzsernek általában le kell fordítania a követelményeket a programozási szakzsargonról az ügyfél nyelvére, majd vissza."
– Túl sok a bizonytalanság.
"Gyakran a megrendelő igényei a következők: csináld meg valahogy, aztán mutasd meg – ha nem tetszik, akkor megismételheted."
– Ööö... ez borzasztó.
"Az új paradigma szerint a programozók már nem fejlesztenek terméket vagy programot, hanem azt a funkcionalitást valósítják meg, amelyre a vásárlónak szüksége van."
"Mi a különbség?"
"Nos, tegyük fel, hogy a program kidolgozása egy évig tartott. És hat hónapnak kellett eltelnie, mire nem volt mit nézni. Ez olyan, mint egy nagy ház építése: először gödröt ásunk az alapnak, majd kiöntjük az alapot, falakat, tetőt, kárpitozást stb.
"De most a programozók igyekeznek a lehető leghamarabb felszabadítani a szükséges funkcionalitást. Ez olyan lenne, mintha először egy kunyhót, majd egy mobilházat, majd egy kis házat építenének, és csak azután egy nagy házat – részletekben."
"Tekintettel arra, hogy az ügyfél valószínűleg nem tudja pontosan, mit akar, ez egy nagyon ésszerű megközelítés."
– Tegyük fel, hogy az ügyfél egy nagy vadászházat akar.
"A fejlesztők építenek neki egy picit. Egy télig lakik benne. Aztán úgy dönt, hogy nem szereti a faházakat. Csináljunk egyet téglából."
"Egy nyáron a tó közelében lakik, de a szúnyogok élve megeszik. Valahol hallotta, hogy a tavak hűvösek, ezért azt szerette volna, hogy legyen egy. De most nem akar tavat. És könnyebb lesz építeni. a házat így: a tó hiánya nem jelent árvízveszélyt, és a házat a földre is építheti a gólyalábak helyett, ami 25%-kal gyorsabb lesz."
"Érdekes analógia. Valóban ilyen gyakran változtatják az ügyfelek igényeit?"
– Igen, de a probléma nem az ügyféllel van.
"Először is nagyon nehéz elképzelni, hogyan alakulnak a dolgok a jövőben. A menedzserek, a tesztelők és a programozók is ezt teszik. A dolgok alakulásától függően is meggondolják magukat."
"Másodszor, nem az ügyfél igényei a legfontosabbak? Végtére is , ennek a munkának az a lényege, hogy azt hozzuk létre, amire az ügyfélnek szüksége van , nem pedig azt, amit kezdetben meg kellett teremtenie ."
"Valóban, ez így működött: az üzleti elemzők listát készítettek az összes követelményről. Ezt a listát belefoglalták egy szerződésbe, aláírták, és csak a lista szerint dolgoztak."
"Ha a listából hiányzik valami, amire az ügyfélnek nagyon szüksége volt , de elfelejtette, senki nem tenne ellene semmit."
"Értem. Könnyebb követni egy tervet, de nem lehet mindent terv szerint csinálni!"
"Pontosan."
– Ezért találták ki az agilis fejlesztési módszereket.
„És ma a Scrumról fogok mesélni – a legnépszerűbbről.
"A Scrum elsődleges jellemzője a projektfejlesztés kis iterációkra osztása – általában 2-4 hétig. Minden iterációt sprintnek neveznek."
"Egy sprint elején sprint tervező értekezletet tartanak. Ez 3-4 óráig tart."
"A végén van egy bemutató az összes teljesen elvégzett feladatról."
"Általában minden így működik:"
"A legelső sprint előtt az ügyfél (vagy az ügyfél képviselője) összeállít egy követelménylistát, vagyis azt a készletet, amit a programnak képesnek kell lennie. Ezeket a követelményeket általában felhasználói történeteknek nevezik, és az ügyfél általában felhívta a termék tulajdonosát ."
"Őt hívják terméktulajdonosnak , mert a terméket neki írták. Ő és egyedül ő határozza meg a követelmények listáját – mit, mikor és milyen sorrendben."
"Emellett a terméktulajdonos általában feladatprioritásokat is kijelöl. A legmagasabb prioritású feladatokat hajtják végre először. A teljes követelménylistát termékhátraléknak is nevezik . "
"Amikor egy sprint kezdődik, mindenki összegyűlik egy értekezletre. A scrum mester , általában a csapat tagja, általában vezeti a találkozót. A találkozó célja az aktuális sprint (a fejlesztés iterációja) feladatok ( felhasználói sztori ) kiválasztása. "
"Először a csapat minden feladathoz hozzárendel egy durva becslést absztrakt embernapokban, más néven történetpontokban. Ezután a csapat eldönti, hány feladatot lesz idejük elvégezni a sprint során."
"Ismét, maga a csapat dönti el, hány feladatot lesz idejük elvégezni a sprint során."
"Tegyük fel, hogy a terméktulajdonos azt várta, hogy a csapat választja ki az első 7 feladatot, de csak 5-öt választott ki, majd a 6. és 7. feladatot a következő sprintre halasztják. Ha ez nem felel meg a terméktulajdonosnak, emelheti a feladatok prioritását. 6. és 7. pont, hogy biztosan ki legyenek választva, de akkor néhány más feladat kiesik a sprintből."
"A scrum mester azt is javasolhatja, hogy egyes feladatokat kisebbre bontsanak, és különböző prioritásokat állítsanak fel nekik, hogy a termék tulajdonosa a lehető legnagyobb örömet okozza."
"Ez a találkozó lényege: a feladatok változtathatók és feloszthatók, a prioritások változtathatók, stb. Ez az a munka, ami az elején nem volt látható, de nagyon értékes."
"Értem. Olyan, mint autót vezetni. Még ha eleinte úgy gondolja is, hogy csak egyenesen kell mennie, a valóság az, hogy folyamatosan kerülnie kell a kátyúkat, jobbra-balra kell kormányoznia, és el kell hagynia másokat, vagy hagynia kell, hogy elhaladjanak ön mellett."
– Igen, valami ilyesmi.
"A sprinthez kiválasztott feladatok listáját sprint hátraléknak nevezik ."
"A programozók döntik el, hogy ki mit csinál, és csak ezután kezdenek dolgozni. "A hatékonyság növelése érdekében a Scrum azt javasolja, hogy minden nap tartsanak egy 5-15 perces megbeszélést, ahol mindenki elmondhatja egymásnak, mit csinált tegnap és mit csinált. ma megteszem."
"Csapatmunka. Ezt tudom tisztelni!"
"A dolgok könnyebb megjelenítése érdekében általában ajánlott egy speciális táblán megjeleníteni a sprint aktuális állapotát:"
– Jegyezze meg a bal oldali három oszlopot.
"Cetlikre írják a rövidített feladatneveket. A cetlik pedig állapotuktól függően (tervezett, folyamatban, kész) különböző oszlopokba kerülnek."
"A jobb oldalon egy kiégési diagram látható . Ez a diagram minden napra felsorolja a még végrehajtatlan feladatokat. Ideális esetben a befejezetlen feladatok száma nullára csökken a sprint során."
"Amikor a sprint véget ért, a scrum-master bemutat egy demót , amely megmutatja mindazok listáját, amelyek teljesen elkészültek."
"Ezután egy sprint retrospektív megbeszélést tart , ami szintén néhány óráig tart. Ezen a találkozón a résztvevők általában megpróbálják kitalálni, mi ment jól, és mit (és hogyan) lehetett volna jobban csinálni."
"Általában 2-3 sprint után lehet azonosítani és kiküszöbölni azokat a fő problémákat, amelyek megakadályozzák a csapat hatékonyabb munkáját. Ez nagyobb termelékenységhez vezet anélkül, hogy növelné a csapat munkaterhelését. Ez nem volt lehetséges az agilis módszertan korszaka előtt. "
"Néha a sprint során ápolási értekezletet is tartanak. Ennek célja a következő sprint megtervezése. A résztvevők általában ezen a megbeszélésen tisztázzák a feladatok prioritását. Egyes feladatokat részekre is oszthatnak, és/vagy új feladatokkal bővíthetik a termékhátralékot . "
"Nos, lényegében ez minden, amivel rendelkezem. Ez csak egy áttekintés. Lehetetlen néhány szóban elmagyarázni az egészet, de itt olvashat egy jó cikket a témában:"
GO TO FULL VERSION