neděle 28. února 2016

Požadavky na požadavky

Primárním cílem každého software je řešit problémy zákazníka nebo své cílové skupiny. Řešení je popsáno specifikací požadavků na systém. Psát dobré požadavky a efektivně je spravovat není snadné. Vyžaduje to specifické dovednosti a spolupráci napříč celým týmem. Dobrá specifikace je ale stejně důležitá jako dobrý zdrojový kód.

Pojďme se společně podívat, jaké problémy nám mohou komplikovat práci s požadavky.

Tohle není můj problém

Programátor: “Od analytiků dostáváme hrozné zadání. Jak podle toho máme něco naprogramovat!?”

Analytik: “Vykomunikoval jsem to se zákazníkem, popsal hlavní ideu, navrhl postup a tím to pro mě končí. Programátoři ale chtějí, abych za ně promýšlel problém do úplných detailů. To je jejich práce. Na to nemám čas.”

Pokud mají dvě skupiny v naší firmě potřebu se vzájemně vyhraňovat, máme dost závažný problém. Týmové role nespolupracují efektivně. Chtějí si nadefinovat rigidní rozhraní místo snahy o spolupráci na nejlepším výsledku. Agilita je o společné zodpovědnosti za vše, co s vyvíjeným software souvisí. Včetně požadavků. Odolejme pokušení sortovat na ty, co dělají zadání a na ty, co podle zadání dělají konstrukci. Jsme jeden tým. Pokud můžeme, posaďme zákazníka, analytika, programátora, testera a další lidi do jedné kanceláře. Nebo je propojme nějakým efektivním komunikačním kanálem. Potřebujeme dobrou komunikaci, rychlou zpětnou vazbu a rychlé zapracování změn.

Zrovna dodělávám kompletní specifikaci

Projektový manažer: “Výborně Karle, ta specifikace vypadá neprůstřelně, teď to necháme kluky naestimovat a můžeme podepsat smlouvu.”

Pokusy vytvořit kompletní specifikaci ještě před konstrukcí (up-front) možná fungují u malých věcí nebo u opakujících se podobných projektů. Často ale ani tam. U větších věcí s vysokým stupněm inovace a nejistoty jsou ale podobné ambice tvrdě trestány. Navýšením nákladů a frustrací ze zbytečné práce, kterou musíme často zahodit. Rigidní vodopádová snaha zakonzervovat požadavky je často naivní obranou proti neschopnosti efektivně provádět změny během konstrukce. A nebo je důsledkem striktní smlouvy o dílo, kde zákazník raději vsadí na jistotu “dodání funkcionality v požadovaném rozsahu”.

Buďme připraveni na změnu. Mějme na paměti celek, ale rozdělujme na podproblémy. Specifikujme vysokoúrovňové business požadavky. Analyzujme je podle priority a rozpracujme do podrobnějších produktových požadavků ve formě user stories. Prioritizované user stories nám vytvoří produktový backlog. User story ale zatím není zadání, na které čeká programátor. Je to pouze placeholder pro následnou detailní specifikaci.

Když se na user story dostane řada, začíná její detailnější analýza a definice požadavků. Očekávanými výsledky jsou popis chování systému (use cases), upřesnění UI (mock-ups) a nefunkcionální specifikace. Analytik analyzuje problém a navrhuje řešení v úzké spolupráci se zadavatelem. Využívá znalostí a spolupráce dalších rolí v týmu. V případě rizik, omezené znalosti technologií nebo možnosti více konceptů, je prováděno rychlé prototypování. Ty nejrizikovější věci by měly být odprototypovány na začátku projektu.

Dobrou praktikou je vytvoření test cases ještě před vlastní konstrukcí. V této fázi mohou test cases odhalit závažné nedostatky ve specifikaci požadavků a ušetřit tak spoustu peněz v případě pokračování špatným směrem. Pokud tester není schopen napsat kompletní a jednoznačné testovací případy, zřejmě ani programátor nebude schopen efektivní implementace. Zkušený tester prokoukne nedefinované alternativní větve, chybějící podmínky nebo neošetřené chybové stavy. Často jsou v detailech ukryta závažná projektový rizika.

Nevíte někdo, jak to funguje?

Analytik: “Omlouvám se za hromadný email na všechny lidi ve firmě, ale nemůžu najít specifikaci business pravidel pro XY. Poradí mi někdo, prosím?”

