Category: Scrum

Vše o Scrum procesu

Planning meeeting na 30 minut – část 2

Jak jsme již říkali v minulém článku, celý Planning meeting se komfortně vejde do 30ti minut. Pojďme se tedy podívat, jak vypadá jeho druhá část. Tým má vybrané User Story na tabuli a v rámci této fáze rozpadá jednotlivé funkcionality na konkrétní činnosti, které nebudou podle jejich předpokladu větší, než aby šly dokončit v rámci jednoho dne.

Na rozpadu pracuje celý tým najednou a paralelně plní tabuli lístečky s jednodenními tásky. Když jednotliví členové týmu rozpad dokončí, společně revidují, jestli na něco nezapomněli. Stejně jako v minulém případě, je dobré se podívat kolik tásků na tabuli vzniklo. Obecně platí, že User Story s vyšším ohodnocením se rozpadá na více drobných aktivit než menší User Story.

Ale není to matematika. Jestli jste naplánovali Sprint Backlog, kde počet lístečků odpovídá práci týmu na dva dny, máte buď příliš nízký commitment, nebo jsou jednotlivé tásky výrazně větší než jeden den, a nebo vám některé aktivity zcela chybí. Naopak, naplánovali-li jste tásků stejně jako je dnů*počet členů týmu, máte vysokou pravděpodobnost, že to nestihnete. Vždycky se něco protáhne a na něco jsme vždy zapomněli. Polovina tohoto čísla může být reálná.

Když jako tým souhlasíte s rozpadem, podíváme se ještě jednou na výsledný Sprint Backlog a eventuálně ho upravíme (přidáme / ubereme nějakou User Story) a o výsledném commitmentu informujeme Product Ownera.

Nutnou podmínkou takového rychlého Planningu je dobrá příprava. Tým nesmí vidět User Story poprvé na Planningu – už se s nimi dobře seznámil na Backlog Groomingu, kde je i ohodnotil. Zanedbat se nesmí ani příprava na rozpad User Stories na jednotlivé aktivity. Tým zná prioroty pro další Sprint několik dní dopředu a může si tak zavčas popovídat o řešení a připravit se na jejich rozpad.

Zkuste a uvidíte, že to není zas tak těžké, a že to funguje. A navíc, jako bonus ušetříte spoustu času a získáte kvalitnější Sprint commitment.

Planning meeeting na 30 minut – část 1

Často s týmy diskutuji na téma, že Scrum jsou jen samé meetingy. A tak začínám tím, že s nimi projdu, jak mají být jednotlivé meetingy dlouhé. Většinou se zasekneme na Planningu, který byste měli v pohodě zvládnout za 30 minut. Jak takový planning vypadá? Tým si nejdříve v cca 15 minutách vybere, které User Story z priorit Product Ownera by mohl dokončit. Ideální je, když opravdu fyzicky vybírá, které z kartiček na stole dá na svoji Scrum tabuli. Jednotlivé User Story a jejich business hodnotu si může tým ještě upřesnit s Product Ownerem, ale výběr je na nich.

Je tedy nasnadě, že jich Product Owner musí přinést dostatek, aby bylo z čeho vybírat. Tým tím přebírá větší zodpovědnost, a také musí produktu po všech stránkách více rozumět, než když jen bere User Stories jednu po druhé podle přesných priorit Product Ownera. Zároveň je to také často efektivnější, protože tým může vybrané User Story přizpůsobit svým zkušenostem a znalostem a optimalizovat tak dokončenou funkcionalitu v rámci priorit Product Ownera.

Fyzická reprezentace ve formě kartiček jako obvykle pomůže. Usnadňuje to týmu převzít kolektivní ownership a zodpovědnost za výběr. Jak jednotliví členové týmu navrhují, které User Stories by tým mohl stihnout, někde se to ve výběru zastaví. A členové týmu si již nejsou jisti, jestli by další věc stihli nebo ne.

Tým si může ještě udělat rychlá cross-check obvyklé velocity, když vyšlo řádově jiné číslo, tak je to dobrý indikátor k zamyšlení se, co nás vede k tomu, že toho tentokrát stihneme dvojnásobek, nebo naopak polovinu, a případné revizi návrhu Sprint Backlogu.

Tady první část Planningu končí, Product Owner i Scrum Master nechávají tým pokračovat druhou 15ti minutovou částí a odchází.

