Historické souvislosti, vznik a obsah Agilního manifestu

Minulý týden jsme v článku na serveru Živě poznali principy agilních metodologií vývoje softwaru. V tomto článku budeme pokračovat popisem vývoje a obsahu základního pilíře agilního přístupu – tzv. Manifestu agilního vývoje softwaru (The Agile Manifesto). Manifest obsahuje třináct bodů, které podrobně vysvětlují principy agilního programování. Proč však vznikl? Na co reaguje? O čem hovoří?
Jak bylo naznačeno již v minulém článku na toto téma, historie agilního hnutí je velmi mladá: sahá jen do roku 2001. V únoru roku 2001 se sešlo v půvabné krajině horského lyžařského střediska Snowbird v americkém státě Utah sedmnáct lidí – představitelů a zastánců netradičního přístupu k vývoji.

Zneuznaní programátoři?

Mezi přítomnými bylo mnoho známých tváří a významných osob, určitě vám něco říkají např. jména Alistar Cockburn, Kent Beck, Ward Cunningham, Martin Fowler, Ken Schwaber nebo Jeff Sutherland.

Začnete-li pátrat po předchozích pracovních zkušenostech zúčastněných osob, záhy zjistíte, že v jejich životopisech je cosi společného:

  • pracovali zpravidla postupně v několika vývojových týmech, počínaje menšími až k velkým kolosům;
  • obvykle zažili krach několika projektů;
  • obvykle neměli ze své práce patřičně dobrý pocit, o radosti ani nemluvě;
  • obvykle se pokoušeli vážně zamyslet nad tím, co způsobilo výše uvedené neúspěchy;
  • a obvykle patří ve světě programování k uznávaným odborníkům a ke špičkovým vývojářům.

Shromážděné osoby však mají společnou ještě jednu věc: už předtím, než se v únoru 2001 společně sešli v americkém Utahu, pracovali mnozí z nich na návrhu nové metodologie (nebo chcete-li, nového přístupu k programování). Na svých metodologiích pracovali nezávisle, avšak částečně o své činnosti navzájem věděli a začali zjišťovat, že ač se jejich výtvory v mnoha aspektech liší, obsahují zároveň překvapivé množství společných principů.

Překvapili sebe sama

Na jejich setkání se tedy stalo, co se muselo stát. Cimrman by situaci možná komentoval slovy „navzájem si pochválili svá vlastní díla“, nicméně skutečností zůstává, že po podrobné analýze jednotlivých metodologiích se účastníci překvapivě snadno shodli na základních zastřešujících tezích, z nichž posléze vzešla formulace Manifestu.

Alistar Cockburn se před setkáním například obával přílišné roztříštěnosti názorů a neočekával, že by se skupina takto reformních lidí mohla shodnout na konkrétních společných závěrech. Po skončení akce byl pak sám příjemně překvapen výsledkem: „Pokud jde o mě, jsem potěšen konečnou formulací Manifestu. Byl jsem také překvapen, že ostatní jevili stejné potěšení. Znamená to, že jsme se shodli na něčem podstatném.“

Jsou to nepodložené výplody?

Proč to všechno zdůrazňuji? Rád bych čtenářům ukázal, že i když můžeme o jednotlivých myšlenkách agilního vývoje dlouze diskutovat a i když můžeme pochybovat o jejich praktickém využití, nelze jim dát nálepku uspěchaných a nepodložených výplodů několika nadšenců, kteří o praktickém vývoji softwaru nic neví.

Důležité je, že (ve většině případů) na začátku byl tradiční vývoj podle konzervativního, více či méně rigorózního softwarově inženýrského přístupu. Tento způsob vývoje evidentně nevedl k ekonomické tvorbě softwaru (jak je definována v Bauerově definici SWI), proto se členové příslušných týmů postupně odhodlávali vypracovat metodologie, které by odstranily zjevné problémy.

Teprve poté, co tyto metodologie na základě hlubokých úvah a diskusí vznikly, a teprve poté, co prošly určitým, různě dlouhým vývojem, byl na základě společných myšlenek několika takových metodologií formulován agilní manifest.

Jaké jsou základní dva pilíře Manifestu?

Výsledkem setkání reformátorů tedy byla formulace Manifestu agilního vývoje (The Agile Manifesto: podrobnosti, plné znění i seznam signatářů naleznete www.agilemanifesto.org). Ten je postaven na dvou základních pilířích, které jsou dále rozpracovány do podrobných bodů:

  • přijmout a umožnit změnu je mnohem efektivnější než se snažit jí zabránit;
  • je třeba být připraven reagovat na nepředvídatelné události, neboť ty bezpochyby nastanou (jedinou jistotou je změna).

Jak si všimli i mnozí čtenáři v diskusi pod předchozím článkem, agilní přístupy k vývoji jsou nejvhodnější pro projekty s nejasným, nejistým a nebo často se měnícím zadáním. Lze připustit, že u projektů, u nichž je zadání jasné, definitivní, neměnné, stabilní, jasně formulovatelné a ověřitelné, není účelné přistupovat k vývoji agilně. Alespoň ne ve všech bodech. Na druhou stranu je nutné vidět, že ne všechny agilní přístupy jsou natolik reformní, jako třeba Extrémní programování; některé agilní metodologie např. počítají s analýzou i specifikací, a právě takové je možno s výhodou využít pro výše uvedená zadání.

Preference a priority

Z důvodů uvedených ve dvou tezích v předchozím odstavci, dávají autoři manifestu přednost:

  • individualitám a komunikaci před procesy a nástroji
  • provozuschopnému softwaru před obsáhlými dokumentacemi
  • spolupráci se zákazníkem před pouhým sjednáváním kontraktu
  • reakci na změnu před plněním plánu

Opět se to docela hezky čte, že? Praxe samozřejmě nemusí být (a zřejmě ani nebude) tak růžová. Lze určitě namítat, že individuality se mohou vymknout kontrole; že komunikace za nás šibeniční termín nesplní; že software nikdy nebude provozuschopný, pokud nebude řádně zdokumentován; že zákazník nestojí o spolupráci, ale o splnění harmonogramu za co nejméně peněz; a že reakce na změnu stojí peníze navíc, které nám nikdo nedá. Na druhou stranu – dokážeme-li si představit situaci, v níž uvedené body neobstojí, zvládne naše představivost také případy, v níž tytéž body povedou k účelnému, efektivnímu, ekonomickému a nakonec i radostnému (proč to neuznat) vývoji. A o to jde – není přece cílem šmahem tento přístup odsoudit, a není ani cílem považovat jej za legendární stříbrnou kulku (znáte Hoping for the Silver Bullet?).

Manifest agilního vývoje

Na základě uvedených dvou tezí a čtyř preferenčních pravidel lze formulovat následující základní teze agilních metodologií:

  • Nevyšší prioritou je uspokojovat zákazníky včasnou a kontinuální dodávkou softwaru, který jim přináší hodnotu. Zákazník bude mít největší užitnou hodnotu ze softwaru, nikoliv z UML diagramů nebo ERA modelů.
  • Změny požadavků dokonce i v pozdních fázích projektu jsou vítané, neboť změna může být pro zákazníka konkurenční výhodou. Agilní metodologie očekávají příchod změn a nedělají nic, co není momentálně potřebné, protože je pravděpodobné, že se to v budoucnu změní.
  • Fungující software je třeba dodávat často (od dvou týdnů do dvou měsíců). Iterativní vývoj je podporován i většinou tradičních přístupů (např. RUP, o němž budeme psát v některém z následujících článků), agilní metodologie však zdůrazňují velmi krátké iterace a zkrácení cyklu dodávky.
  • Zákazníci a vývojáři spolupracují denně na projektu. Agilní přístupy vycházejí z toho, že nelze na začátku projektu podepsat specifikaci požadavků a nadále ji v celém průběhu vývoje považovat za neměnný etalon. Místo toho se zpočátku definují pouze hrubé požadavky umožňující základní návrh architektury, nicméně očekává se, že i ty se mohou v čase měnit. Aby na základě takto vágně definovaných požadavků šlo vůbec provádět návrh a implementaci, je nutný bezprostřední kontakt s lidmi ze strany zákazníka.
  • Motivovaní jedinci, kteří mají dobré podmínky a podporu vedení, jsou klíčovým faktorem úspěchu projektu. O úspěchu projektu vždy rozhodnou lidé, pro něž je často nejcennější důvěra v jejich schopnosti. Také rozhodování musí provádět kompetentní a pozitivně motivovaní jedinci.
  • Nejvýkonnější a nejefektivnější metodou přenosu informací v rámci vývojového týmu je vzájemná konverzace. Agilní přístupy tvrdí, že smyslem dokumentace (v obecném významu) je porozumění problému; tohoto porozumění se však nejefektivněji dosáhne používáním přímé komunikace, nikoliv psaním a čtením rozsáhlých zpráv.
  • Fungující software je primární mírou pokroku a úspěchu. Naplnění specifikace neznamená ještě úspěch projektu; může nastat např. neočekávaný problém při integraci.
  • Agilní metodologie předpokládají udržitelný vývoj. Přesčasy, práce v noci, přetěžování pracovníků může krátkodobě vyřešit zpoždění projektu, ale dlouhodobě je zdrojem nízké produktivity práce. Kent Beck, autor Extrémního programování, uvádí, že nutnost práce přesčas je téměř vždy signálem závažných problémů v projektu.
  • Stálá pozornost perfektnímu návrhu a technickému řešení. Agilní přístupy zdůrazňují kvalitu návrhu, přičemž ale změnu v návrhu neinterpretují jako důkaz jeho nízké kvality. Vzhledem k tomu, že základním jevem agilního programování jsou změny přicházející i v době, kdy kód je již napsán, je nutnost měnit návrh a jeho změny následně promítat i do zdrojového kódu zcela přirozená. Návrh není samostatnou etapou dokončenou před zahájením implementace; je to souvislá, každodenní činnost zasahující do všech fází projektu. Základním omylem je však představa, že návrh je vynechán nebo zanedbán. Není tomu tak: o důležitosti návrhu nikdo nepochybuje, návrh je naopak zařazen do každodenní náplně práce programátorů.
  • Jednoduchost – umění maximalizovat množství neudělané práce – je zásadní. V agilních procesech je kladen důraz na jednoduché postupy, protože se snáze mění. Je snazší přidat něco k jednoduchému procesu než odebrat něco z komplikovaného. Do řešení by se mělo zahrnout jen to, co prokazatelně potřebuje každý; nikoliv to, co možná bude někdo potřebovat. Extrémní programování si např. klade otázku „Jaká je minimální konfigurace, která ještě může fungovat?“
  • Nejlepší návrhy vznikají ze samoorganizujících se týmů. Kreativita lidí přináší skvělé návrhy; musíme ji však podpořit důvěrou, častou komunikací a rozumnou zátěží.
  • V pravidelných intervalech se týmy zabývají otázkou, jak pracovat efektivněji. Agilní metodologie nejsou předem dané, ale vyvíjejí se, přizpůsobují a reflektují sebe sama.

