Skryté činnosti, které ničí váš odhad času na vývoj

Nejdůležitější je sledovat, jak se mění nároky na data v čase. To, co fungovalo při stovkách záznamů, selhává u milionů. Typická chyba je spoléhat na to, že databáze si poradí sama. Neřekne vám, že chybí vhodný index, dokud není pozdě. Pravidelně proto kontrolujte plán provádění dotazů a hledejte operace typu sekvenční skenování velkých tabulek. Pokud je najdete, zvažte přidání indexu nebo přepsání dotazu – často pomůže i pouhé rozdělení složitého dotazu na menší části.

Scrum se v českých firmách často zavádí mechanicky. Tým si přečte pár článků, nastaví sprinty na dva týdny, zvolí product ownera a scrum mastera – a pak se diví, že místo zrychlení přichází chaos. Nejde přitom o to používat správně role, ceremonie nebo artefakty. Jde o to pochopit, že Scrum je nástroj pro řízení složitosti, ne bič na vývojáře. Bez tohoto základu zůstane jen u povrchního procesu, který nikomu nepomůže.

Častou chybou je podceňování verzí a jejich životního cyklu. Výrobci databázových systémů poskytují opravy pouze po omezenou dobu. Po jejím uplynutí přestávají řešit bezpečnostní chyby i výkonnostní problémy. Pokud tedy běžíte na staré verzi, nejste jen nepodporovaní – vystavujete se zbytečnému riziku. Naplánujte si upgrade s dostatečným předstihem a vyhraďte si čas na testování kompatibility s vaší aplikací. Změna hlavní verze často přináší změny v chování optimalizátoru a může odhalit skryté závislosti.
Než Scrum zavrhnete, podívejte se na to, jak používáte jeho pravidla. Pokud máte pocit, že jde o zbytečnou byrokracii, zeptejte se, jestli nepoužíváte příliš mnoho formálních nástrojů. Scrum má být jednoduchý. Když zjistíte, že plánujete sprint na tři dny a píšete podrobné user story, děláte něco špatně. Zkuste místo toho začít s menšími kroky, s minimálními pravidly a s důrazem na zpětnou vazbu. Teprve pak uvidíte, že Scrum skutečně zrychluje práci a snižuje stres.

Prakticky: http://miklagaard.No/index.php?title=První_aplikace_v_Androidu:_co_se_stane,_když_začnete_u_Javy začněte s krátkými sprinty, ideálně dvoutýdenními. Na začátku si naplánujte, co chcete dodat, a na konci si ukážete, co je hotové. Kritérium „hotovo" si nadefinujte tak, aby bylo ověřitelné – třeba „kód prošel code review, má testy a je nasazený na staging". Bez tohohle jasného cíle skončíte zase jen s rozpracovanými funkcemi, které nikdo neodzkouší. A pozor, sprint není maraton; pokud se vám nedaří dodat, co jste slíbili, snižte objem práce, ne navyšujte hodiny.

Praktickým nástrojem je tzv. rezerva na neznámé. Vytvořte si vlastní šablonu odhadu, která obsahuje položky jako „průzkum", „implementace", „testování", „integrace", „komunikace" a „dokumentace". Ke každé položce si napište čas, který jste u minulých podobných úkolů reálně potřebovali, ne to, co jste si představovali. Po dokončení úkolu si porovnejte odhad se skutečností a zapište si, kde jste se mýlili. Tato zpětná vazba je nejcennější pro budoucí plánování.

jak zařídit malou kuchyni se vyhnout nejčastějším nástrahám scrumu? Největší pastí je, že se tým zaměří na rituály místo na hodnotu. Stand-up by neměl být hlášením stavu šéfovi, ale příležitostí, kde si řeknete, co vám brání v práci. Pokud trvá déle než patnáct minut, rozdělte si úkoly na menší. Retrospektiva zase nemá být nuda; zkuste ji pokaždé zaměřit na jinou otázku – třeba „co nás zpomalovalo" nebo „která spolupráce nám fungovala". Vyhněte se ale tomu, abyste se vraceli k minulým sprintům do nekonečna. Vždy si vyberte jedno konkrétní zlepšení a to do příštího sprintu skutečně implementujte.

Nakonec si uvědomte, že Scrum není všelék. Pro týmy, které řeší hlavně operativní požadavky nebo podporu, může být kanban jednodušší a efektivnější. Kanban nemá sprinty, jen kontinuální tok práce, a hodí se tam, kde nestíháte plánovat dlouhodobě. Vyzkoušejte obojí a klidně si vezměte prvky z každého – důležité je, aby vám proces pomáhal, ne vás brzdil. Agilita není o tom, že budete mít certifikát, ale že budete schopni rychle reagovat na změny a dodat funkční software.

Retrospektiva je nejdůležitější ceremonie, ale v praxi se často odbývá jako formální povinnost. Tým sedí, říká, co bylo špatně, ale nikdo neudělá akční kroky. Bez změny je retrospektiva ztráta času. Zkuste na každé retrospektivě vybrat jen jeden konkrétní problém a domluvit se, kdo ho vyřeší do příštího sprintu. Můžete si také psát seznam „věcí, které jsme zkusili" a sledovat, co se skutečně změnilo. Tým pak vidí, že zpětná vazba má smysl, a začne se zapojovat.

Další častou chybou je přetížený backlog. Mít stovky položek, z nichž polovina už není aktuální, je k ničemu. Naučte se backlog pravidelně čistit a prioritizovat podle obchodní hodnoty, ne podle toho, co zrovna někoho napadlo. A nebojte se říct „ne" novým požadavkům uprostřed sprintu. Pokud to uděláte, ztratíte smysl sprintu jako uzavřeného celku. Místo toho si napište návrh do dalšího sprintu a nechte tým dokončit to, na čem už pracuje.

Here is more information on Https://Wiki.MAN-Noir.Com look into our own page.