Administrace komentářů

Proti tomu já nic nemám. Akorát si plánuju práci tak, že ji mám hotovou a můžu odevzdávat průběžně po 1 dni. (Celá debata se pak strhla ve smyslu, že takhle se práce plánovat nedá, ale ona se tak plánovat dá.)

Pro mne je práce hotová, když je hotový nějaký smysluplný celek. Pro vás je asi hotová tehdy, když projde kompilace a testy.

Vy používáte svůj vlastní postup, který chybně nazýváte CI. Váš postup není agilní metodika, protože ho nikdo jiný, než vy, k agilním metodikám neřadí, a protože je postaven na přesně opačných principech, než agilní metodiky.

A v čem se konkrétně liším?

Agilní metodiky se nesnaží zamaskovat, že vývojáři dělají chyby, že se mění požadavky na software nebo že se software postupně vyvíjí. Přistupují k tomu opačně, např. když už tedy programátor dělá chyby, tak se udělají taková opatření, aby se na ty chyby co nejrychleji přišlo, aby jejich oprava byla snadná, aby ovlivnily co nejméně ostatních programátorů a kódu. Vy k tomu přistupujete přesně opačně, chyba během vývoje je pro vás obrovský problém, takže vaši programátoři se logicky nebudou soustředit na to, aby výsledný produkt obsahoval co nejméně chyb, ale na to, aby bylo co nejméně chyb během vývoje. Když to přeženu, je jedno, zda bude výsledný program fungovat, ale hlavně aby se nikdy nespustil kompilátor nad zdrojákem, ve kterém chybí středník.

Dobře je to vidět na příkladech, kde jste popisoval plánování své práce. Rozdělíte ji na části, které sami o sobě nedávají žádný smysl a výsledek té práce se nepoužívá. Díky tomu vám pak prochází testy a vy jste spokojen. To je ale přesný opak toho, o co se snaží CI. CI znamená, že se snažíte funkční kód co nejrychleji začít používat; vy místo toho kód složitě upravujete, aby se nepoužíval, a pak jej co nejrychleji dáte do VCS. Ke skutečné integraci (ne kódu, ale funkcionality) pak dojde až po několika dnech, když skončíte práci – jenže při skutečné CI už by ten kód dávno někdo používal.