Mit jelent az Agilis szoftverfejlesztés?

Az agilis kifejezés a szoftverfejlesztés olyan megközelítéseit ismerteti, amelyek a növekményes teljesítést, a csapatmunkát, a folyamatos tervezést és a folyamatos tanulást hangsúlyozzák. Az Agile kifejezést 2001-ben alkották meg az Agile Manifesto-ban. A kiáltvány a szoftverfejlesztés jobb megközelítését segítő alapelvek kialakítását irányozza elő. A kiáltvány középpontjában négy értékkimutatás áll, amelyek az Agile-mozgalom alapjait képviselik. Ahogy megírtuk, a kiáltvány a következőt állítja:

A következő értékre jutottunk:

• Az egyének és az interakciók a folyamatok és az eszközök felett.
• A szoftverek átfogó dokumentáción keresztüli használata.
• Ügyfél-együttműködés a szerződéstárgyalások során.
• A változásokra való reagálást helyezzük előtérbe a terv követésével szemben.

A kiáltvány nem azt jelenti, hogy az utasítások jobb oldalán lévő elemek nem fontosak vagy szükségesek. A bal oldali elemek inkább értékesebbek.

Agilis módszerek és eljárások

Fontos megérteni, hogy az Agilis nem egy dolog. Nem csinálod az Agile-t. Az Agile inkább egy olyan gondolkodásmód, amely a szoftverfejlesztés megközelítését vezérli. Mivel nincs egyetlen megközelítés, amely minden helyzetben működik, az Agile kifejezés különböző módszereket és gyakorlatokat jelent, amelyek összhangban vannak a kiáltványban szereplő érték-állításokkal.

Az agilis módszerek, amelyeket gyakran keretrendszereknek neveznek, a DevOps-életciklus fázisainak átfogó megközelítései: tervezés, fejlesztés, teljesítés és műveletek. Egyértelmű útmutatással és alapelvekkel írják elő a munka elvégzésének módszerét.

A Scrum a leggyakoribb Agile-keretrendszer, és a legtöbb ember által használt keretrendszer. Az agilis eljárások viszont olyan technikák, amelyeket a szoftverfejlesztési életciklus fázisai során alkalmaznak.

• A Póker megtervezése egy együttműködési becslési gyakorlat, amelynek célja, hogy ösztönözze a csapattagokat, hogy megoszthassák tudásukat a megtett eszközökről . Sokan szórakoztatónak találják a folyamatot, és bebizonyosodott, hogy elősegítik a csapatmunkát és a jobb becsléseket.
• A folyamatos integráció (CI) egy gyakori agilis mérnöki gyakorlat, amely magában foglalja a kódmódosítások gyakori integrálását a fő ágba. Az automatizált buildek ellenőrzik a változásokat. Ennek eredményeképpen csökken az integrációs adósság és a folyamatosan szállítható főág.

Ezek a gyakorlatok, mint minden Agile-gyakorlat, az Agile címkét hordozzák, mivel összhangban vannak az Agile-kiáltvány alapelveivel.

Mi az Agile nem

Ahogy az Agile egyre népszerűbb, számos sztereotípia és félreértelmezés negatív árnyékot vet a hatékonyságára. Könnyű kimondani, hogy "Igen, agilisak vagyunk", elszámoltathatóság nélkül. Tartsa szem előtt ezt a pontot, fontolja meg néhány dolgot, hogy Agile nem.

• Az agilis nem cowboy kódolás. Az Agilist nem szabad összekeverni a szoftverfejlesztés "mi fogjuk kitalálni, ahogy haladunk" megközelítéssel. Egy ilyen ötlet nem lehet messzebb az igazságtól. Az Agile megköveteli a kész és explicit érték definícióját is, amelyet minden futamban az ügyfeleknek kézbesítenek. Míg az Agile az egyének és a csapatok autonómiáját értékeli, az összehangolt autonómia hangsúlyozása annak biztosítása érdekében, hogy a megnövekedett autonómia nagyobb értéket teremtsen.
• Az agilis nincs szigorúság és tervezés nélkül. Éppen ellenkezőleg, az agilis módszertanok és gyakorlatok általában a tervezés szemléletét hangsúlyozzák. A kulcs a folyamatos tervezés a projekt során, nem csak előre megtervezve. A folyamatos tervezés biztosítja, hogy a csapat tanuljon az általuk végrehajtott munkából. Ezzel a megközelítéssel maximalizálják a tervezés megtérülését (ROI).

"A tervek értéktelenek, de a tervezés minden." – Dwight D. Eisenhower

