Přejít k navigační liště

Zdroják » Různé » Agilní vývoj: Getting Real

Agilní vývoj: Getting Real

Články Různé

V posledním díle stručného seznámení s agilními metodikami vývoje si představíme metodu Getting Real, která je vhodná pro vytváření webových stránek a aplikací v malých týmech, a přidáme užitečný seznam agilních technik.

Seriál: Agilní vývoj (3 díly)

  1. Agilní vývoj: Úvod 11. 12. 2009
  2. Agilní vývoj: Scrum 18. 12. 2009
  3. Agilní vývoj: Getting Real 23. 12. 2009

Tuto metodu vývoje software vyvinulo studio 37 signals. S její pomocí vytvořili několik velmi úspěšných webů (Basecamp a další – všechny k nalezení na jejich webu) a mimojiné známý framework Ruby on Rails.

Metoda vývoje a řízení Getting Real se na veřejnost dostala díky stejnojmenné knize. Kniha je volně ke stažení.

Getting Real se oproti Scrumu hodí na projekty:

  • s velmi nízkým počtem vývojářů (ideální pro začátek s GR jsou 3).
  • tam, kde není možné vymezit z týmu Scrum Mastera.
  • tam, kde je nutné velmi krátkých iterací (přestože Scrum dobře zvládá i pouze několikadenní iterace, Getting Real je na tento způsob práce přímo určen).
  • v situaci, kdy firma nemá přístup k certifikovanému Scrum masterovi, který by firmu zaškolil.
  • metodika je určena pro vytváření WWW stránek, jakkoliv to není podmínkou.

Mezi zásadní vlastnosti Getting Real patří:

  • Extrémní důraz na vývoj systému s velmi malým počtem vlastností, které jsou velmi kvalitní oproti menšímu množství ne tak dobrých funkcionalit.
  • Stejně takový důraz na pravidelné a časté doručování nových verzí.
  • Krátké iterace.
  • Důraz na graficky atraktivní a použitelné řešení.
  • Getting Real radí, jak dělat produktu marketing.
  • V GR se lze dočíst, jaké vybírat zaměstnance a jakou u toho zvolit strategii.
  • Produkt se neustále vyvíjí, vývojáři jsou kreativní a neustále reagují na aktuální nejcennější vlastnost.
  • Produkt může znamenat téměř cokoliv, často se stává, že produkt určené skupině šetří někomu hodně času. Může to být komunikační software, výměna dat, project management, správa dokumentů, wiki, verzovací systém, zálohování, kalendář, kalkulačka, převodník měn, vyhledavač…

Výčet základních tezí Getting Real si uvedeme spolu s odkazy na odpovídající kapitoly:

Navzdory tomu, že GR dává týmu do rukou komplexní workflow, občas se zpochybňuje to, zda je agilní metodikou, nebo jen shrnutím užitečných tipů. Je pravda, že mnoho praktik se v knize, ze které metodika vychází a které se považují za podmínky Agile, nezmiňuje. Na druhou stranu žádná doporučovaná metoda ani postup nebrání běžnému pojetí Agile podle manifestu, ani nebrání žádné z běžně užívaných Agilních technik.

Zajímá vás Zend Framework nebo unit testování? Chcete se dozvědět víc? Autor článku Jiří Knesl pořádá školení na tato témata. Více informací naleznete na stránce školení Zend Frameworku.

Agilní techniky

Účast zákazníka na vývoji

Poznámka: Tato metoda se často za agilní neoznačuje. Přesto patří k best practices, kterou
doporučuje mnoho vývojářů i manažerů pohybujících se v agilním prostředí.

Firmy v nejčastěji pracují odděleně od zákazníků. Chrání si tím svůj klid. Zároveň ale takové prostředí nedokáže plnit zcela podle přání zákazníka (v rámci daného workflow). Účast zákazníka znamená fyzickou přítomnost osoby, která zastupuje zájem produktu, který se buduje. Může to být pověřená osoba z firmy klienta, nebo i přímo zaměstnanec firmy, například Product Manager.

Continuous Integration

Základní myšlenkou CI je zamezení dlouhodobého vývoje kódu samostatně jedním zaměstnancem. Pravidlem je, aby zaměstnanec kód často a pravidelně přidával do společného kódu. Toto rozhodnutí vede k výraznému snížení chybovosti. Zároveň společné servery bývají stabilnější a častěji zálohované, než počítače programátorů – eliminuje se tím riziko, že programátor přijde o svou práci. (více informací k tématu).

Není podmínkou vyvíjet na společném serveru i při samostatné práci přes den, je možné

vytvářet software přímo na počítači programátora. CI znamená to, že programátor svou práci

pravidelně nahraje na server a otestuje, zda spolupracuje s ostatními součástmi systému.

Test Driven Development

