Trzecia kawa Szkolenie Scrum

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ścicielami 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. (więcej…)

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

(więcej…)

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?

(więcej…)

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

(więcej…)

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. (więcej…)

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? (więcej…)

IT – historie (nie)zwykłe, część II

Historie_niezwykle_2

Druga część mrocznych historii z branży IT. Tym razem rzecz będzie o prawdziwych piratach, kontraktorach i spotkaniu z przeznaczeniem.

(więcej…)

IT – historie (nie)zwykłe

yo-dawg-cool-story-dont-tell-it-againCzas płynie, a z nim przybywa ciekawych i czasem zatrważających doświadczeń z pracy w branży IT. Historie tu przedstawione miały miejsce w rzeczywistości. Opis poniższych przypadków nie ma na celu postawienia kogokolwiek w złym świetle, a zostały one spisane ku przestrodze i uciesze czytelnika.

(więcej…)

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!” (więcej…)

Szewc bez butów chodzi, czyli coś o narzędziach w IT

szewc_bez_butow_r0Firmy z branży IT, szczególnie w momencie szybkiego wzrostu z małego przedsiębiorstwa do korporacji, stoją przed wyzwaniem i pytaniem: “jak efektywnie zorganizować pracę?”.

Przy gwałtownym wzroście nieformalne metody współpracy i posługiwanie się skrzynką pocztową do zlecenia zadań przestają działać. Rozwiązaniem jest wprowadzenie narzędzi wspierających.
(więcej…)