Trzecia kawa

Zwinne szkolenia i nie tylko...

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

[…]

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?

[…]

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

[…]

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.

[…]