Scrum a další: Jak na agilní softwarový vývoj

My ani tak ne ale kdyz se rozhlidnu kolem jak funguji nekteri velkovyrobny a co dodavaj . Ono je to v tomhle businesse uplne stejny jako ve vsech ostatnich odvetvich, gaussovo rozlozeni idiotu ve spolecnosti je platne i zde. Akorat v IT se z idiotu rekrutuji PM, analytici & manageri .

Zlatá slova. Přidám zkušenost z neprogramátorského soudku. Svého času k nám na firmu vtrhl jeden "manager". Nechal si platit nehorázný peníz za to, aby s námi provedl několik prastarých a všem známých koučovacích cvičení a hlavně - přivedl šéfa na tu obludnou myšlenku psaní denních reportů. Takže oddělení, která fungovala na jedničku a kde lidi makali, najednou nestíhala, protože "nemám čas kámo, já teď musím psát report" - a stejně ty reporty byly ubohé, protože jen zdržovaly od skutečné práce. Zato oddělení, kde se lidé šťourali nudou v nose, plodila nádherné slohové útvary a byla za ně patřičně odměňována. "Managerovi" vydržela jeho snaha půl roku, pak se někdo konečně začal zajímat, proč nám klesají tržby a proč jsou obchoďáci neustále nas..štvaní...
A pak napadla šéfa ta spásná myšlenka - rozhodit naprosto transparentně čistý zisk firmy mezi jednotlivá oddělení podle skutečných zásluh (jak to dlouhodobě navrhovala velká část zaměstnanců). A ejhle - dejte lidem pocítit přímou úměru mezi výsledky jejich práce a výší částky na výplatní pásce a najednou se přestanou "snažit" a začnou makat. A kupodivu zisky velmi narostly a report najednou stačil jednou za měsíc.

jak se poznaji skutecne zasluhy (aby se podle nich mohl transparentne rozdelit zisk)? 10Kc za 1 radek kodu pro programatory? 50Kc za 1 nalezeny bug pro testery?? Nebo vsechny penize pro obchodniky, protoze jenom oni formalne vytvareji zisk?

To je přesně několik otázek, kterými je dobré začít. Dáte uklízečce, účetní, kolegovi z reklamací, sekretářce? Oni také negenerují zisk. Ale kdo chce najít systém, který bude spravedlivý a zároveň motivující, ten si tu práci dá a donutí obchodníka, aby uznal, že v neuklizeném showroomu s nespárovanými fakturami se špatně vydělává. Samozřejmě to je spousta ladění a běh na dlouhou trať, ale jak říkám - kde je vůle, tam se dějí zázraky. Samozřejmě stoprocentní spokojenost je spíše v úrovni sci-fi, ale kdybyste viděl, jak se pak obchodníci na showroomu doslova předhánějí, kdo si se zákazníkem promluví (po předchozím stavu, kdy reakcí na příchozího byly obličeje zabořené do monitorů a simulující nějakou naléhavou práci), srdce by vám plesalo. A přitom ty obchodníky nikdo nenutí, oni sami CHTĚJÍ.

My používáme metodiku finančních hodin. Přijde zakázka, požadavek, úkol. Tento se analyzuje a odhadne se čas. Pak se nechá odsouhlasit klientem. Jakmile je souhlas, tak se to realizuje a na konci se označí za vyřešený. Sjednaný čas se zapíše. Takže na konci měsíce je pak vidět, kolik kdo nasbíral hodin. Čím víc hodin, tím víc pracoval. Pro zaměstnance je to pak vyšší odměna a pro firmu pak vyšší zisk. Reklamace, opravy nebo mimopracovní činnosti se do času nezapočítávají. Takže, ten, kdo se fláká, bude mít minimum hodin. A kdo dělá chyby a musí po sobě opravovat, také má miň hodin. Motivaci pracovat lze umocnit zavedením limitu. Třeba nasbírat 90 finančních hodin za měsíc. Pokud nasbíráš víc, tak tě může čekat odměna. Pokud miň, tak nic. A pokud jsi dlouhodobě výrazně pod, tak tě čeká kobereček.

mozes mi povedat podla coho vyzistite kolko bude na danu ulohu casu ? ako prebieha taka analyza ? mne osobne sa uz neskutocne vela krat v realnom zivote stalo ..ze uloha ktora bola predpokladana na 10-12 dni bola spravena za 2 dni a naopak zdanlivo jednoducha uloha ktora mala zabrat par hodin sa zasekla kvoli nejakemu hlbsiemu problemu aj na par tyzdnov ... taktiez na splnenie limitu mozem pouzatvarat ulohy aby mi sedeli pritom nebudu napr otestovane .. toto moze fungovat u support teamov, na ekonomickych alebo kreativnych oddeleniach ale neviem si toto predstavit vo vyvojovom teame ..a hlavne na projekte ktory sa realne este nepredava ale len vyvija (1-2 roky)

Na to je třeba mít zkušenosti. Zkušený programátor / analytik, který už má nějaké ty roky praxe, dokáže poměrně přesně odhadnout čas. Samozřejmě to nikdy nebude přesně. Jde prostě o kompromis. Ne miň ani ne víc. Pokud podceníš čas, tak je to špatné pro tebe. Pokud čas přeceníš, tak je to sice dobré pro tebe, ale zase tím nezískáš reputaci klienta. Časový odhad je proto důležitý, protože od toho se odvíjí cena, kterou musí klient zaplatit a podstatě je ta cena i konečná.
Drobky se dají odhadnout s přesnosti na minuty. Standardní úkoly na hodiny a složitější na dny. A pokud jde o celý projekt, tak tady jde o podrobnou analýzu, kdy se zjišťuje co všechno to má mít, jak to má být. Rozdělí se to na části a od každého se zjišťuje čas. Z toho se to pak sečte a připojí rezerva, testování apod. Dlouhodobé projekty se řeší právě tak, že se rozdělují na části (moduly).
Prostě jde o zkušenosti. Pokud to firma neumí, pak je metoda, kterou uvádím nepoužitelná. A popravdě pro firmu samotnou to také není zrovna dobré. Pokud se často přestřeluje, tak tím zrovna reputaci nezíská. Buď nestíhá nebo je drahá.

Pardon to sou keci v kleci. Sef prinese ulohu budeme vymenovat system XY, tady mas nejaky podklady a chci "hrubej odhad" mam skoro 30 let zkusenosti a s timhle bych ho vzdy nejradeji poslal stredem. Principialne si myslim ze je spatne uz model fix time/fix price. Vzdycky je to velka ducharina ... a ty kecy ze zkuseny programator to trefi v rozsahu 10-20% ...

Tak nějak. Nezřídka dělám úlohy, kde člověk nemůže dát seriózní časový odhad, dokud řešení nevyzkouší že fakt fungují (dokumentace a normy jsou jedna věc, realita druhá). No a aby ho vyzkoušel, tak ho vlastně už potřebuje mít hotové...

Ale pánové. Tak se uklidníme. Že neumíte analyzovat projekt a dobře určovat časové odhady, je mi jedno.
Třicet let zkušenosti? Tak to Vám musí být už tak 50 let. Takže asi stará škola nebo neochota dělat nové věci. Nebo jen prostě kecáte. Základem každého projektu je i analýza. Tam se vždy s klientem probere co potřebuje, jak to chce. A na základě analýzy se určí potřebný čas nebo průběh. A od toho se obvijí i potřebná částka. Dělat projekt na slepo bez toho, aby obě strany věděli jak dlouho to bude trvat nebo kolik to bude stát, je naprostá blbost.
Docela zvláštní. Já mám tři roky zkušenosti a nějak mi to funguje. Asi mám talent, když tvrdíte, že to není možné. Odhady, které provedu většinou souhlasí. Když řeknu, že mi to bude trvat tři týdny, tak to do tří týdnů udělám.
A nové neznámé věci? Tak si předem zjistím do čeho jdu a jak složité to asi může být. Tyto jsou oříšky, proto je také důležité si to pořádně promyslet.Nechci se hádat. U mě to takto prostě je a funguje to. Že to nefunguje u jiného, je pak jiná věc.

Podle toho, co píšete, to vypadá, že pracujete sám a na docela drobných projektech. Nebo jste už někdy odhadoval větší projekt, řekněme pro tým 5-10 vývojářů s náročností v rozsahu 3-6 měsíců? Protože to je naprosto jiná třída, než odhadovat, že "tuhle ptákovinu zmáknu za tři týdny".

Tak větší a dlouhodobější projekty mají jiná pravidla než drobky. Tam je těžké předem odhadnout celkový čas, náklady a prostředky. Tam to jde postupným krokem po částech.
A ano pracuji a odhaduji i větší projekty spolu s kolegy. A vím, že to není sranda. Ostatně ten motivační příklad, který jsem uvedl se na tohle nevztahuje.

No, teorii popisuješ hezky ;) Ano, pokud se projekt dělá na zelené louce, tak to relativně funguje. Horší je to třeba v oblasti systémové integrace, kde, pokud jste danou věc nedělali předtím na stejné verzi SW, tak nevíte jistě, kolik zádrhelů tam kde bude. Nebo musíte spolupracovat s nějakým dalším dodavatelem. A jak odhadnete, kolik času budete potřebovat na jednání s nimi - jak moc budou vstřícní a naopak jak moc vám budou házet klacky pod nohy?

Haha, uvedu konkretni pripad na cem jsem delal naposled abychom tady nevarili z vody. Pro jednu velkou spolecnost ktera se rozhodla usetrit par milionu na licenci za jeden vypeceny soft a rozhodla se jej vymenit jsem delal analyzu a architekturu vymeny. Sef prinesl "par slov" a ptal se na odhad . Takze jsem ho poslal alespon pro nejaky dokumenty, prinesl neco kolem 5000 stranek textu, par set kilo zdrojako v C a potom jeste nejaky doprovodny sperky a rika dam ti par dni dej mi odhad. Par dni byly 3 . Dostal odhad umerny casu .. a tak je to vzdycky. Kdyz to opichaj nagelovany dickheadi opichaj to potom i programatori a podle toho to mnohdy vypada. Docela bych se pobavil, kdyby ti analytiku prinesli zdrojaky napriklad z www.kernel.org a zeptali se te jak dlouho si myslis ze bude trvat implementace feature XY ... a ted mudruj. Jo a 50 mi jeste neni a nemam ve zvyku kecat, nemam to zapotrebi.

Nic ve zlým. Zkušenosti a praxe jsou přece jen trochu jiné věci. Pokud ti není 50, tak dle tvého vyjádření jsi musel začít pracovat v pubertě. Což je proti zákonu. Ale pokud to bereš takto, pak já mám zkušenosti již 12 let.
Tvůj příklad je typická byrokracie managementu. Hodí ti projekt a dá ti šibeniční termín. V tomto případě je fakt těžký za ten čas to všechno projít a říct přesný odhad. Takže musíš střílet do boku.