Agilis módszerek és módszertan kezdőknek - Agilis szoftverfejlesztés és agilis projektmenedzsment példák

Az Agile a szoftverfejlesztés megközelítésének módszertana. Különböző keretrendszerekből áll, mint például a SCRUM vagy a Kanban, amelyek segítenek a fejlesztő csapatoknak folyamatosan felépíteni, tesztelni és visszajelzést gyűjteni termékükről.

Az agilis négy alapelvből áll:

  1. Egyének és kölcsönhatások a folyamatok és eszközök felett
  2. Működő szoftver átfogó dokumentációval
  3. Ügyfél együttműködés a szerződéses tárgyalások során
  4. Válasz a változásra egy terv követésével

Később áttekintem ezeket az elveket, és jobban értelmezem őket. Ehhez fontos egy lépést hátrálni és megérteni a korábban alkalmazott szoftverfejlesztési gyakorlatokat.

Vízesés

A vízesés fejlesztése nagyon lineáris megközelítés a termék építéséhez. A termék teljes felépítéséig és teszteléséig alig vagy alig lehet visszajelzést vagy iterációt.

Így működik: a csapatok heteket (és néha hónapokat) töltenek a termékigény dokumentumok elkészítésével.

Mielőtt bármilyen kódot írnának, a termékmenedzserek, az elemzők és a tervezők összeállítanak egy hatalmas dokumentumot, amely rendkívül részletesen vázolja a termék követelményeit.

Könnyen szólva ez egy hosszú és fáradságos folyamat, amelyben elkerülhetetlenül egyes dolgok elmaradnak.

Itt van egy egyszerű gondolatkísérlet. Gondoljon a Google keresésre vagy az ügyfél e-mail keresőjére.

Most próbáljon meg képet készíteni ezekre a termékekre vonatkozó követelményekről.

Kétségtelen, hogy fontos dolgok elmaradnak. Egyszerűen nem lehet elképzelni, hogy ezek a termékek hogyan fejlődnek az idő múlásával.

Ha egy terméket épített - egyedüli építőként vagy egy csapat tagjaként -, valószínűleg kapcsolódhat ehhez az állításhoz.

Ha mindenről megegyeznek, a specifikációkat átadják a mérnöki csapatnak, amely ezt követően a terméket gyártja, minőségi és kvantitatív adatokat és inputokat felhasználva.

Amikor minden kódolva van, megkezdődik a tesztelés.

Ha összetett termékről van szó, a tesztelés és a hibajavítás heteket vagy hónapokat vehet igénybe, mivel az egész terméket szigorú felülvizsgálatnak kell alávetni. Amikor a tesztelők és a termékmenedzserek aláírják a tesztkövetelményeket, a termék készen áll a szállításra.

A vízesések fejlődésében számos hiányosság van, és itt van néhány.

Beépített visszacsatolási mechanizmusok hiánya

Mi van akkor, ha a fejlesztőcsapat pontosan követi a specifikációkat, és kiderül, hogy annak életre keltése nem éppen olyan meggyőző, mint a termékcsapat gondolta? Vagy még ennél is rosszabb: mi lenne, ha hiba lenne a specifikációs dokumentumban?

A Vízesés fejlesztés során csak akkor tudja meg a választ ezekre a kérdésekre, ha a terméket már elkészítették.

A termékfejlesztés nagy fix költségekhez vezethet. Ha a termék nem működik, akkor ezek a költségek elsüllyedté válhatnak.

Az elsüllyedt költségek az építõ ellenségei, mert az elsüllyedt költségek már felmerült költségek, amelyeket nem lehet megtéríteni.

Mi van, ha az ütemterv megváltozik?

Ez folyamatosan történik. Azon a számítógépen történik, amelyet a cikk elolvasásához használ, a vállalatában, és nagy és kicsi technológiai cégeknél.

Mi van, ha az ütemterv megváltozik, és a csapatnak valami másra kell fordítania a figyelmét? A Vízesés alatt használhatatlan termék marad. Gondolj: merevség.

Ismételten, ha nem tudja a fix költségeket valami rugalmassá alakítani, akkor nagy számla marad, és nem sokat mutat be.

Minden odaadó munka, megterhelő határidők, tábla kalandozás és késő éjszakák nem vezetnek a projekt elején kívánt eredményekhez.

A termék addig gyűjti a port, amíg végül el nem szállítják

Ahelyett, hogy a termeléshez egy bizonyos időtartamra inkrementális fejlesztéseket juttatnának, a vízesés módszertana a végéig várja a teljes termék szállítását.

Bár ez ésszerű megközelítés az autó építéséhez, ez nem nagyszerű megközelítés a szoftverekhez.

A szoftverek, az autóktól eltérően, rugalmasak a tervezésben.

