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

Kiedy decydujemy się na pracę we framework’u Scrum, to oczekujemy z tego jakiś 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.

Read more

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.

Read more

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

Read more

Kto znowu zmienił moje dane?!

Godzina 16.30, już wychodziłeś z pracy, w planie było kino i kolacja – i stało się… Zgłoszenie produkcyjne z wysokim priorytetem zostaje przypisane do ciebie. Już po godzinie wiesz, że przyczyną jest pewien wpis w bazie danych w tabelce z transakcjami, ale skąd się ten wpis tam wziął? Godzina 18:00, na szybko korygujesz wpis i aktualizujesz dane ręcznie, żeby zamknąć zgłoszenie. Jest 18:15 i masz nadzieję, że już więcej się to nie zdarzy – bo gdybyś chciał dojść do tego, jak ten wpis powstał, to pewnie byłby godziny analizy i pracy z debuggerem. Wychodzisz o 18:30, jeszcze wyrobisz się do kina, ale co będzie jeżeli zadzwonią znowu z tym samym problemem za pół godziny?

Read more

Warsztaty BSS/OSS w Warszawie dla rynku telekomunikacyjnego, 2016

8 czerwca 2016 miałem okazję brać udział w warsztatach BSS/OSS w Warszawie organizowanych przez Comarch dla rynku telekomunikacyjnego.
Warsztaty miały charakter mocno sprzedażowy, ale nie zabrakło momentów wskazujących bieżące kierunki rozwoju tej dynamicznej branży.
Nie zabrakło w wystąpieniach również wielu popularnych obecnie buzzword-ów takich jak IoT, M2M, customer expirience, czy już trochę przebrzmiałe big data.
Poniżej znajdziecie podsumowanie tematyki prezentacji i mam nadzieję, że wyczytacie coś ciekawego dla siebie :)

bssoss1

Read more

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.

Read more

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? Read more

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!” Read more