Z blogchainu: 5 ideálov, ako ich pomenoval a definoval Gene Kim v knihe The Unicorn Project.
Jeden môj kamoš zvykol používať svojho času takúto hlášku:
To je nadlho a komplikované.
To bola univerzálna odpoveď, keď on sám nevidel východisko zo situácie, v ktorej sa nachádzal, alebo práve naopak, z jednoduchej situácie (problému) urobil z komára somára.
Vieš aký je rozdiel medzi komplikovanýcm a komplexným? Komplexné je porozumiteľné, i keď je zložené z viacerých úrovni (vrstiev). Komplikované je už horšie porozumiteľné, lebo vzájomné pôsobenie prvkov systému nie je možné jednoducho alebo v rozumnom čase rozlíšiť.
❓Koľko ľudí je potrebných zapojiť do procesu realizácie zmeny softvérového riešenia?
❓Máš pocit úzkosti, keď má byť nasadená zmena v softvérovom riešení?
Ideál jednoduchosti ma za cieľ pripomínať, že sme si niektoré pracovné postupy prekomplikovali (organizačná komplikovanosť). Že naše technické riešenia majú vysoký technický dlh, a keď v nich chceme spraviť zmenu, tak to bolí, alebo to vlastne už ani nie je možné (technická komplikovanosť).
Ak riešenia navrhujeme jednoducho, táto jednoduchosť podporuje lokálnosť.
Lokálnosť?! Lokálnosť znamená, že nepotrebuješ pre vykonanie rozhodnutia n povolení, alebo pripojiť tu telekonferencii 5 achitektov a analytikov, aby sa v konečnom dôsledku vyjadrili, ako sa to nedá, alebo len s veľkými obtiažami.
if a team couldn’t be fed with two pizzas, it was too big.
Jeff Bezos
Aplikácia jednoduchosti a lokálnosti po organizačnej stránke je napríklad pravidlo tzv. 2 pizza tím - stačia ti dve pizze, aby si nasýtil tím ľudí, ktorý by mal vedieť problémy a výzvy samostatne riešiť? Ak nie, tak tvoj tím je pravdepodobne príliš veľký, aby fungoval efektívne.
Aplikáciou jednoduchosti po technickej stránke je napríklad princíp jednej zodpovednosti a voľných väzieb. Majestátny monolit má svoje miesto v sieni slávy vývoja softvérových riešení. O tom inokedy. Je však potrebné si
na pomyselnej škále od monolitu až po microservices architektúru na každú malú IT capabilitu, klásť opakovane otázky:
- nepreháňam to už s prípravou na potencionálne škálovanie?
alebo opačne - netlačím kopec funkcionality do jednej megaaplikácie (monolitu), ktorá by si už zaslúžili, aby bola vytiahnuté do samostatnej služby?
Koľko dní, týždňov, mesiacov ubehne od iniciálnej myšlienky na zmenu až po jej nasadenie do prevádzky? (flow time) Ak je tento čas neprimerane dlhý, tak výsledkom je strata príležitosti šetriť, alebo zarábať (cost of delay), alebo sa jednoducho rýchlo niečo naučiť (objaviť, dozvedieť), frustrácia z nevyhnutnej potreby prepínať kontext (tu čakám, tak idem zatiaľ na iné zadanie).
Treba si neustále pripomínať, či si organizačne nehádžeme polená pod nohy (treba chodiť cez 5 úrovní, aby bolo možné zmenu/vylepšenie nasadiť, uvedomenie si hodnoty pre zákazníka). Či sa po technickej stránke neprichytíme v stave úzkosti, že plánovanou zmenou sa rozbije nejaká neznáma vnútorná závislosť (ktorá z tej spleti kódu nie je jasná).
Inak povedané, môžeš aplikovať dve základné pravidla:
- snažiť sa potreby pokrývať jednoduchšími riešeniami. Skôr sa snažiť uberať/prerobiť to čo už mám, ako pridávať nové a ligotavé (ktoré sa po nasadení do života okamžite stáva novým "bohatým" dedičstvom - legacy)
- snažiť sa zachovať môžnosť rozhodnúť sa lokálne (mať zodpovednosť a rozhodovaciu právomoc od nadriadeného, pýtať sa, čo na kom som závislý a prečo, vedome tvoriť menšie tímy)