Kategorie
Podcast Hansei Talks

Scrum Master i software house (rozmowa z gościem)

Rozmowa z Kariną Człapińską – jak wygląda praca Scrum Mastera w software house.

Jak wygląda praca Scrum Mastera w software housie? Czym się różni od pracy z zespołem rozwijającym swój własny produkt? Na tego typu pytania znajdziecie odpowiedź w dwunastym odcinku Hansei Talks! Zaprosiliśmy do podcastu Karinę Człapińską, która ma kilka fajnych spostrzeżeń. Te spostrzeżenia pochodzą z pierwszej linii frontu, ponieważ na codzień Karina pracuje w software housie Neoteric. Gotowi? Zapraszamy do radioodbiorników ;-)

🤓 Naszego podcastu możesz posłuchać na platformach:
Spotify / Google Podcasts / Apple Podcasts / Overcast / Pocket Casts / Radio Public

Karina Człapińska – entuzjastka pracy zwinnej. Pracowała jako Agile Project Manager i Scrum Master, a obecnie pełni rolę Lidera zespołu Agile Delivery w gdańskim software housie Neoteric. Swoją energię i czas inwestuje w budowanie produktów. Uwielbia pracować z ludźmi. Kiedy wychodzi z butów lidera to jest prawdziwym maniakiem filmów i seriali. Jeśli nie odróżniasz bohaterów Marvela od DC albo nie oglądałeś Suits to raczej nie zostaniecie przyjaciółmi.


Nie przegap kolejnych fajnych postów i podcastów! Zapisz się na newsletter!

Przetwarzamy…
Udało się!

2 odpowiedzi na “Scrum Master i software house (rozmowa z gościem)”

Hej, mam pytanie, w związku z tym, że praca nad projektem czasami trwa bardzo krótko to na ile tak na prawdę pracując z jednym zespołem przez 3 miesiące jesteśmy w stanie zapewnić odpowiedni poziom zwinności? Czy nie jest tak, że żeby być na prawdę zwinnym zespół musi być jednak „long lived”?

Hej, czas trwania projektu nie musi tutaj determinować technik czy metod pracy. Praca zwinna sprawdzi się tam gdzie mamy dynamiczne środowisko i szybko zmieniające się warunki. Wówczas iteracje pomagają nam sprawnie adaptować się do tych zmian. Nie chcemy dopuścić do sytuacji, w której budujemy coś przez 3 miesiące i na końcu użytkownik dostaje coś czego już nie potrzebuje. Dlatego pracujemy iteracyjnie, aby móc zbierać feedback i szybko reagować na zmieniające się potrzeby. Wówczas jeśli dowiemy się, że coś co wykonaliśmy nie zostało dobrze odebrane przez userów to przeróbki kosztują nas jeden sprint vs 3 miesiące pracy, która by poszła do kosza. Dodatkowo w każdej iteracji zespół się uczy. Także jeśli wiesz, że szacowany czas trwania projektu to 3 miesiące to wybierz krótsze iteracje. Po każdym takim sprincie na pewno w trakcie retro wyjdą Wam już jakieś wnioski co można poprawić następnym razem.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *