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ń:
- 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ół.
- 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.”
- 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”.
- 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”.
- 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?
- 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.”
- 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”.
- 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”.
- 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.”.
- 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).