Stanisław Matczak

Po co nam ten Product Owner? (historia ilustrowana)

Zdarza się czasami, że rozmawiam z kimś, używamy tych samych wyrazów, wydaje się, że rozmawiamy o tym samym – i niespodziewanie w rozmowie pojawia się niezrozumienie lub zdumienie. Często wówczas odkrywamy, że co prawda używamy tych samych słów, ale zupełnie inaczej je rozumiemy…

Kiedy rozmawiam o wytwarzaniu oprogramowania, takie niezrozumienie często pojawia się przy terminie Właściciel Produkt. Zdarza się, że ktoś mówi „tak, mamy oczywiście właścicieli produktów” – a później okazuje się, że opisuje rolę menedżera albo kierownika projektu.

Po co nam Właściciel Produktu i czym ta osoba różni się od Kierownika Projektu? Spróbujmy to sobie narysować!

Czytaj więcej »Po co nam ten Product Owner? (historia ilustrowana)

Nie używamy metryk, bo…

Na portalu AgileBrains Przemek napisał bardzo dobry tekst „Metryki w Scrum – Jak mierzyć efektywność wdrożenia Scruma?”. Po przeczytaniu tego artykułu można odnieść wrażenie, że bardzo łatwo jest zacząć mierzyć i odkrywać nowe wymiary efektywności. Bułka z masłem. Albo kawałek ciastka, jak mawiają Amerykanie.

Tymczasem w organizacjach, z którymi pracowałem, bardzo rzadko spotykałem się z używaniem wartościowych metryk. Dlaczego tak jest? Dlaczego mamy dostępnych sporo ciekawych metryk – a tak rzadko ich używamy?

Czytaj więcej »Nie używamy metryk, bo…

Dlaczego trudno być dużym i zwinnym

W 2012 roku Henrik Kniberg opublikował krótki film, w którym wyjaśnia ideę „Agile Product Ownership in a Nutshell”. Filmik zdecydowanie warto obejrzeć – a ja dzisiaj chciałbym wykorzystać obrazek z tego filmu do zastanawienia się, dlaczego dużym organizacjom IT trudno jest zwinnie rozwijać produkty.

Naszkicowany przez Kniberga obraz zwinnego wytwarzania produktu wygląda tak:

Czytaj więcej »Dlaczego trudno być dużym i zwinnym

Dlaczego Scrum nie działa – część 2

Kiedy decydujemy się na pracę we framework’u Scrum, to oczekujemy z tego jakichś korzyści. Zresztą obiecuje nam to sam Scrum Guide mówiąc, iż dzięki Scrumowi możemy „wytwarzać produkty o najwyższej możliwej wartości”.

Czasami jednak wprowadzamy takie rzeczy jak „sprint”, „backlog” i „właściciel produktu” – a jednak nie dostrzegamy żadnych benefitów. Mamy poczucie, że tracimy czas na planowaniach, stand-upach i przeglądach, a nie dostajemy nic w zamian…

Przyczyny takiego stanu mogą być oczywiście różne – w tym tekście chciałbym omówić jedną z nich, którą jest brak barier chroniących zespół deweloperski.

Czytaj więcej »Dlaczego Scrum nie działa – część 2

Ilu Właścicieli Produktu potrzebujesz?

Zdarzyło mi się kiedyś usłyszeć takie słowa „No to mamy tego Scruma, ale mamy mały problem z Właścicielem Produktu…”. „Hm, a co to znaczy: mały problem?” – zapytałem. „W zasadzie to problem polega na tym, że go nie ma…”.

Scrum Guide mówi jasno: żeby nazywać swoją pracę Scrumem, musisz mieć wszystkie elementy opisane w tym przewodniku. Jednym z najważniejszych elementów Scruma jest rola Właściciela Produktu – jeżeli go nie ma (albo jeżeli z jakiegoś powodu nie pełni swojej roli, albo jest więcej niż jedna osoba zarządzająca backlogiem), to po prostu nasza metoda pracy nie jest Scrumem, tylko czymś innym.

I tutaj często pojawia się kolejne zastrzeżenie: „Ale nasz produkt jest tak skomplikowany, że nie ma żadnej osoby, która potrafiłaby go zrozumieć i pełnić taką rolę!”. Przyjrzyjmy się zatem, w jaki sposób różne metody i frameworki radzą sobie z problemem zarządzania złożonym backlogiem.

Czytaj więcej »Ilu Właścicieli Produktu potrzebujesz?

Umowy i zaufanie