Jako včerejší počasí

Na jednoduchý problém existuje jednoduchá pomoc. Tým neustále overcommituje. Tedy slíbí sedm User Stories a dodá čtyři. Příští Sprint slíbí osm a dodá jen tři, další se zaváže dodat sedm a dodá pět. A tak to pokračuje Sprint po Sprintu. Když se zeptáte co s tím tým dělal, obvykle odpoví, že to řešili na retrospektivě a že příště už se to povede.

Jak dobře odhadovat, kolik se nám toho vejde do Sprintu? Tak předně věřte tomu, že obvyklé věci se dějí obvykle a výjimečné jen výjimečně. Tedy, že když několik sprintů za sebou dodáváte méně, než plánujete, tak se tak asi bude dít i v budoucnu. Důvody pro to se mohou různit, ale na úrovni týmu a Sprintu to vždycky vyjde.

Existuje rychlá medicína. Příští Sprint si do Sprint Backlog vezměte přesně tolik, kolik jste minule stihli dokončit. Takzvaně “včerejší počasí“. Ostatně říká se, že kdyby předpověď počasí byla dělaná podle včerejšího dne, že bude přesnější, než když se ji snažíme odhadovat. Nevím, jak s počasím, ale tady to funguje a výsledek se dostaví okamžitě. A teď, když už to umíme, tak se můžeme pozvolna zaměřit na to, jak rychlost týmu zvednout. Je to první úspěch a na tom se dá stavět. A můžete začít tím, že ho společně zajdete oslavit.

Backlog Grooming

Také se ptáte k čemu je Backlog Grooming? Cílem tohoto meetingu je zajistit, aby tým rozuměl celému Backlogu. Proto na úplně prvním Groomingu začínáme tím, že Product Owner v 15ti minutách představí vizi produktu /releasu a všechny Epicy. V druhých 15ti minutách představí střední vrstvu Backlogu, tzv. Super User Stories – tedy předpřipravené funkcionality, které přijdou na řadu za několik Sprintů. Nejsou ještě dostatečně malé ani úplně konkrétní, ale už mají obvykle formu User Story. Takových Super User Stories by mělo být připraveno na 5-10 sprintů. A zbývající čas Backlog Groomingu věnuje Product Owner konkrétním User Stories na vrcholu Backlogu. Ty už musí být INVEST, tedy jasné, konkrétní a dostatečně malé, aby se daly kdykoliv naplánovat a v rámci Sprintu dokončit. Takových User Stories potřebujeme v Backlogu na cca 2-3 Sprinty.
Backlog Grooming

Každý další Grooming už většinou Product Owner spolu s týmem prochází User Story podle priorit tak, aby měli pokaždé připraveno dostatek práce pro další Sprinty. Grooming se obvykle dělá v půlce Sprintu, aby v případě potřeby bylo dost času si danou funkcionalitu promyslet a to jak ze strany Product Ownera, tak týmu. Obvyklou součástí Backlog Groomingu je i ohodnocení User Stories Story Pointy, aby se Product Owner mohl rozhodnout na základě komplexity o prioritě, tým si ověřil, že to všichni chápou stejně a společně ev. dodefinovali akceptační kritéria, či User Story rozdělili.
Jak dlouho takový Backlog Grooming trvá? To záleží na přípravě, kterou tým jednotlivým User Stories věnuje, na připravenosti a kvalitě jednotlivých User Stories, a schopnosti efektivně komunikovat. První Groomingy obecně trvají dlouho, další mohou běžně trvat kolem 30-60minut.

Backlog Grooming

Chcete-li Grooming krátký, a navíc nemáte rádi meetingy, můžete zvážit jako tým na fotce ho dělat u tabule ve stoje. Určitě se omezí dlouhé nikam nevedoucí diskuse a posílí příprava týmu. Zároveň fyzická reprezentace umožňuje se zapojit do dodefinování User Stories každému, a nečekáte na Product Ownera až to dopíše do systému. Takže rozhodně doporučuju. Určitě to zkuste.

Je Scrum samospasitelný?

