Agilis, scrum, vízesés

– 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:"

https://en.wikipedia.org/wiki/Scrum_(software_development)