Na sprint review ukazujte hotové funkce, ne powerpoint. Zákazník nebo stakeholder si může věci vyzkoušet a dát zpětnou vazbu. Typická chyba: tým ukazuje „skoro hotovo" a pak opravuje chyby po sprintu. Definice hotového (Definition of Done) musí být jasná a odsouhlasená – třeba „kód je otestovaný, prošel code review a je nasazený na testovací prostředí". Pokud DoD porušíte, sprint se počítá jako nedodaný.<br>
<br>
<br>
<br>
Pamatujte, že cílem není vyhnout se slibům za každou cenu, ale slibovat jen to, co můžete splnit. Když se naučíte komunikovat odhady jako pracovní nástroj, ne jako věštbu, získáte si respekt a klienti se k vám budou rádi vracet. A to je lepší než sto rychlých, ale nesplněných termínů.<br>
<br>
<br>
<br>
Než začnete mluvit o termínech, zjistěte si co nejvíce informací o zadání. Pokud zadání není kompletní, řekněte to nahlas. Klientovi vysvětlete, že odhad bez detailů je jako jízda bez mapy. Stanovte si interní rezervu – nepočítejte jen s optimálním průběhem, ale i s menšími komplikacemi, které se běžně stávají. Do odhadu zahrňte i čas na kontrolu, komunikaci a případné úpravy. Mnozí dělají chybu, že odhadnou čistý pracovní čas a pak bojují s každým dnem zpoždění.<br>
<br>
<br>
<br>
Na závěr: Scrum nefunguje, pokud ho aplikujete rigidně. V českých týmech často selhává, když se Scrum Master stane projektovým manažerem, který rozdává úkoly, nebo když produktový vlastník změní priority každý den. Dejte týmu čas na učení – první dva sprinty budou nepohodlné. Měřte si rychlost (velocity) až po třetím sprintu, kdy se stabilizuje. A hlavně: experimentujte, upravujte pravidla podle svých potřeb, ale vždy respektujte empirismus – kontrolujte, co funguje, a změňte to, co ne.<br>
<br>
<br>
<br>
Při samotném psaní zdrojových textů myslete na délku. Česká věta je často delší než anglická, a pokud máte tlačítko s pevnou šířkou, text se ořízne. Vždy testujte, jak se překlad chová v extrémních případech — nejdelší slovo, nejdelší věta, nejdelší číslo s jednotkou. Stejně tak pozor na složené výrazy. V češtině skloňujeme, takže věta „Máte 3 nové zprávy" se nedá jednoduše poskládat z částí „Máte" + číslo + „nové zprávy". Používejte raději celé věty s placeholdery, než abyste spojovali kusy textu podle počtu.<br>
<br>
<br>
<br>
<span style="font-weight: bold;">Komunikace odhadů času</span> patří k nejcitlivějším momentům spolupráce. Zákazník chce jasný termín, vy ale víte, že se může cokoliv změnit. Základem je rozlišovat mezi pojmy „odhad" a „závazek". Odhad je pracovní hypotéza, závazek je pevný slib. Pokud obojí smícháte, dříve nebo později narazíte. Místo slov „bude hotovo" používejte „předpokládám" nebo „odhaduji". Tím dáváte najevo, že časový údaj není věštěním z křišťálové koule, ale výsledkem analýzy.<br>
<br>
<br>
<br>
Dalším častým problémem je kódování a speciální znaky. Pokud používáte soubory s překlady, vždy je ukládejte v UTF-8, jinak se diakritika rozsype. Stejně tak si dejte pozor na apostrofy a uvozovky — v některých formátech se musí escapovat, a pokud to uděláte špatně, aplikace spadne. Před nasazením si vždy spusťte automatizovaný test, který ověří, že všechny klíče existují ve všech jazycích a že žádný soubor neobsahuje syntaktickou chybu. Tím odhalíte problém dřív, než se dostane k uživatelům.<br>
<br>
<br>
<br>
<span style="font-weight: 900;">Při práci s více jazyky</span> narazíte také na rozdíly v datech, číslech a měnách. Formát data „03/04/2025" znamená v češtině 3. dubna, v angličtině 4. března. Proto nikdy netvrďte formát ručně, ale používejte funkce pro lokalizaci z vaší knihovny. Stejně tak desetinná čárka, mezery mezi tisíci nebo symbol měny se liší. Všechny tyto hodnoty by měly být součástí lokalizačního systému, ne pevně zapsané v kódu. Uživatele byste tím zmátli a v některých případech by mohli nesprávně interpretovat důležité údaje.<br>
<br>
<br>
<br>
Častou chybou je přizpůsobovat odhad představám klienta jen proto, aby se zalíbil. Takový odhad nemá žádnou hodnotu a vede ke ztrátě důvěry. Držte se svých zkušeností, i když se to na první pohled nezdá jako cesta nejmenšího odporu. Vysvětlete, co všechno ovlivňuje délku práce – od dostupnosti podkladů přes technologická omezení až po nutnost koordinace s dalšími lidmi. Tím klient získá lepší představu o tom, proč je odhad takový, jaký je, a nebude ho vnímat jako svévoli.<br>
<br>
<br>
<br>
Nejdřív si definujte strukturu klíčů Než začnete překládat, navrhněte si systém pojmenování. Ideální je používat hierarchické klíče, třeba „header.navigation.home" nebo „checkout.button.submit". Vyhnete se tak dlouhým řetězcům, které jsou nepřehledné a při změně názvu funkce se snadno rozbijí. Důležité je také myslet na kontext: klíč „save" může být v jednom místě tlačítko, jinde odkaz. Proto klíč vždy popisuje umístění, ne jen samotný text. Tím zajistíte, že překladatelé a vývojáři budou přesně vědět, kde se řetězec používá.