Az emberek nem használhatják a félig gyártott autókat. De félig beépített szoftvert használunk folyamatosan.

Adja meg az Agile lehetőséget

Az Agile segít megoldani ezeket a problémákat azáltal, hogy lehetővé teszi a termékfejlesztő csapatok számára, hogy folyamatosan hozzanak létre értéknövelő funkciókat. Ez lehetővé teszi a csapatok számára, hogy folyamatosan visszajelzéseket kapjanak munkájukról, és szükség esetén változtatásokat hajtsanak végre.

Az agilis módszerek alkalmazásával a csapatok következetesen és kiszámíthatóan, gyors ütemben szállítanak kis darab kódokat a gyártásba.

Miután elvégeztek bármilyen funkciót, amely hozzáadott értéket képvisel, tesztelik és kiadják a világnak. Ez a technológiaépítés iteratív megközelítése.

Ahelyett, hogy hónapokba telne egy végtermék elkészítése és egy end-to-end teszt futtatása, az Agile fejlesztés lehetővé teszi a csapatok számára, hogy folyamatosan készítsenek kisebb darabokat a végtermékből, és idővel hozzáadják a termeléshez.

Ez azt jelenti, hogy a tesztelés gyorsabban megy, mivel Ön csak a legújabb kódrész kompatibilitását teszteli. Ez azt is jelenti, hogy a felhasználók és az érdekelt felek boldogabbak, mert folyamatosan megismerhetik és felhasználhatják a legújabb termékfejlesztéseket.

Vegye figyelembe mindkét megközelítést a konyha átalakításának valódi szóra. Tegyük fel, hogy az átalakítási munka jól elvégzéséhez hat hónap kell.

A Waterfall azt javasolja, hogy a vállalkozó és munkatársai építsék fel az egész konyhát, majd a hat hónap lejárta után tárják fel az ügyfél számára az egész konyhát.

Míg a munka ugyanannyi idő alatt elvégezhető, a tulajdonos sötétben marad. Az olyan egyszerű kérdések, mint például hogy megy, nagyrészt megválaszolatlanok. A legrosszabb, hogy a tulajdonosok a végsőkig nem tudják használni a konyha egyetlen részét sem.

Az Agile segítségével a vállalkozó inkább kitalálná, mit tudna elvégezni csapata néhány hetente, majd engedje meg ügyfelének, hogy lássa és használhassa, amíg átalakítják a maradékot.

Talán az első hónapban ki tudják cserélni a szekrényeket, a második hónapban a munkalapokat, a harmadik hónapra pedig új hűtőt és tűzhelyet telepítenek. Nem rossz eredmény mindkét fél számára!

A második megközelítésben a tulajdonos a konyhai részek előnyeit élvezi, mielőtt minden elkészülne. Ahelyett, hogy az új kályha csak ott ülne és port gyűjtene, valójában azonnal felhasználják, amint használhatóvá válik.

És talán a konyhatulajdonos le akar cserélni egy szekrényt egy polcra?  

A vállalkozó most legalább megtervezheti ezt a változást a hat hónap lejárta előtt, és tudatja a tulajdonosral, hogy ez hogyan befolyásolja a projekt ütemtervét.

Úgy tűnik, mindkét fél együtt tud működni és átláthatóan kommunikálni a megfelelő eredmények és munka biztosítása érdekében.

Ezek egyike az Agile számos előnyének. Mindkét fél jobban jár.

Próbálja meg tovább vinni ezt a leckét, amikor új fejlesztési készségeket tanul meg a freeCodeCamp-on, és alkalmazza készségeit projektekben.

Vegyünk néhány további példát a szoftvervilágban

Áttekintve az Agile négy alapelvét, most elkezdhetünk találni példákat az Agile alkalmazására a valós és a digitális világban.

Remélem, mostanra meglátja, hogy ezek az alapelvek közvetlenül támadják-e a vízesés folyamatát.

1. elv: Egyének és kölcsönhatások a folyamatok és az eszközök felett

Szilárd folyamat és eszközkészlet nagyon fontos az Agile számára. Az egyének és az interakciók értékelése az eszközök felett azonban több értékteremtést és outputot tesz lehetővé.

Az egyes csapattagok újíthatnak.

Ahelyett, hogy az embereket a szigorú elképzelések és előírások betartására kényszerítené, nagyobb sávszélességet adhat nekik a kísérletezéshez.

Az egyéneknek az eszközök fölé helyezésének része az új munkafolyamatokkal való kísérletezés. Az agilis szoftverfejlesztés innovációjának egyik fontos példája a kodek, egy számítógépes program, amely digitális adatfolyamot vagy jeleket kódol vagy dekódol.

A H266 / VVC kodek az adatok körülbelül felét használja a 4K videók streameléséhez. És a leghatékonyabb kódolási megoldásként ismerik el a jövőbeni 4K, sőt 4K VR valós idejű streaminghez.