Nejhorší ze všeho jsou zkratky. Něco nám nefunguje, třeba dodáváme aplikace zákazníkům pozdě, s chybami a nevíme co s tím. Někde zaslechneme, že existuje nová metodika, jejímž jádrem je jakýsi Scrum. Tak si to rychle někde přečteme, zajdeme na školení a vše změníme, jenom abychom měli Scrum. Moc nad tím nepřemýšlíme, přeci Scrum je přesně tohle a tamto. Přesně dané postupy, jako v každé metodice. Když to budeme “přesně“ aplikovat, tak bude konečně vše dobré. Ale ono to tak často není. Ba co víc, z pohledu zvenku je vše stejné, nic se nezměnilo, a pohledem uvnitř je vidět spousta vyhozené energie na tuny meetingů které nic nepřináší. Máme sice jakýsi Scrum, ale výsledek je stejný. Kdo za to může? Scrum? My? My přece ne, takže je to jasné, Scrum.

Klidně můžeme říct, že Scrum je k ničemu. A můžeme mít i pravdu protože vás zázračně nezachránil. Ale problém je v tom, že tato změna není snadná. Neexistuje žádná kuchařka, co musíte udělat, aby to fungovalo. Jen sada doporučení, které by se daly shrnout do dvou principů:

  • Pochopte, jak vypadá správně Scrum a proč by tak měl vypadat. Rozlište co je důležité a co jen berlička která vám pomůže se se Scrumem sžít. I kdyby se ta představa zdála být nedosažitelná.
  • Začněte co nejdříve. Aplikujte maximum toho co je Scrum. A pak takový proces postupně měňte. Vyměňujte berličky, abyste se víc a víc blížili cíli.

Když neuspěcháte první krok, bude to fungovat. Slepé kopírování postupů často k cíli nevede. Ani Scrum není samospasitelný. Vlastní úsudek a zdravý rozum při implementaci je také velmi důležitý. Pak nás Scrum může a často také spasí.

Certified Scrum Master kurz CSM poprvé i v češtině, aneb jak se to stalo

Byla k tomu dlouhá cesta. Někdy před rokem jsem se potkala na Scrum Gatheringu v Indii s Bobem Hartmanem, který zastupoval na konferenci Scrum Allianci. Část konference party jsme diskutovali o tom, že Scrum Alliance chce změnu, že se chce více otevřít novým lidem, nebýt už tolik tím uzavřeným elitním klubem, co mezi sebe nepustí nikoho nového, bez ohledu na to, jestli je člověk dobrý či ne. A tak jsem si říkala, že je asi na čase to zkusit. Využila jsem pro to jejich provisional CST proces. A začala sepisovat žádost, takový aplikační balíček. Byla to docela legrace. Bylo toho opravdu hodně a bylo to hodně detailní. Zkušenosti, doporučení, cotrainingy, mentoring… Když to zkrátím, trvalo téměř rok, než jsem se dopracovala k interview a po pár dnech čekání na výsledek to tu bylo. Nejdříve PCST – tedy Provisional Certified Scrum Trainer. A krátce na to Certified Scrum Trainer – CST. O co těžší a méně přehledný ten proces byl, asi o to větší z toho mám nakonec radost.

Proč byste měli chtít CSM certifikaci? Neměli. Žádná certifikace z vás odborníka neudělá. A certifikační kurz není nutně v ničem lepší než ten bez certifikace… Ale pro spoustu lidí je to určitý krok dál. Někde si ho odškrtnou ve svém vlastním interním rozvojovém plánu. Já vlastně nikdy certifikace nechtěla a dostávala je tak trochu náhodou… ve správný čas na správném místě. A překvapivě je nikdo nechtěl ani po mně, což mě vždy udivovalo. A proč jsem se tedy do toho celého kolotoče se Scrum Alliance a CST tedy pustila? Asi abych si dokázala, že na to mám. Přišlo mi trapné říkat, že nepotřebujete certifikaci, stačí vám můj necertifikační kurz, ale žádný certifikační kurz sama nenabízet. Je to jako ta bajka o lišce a hroznech vína. “Stejně jsou kyselé,” říká liška, když zjistí, že ani omylem na žádný hrozen nedosáhne. A tak jsem si říkala, že nechci být jako ta liška. A proč zrovna Scrum Alliance a Certified Scrum Trainer (CST)? Asi že není snadné takovou CST certifikaci dostat. Tyhle hrozny se prostě zdály být nejvýš. Tohle všechno jsou asi často motivace lidí jako jednotlivců. Jako důvod můžete přidat lepší šanci uspět u pohovorů, ale to stejně v praxi moc nefunguje.

