Skip to content

agile

Rozpoznawanie „Agile Bullshit”

Watergile manifesto


Dziś wszystkie projekty w IT „by default” są Agile. Na rozmowach kwalifikacyjnych padają pytania o metodologię Agile i czym to się różni od Scruma. Nawet na późniejszych rozmowach technicznych, dużo osób twierdzi że ich projekty są Agile-ish.

Aby pośmiać się z problemów (zwłaszcza w dużych firmach) związanych z wprowadzaniem na siłę zwinności stworzyliśmy fanpage na Facebooku – Watergile. To jest taki trochę śmiech przez łzy, który traktujemy jako wentyl negatywnych emocji związanych z codziennymi przygodami w projektach.

W związku z tym postanowiłem podejść do tematu trochę poważniej i ruszyć z dyskusją na temat „Agile Bullshit”. Chciałem stworzyć pytania, których odpowiedzi wykryją ściemę. Efektem tego była dyskusja na reddicie i zebranie w jednym miejscu kilku pytań, które możesz zadać na rozmowie kwalifikacyjnej. Oryginalna dyskusja w języku angielskim znajduje się tu.

Oto 10 wybranych przeze mnie pytań:

  1. Jak testujecie swój kod? Złe odpowiedzi: „Mamy niezależną organizację testującą”, „Testerzy są odpowiedzialni za testowanie”, „Testuje klient”. Dobra odpowiedź: „Mamy CI i każdy merge do developa odpala testy jednostkowe, integracyjne a po deployu lecą testy E2E pisane przez zespół.
  2. Jaki poziom automatyzacji macie w swoim developmencie, testowaniu, zapewnieniu bezpieczeństwa i deploymencie. Złe odpowiedzi: „Mamy CI ale deployment robimy ręcznie”, „Krzysiek odpowiada za deployment”, „Testy automatyczne? Mamy unit testy i developerzy są zobowiązani je uruchamiać przed pull requestem.” Dobra odpowiedź: „Programiści pushują zmiany na branch, wystawiają pull request który przechodzi code review a reszta dzieje się automatycznie sama.”
  3. Kim są wasi użytkownicy i jak wygląda interakcja z nimi? Złe odpowiedzi: „PM/BA kontaktują się z użytkownikami. Staramy się odseparować programistów od użytkownika, żeby nie tworzyć zamieszania.” Dobra odpowiedź: „Mamy Jirę/Confluenca (lub inne podobne narzędzia), w której użytkownicy mogą zgłaszać pomysły na usprawnienia, rozmawiać z nami. Po każdym sprincie robimy demo i słuchamy feedbacku”.
  4. Ilu programistów/testerów jest częścią organizacji odpowiadającej za budżet i kamienie milowe programu? Złe odpowiedzi: „Nie wiemy”, „Zero”, „To zależy jak zdefiniujesz programistę/testera”. Dobra odpowiedź: „Team lead ma wpływ na budżet i zasoby projektowe, QA lead ma wpływ na zasoby projektowe. Obaj mogą zwiększyć np. ilość wirtualnych maszyn lub ludzi przed releasem na proda”.
  5. Jakie macie metryki dla developmentu i deploymentu? Jak często używacie ich i w jaki sposób do wykrywania problemów. Jak często rozmawiacie o metrykach z menadżerami?
  6. Czego nauczyliście się podczas ostatnich trzech sprintów i co z tym zrobiliście? Złe odpowiedzi: „A czym jest sprint?”, „Czekamy na zatwierdzenie naszych propozycji przez menadżerów”. Dobra odpowiedź: „Na retrospektywie wskazaliśmy problem X,Y,Z. Udało nam się poprawić Z, bo X i Y czeka na akceptację budżetu.”
  7. Kim są użytkownicy którym dostarczacie działający program na koniec sprintu? Czy możemy z nimi rozmawiać? Złe odpowiedzi: „Nie przekazujemy działającej aplikacji bezpośrednim użytkownikom”, „Od rozmów z użytkownikami są analitycy”. Dobra odpowiedź: „Robimy tą aplikację dla firmy X. Jej pracownicy i zarazem użytkownicy końcowi aplikacji na koniec każdego sprintu są obecni na demo i zbieramy od nich feedback”.
  8. Ile czasu zajmuje, od momentu zgłoszenia zapotrzebowania, aby nowa funkcjonalność została zaimplementowana w aplikacji? Zła odpowiedź: „Mamy pipeline na takie usprawnienia, przechodzi to przez ręce analityka i product ownera, którzy po uporaniu się z tym wrzucają to do backlogu. Reszta już zależy, czasem nigdy nie implementujemy, a czasem jeszcze w aktualnym sprincie”.
  9. Czy feedback od użytkownika zostaje przekuty na konkretne zadania przypisane programistom? Czy zespół może samodzielnie wprowadzać zmiany do aplikacji na bazie feedbacku użytkownika? Zła odpowiedź: „Od wprowadzania zmian jest PO i tylko on może ruszyć backlog.”. 
  10. Czy cały ekosystem projektu jest prowadzony w metodologii Agile? (np. zwinne wytwarzanie oprogramowania, po którym następuje liniowy, biurokratyczny deployment z formalnym zatwierdzaniem przez zewnętrzny zespół testerski to porażka).

Nie wymierzajmy sobie feedbacku

Podczas warsztatu dowiecie się czym jest informacja zwrotna. Poznacie dwa sposoby udzielania sobie informacji zwrotnej – FUKO i SBI jak również sposób w jaki należy przyjmować takie prezenty.
Podczas warsztatu będziecie mieli okazję przećwiczyć, w bezpiecznej atmosferze i na własnej skórze, jak przygotować się i przeprowadzić wymianę informacji zwrotnej oraz jakich rzeczy lepiej unikać.

Agile on the Boat

Agile on the Boat to unikatowa na skalę Polski konferencja Agile. Cechą, która nas wyróżnia jest praktyczna warsztatowa forma, pozwalająca lepiej opanować praktyczne umiejętności i narzędzia. Uczestnicy pracują w małych grupach, które pozwalają lepiej skupić się na celu ćwiczenia, a także nawiązać głębszą relację z prowadzącym i współuczestnikami. Wymiana praktycznej wiedzy jest znakomitym motywatorem, by po konferencji z nowym zapałem zabrać się do usprawniania codziennej pracy.

Mamy zaszczyt zaprosić Was na drugi rejs naszą zwinną Barką.
Podobnie jak w roku ubiegłym chcemy w warsztatowy sposób skupić się na trzech ścieżkach:

ZWINNY ZESPÓŁ
ścieżka poświęcona miękkim i twardym umiejętnościom przeznaczonym dla wszystkich, którzy pracująz zespołami developerskimi (lub są developerami).
ZWINNY PRODUKT
to ścieżka przeznaczona dla Product Ownerów, Project i Product Managerów.Będziemy w niej pracować nad przyrostowym, zwinnym i „szczupłym” rozwojem produktów.
ZWINNA ORGANIZACJA
w tej ścieżce zapraszamy do przećwiczenia z uczestnikami narzędzi i mechanizmów, które sprawdziły Wam się przy pracyw szerszym kontekście organizacji. Wszystko, co związane ze współpracą między zespołami,wprowadzaniem zmian, pracą z zarządem czy okiełznaniem zależności.