Ostatnio miałem przyjemność prowadzić szkolenie na temat zwinnego wytwarzania oprogramowania dla pracowników jednej z dużych firm informatycznych. W trakcie gdy mówiłem, widziałem w twarzach uczestników narastającą konfuzję i zwątpienie. Aż wreszcie jeden z nich wypowiedział to, co nurtowało zapewne ich wszystkich: „Ale czy w ogóle można tak pracować? A gdzie umowa z klientem? A gdzie wpisujemy zakres prac? A ustawa o zamówieniach publicznych? A jaki klient na to pójdzie?”.

Czytaj więcej »Umowy i zaufanie

O zwinnym remontowaniu

remont1Przez kilka wakacyjnych dni razem z dwójką przyjaciół remontowaliśmy niewielkie mieszkanie. I nieoczekiwanie sposób naszej współpracy zaczął mi bardzo mocno przypominać słowo „agile”…

Rozpocznijmy od przedstawienia projektu: naszym celem było wyremontowanie mieszkania, ponieważ zmieniała się nieco jego funkcja. Zespół do wykonania prac składał się z trzech osób. Mieliśmy inwestora (vel właściciela produktu…), 6-dniowy termin na wykonanie zadania oraz dość ściśle określony budżet projektowy.

Czytaj więcej »O zwinnym remontowaniu

Co tak naprawdę robi Scrum Master?

Na piętnastu stronach Scrum Guide’a – podstawowego dokumentu opisującego ten framework – roli Scrum Mastera poświęcona jest jedynie jedna strona. Na tej stronie znajdziemy kilkanaście punktów opisujących, w jaki sposób Scrum Master (albo pisząc krócej: SM) wspiera Właściciela Produktu, Zespół Deweloperski i całą organizację oraz przeczytamy definicję, iż SM to „servant-leader” zespołu. Tylko tyle.

Osobiście mam poczucie, że wyobrażenie o sposobie działania SM wśród znanych mi deweloperów jest bardzo różne. Niektórzy wyobrażają sobie SM jako osobę, która organizuje spotkania, inni jako osobę która usuwa przeszkody z drogi zespołu, inni jako kierownika-bez-prawa-do-podpisywania-urlopów, jeszcze inni jako osobę, która chodzi i sprawdza czy wszystkie zadania są wpisane w odpowiednie miejsca. Te wyobrażenia często mocno bazują na tym, co usłyszeliśmy o roli SM albo na tym, jakich SM w swoim życiu spotkaliśmy. A bazowanie na wyobrażeniach może łatwo doprowadzić do nieporozumień…

Może więc warto poświęcić kilka akapitów na przybliżenie tej roli?Czytaj więcej »Co tak naprawdę robi Scrum Master?

Jak to się robi w Story Point’ach

Jeżeli używamy tradycyjnych metod rozwoju oprogramowania, najczęstszą jednostką szacowania pracy jest osobodzień, osobogodzina czy osobomiesiąc. Przy szacowaniu jakichś zmian czy projektów możemy usłyszeć: „ta zmiana to trzy dni pracy” lub „ten projekt to pięć miesięcy pracy dla jednej osoby”.

Jeżeli wprowadzamy w organizacji metody zwinne, to prędzej czy później zjawia się jakiś TrueAdżajMaster, który mówi: „proszę państwa, osobodni są już passe, to jest przestarzały waterfall, prehistoria i epoka kamienia łupanego, prawdziwy AdżajDeweloper szacuje wyłącznie w Story Pointach!”Czytaj więcej »Jak to się robi w Story Point’ach

Badając zwinność

agilecatW kwietniu i maju bieżącego roku BPM Laboratory uniwersytetu w Koblenz przeprowadziło badanie zatytułowane Status Quo Agile. Celem badania było zebranie doświadczeń różnych organizacji w zakresie wykorzystania zwinnych metod zarządzania projektami. W ankiecie wzięło udział ponad 600 respondentów, a opracowanie jej wyników można pobrać ze strony http://www.status–quo–agile.net/.

Dlaczego to badanie jest ciekawe? Dlatego, że mówiąc o zwinności w organizacjach, zazwyczaj wypowiadamy się na temat kilku-kilkunastu projektów, które dane nam było prowadzić czy zobaczyć. Tutaj zaś mamy zebrane z opinie z wielu różnych firm i organizacji.

Celem tego artykułu nie jest streszczanie 142-stronicowego raportu lecz wybranie z niego kilku fragmentów, które wydają mi się najciekawsze.Czytaj więcej »Badając zwinność