Je nutné zavést nový termín. Unit Testing. Takto se ve světě IT nazývá činnost, při které
programátor vytváří kód, jehož účelem je testovat funkčnost aplikace. Test tedy nepřispívá k řešení, ale pomáhá jinak. Často tuto agilní metodiku manažeři bourají představou, že TDD nevede k lepší produktivitě.

Je tedy Unit Testing zdržení? Ve výsledku není. Prodlouží se sice doba vývoje, ale zkrátí se doba, kterou musí vývojář věnovat otestování, údržbě apod. Objevení chyb v rané fázi projektu snižuje náklady na opravu. Samozřejmě záleží na povaze projektu, tam, kde vývojář dělá rutinní práci, nemusí být TDD zlepšení produktivity. Pokud se tento přístup používá na složitějších projektech, riziko chyb se zvyšuje.

Jen správné otestování ochrání aplikaci proti chybám. A pak samozřejmě ještě inteligence, znalosti
a zkušenosti vývojářů.

Behaviour Driven Development

Protože občas dochází k tomu, že programátor implementuje něco jiného, než se od něj ve skutečnosti žádá, vedla taková situace k hledání způsobu, jak tomuto jevu zamezit. Jedním z nápadů, který pomáhá předcházet takovým problémům, je Behaviour Driven Development. V čem tato technika spočívá? V zásadě se jedná o to, že se napíše specifikace ve velmi jednoduchých větách, v dalším kroku se naprogramuje test, který převádí větu specifikace na sled příkazů, které ověřují, zda se program podle specifikace chová. Teprve tehdy se implementuje samotné řešení a celou dobu se zjišťuje, jak dobrý je v tu chvíli kód. Dále se smí pokračovat, až když jsou všechny chyby vyřešené.

Takto může vypadat scénář, z kterého se vytvoří test (ukázky scénáře i kódu pochází z github.com):

# language: en
Feature: Division
    In order to avoid silly mistakes
    Cashiers must be able to calculate a fraction
    Scenario: Regular numbers
        Given I have entered 3 into the calculator
        And I have entered 2 into the calculator
        When I press divide
        Then the result should be 1.5 on the screen

Následuje ukázka kódu, který implementuje řešení. Použit byl skriptovací jazyk Ruby, oba
příklady jsou z výpisu zdrojového kódu:

# encoding: utf-8
require 'spec/expectations'
$:.unshift(File.dirname(__FILE__) + '/../../lib')

require 'cucumber/formatter/unicode'
require 'calculator'

Before do
  @calc = Calculator.new
end

After do
end

Given /I have entered (d+) into the calculator/ do |n|
  @calc.push n.to_i
end

When /I press (w+)/ do |op|
  @result = @calc.send op
end

Then /the result should be (.*) on the screen/ do |result|
  @result.should == result.to_f
end

Párové programování

Nejvíce šokující praktikou Agile je tzv. párové programování. O párovém programování napsal z vlastní zkušenosti Jan Kaltoun (Scrum Master, učitel na VŠE, student tamtéž):

“Tato technika je výjimečně vhodná zejména při práci na velmi složitých úkolech u kterých je vysoká šance na vytvoření chybného kódu, nebo například při debugování složitého kódu. Naopak je tato technika spíše kontraproduktivní pro jednoduché úkoly, kdy druhý programátor, který by mohl na jiném stroji psát jiný kód, prakticky zbytečně kontroluje triviální kód druhého programátora, jehož chybovost je vzhledem k jednoduchosti úkolu velmi nízká.”

Největší výhody párového programování jsou:

  • Žádný kód, který nikdo neviděl kromě vývojáře samotného.
  • Lepší náhled na architekturu systému.
  • Zamezení commitování “hacků” – to si obvykle dovolí jeden vývojář, nikdy ale dva profesionálové.
  • Odstranění takzvané “autorské slepoty”.
  • Lidé, kteří párové programování používají tvrdí, že se velice zvýšila jejich kvalita kódu.

Závěrem

Používat agilní způsob řízení znamená přebudovat vnímání toho, jak se řídí projekty, jak má vůbec manažer i tým přistupovat ke klientovi, jeho potřebám a změnám v zadání. Proto bohužel dnes management často Agile zcela ignoruje. Situace se v České republice postupně zlepšuje, o metodách se často diskutuje (nejčastěji ve spojením s psaním Unit Testů), a lze tedy očekávat zlepšení situace do budoucna.

Problémem iterativního vývoje je oceňování, zvlášť tehdy, kdy konkurence udává od začátku konečnou cenu, zatímco agilní firma tohoto není schopna. Protože ale firmy uplatňující klasický waterfall model se brání ztrátám ze zdržení tím, že velmi nadsadí cenu, a navíc obvykle firma neuplatňující Agile není tak produktivní, rozhoduje o tom, zda si klient vybuduje k Agile přístupu důvěru pouze to, zda dá této firmě první příležitost. Poté zjistí, jaké výhody postupné platby, rychlý vývoj a možnost kdykoliv změnit zadání (kdykoliv mezi sprinty, ne v průběhu), mají.

