Často se stává, že testeři pracují na dvou nebo více projektech. V určitých případech to možné je a nemusí to přinášet žádná negativa. Podle mě ale tento přístup není dobrý a z dlouhodobého hlediska také neudržitelný. Jaké jsou pro a proti, když tester sedí „na dvou židlích“?
Jedno zenové přísloví praví, že když lovíte dva zajíce zároveň, nechytíte ani jednoho. Myslím, že tohle přísloví přesně sedí na situaci, kdy musíme svoji pozornost dělit mezi více projektů. Během takového lovu můžeme nabrat více zkušeností, ale nemusíme se každý den vrátit s kořistí a naopak nás taková aktivita více vyčerpává. Ve výsledku tak spíše strádáme a s ustupujícími silami klesá také naše šance na úspěch.
Při testování na více projektech můžeme získat více zkušeností. Pracujeme s různými technologiemi, používáme více nástrojů a jsme součástí více týmů. To je bezesporu výhoda. Na druhou stranu ale nemáme prostor pro lepší proniknutí do projektu a učící křivka je spíše pozvolná. Může nám připadat, že toho „víme“ víc, ale hloubka našich znalostí není tak vysoká, jako když se věnujeme jen jednomu projektu.
Podle mého názoru by měl tester mít o projektu největší přehled z celého týmu. To je ale věc, kterou při testování na více projektech nejde moc zaručit. Obsáhnout dokonale všechny projekty je náročné a stresující, což může snadno vést například k tomu, že něco přehlédneme, nebo dokonce vynecháme, protože na to jednoduše nemáme prostor. Je důležité mít v takovém případě k dispozici kvalitní dokumentaci a současně dokumentovat vše, co děláme (například formou test cases). Máme tak lepší přehled o tom, co děláme a současně máme i větší jistotu, že jsme na něco nezapomněli.
Organizace práce je něco, co může být při testování na více projektech, velký problém. Chodíme na více meetingů, řešíme více záležitostí naráz a často musíme „přepínat“ kontext. Podle výzkumu University of California trvá 23 minut, než se člověk dokáže opět „ponořit“ do práce po tom, co ho někdo vyruší. Určitě si dokážete představit situaci, kdy začnete ráno řešit nějaký úkol, potom jdete na meeting a než se stihnete po meetingu znovu „ponořit“, jdete na další, nebo vás někdo vyruší s dotazem. V takové situaci se věci těžko dotahují „do konce“ a úkoly, které jste si na daný den naplánovali, se často táhnout do dalších dnů.
Proto je důležité si den správně naplánovat. Vytvořte si v kalendáři „okna“, kde si naplánujete konkrétní úkoly nebo prostě jen čas, ve který budete řešit problém. Uvědomte své kolegy, že v tento čas nemůžete reagovat na jejich dotazy. Snažte se také práci na projektech rozdělit v rámci celého týdne. Vyčleňte si určité dny na určité projekty a snažte se také přeorganizovat týmové meetingy tak, aby jste byli účastní alespoň na těch nejdůležitějších.
Myslete také na to, že při práci na více projektech, máte opravdu méně času. Při plánování tak počítejte pouze s takovou kapacitou, kterou máte skutečně k dispozici. To, že jste v kanceláři celý týden, neznamená, že jste celý týden k dispozici pro daný projekt. Bohužel budete muset některé meetingy vynechat, což vám současně ubírá přehled o projektu a často vám tak může něco „utéct“.
Často také dochází ke konfliktu, například ke konci scrumového sprintu. To je situace, kterou vlastně nejde moc dobře řešit zvlášť v případě, kdy mají jednotlivé projekty stejný cyklus. Pokud je to jenom možné, zkuste změnit cyklus projektů tak, aby bylo možné být ke konci sprintu k dispozici na každém projektu.
Nejhorší situace nastávají v době releasování, kdy tlak na testování zpravidla roste a pokud se vám sejdou dva release naráz, je to v podstatě neřešitelná situace.
Vždy tedy komunikujte se svým týmem, scrum masterem i product ownerem o tom, jakou máte kapacitu i na ostatních projektech.
