Agilní vývoj: Getting Real

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í.

Jiří Knesl se zabývá hlavně Scrumem a správným vývojem software (prevence chyb, vyšší produktivita).

Komentáře: 8

Přehled komentářů

MD parove progamovani
Jiří Knesl Re: parove progamovani
MD Re: parove progamovani
fju Re: parove progamovani
olgo Re: parove progamovani
uf Re: parove progamovani
okovarik chybka v logice jedne podminky ?
Jiri Knesl Re: chybka v logice jedne podminky ?
Zdroj: https://www.zdrojak.cz/?p=3140