Komentáře

Subscribe
Upozornit na
guest
8 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
MD

Pekny clanek.

Jak se resi situace, kdy se oba nemohou shodnout na tom, jakym zpusobem kod napsat? A kdo z nich pise? Stridaji se? Nedopada to tak, ze jeden dela jen „zapisovatele“ toho druheho, dominantnejsiho?

Jiří Knesl

Z vlastní zkušenosti můžu říct, že k situaci „nemohou se dohodnout“ většinou nedojde. Pokud ano, pravdu má ten, kdo zrovna sedí u klávesnice. Ostatně se za chvilku prohodí a ten druhý může ten kód refaktorovat/napsat unit test, který ukáže ošemetnost prvního řešení.

V psaní se tedy vývojáři střídají. Zajímavá je tzv.ping-pong metoda, při které vždy vývojář napíše kód, který projde testy a napíše nový test a vývojáři se u klávesnice vystřídají. A tak pořád dokolečka.

Aby jeden dělal zapisovače druhému je téměř nemožné. Zkoušel jsem při párovém programování zapisovat delší dobu a místo výhod došlo k nevýhodám:
a) párové programování je mnohem náročnější na mozek – po delší době přijdete o pozornost
b) PP je zároveň poměrně vyčerpávající jako takové – to víte, žádný facebook, blogy, ICQ, nebo refaktorování lehkého kódu. Když už vypárovávám, tak proto, že mám vyvinout/refak­torovat složitý kód. Pokud se člověk X hodin pohybuje jen ve složitých částech aplikace, docela ho to unaví. Pozice „dohližitele“ je v tomto méně náročná, protože v případě únavy se dá zredukovat na „kontrolovače lapsů“.

Jinak by nemělo jít o „dominanci“. Obecně bych řekl, že párování spíš (minimálně u mě) utužuje týmového ducha, odstraňuje místa v kódu, které nezná nikdo kromě jednoho vývojáře a vede k vyrovnávání schopností. Často se vyplatí mít dvojice začátečník-začátečník, příp. profesionál-profesionál, předejde se tím právě dominanci jednoho.

MD

dik za odpoved

fju

ano, parove programovani je fajn, kdyz treba jako starsi z dvojice jiz neumim ty ruzne nove technologie uchopit. pak se to sledujice toho mladsiho s aktualnimi znalostmi anebo agilnejsiho naucim rychleji delat sam. protoze nove technologie jsou jenom o jinych postupech, programovani je temer podobne drivejsimu. Ale jinak agilni metody neuznavam, protoze aby to fungovalo potrebujete homogenni vesmes agilni skupinu lidi, coz je nerealnost sama. Jsou to jenom dalsi pozlatka coby napady jak programovani zefektivnit ale ta agilita nefunguje lehce, spise naopak.

olgo

> Často se vyplatí mít dvojice začátečník-začátečník, příp. profesionál-profesionál
imho takto tím nemôže fungovať neustále pretože značne redukuje počet možných dvojíc (za predpokladu že sa dvojice obmieňajú) s čím má napríklad Extrémne programovanie problém.

PP dáva tiež možnosť začiatočníkom sa učiť od svojich skúsenejších kolegov z „prvej rady“

ps: skvelí seriál

uf

Parove programovani se nam dost osvedcilo ve verzi programator-analytik. Analytik ma nadhled z vysky a vi, co se ma udelat, ja vidim problemy zevnitr a z hlediska algoritmu a vim, jak to udelat.

Navic pri psani vyvijime i vlastni algoritmus, protoze se jeden z nas zepta „ale co kdyz…?“ a je z toho hodinova diskuse, nekolik telefonu a nekolikadenni diskuse u zakazniku.

Ten druhy zaroven hlida moje boty dotazy „jaks myslel tohle?“, „Neni tohle nejak divny?“, „Mas osetrenou i variantu (co nenastane)?“.

okovarik

„Extrémní důraz na vývoj systému s velmi malým počtem vlastností, které jsou velmi kvalitní oproti menšímu množství ne tak dobrých funkcionalit. “

mozna jsem takhle po prazdninach jeste nepozorny, ale z toho mi vyplyva, ze je kladen duraz na malo dobrych funkci, oproti mensimu mnozstvi horsich funkci

asi je to jen o vymene slova „mensimu“ za „vetsimu“

Jiri Knesl

Ano, jde o preklep. Samozrejme melo byt, ze se v GR zamerujete na jednoduchy, ale skvele dotazeny produkt a ne na vytvoreni systemu pro vsechny, vsechno a vsude.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.