Proč ale firmy chtějí certifikaci? Asi abyste jako firma dodali celému procesu důležitost, my to opravdu myslíme vážně, a opravdu Scrum chceme nasadit. Vidíte? Anebo abyste svým novým Scrum Masterům pomohli vytrvat, vydržet všechna ta příkoří a složitosti, kterými si při Agilní transformaci musí projít, zvednout jim sebevědomí, že to dokážou. Zvládnou to, mají přeci certifikaci. To oni jsou ti, kteří znají Scrum a pomůžou vám ho nasadit a adaptovat tak, aby fungoval. Když se nad tím zamyslíte, asi na tom něco je.

Takže jestli žádnou certifikaci nechcete, je to fajn. Váš Agilní život nebude o nic méně úspěšný. Tedy za předpokladu, že se nestěhujete třeba do Indie, kde každým získaným certifikátem významně stoupá společenské postavení jednotlivce. Ale jestli vás certifikace láká, teď máte první a jedinečnou příležitost absolvovat CSM – Certified ScrumMaster kurz nejen v angličtině, ale i v češtině.

Správný Product Owner není úředník

Správný Product Owner má nápad, dokáže ho zformulovat do vize, a tu prodat jak zákazníkům, tak firmě i týmu, který pro něj pracuje. Spousta Product Ownerů ale je jen úředníky. Vychází z té armády business requirement specialistů, business konzultantů. Dělají to, co jim někdo řekne. To se ale přesně snažíme pomocí Agilních metod a Scrumu změnit. Proto jsme toho člověka udělali Product Ownerem, a ne jen Product úředníkem.

Jak takový produkt začíná? Ideálně si uděláme product charter. A to jak pro produkt jako takový, tak pro první release. Co to je a jaký to má formát. Je to snadné. Vše se vejde na jeden flipchart. Jméno, timeframe, elevator pitch – tedy jedna, dvě věty, které shrnují, co že to děláme a hlavně proč, vytváří obrázek, konkrétní jasnou představu cíle, vzbuzují emoce. Prostě vás zaujmou. A pak ve dvou sloupcích jako stručné odrážky cíle, kterých chcete dosáhnout a success measures, tedy jak poznáte, že jste toho dosáhli.

Product nebo Release Charter je klíčová věc. Bez ní ani nemá smysl se pouštět do psaní Backlogu a User Stories. A není to ani snadné. Když se do toho pustíte, bez ohledu na množství prezentací, které jste už o produktu vyrobili, zjistíte, že umět z toho všeho, co byste mohli dělat vydestilovat podstatu stojí čas a energii. A Product nebo Release Charter je přesně to, co vám roli Product Ownera jako člověka zodpovědného za funkcionalitu (tedy Backlog) a celkový úspěch produktu usnadní. Cílem toho “product úředníka“ z klasického světa totiž je daný nápad rozpracovat do šířky. Vymyslet co nejvíce funkcionality tak, abychom pokryli přání zákazníků a stakeholderů. Cílem Product Ownera ale je pravý opak. Nápady a přání omezit na minimální funkcionalitu, která zákazníkům přinese to, co opravdu potřebují. Dělat tedy ne to, co umíme a můžeme, ale jen to, co má nejvyšší business value. To, co potřebujeme. Jen takový produkt je potom agilní, a jen takový produkt bez ohledu na Agile a Scrum je úspěšný.

Jak vybrat Scrum Mastera aneb proč i zkušení Scrum Masteři selhávají v Agilní transformaci

Role Scrum Mastera není zdaleka snadná, a ne nadarmo se považuje za klíčovou k úspěchu týmu a nasazení Scrum procesu. Scrum Masterem je typově někdo jiný než se hodí na běžnou roli team leadera (který často vše určuje za tým), nebo experta (který se neptá, ale za tým rovnou odpovídá, protože jako expert zná vždy tu správnou odpověď), nebo projektového managera (který často mikromanaguje, vše řídí sám a to včetně organizace týmu, priorit a celé dodávky). Scrum Master není zodpovědný za dodání, ale za to, že tým funguje jako samoorganizovaný tým, že tým přebírá zodpovědnost za svůj vnitřní proces, že se zlepšuje, je motivovaný, prostě v dlouhodobém pohledu funguje optimálně. Krátkodobě klidně nechá tým v rámci Sprintu nedodat nic, ale nenechá takovou situaci vyrůst v běžný zvyk a obvyklý stav. Když máte plně Agilní firmu a zaběhnutý, zkušený tým, je to relativně snadné. Stačí najít Scrum Mastera, který rozumí Scrum procesu a podstatě své role, je vnímavý, empatický, umí naslouchat a dá týmu prostor, aby se sám rozhodoval a nesl v rámci procesu za svá rozhodnutí zodpovědnost. Koučuje, facilituje, staví tým. A tým funguje.