Odpověď A: “Aleši, to by mě taky zajímalo, až to zjistíš, dej mně prosím vědět.”

Odpověď B: “Zkus složku SpecABC, jsou tam nějaké staré wordy. Kdyby to nebylo tam, tak něco možná bude na naší wiki. Jinak dělal to Lojza a ten už ve firmě není. Jak asi víš, z těch přesčasů mu nakonec hráblo. Pokud to nenajdeš, budeš to muset pochopit z kódu. Ale to ti fakt nezávidím. :)”

Na začátku každého projektu vše vypadá krásně a růžově. Lidé jsou nadšení. Všichni zúčastnění vědí o projektu téměř všechno. Nějaká specifikace možná existuje, ale její správě a aktualizaci se často nevěnuje příliš velká pozornost. Požadovaná funkcionalita se dodává rychle, všechno klape a management se poplácává po zádech. Všichni jsou happy.

Projekt roste, vyvíjí se, nová funkcionalita přibývá a stávající se mění, noví lidé přicházejí, původní odcházejí. Je nutná specializace, komplexita systému je už příliš vysoká. Začínají se zvyšovat náklady na správu všech projektových artefaktů. Kde máme aktuální informace? Co všechno se musí upravit kvůli novému požadavku? Jaká jsou rizika? Co vlastně máme před releasem otestovat?

Špatné nakládání se specifikací systému je jednou z nejrizikovějších forem softwarového technického dluhu. Členové týmu zdlouhavě dohledávají informace, dělají špatná rozhodnutí na základě nesprávných informací, vznikají duplicity, zvyšuje se chybovost, management je pod tlakem a přehazuje lidi podle toho, kde to nejvíce hoří. Lidé nemají možnost dělat práci kvalitně a proto frustrovaně odcházejí. Někdy může situaci dospět až k tomu, že údržba projektu je tak drahá, že se už dále nevyplácí a projekt je ukončen. Poslední ať zhasne.

Začněme správu požadavků řešit co nejdříve. Celý proces musí být co nejefektivnější a nejjednodušší. Složité postupy nefungují. Zde je přehled Requirement Management Software. Pokud máte s nějakým systémem větší zkušenost a můžete jej doporučit, přidejte prosím komentář.

Výkonný systém s intuitivním UI

Programátor: Arnošt mi zase poslal zadání, ve kterém píše “vytvořit dostatečně výkonný modul s intuitivním ovládáním, podobný tomu z loňska, ale upravený pro letošní administrativu”. Jdu ho intuitivním způsobem poslat k šípku, podobně jako loni.

Jak psát efektivně požadavky je popsáno v Writing Quality Requirements. Je to už sice hodně vousatý článek, ale přehledně shrnuje to nejdůležitější. Čemu se máme vyvarovat a na co se zaměřit. Jedná se o povinné čtení pro všechny vývojáře software.

Podobně jako jsme zvyklí revidovat kód, abychom našli problémy a sdíleli znalosti o implementaci, můžeme revidovat i požadavky. Analytik musí vysvětlit své chápání problému a důvody proč navrhl toto řešení. Pár tipů na review najdete v How to Conduct a Requirements Review.

Dobrý business analytik je vyladěnou kombinací doménových znalostí a analytických dovedností, viz. např. What Business Analyst Skills are Important. Ty je potřeba neustále procvičovat a vylepšovat. Jak rozvíjíte BA ve vašem týmu?

Shrnutí

Dobře definované požadavky na systém jsou prvním zásadním krokem pro kvalitní výsledek snažení celého týmu. Nesnažme se však všechno vymyslet a popsat hned na začátku. Riziko špatné specifikace je příliš vysoké. Změny pak budou bolet mnohem víc než při postupném iterativním vývoji.

Chápejme proces specifikace systému jako spolupráci celého týmu. Nechtějme programátory-opičky, kteří dostanou přesné zadání a jen klepou. To nefunguje. Chceme myslící bytosti, s určitou znalostí domény, aktivně zapojené do procesu vytváření software.

Specifikace je živá interaktivní dokumentace, která se musí efektivně udržovat po celou dobu života projektu. Úroky za macešský přístup k požadavkům jsou totiž příliš vysoké.

Podělíte se s námi o to, jak se daří spravovat požadavky u Vašeho projektu? Díky.