Skip to content

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).

Antifragile – jak i czym konkurować w wytwarzaniu oprogramowania?

Po słowach krytyki i wsparcia dotyczących mojego poprzedniego postu postanowiłem opisać spojrzenie od strony klienta / stakeholderów dotyczących jakości oprogramowania.

Odpowiedź na pytanie postawione w tytule postu w przypadku zadania go osobie związanej z QA będzie jednoznaczna – należy konkurować jakością.

Odpowiedź zarządu firmy nie będzie już jednoznaczna. Zanim zaczniemy projekt firma musi go wygrać. Projekty w uproszczeniu wygrywa się według kryterium najlepszej oferty. Co składa się na ocenę najlepszej oferty?

Read More →

Zagrożenia sztucznej inteligencji według developerów – czyli ankieta Stack Oveflow 2018

„By the far the greatest danger of Artificial Intelligence is that people conclude too early that they understand it.” – Elizer Yudkowsky

„If you’re not concerned about AI safety, you should be. Vastly more risk than North Korea.” – Elon Musk

Wyniki rocznej ankiety StackOverflow są dostępne tutaj: https://insights.stackoverflow.com/survey/2018

Najbardziej zaciekawiła mnie część ankiety dotycząca etyki w zawodzie programisty i zagrożeń sztuczne inteligencji. Podsumowując:

  • Zaledwie ułamek deweloperów powiedział, że byliby w stanie napisać nieetyczny kod lub że nie muszą brać pod uwagę etycznych implikacji swojego kodu, ale poza tym, respondenci widzą dużą etyczną szarą strefę. Deweloperzy nie są pewni w jaki sposób zaraportowaliby etyczne problemy, i mają różne zdanie na temat tego kto ostatecznie odpowiada za nieetyczny kod.
  • Większość deweloperów zgadza się co do pozytywnych aspektów możliwości jakie oferuje sztuczna inteligencja, nie zgadzając się jednocześnie co do zagrożeń jakie AI ze sobą niesie.

Read More →

Kilka rzeczy, o których żałuję że nie powiedziano mi, gdy zmieniałem branżę na IT.

Do napisania tego posta natchnął mnie wpis na blogu Kuby Łopuszańskiego pt. Kilka rzeczy, o których żałuję, że nie powiedziano mi, gdy byłem młody

Mniej więcej 2,5 roku temu podjąłem decyzję o nauczeniu się programowania i przejściu do branży IT. Wcześniej przez ~8 lat zajmowałem się projektami w budownictwie i instalacjach sanitarnych. Przeszedłem drogę od inżyniera budowy przez konsultanta po PMa. Dziś po trochę ponad dwóch latach świadczenia usług w IT postanowiłem spisać rzeczy, które chciałbym żeby ktoś mi powiedział (lub móc powiedzieć sobie) na początku drogi związanej z przebranżowieniem.

Read More →

Automatyzacja desktopowych aplikacji Windows 10 – cześć #2

Czyli uruchamiamy z poziomu frameworka WinAppDriver i odpalamy aplikację Notepad++. Wszystkie aplikacje są darmowe (wymagają niestety płatnego Windowsa 10, lub darmowej wersji studenckiej). Nie testowałem podanych dalej rozwiązań na innych wersjach Windowsa niż 10.

Zaczniemy od kodu uruchamiającego WinAppDrivera (uprzednio zainstalowaliśmy go w domyślnej lokalizacji).

Read More →

Automatyzacja desktopowych aplikacji Windows 10 – cześć #1

W tym artykule przygotujemy sobie bazę do pisania testów w Gherkinie i utworzymy szkielet całego frameworka.

Jeżeli jesteś „początkujący” i jest to Twój pierwszy kontakt z C#/SpecFlow/Appium to polecam przeczytać najpierw wpis na blogu testuj.pl, w którym wszystko jest opisane krok po kroku od podstaw. Tutaj celowo pomijam te elementy, które są tam opisane wystarczająco dokładnie.

Krótki powód dla którego wybrałem taki a nie inny stack technologiczny: wszystko jest darmowe, do wszystkiego mamy zaplecze w postaci społeczności rozwijającej produkt, aplikacje na Windows 10 zazwyczaj są pisane w C# w Visual Studio (co pozwala część problemów rozwiązać wspólnie z developerami). Bo bez pomocy developerów, automatyzacja aplikacji na platformę UWP ma marne szanse powodzenia.

Read More →