Akceptácia softvéru nie je zadarmo, stojí nezanedbateľnú mentálnu energiu tých, ktorí sa podpíšu pod to, že to čo im bolo (veľa krát za nemálo peňazí) dodané, funguje dľa očakávaní. Rovnako ako nemálo energie stojí to, aby biznis (prípadne dedikovaný biznis analytik), efektívne popísal (nadesignovať) požiadavku.
Čím väčší (zásadnejší) kus funkcionality sa akceptuje, tým väčší prirodzený odpor k tomu, aby som sa do danej úlohy ponoril. Takáto úloha vyžaduje moje plné nasadenie (hlbokú prácu). Vyčleniť si blok nerušeného času pre konečných užívateľov softvéru, ktorí sú zavalení svojou bežnou operatívnou prácou, je problém. Keď si idem kúpiť rožok do Tesca, tak nad tým nepremýšľam tak, ako keď chcem kúpiť nové auto, alebo nehnuteľnosť. (I keď mne niekedy pripadá, že niektorí realitní agenti sa tvária, ako keby nehnuteľnosť bol rožok 😄).
👍 ⬆️ Testovacie scenáre na (vopred popísané) akceptačné kritéria, sú pomocníkom, ktorý tento dôležitý úkon pomáhajú procesne pokryť. Tým chcem povedať, že podstatná časť problémov spojených s akceptáciou, sa môže riešiť ešte v čase, keď nemám na stole riešenie, ktoré mám odakceptovať v stanovenom časovom okne. Viď priepasť na grafe.
👎 ⬇️ Ak na nasádzanie softvéru do užívania existujú vopred stanovené "okná" a sú málo časté (každý štvrťrok), to rovnako vytvára nepriamy tlak, lebo za chybu v akceptácii bude veľký trest, pretože ďalšia možnosť opravy nebude okamžitá (možná až o ďalší štvrťrok).
Ako urobiť z akceptácie prechádzku ružovou záhradou?
- minimalizovať čas medzi definiciou (finálnym zarámcovaním požiadavky) a jej akceptáciou - keď mám niečo čerstvo na pamäti, ľahšie sa mi k tomu vracia
- minimalizovať rozsah zmeny, ktorá však má stále biznis hodnotu - jednoduchšie akceptovať menšiu zmenu, ako 10 zmien, ktoré tvoria megazmenu
- ideálne (už) pri zadaní požiadavky, ako súčasť zadania identifikovať (testovacie) scenáre, ktoré sú zároveň aj pomôckou pre vývojára, aby získal širší kontext
- preniesť časť zodpovednosti za testovanie aj na vývoj - formou automatického testovania (nie však triviality ako unit testing)
- skracovať čas a zjednodušovať proces okolo nasádzania zmien na produkčné prostredie (continuous delivery/continuous integration, využívanie feature flags)
- hľadať a podporovať motivácie členov projektového tímu preberať zodpovednosť
- hľadať a pochopiť, čo bráni vlastníkom požiadavky danú zmeny odakceptovať
- zdokumentovať (jednoduchý popis plus diagram) proces od vzniku požiadavky až po jej akceptáciu so zodpovednostami a kompetenciami
Tvorba biznisových požiadaviek nie je výhradná jednej roli - biznis analytik, alebo produktový vlastník (aby nevznikalo úzke hrdlo). Biznisovú požiadavku vie napísať každý. A tento každý by mal mať aj toľko motivácie, aby bol schopný si to, o čo si žiadal, aj odakceptovať. Alebo identifikovať to, čo mu v tom bráni, kedže tento úkon nie je zadarmo. Projektový manažér (ako prostredník v tomto celom) má hľadať nástroje, pomôcky, aby boli schopní majitelia požiadaviek tú akceptáciu urobiť. Identifikovať v čom majú problém s tým, aby to odakceptovali (čo im bráni, čoho sa boja).