Top témy

Agile pragmaticky (časť 3) – Softvér nepíšu stroje, ale ľudia

V druhej časti Agile pragmaticky - Best practicies, som sa venoval praktikám, ktoré nám v PosAm pomáhajú uchopiť realitu, často vzdialenú od ideálneho stavu z literatúry. Komplexita nemusí mať rozmer iba technologickej či doménovej zložitosti, ale môže ju spôsobiť aj problém veľkosti systému v kontexte veľkosti teamu a o tom viac dnes.

V druhej časti som sa venoval praktikám, ktoré nám pomáhajú uchopiť realitu, často vzdialenú od ideálneho stavu z literatúry. Ukázal som, že k príprave prioritizovaného backlogu často nestačí prístup k doménovému expertovi, a vtedy si vyžaduje svoj čas. Táto fáza sa u nás nazýva HLD a jej cieľom je nielen backlog, ale aj spoločná vízia riešenia. Z hľadiska vecnej problematiky sa snažíme uzavrieť príbuzné témy do samostatných modulov z využitím techniky DDD (domain driven design), aby sme umožnili izolovať prípadné zmeny. Aby sme dosiahli naplánované ciele, využívame čo najviac spätnú väzbu formou „walking skeletonu“ a Konceptu Definition of done. Komplexita nemusí mať rozmer iba technologickej či doménovej zložitosti, ale môže ju spôsobiť aj problém veľkosti systému v kontexte veľkosti teamu a o tom viac dnes.

Dôležitosť proaktívnej komunikácie pre udržanie spoločného cieľa

Čím väčší projekt, tým je dôležitejšie komunikovať. A komunikovať nielen na začiatku, ale aj počas projektu. Nielen v teame, ale aj medzi teamami navzájom. Ideálna veľkosť agilného tímu je 7+/-2. Veľké enterprise projekty bez problémov túto hranicu prekročia. Agilné fungovanie v takomto prípade sa nezaobíde bez paralelnej práce viacero tímov. Túto podporujeme najmä zvýšením dôrazu na „ceremónie“ v oblasti plánovania, vzájomnej komunikácie a integrácie - nastupuje úloha scalingu agile.

Scaling dosahujeme vytvorením governance modelu postavenom na dekompozícii dodávky na sub-oblasti, ktorým hovoríme funkčné celky. Za funkčný celok je zodpovedný príslušný tím vedený teamleadrom, ktorý preberá vlastnícku zodpovednosť nad svojou oblasťou.

PosAm sa nám osvedčil model core teamu zloženého z teamleadrov, ktorí spoločne so solution architektom definovali HLD a naďalej zodpovedajú za dodržiavanie vzájomných závislostí na rozhraniach sub-oblastí (API kontrakty, technologické predpoklady, ...).

Komunikáciu medzi teamleadrami nie je možné obmedziť iba na prípravnú fázu HLD, ale treba ju podporovať aj počas implementačných sprintov alebo plánovaných releasov. Teamy musia medzi sebou zdieľať informácie o zmenách, aby sa na ne vedeli adaptovať a rozumieť ich dopadom.

Ideálnym miestom pre tieto dohody je release planning stretnutie pred spustením nového releasu systému, ktoré môže kľudne trvať pár hodín, ale aj niekoľko dní (ak pripravujeme postupový release na zelenej lúke alebo veľkú zmenu v rozsahu 2-3 team mesiacov do veľkého existujúceho systému). Netreba sa obávať, že plánovanie je niečo zlé. Bez neho a bez rozumného stupňa formalizmu v zachytávaní dohôd, môže dôjsť k zbytočným finančným a časovým stratám. Toto neznamená, že plán sa nemení, práve naopak. Jeho najväčší význam nie je v jeho záväznosti, ale je v jeho schopnosti komunikovať ciele a ich vzájomné závislosti v čase.

Agilný organizačný design ako nástroj delegovania zodpovednosti

Agile so sebou prináša aj väčší pocit vlastníctva. Nie je to len v osobe teamleadra (scrummastra), ktorý nesie aj formálnu zodpovednosť za funkčný celok, ale je to aj v nastavení motivácie celého tímu. Čo nám dávajú techniky agile naviac, je väčšia transparentnosť informácie o stave úloh. Toto vedie k lepšej komunikácii medzi členmi tímu a rýchlejšej akcii, ak treba niekomu s niečím pomôcť.

Výkonnosť tímu sa v PosAm snažíme posilňovať aj vytvorením stabilných jadier tímov, ktoré zostávajú spolu na projektoch dlhodobo. Toto je v podmienkach firmy poskytujúcej služby v oblasti custom vývoja náročné, ale dáva to lepšie predpoklady pre transfer znalostí a podporuje nastavenie „mindsetu“ v duchu Pinkovskej motivačnej teórie o Autonómii, Dosahovaní majstrovstva a Vnímaní poslania svojej práce.

Miesto DevOps pri agilnej dodávke riešenia na mieru

Projekty, ktoré PosAm realizuje, väčšinou na konci preberá prevádzka zákazníka a my zabezpečujeme tretiu úroveň podpory. Preto zavádzanie DevOps (spájanie vývojárov a špecialistov prevádzky) v pôvodnom význame pojmu nemá pre nás zmysel. V našich projektoch chápeme ako Ops našich administrátorov midlleware technológií, na ktorých bude softvérové riešenie prevádzkované. V minulosti takýto špecialista prichádzal na projekt na dobu určitú a potom odchádzal. Dnes sa ho snažíme urobiť viac-profesným a využiť priebežne najmä v oblasti automatizácie deploymentu a konfiguračného managementu. Chceme tým dosiahnuť čo najviac automatizovanú podobu procesu nasadzovania, monitorovania a logovania. Toto dáva tímu väčšiu súdržnosť pri riešení prípadných technických incidentov na rozhraní softvérového diela a infraštruktúry. Zaujímavým dôsledkom je vyšší stupeň automatizácie činností na projekte, jednoduchšie odovzdanie do prevádzky a lepšie pokrytie monitoringom.

Na záver ...

Vôbec nechcem zakončiť tento príspevok hodnotením, kde v PosAm v adopcii agile práve sme. Zaviedli sme mnohé prvky, ale staviame sa k tejto téme pragmaticky. Snažíme sa prevziať čo funguje, ale nezavrhnúť ani staré známe pravdy, ktoré platia nezávisle od názvu, ktorý metóda riadenia vývoja práve nesie.

Článok na stiahnutie

Čomu som sa venoval v predchádzajúcich častiach:

Agile pragmaticky (časť 1) - Zmena paradigmy

Agile pragmaticky (časť 2) - Best practices, alebo aplikácia agile v praxi

Zdieľajte

späť hore

Kontakt

hladky peterPeter Hladký

Riaditeľ vývoja softvéru peter.hladky@posam.sk