• Az agilis nem ürügy az ütemterv hiányára. Ez a tévhit valószínűleg a legnagyobb kárt az Agilis mozgalom összességében. Az Agilis megközelítést követő szervezetek és csapatok teljesen tudják, hogy hová mennek, és milyen eredményeket szeretnének elérni. A változás felismerése a folyamat részeként eltér attól, hogy minden héten, futamban vagy hónapban új irányban forduljon.
• Az Agilis nem fejlesztés specifikációk nélkül. Minden projektben szükség van arra, hogy a csapat igazodjon a munka okához és működéséhez . A specifikációk agilis megközelítése magában foglalja annak biztosítását, hogy a specifikációk megfelelő méretűek legyenek, és hogy megfelelően tükrözzék a csapat szekvenciáinak működését és működését.
• Az agilis nem képes alkalmazkodni a nem tervezett munkához és egyéb megszakításokhoz. Fontos, hogy a futamok ütemezés szerint befejeződjenek. De csak azért, mert egy probléma merül fel, hogy az oldalsávok fejlesztése nem jelenti azt, hogy egy futamnak sikertelennek kell megjelennie. A Teams úgy tervezhet megszakításokat, hogy előre megtervezi az erőforrásokat a problémák és váratlan problémák esetén. Ezután meg tudják oldani ezeket a problémákat, de a fejlesztéssel kapcsolatban továbbra is jó úton haladnak.
• Az agilis nem megfelelő a nagy szervezetek számára. Gyakori panasz, hogy az együttműködés, az Agilis módszertanok kulcsfontosságú összetevője, nehéz a nagy csapatokban. Egy másik megközelítés, hogy az Agile skálázható megközelítései olyan struktúrát és módszereket vezetnek be, amelyek rontják a rugalmasságot. Ezeknek a tévhiteknek ellenére az Agile-alapelveket sikeresen skálázhatja. A nehézségek leküzdéséről további információt az Agile nagy csapatokra való méretezése című témakörben talál.
• Az agilis nem hatékony. Az ügyfelek változó igényeihez való alkalmazkodás érdekében a fejlesztők minden iterációban időt fektetnek egy működő termék bemutatására és visszajelzések gyűjtésére. Igaz, hogy ezek az erőfeszítések csökkentik a fejlesztésre fordított időt. Az ügyfélkérések korai beépítése azonban később jelentős időt takarít meg. Ha a funkciók igazodnak az ügyfél elképzeléséhez, a fejlesztők elkerülik a nagyobb átalakításokat.
• Az Agilis nem megfelelő a mai alkalmazásokhoz, amelyek gyakran az adatstreamelésre összpontosítanak. Az ilyen projektek általában több adatmodellezést és ETL-terhelést (ETL) igényelnek, mint a felhasználói felületek. Ez a tény megnehezíti a használható szoftverek konzisztens, szoros ütemezésű bemutatását. A célok módosításával azonban a fejlesztők továbbra is használhatják az Agilis megközelítést. Ahelyett, hogy az egyes iterációk feladatain dolgoznak, a fejlesztők az adatkísérletek futtatására összpontosíthatnak. Ahelyett, hogy néhány hetente bemutatnának egy működő terméket, az adatok jobb megértésére törekedhetnek.

Miért az Agile?

Akkor miért gondolna bárki is agilis megközelítésre? Egyértelmű, hogy a szoftverfejlesztésre vonatkozó előjegyzési szabályok alapvetően megváltoztak az elmúlt 10-15 évben. Sok tevékenység hasonlónak tűnik, de az a táj és környezet, ahol alkalmazzuk őket, észrevehetően eltérnek.

• Hasonlítsa össze a mai szoftverek vásárlásának módját a 2000-es évek elejével. Milyen gyakran vezetnek az emberek a boltba, hogy üzleti szoftvereket vásároljanak?
• Gondolja át, hogyan gyűjtenek visszajelzést az ügyfelek a termékekről. Hogyan értette meg a csapat, hogy mit gondolnak az emberek a szoftverükről a közösségi média előtt?
• Gondolja át, hogy a csapat milyen gyakran szeretné frissíteni és fejleszteni az általuk szolgáltatott szoftvereket. Az éves frissítések már nem valósíthatóak meg a modern verseny ellen.

Forrester Diego Lo Guidice azt mondja, hogy a legjobb az ő blogja, Átalakítása Application Delivery (október, 2020).

"Minden drámaian megváltozott. A fenntarthatóság, a zöld és a tiszta mellett azt jelenti, hogy amit ma építünk, azt holnap könnyen és gyorsan meg kell változtatni. A stratégiai tervek rövid távúak, a tervezés és a változás pedig folyamatos." – Diego Lo Guidice, Forrester

A szabályok megváltoztak, és a szervezetek világszerte ennek megfelelően igazítják a szoftverfejlesztéshez való hozzáállásukat. Az agilis módszerek és eljárások nem ígérik, hogy minden problémát megoldanak. De ígéretet tesznek arra, hogy létrehoznak egy kultúrát és környezetet, ahol a megoldások együttműködésen, folyamatos tervezésen és tanuláson keresztül jelennek meg, és arra törekszenek, hogy minél gyakrabban küldjenek kiváló minőségű szoftvereket.

Következő lépések

Ha úgy dönt, hogy az Agilis útvonalat választja a szoftverfejlesztéshez, érdekes lehetőségeket kínálhat a DevOps-folyamat fejlesztésére. Az egyik legfontosabb szempontcsoport arra összpontosít, hogy az Agilis fejlesztés hogyan hasonlítja össze és hasonlítja össze a szervezet jelenlegi megközelítését.