Problém nastává, když ale Scrum Mastera zvyklého takhle pracovat dáte do týmu, který ani neví, co je Scrum, proč jednotlivé praktiky aplikují a co by jim měly přinést. A takový Scrum Master si nevzpomene na své začátky, a jen pomocí coachingu a facilitace vykonává roli Scrum Mastera v ideálním týmu tak, jak byl zvyklý. To samozřejmě nestačí. Scrum Master musí být i mentorem a týmu Scrum proces vysvětlit, prodat. Ne přikázat, ale poradit. A postupně je učit Agilu jako mindsetu, Scrumu jako procesu, kde jde primárně o zodpovědnost, samoorganizaci. Čistý koučing a facilitace nestačí. Tým prostě neví co a jak. Nemá zkušenosti. Nikdy nic podobného nezažil.

Další častou chybou Scrum Mastera v začínajícím týmu (a takový tým může začínat i dva roky) je pocit, že tým musí ‘rychle začít fungovat a že vysvětlování ‘proč‘ by vše jen zdržovalo. Prostě jim řekne, jaké mají dělat meetingy a co na nich říkat, a žádným školením ani vysvětlováním proč to všechno se nebude zdržovat. Vždyť je to jasné. Výsledkem je v lepší případě technický Scrum. Bez pochopení, bez energie, bez výsledku. Takové loutkové divadlo. Kdo je za takový stav odpovědný? No zcela jistě nezkušený Scrum Master, který neupravil svůj styl týmu. Problém je, že na interview to často nepoznáte. Scrum Master ví, jaká je jeho role, co má dělat, ví proč a jak Scrum funguje, jen nepovažuje za nutné to týmu vysvětlit. Vždyť už agilní jsou, říkali to.

Dalším problémem, který je ve firmách častý, je Scrum Master idealista. Stejně jako v předchozích případech, na pohovoru vše vypadá dobře, ba ideálně. Scrum Master je pravým odborníkem na Scrum. Ví jak funguje, rozumí své roli, a v jednom dobře fungujícím týmu úspěšně Scrum Masteroval. Jen se často zapomene na to, že on ten Scrum neimplementoval a často ani nezažil v rámci větší organizace, a tedy se s mnoha problémy běžnými při transformaci velké organizace nikdy nesetkal. Stačilo rozumět Scrum procesu a mít nadšení. Ve velké organizaci ale nejde implementovat všechno hned a ideálně. Musíte dělat kompromisy. Zbytku organizace často trvá hodně dlouho, než Agilní proces vezme na vědomí a ještě déle, než ho akceptuje a pochopí. Předchází tomu hodně komunikace, diplomatického vyjednávání a PR. Ale Scrum Master idealista na nic nečeká a Scrum tlačí silou hlava nehlava. Product Owner musí, manager nesmí, tým neřekne, protože to není jeho zodpovědnost, proces se musí změnit, pozice upravit, ohodnocování změnit, … Výsledek je jak po procházce slona v porcelánu. Víc škody než užitku. A to nejen mimo tým ve zbytku organizace, ale i v rámci týmu, který takového Scrum Mastera často odmítne stejně jako v předchozích případech. Co z toho plyne? Transformaci velké organizace nemůžete nechat na lidech, co nikdy žádnou takovou organizaci neměnili a s podobnou transformací nemají zkušenosti. A to bez ohledu na to, jak dobrými se zdají být Scrum Mastery. Zdá se to být jasné, ale firmy si často roli Agilních coachů se Scrum Mastery pletou a pak jsou překvapení, že Scrum Master se neosvědčil.

Proč máme Product Ownera

