Zuzi's blog

Jedním z často skloňovaných výrazů je ‘self-organized‘ tým. Týmy přecházející na agilní metody často začínají ranním Scrum meetingem, jako první zaváděnou praktikou. Jistě pomůže při sdílení informací a posílí týmovou spolupráci, ale nedá sám o sobě jednotlivým lidem pocit, že i na jejich názoru záleží, a že je tedy jen na nich, jak si vše [...]

[Read more →]

Reflection meeting je další důležitou součástí Agilních metod. Vychází se z toho, že je v praxi těžké nastavit procesy napoprvé a bez dobré zpětné vazby od lidí co se jimi mají řídit. Agilní metody proto pracují v cyklu. Vždy po několika cyklech je vhodné se zastavit, poodstoupit a podívat se jestli navržený proces funguje. Není [...]

[Read more →]

Máte ve Vaší firmě týmy v různých lokalitách? A dokonce v různých časových pásmech? Nebo využíváte pro práci často externisty? Dá se tedy Scrum který je přímo postavený na psychologii týmové spolupráce a kooperace, intenzivní komunikaci a sdílení informací použít v takto distribuovaném prostředí? Ano, ale přinese to s sebou spoustu obtíží, které byste nemuseli [...]

[Read more →]

Určitě jste se setkali s jistou nedůvěrou zákazníků ke Scrum procesu. Takže co s tím? Otevřete-li si knihu Art of War od vojevůdce Sun Tsu, jedna z nabízených strategií je “When you are going to attack nearby, make it look as if you are going to go a long way; when you are going to [...]

[Read more →]

Jedním z nejčastějších problémů na které narazíte, budou diskuze kdy je úloha dokončená a co dělat když z nějakých procesních důvodů dokončit v rámci Sprintu nejde (např. čeká se na review konkrétní osoby). Samozřejmě že ‘tým za to přeci nemůže‘ a tedy si přeci musí vzít body z dané úlohy. A že dokončení je již [...]

[Read more →]

Podíváte-li se na běžné softwarové projekty, většina z nich končí daleko po naplánovaném konci. To je samozřejmě způsobeno několika faktory. Tím kdo plán dělá, nakolik je zkušený, nakolik umí odhadnout, co všechno bude potřeba naimplementovat, nakolik je obeznámen s procesem vývoje a samozřejmě kvalitou a spolehlivostí vstupní specifikace. Zkusme ale začít u jednotlivých vývojářů. Kolik [...]

[Read more →]

Dalším z klíčových prvků plánování je rychlost, kterou tým pracuje. Měří se samozřejmě na body, které si tým započítává za dokončené úlohy. Na začátku každého projektu budete mít pozvolný náběh, kdy se tým seznamuje s úkolem, specifikací, technologií a architekturou. A učí se. Učící křivka bude stoupat po dobu cca 1-3 sprintů v závislosti na [...]

[Read more →]

Podíváte-li se na software development projekty, dost část se Vám stane, že nejsou dostatečně dobře časově odhadnuty. Samozřejmě částečně je to dáno špatnými odhady vývojářů. Často je ale hlavním problémem nejasná specifikace na začátku, která se v průběhu stále upravuje a designe a architektura se pak neustále předělává. V tom úplně nejhorším případě na konci [...]

[Read more →]

Ideálně byste měli podpořit soutěživost. Je-li to možné, sestavte týmy dva. Neměly by být ani moc malé – to by omezovalo znalosti a spolupráci v rámci týmu, ale na druhou stranu ani moc velké. Ideálně tak asi 5-10 lidí. Podaří-li se Vám sestavit týmů více, nezapomeňte na komunikaci mezi nimi. Jednou z dobrých praktik je [...]

[Read more →]

Angličtina má pěkný výraz na vnímání komunikace na pozadí – Osmotic communication. Je to velmi efektivní způsob jak udržet všechny v obraze co se děje, a jak zajistit aby si vzájemně nabízeli radu bez formálního požadavku. Je to způsob, jak se informace šíří samy na pozadí a lidé si z nich zapamatují jen to co [...]

[Read more →]