Tolik k základním myšlenkám agilního Manifestu. Vidíte, že tvůrci vytvořili poměrně štíhlou množinu doporučení: demonstrují tak, že i malé množství dokumentace může mít vysokou informační hodnotu.

Konkrétní agilní metodologie

V současnosti se stále zvyšuje počet konkrétních metodologií, u nichž lze vysledovat přímou souvislost s agilním manifestem. Následující přehled obsahuje jen nejvýznamnější zástupce:

  • Adaptivní vývoj softwaru (Adaptive Software Development: Jim Highsmith)
  • Vlastnostmi řízené programování (Feature-Driven Development: Jeff De Luca a Peter Coad)
  • Extrémní programování (Extreme Programming: Kent Bect)
  • Lean Development: Bob Charette
  • SCRUM Development Process: Ken Schwaber a Mike Beedle
  • Crystal metodologie (Crystal Methodologies: Alistar Cockburn)
  • Dynamic System Development Method (DSDM Consortium)

Nejzajímavějšími metodologiemi se budeme podrobně zabývat v příštích článcích.

Jak je to v praxi?

V příštích článcích budeme diskutovat o jednotlivých metodologiích, ale už teď, při znalosti agilních tezí, si každý jistě začíná vytvářet svou představu o využitelnosti agilních přístupů. Co si myslíte o Manifestu vy? Mohou tyto principy fungovat v praxi? Lze vůbec formulovat konkrétní metodologii, která bude vycházet z výše uvedených, agilních tezí a přitom povede k rozumnému, ekonomickému, úspěšnému vývoji softwaru?

Diskuze (8) Další článek: Vypalovačka Sony DRU-500A, Nero a DVD-RW = problémy?

Témata článku: Software, Programování, Podrobná analýza, Lean, Jednoduchý princip, OBS, Dobrá využitelnost, Bezprostřední kontakt, Manifest, Agile, AgI, Crystal, Dokončené dílo, Přesčasy, Předchozí odstavec, Obsah, Roztříštěnost, Šibeniční termín, Neočekávaný problém, Beck, Kent, Pozdní využití, Základní princip, Development, Zjevná výhoda

Určitě si přečtěte


Aktuální číslo časopisu Computer

Test 6 odolných telefonů a 22 powerbank

Srovnání technologií QLED a OLED

Měřte své sportovní výkony

Sady pro chytrou domácnost