Dokument czy mapa?

…czyli o różnicy między zapisywaniem dokumentu z wymaganiami, a tworzeniem mapy historyjek.

Tworząc oprogramowanie często zaczynamy od jakiegoś konceptu lub wyobrażenia – próbujemy określić, co nasz system ma robić albo jaki problem ma on rozwiązywać. Bardzo często narzędziem do zapisania tego konceptu staje się edytor tekstu. Tworzymy dokument, który opisuje kształt naszego rozwiązania. Bardzo często dokument ten otrzymuje tytuł „Analiza wymagań systemu XYZ”.

W samym pomyśle zapisania koncepcji lub wymagań nie ma nic zdrożnego. Natomiast często w praktyce bywa tak, że praca nad systemem oparta o obszerny dokument tekstowy niesie za sobą niepożądane skutki uboczne…

[…]

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ć!

[…]

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?

[…]

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:

[…]

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.

[…]

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.

[…]

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?”.

[…]

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.

[…]

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? […]

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!” […]