Przejdź do treści

Stanisław Matczak

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.

Dowiedz się 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?Dowiedz się 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!”Dowiedz się 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.Dowiedz się więcej »Badając zwinność

Od menedżera do właściciela produktu

darth_vader_product_ownerDzień był szary, deszczowy i mglisty. Wystarczyłaby chwila spojrzenia na zasłonięty mgłą świat, aby zadumać się nad jesienią, przemijaniem i sensem… Na szczęście nikt w wielkim budynku biurowca nie miał czasu na patrzenie za okno – klimatyzacja utrzymywała stałą temperaturę 22 stopni Celsjusza, grube szyby broniły przed deszczem, a ludzie wpatrzeni byli w niebieskie ekrany monitorów, które wyświetlały raporty, maile, kody oraz – od czasu do czasu – zdjęcia małych kotków.

Do pokoju Stefana, młodego i zdolnego menedżera projektu, wszedł dyrektor działu rozwoju oprogramowania, przysunął sobie krzesło, usiadł na nim i powiedział tak:

– Słuchaj, jest taka sprawa. Centrala chce bardzo, żebyśmy byli adżajl i żebyśmy teraz projekty robili w skramie. Wybraliśmy twój projekt jako pilotaż, bo kiedyś mówiłeś, że coś o tym słyszałeś. Także zróbcie szybko tego skrama, wprowadźcie te biegi czy sprinty. Oczywiście cała zmiana nie może mieć wpływu na budżet – jest już ustalony z klientem, terminy są napięte, także nie możemy już niczego przesuwać. Tak za miesiąc potrzebuję prezentacji, która podsumowuje zalety skrama, będzie to rekomendacja dla pozostałych projektów.Dowiedz się więcej »Od menedżera do właściciela produktu

Dlaczego Scrum nie działa?

Scrum FailPewien zespół programistów postanowił wdrożyć w swojej pracy framework Scrum. Jedna z osób w tym zespole przeczytała książeczkę pod tytułem Scrum Guide i opowiedziała innym jak ten cały Scrum wygląda – opowiedziała o tym, że są sprinty, że ostatnio cały świat tak robi, że będą bardziej efektywni oraz że w ogóle będzie miło i przyjemnie.

Zabrano się do pracy. Ustalono role – Franek został Właścicielem Produktu, zaś Marek został Scrum Masterem. Ustalono, gdzie będzie trzymany backlog oraz nauczono się, że gotowe zmiany w kodzie od teraz nazywają się inkrementem. Ustalono długość sprintu, w kalendarzach pojawiły się nowe spotkania pod tytułem planowanie sprintu, codzienny scrum, przegląd oraz retrospektywa. Wszystko zaczęło się toczyć, właściciel produktu priorytetyzował zadania w backlogu, backlog produktu zmieniał się w backlog sprintu, backlog sprintu zmieniał się w inkrement, a wykresy spalania poruszały się to w górę, to w dół.

Wszystko miało być pięknie. Jednakże po pewnym czasie członkowie zespołu doszli do wniosku, że w zasadzie nic się nie zmieniło. Zadania są takie same, jakość dostarczanego produktu w zasadzie cały czas pozostawia sporo do życzenia, a odbiorca cały czas jest tak samo niezadowolony. I w zasadzie to po co nam ten cały Scrum, więcej z niego kłopotu niż pożytku…Dowiedz się więcej »Dlaczego Scrum nie działa?

Dokumentacja – od chaosu do bazy wiedzy

documents.pngPodczas prezentacji, które prowadziłem na tegorocznym GeeCON-ie oraz na Forum Jakości, największe zainteresowanie uczestników wzbudził temat porządkowania i cywilizowania dokumentacji dla dużych systemów IT. Co naturalne, najbardziej tematem zainteresowani byli przedstawiciele firm, które pracują z dużymi systemami i w poprezentacyjnych rozmowach widać było, że wszyscy zmagamy się z bardzo podobnym problemem.

Dowiedz się więcej »Dokumentacja – od chaosu do bazy wiedzy

GeeCON – notatki na marginesie konferencji

geecon_logo2Idea pracy informatyków jest bardzo prosta – tworzymy systemy, które mają jakieś zastosowanie. Możemy za ich pomocą zarezerwować hotel, stworzyć listę zadań w telefonie, założyć lokatę w banku, wymieniać informacje ze znajomymi, wyszukiwać produkty o najniższych cenach, szukać drogi w obcym mieście i robić wiele, wiele różnych rzeczy.

Ale pod powierzchni ą interfejsu systemu kryje się chaos. Kryje się cała masa kodu, danych, założeń, dokumentacji, interfejsów, usług, komunikacji, standardów…Dowiedz się więcej »GeeCON – notatki na marginesie konferencji

GeeCON – myśli zapożyczone

geecon_logoTym razem nie będzie pełnej relacji z konferencji. Będzie kilka nieuczesanych oraz zapożyczonych myśli z prezentacji, które podobały mi się najbardziej.

Patrick Copeland opowiadał o pretotypowaniu (pretotyping). Nie wiecie co to jest? Ja też nie wiedziałem. Pretotypowanie to jak najszybsze sprawdzenie, czy jakiś pomysł jest wart realizacji. Zamiast tworzyć prototypy (które kosztują) warto spróbować coś jeszcze prostego – po to, żeby jak najmniejszym wysiłkiem zrobić już jakąś ewaluację naszej idei.Dowiedz się więcej »GeeCON – myśli zapożyczone