Tag: retrospekcja

Is User Always Right? Are There Any Tools to Prove It? Review of User Experience Tools – Retrospekcja

Już na wstępie, można się pokusić o rozważania, co by zrobił Henry Ford (znany min. z cytatu: if I had asked people what they wanted, they would have said faster horses - przyp.red), gdyby teoretycznie nie tylko posłuchał ludzi, ale zrobił badania i zweryfikował wyniki. Jakie rezultaty dałoby oglądanie ludzi przy pracy w polu, a jakie w trakcie całodziennej podróży koniem (etnografia czy grupa fokusowa?!). A co jeśli by zapytał o zdanie i nie tylko nie powstałaby era motoryzacji, ale może… no właśnie, może szybciej nauczylibyśmy się latać albo postęp transformacji biotechnologicznej byłby już starszy o wiek! Do tego już nie dojdziemy, ale zachęcona do refleksji nad własnym artykułem, mam kilka przemyśleń i wątpliwość, czyli sama sobie dam feedback.

Retrospekcja projektu on-line. Project Managera skrzynka z narzędziami, cz. V

Jednym z najważniejszych elementów projektu, które determinują również efekt przyszłych naszych działań projektowych jest na pewno retrospekcja, czy, jeśli ktoś woli bardziej kaskadowe podejście, groma­dzenie lessons learned. Powinna odbywać się regularnie i dostarczać nam wiedzy i in­spiracji do doskonalenia naszej pracy. Ma być to moment w projekcie, podczas któ­rego nabieramy oddechu, siadamy i zasta­nawiamy się nad tym co do tej pory nam wyszło, a co wymaga poprawy.

Skuteczna retrospektywa w zespole rozproszonym. Project Managera skrzynka z narzędziami, cz. XI.

Agile to już na tyle popularny sposób pracy projektowej w międzynarodowych firmach, które mają siedziby w wielu krajach, że coraz częściej słyszymy o zespołach roz­proszonych. Tym samym coraz rzadziej je­steśmy w stanie, zgodnie z szóstą zasadą Agile Manifesto, mieć zespół w jednej loka­lizacji, siedzący razem i wspólnie pracujący. Niektóre podejścia wychodzą naprzeciw tym wyzwaniom i uwzględniają pomocne praktyki dla zwinnej pracy zespołów roz­proszonych. Najczęściej wykorzystywany jest nadal Scrum i tu często rozmawiając ze Scrum Masterami słyszymy, że ich pro­blemem jest to, że zespół jest pracujący w kilku lokalizacjach, nierzadko w różnych strefach czasowych.