O roli Product Ownera toho bylo napsáno hodně. Přesto však některé firmy nepochopily jeho význam a berou takového člověka jako administrativní sílu. Ostatně, kdo jiný by měl mít čas být týmu k dispozici a psát jasné a konkrétní User Story. Product Manager na to nemá čas, v lepším případě je furt u zákazníka, v horším řeší takových produktů několik nebo jen tráví většinu času na obecných firemních mítincích a stihnout to ani při nejlepší vůli nemůže. V obou případech se pak velmi často setkáváme s modelem, kdy o všem rozhoduje Product Manager, který ale nemá čas, a takzvaný Product Owner se na všechno chodí ptát, protože o čemkoli rozhodne, stejně Product Manager shodí při customer demu ze stolu. Vychází to z neochoty a často i neschopnosti delegovat, nesmyslné organizaci, a také toho, že takový Product Owner není nositelem vize a sám jí často nerozumí. Jak se to pozná? Zeptejte se ho, proč by tým měl na produktu pracovat. Většina takových Product Ownerů odpoví něco ve smyslu, že to asi firma potřebuje… že… Když tím testem přeci jen projde, obvykle se zasekneme hned na další otázce, proč děláme tuhle User Story. A kde je její business value. Co přinese zákazníkovi? A obvyklá odpověď je ‘no Product Manager nebo zákazník to tak chce‘. Kde se pak má brát motivace a zapojení týmu a proč by zrovna na tomhle produktu měli pracovat?

Samozřejmě i takové rozdělení role Product Ownera mezi více osob může fungovat. Jeden příklad z nedávné praxe. Máme Product Managera co nemá moc čas. Je to vizionář, většinu času cestuje po světě a je v letadle. Oblítává zákazníky z různých koutů světa, vymýšlí inovace, dívá se, co má konkurence. Aby tým nebyl od produktu odtržený, není tento člověk vnímán v roli plného Product Ownera, ale spíše interního zákazníka, co chodí s high-level nápady. Product Owner je s ním v častém kontaktu, sdílí spolu nápady a vize, přemýšlí, co by se mělo jak udělat, co změnit. Product Manager je zodpovědný za budget a celkový úspěch produktu na trhu. V podstatě by šlo i říct, že definuje Backlog na úrovni Epiců maximálně velkých Super User Stories, zatímco reálný Product Owner se za pomoci týmu stará o to, aby vznikla správná granularita User Stories a tým byl na produkt, vizi a business value napojený. Je součástí Backlog Groomingů, je zodpovědným za Product Backlog, jeho hodnotu a porozumění týmu. Výhodou je, že takový Product Owner má v roli Product Managera zástupce, a když se stane, že z nějakého důvodu není k dispozici, tak Product Manager převezme jeho roli a tvoří s týmem User Stories. Je to tedy jen o lidech. Tihle to zvládli rychle a nejsou zdaleka jediní. Ale není to bohužel zdaleka tak obvyklé, jak by bylo potřeba.

Další obvyklý problém v této oblasti je neschopnost firem se nad portfoliem produktů zamyslet a nějak je omezit nebo prioritizovat a serializovat. Takové firmy si myslí, že tím, že se na produktu už pracuje, je zajištěna jejich úspěšnost. Musíme dělat všechno najednou. A tak se některé firmy podobají střelcům s automatickými zbraněmi, co sice mají zavázané oči, ale o to více střílejí kolem sebe. Čím více výstřelů, tím větší pravděpodobnost že se do něčeho nakonec trefíte… S takovou strategií vám v efektivitě a úspěšnosti nepomůže nic. Ani Agile, ani krásný formát User Stories. Role Product Ownera je tu proto, aby se někdo staral o to, co nám to přinese a s pomocí agilních metod dostal na business nápady rychlou zpětnou vazbu. Když se to neosvědčilo, zahoďte to a zkuste něco jiného. Ale na to musíte mít již v začátku jasnou představu, co chcete dosáhnout a jak poznáte, že se to povedlo. Jinak střílíte kolem a doufáte, že se to tentokrát povede. Agile a Scrum není jen o týmu a spolupráci, ale je o napojení na business a zpětné vazbě. Je o schopnosti prioritizovat. A to nejen na úrovni User Stories a každého produktu, ale i produktů v rámci firmy. A to se bohužel ve spoustě firem neděje.