Hogyan történt ez a felfedezés? Olyan emberek készítették, akik Agile-t használtak a videotömörítési problémák megoldására.

Pontosabban azért készült, mert az egyének szabadságot kaptak az építkezéshez, a teszteléshez, a kísérletezéshez és az innovációhoz egy bizonyos idő alatt. Nem mondták meg nekik, hogy a semmiből építsék fel a konyhát, és hat hónap múlva térjenek vissza.

Kis lépéseket tettek a megfelelő irányba. Ez az eredmény tanulságos.

Itt van egy második példa: amikor a Lastpass-ot a LogMeIn megvásárolta, a LogMeIn-t éppúgy érdekelte a technológia, mint a tervezési kultúrát, amelyet a Lastpass a termékek építéséhez alkalmazott.

Milyen típusú kultúra volt ez? Az egyik az Agile-t helyezte előtérbe.

Az agilis nemcsak gyorsabban hozza a termékeket a piacra, hanem értékes kreatív és szinergikus eredményeket hoz létre.

Az értékteremtés beágyazódik az Agile kultúrájába.

2. alapelv: Működő szoftver az átfogó dokumentáció fölött

Ennek mostanra nyilvánvalónak kell lennie. A részletes specifikációk és tervezés helyett csak írjon néhány működő kódot.

Próbáld ki. Kérjen visszajelzést róla. Szállítja azt.

Ezután csináld újra.

Ismétlés.

Ennek az ismétlési folyamatnak nagyon releváns példája található a Forms on Fire-ban.

Szoftvert hoztak létre a mobil adatgyűjtés megkönnyítése érdekében. Az indulás előtt nem írták meg az egész társaságukat; írtak néhány sort kódot, tesztelték és elküldték.

Amint lendületet kaptak, felgyorsították tesztelésüket és iteratív lépéseiket.

És megismételték, ami működött, és dobták, ami nem. Az eredmények önmagukért beszélnek.

3. elv: Ügyfél-együttműködés a szerződés-tárgyalás során

Az Agile elősegíti a gyors visszacsatolási ciklust az ügyfelek és az érdekeltek visszajelzésének megszerzése érdekében.

Mi lehet jobb, mint hátrafelé dolgozni, amit a valódi felhasználók és vásárlók szeretnének?

Van egy üzleti mentorom, aki azt tanácsolta, hogy ahelyett, hogy végtelen tervezéssel túlértékelné, mit akarnak az ügyfelek, csak egyszerűen tartsa egyszerű. - A zavaró tényezők enyhítése - mondta.

A KISS elvéről írtam a freeCodeCamp-ben, és ez a tanács minden bizonnyal igaz az Agile esetében: készítsen valami apróságot, és nézze meg, tetszik-e az ügyfeleinek.

Ha mégis, folytassa.

4. alapelv: Válasz a terv követésére történő áttérésre

A gyors visszacsatolási ciklusok gyors változásokat és kiigazításokat eredményeznek. Ez teszi az Agile-t olyan nagyszerűvé a fejlesztő csapatok számára.

Ezért kell magáévá tenni.

Az ütemtervek mindig változnak, ez egy ismert állandóság. Az agilis módszertanok alkalmazásával a csapatok az ügyfelek visszajelzéseinek meghallgatásával és a szükséges kiigazításokkal reagálhatnak a változásokra.

Vannak esetek, amikor a változásra való reagálás a termék kiigazítását vagy a felhasználókról vagy a versenyről alkotott véleményének megváltoztatását jelenti.

Klasszikus példa, amelyet az agilis hallgatók megnézhetnek az e-kereskedelmi térben, az Amazonon értékesít. Hogyan alkalmazkodik gyorsan a versenyhez? Az egyik módja a zárt közösségek felépítése, vagy különböző termékindítási stratégiák kipróbálása.

Tanácsos taktikai és alakítható megoldások bevezetése.

Van egy csodálatos közmondás: „Nem változtathatjuk meg a szél irányát. Csak a vitorlánkat tudjuk beállítani. ”

Ha Agile-re gondolok, akkor erre a mondásra gondolok.

Az agilis a tanulás, az agilis a tanítás. Az agilis a rugalmasságról szól.

Gyakorolhatja az Agile-t mindennapi munkájában, vagy online tanfolyamokon vehet részt a továbbfejlesztés érdekében.

Vannak, akik elég okosak ahhoz, hogy megjósolják, mit akarnak az ügyfelek. Tudják, melyik irányba fúj a szél.

De számunkra, halandók számára az Agile egy módszertan arra, hogy eligazodjunk az ügyfelek által megértett hiányosságainkban.

A rendszer az, amely lehetővé teszi, hogy folyamatosan beállítsuk vitorláinkat.