Zwinny architekt? Empatyczny i programujący!

Prestiż, autorytet, duża wiedza i doświadczenie, wysokie zarobki – z tym przede wszystkim kojarzy się stanowisko Architekta Oprogramowania – przez wielu odbierane jako niezwykły splendor, ukoronowanie kariery programistycznej, dowód przynależności do elity IT.

• • •

„Zet” na Daily Scrum

Daily Scrum to wbrew pozorom – obok retrospektywy – chyba najtrudniejsze ze spotkań Scrumowych. Źle przeprowadzane jest podłożem wszelkich problemów trapiących zespół – od braku realizacji planowanych wymagań, poprzez typowo indywidualne podejście deweloperów do pracy, aż do poczucia bezsensu pracowania w Scrumie.

• • •

Wierchuszka na przeglądach

Przegląd Sprintu (często błędnie nazywany: podsumowaniem lub demem) to spotkanie, które zrewolucjonizowało komunikację wykonawców (IT) z końcowym klientem oraz wymusiło po stronie IT sporą zmianę podejścia do swoich działań. Oto w stałym cyklu i już od samego początku pracy zespół deweloperski nie dość, że musi dostarczyć coś w pełni funkcjonalnego i wartościowego biznesowo, to jeszcze, wspólnie z Product Ownerem, ma za zadanie to zaprezentować. W efekcie klient ma okazję na bieżąco, w stałym cyklu, oglądać efekty prac i zgłaszać swoje uwagi czy propozycje co do dalszych kroków.

• • •

Programiści – języka nie mają?

Tworzymy wspaniale kolaborujący zespół, któremu niestraszne są żadne wyzwania. Na taki cytat natknąłem się ostatnio na stronie całkiem znanej i poważnej firmy tworzącej aplikacje internetowe. To rozwiązanie będzie w znacznym stopniu afektować znaczny odsetek klientów używających aplikacji – czytam w oficjalnym dokumencie definiującym wymagania. Spostponuj to spotkanie na inny termin – usłyszałem całkiem niedawno w przerwie jednego ze szkoleń. O co mi chodzi? Ano o pewien syndrom, który obserwuję od dłuższego czasu – fakt, że o ile angielskim pracownicy działów IT władają bez problemu, to z polskim jest wręcz dramatycznie. Brak znajomości słownictwa, spolszczanie angielskich słów w wydawać by się mogło naturalne rodzime odpowiedniki (affect, collaborate, postpone) przynosi efekty dosyć groteskowe, jak wyżej. Co jednak coraz bardziej przerażające – coraz mniej osób zwraca na to uwagę. A całość jest na tyle powszechna, że niedługo pierwotne znaczenie słów kolaboracja, postponować i afektować faktycznie się zatrze. Czepiam się?

• • •

Zasady dobrego „code review”

Na czym polega ta nieodzowna część pracy programistycznej? Jak wykonywać ją dobrze, na co zwracać uwagę, a czego unikać? Na te i inne pytania postaram się opowiedzieć w niniejszym artykule.

• • •

Istota retrospektywy

Na jednej z ostatnich konferencji agile’owych natrafiłem na grupkę (jak się okazało – w większości Scrum Masterów) żywo dyskutującą o retrospektywach. Jako, że konwersacja była prowadzona publicznie, w trybie otwartym, przyłączyłem się w roli słuchacza. Rzecz była o pomysłach na ciekawe retrospektywy w formie, jak to określono, “psychozabawy” (a słysząc to słowo moje myśli skierowały się ku “Uśmiechowi Numeru” czy innym kultowym nastoletnim gazetkom z lat 90.)

• • •

Niepokorny deweloper

Scrum to gra zespołowa, działa dobrze, jeżeli wszyscy przykładają się na równym poziomie, bo oczywistym jest, że na efekt pracy zespołu składają się ludzie go tworzący. Co jeśli jeden z członków zespołu deweloperskiego zaczyna przysparzać problemów, psując atmosferę? Nie chciałbym się w tym momencie rozpisywać nad przyczynami takiej sytuacji, może być ich bardzo wiele –  od znużenia projektem, wypalenie zawodowe, po kwestie relacji panujących między członkami zespołu czy też kwestie ich charakterów. Skupmy się na samej sytuacji, gdzie problemem staje się komunikacja oraz egzekwowanie zobowiązań od takiej osoby.

• • •

„Nietechniczny” Scrum Master

Czy nietechniczna osoba ma szansę odnieść sukces jako Scrum Master? Na początek, doprecyzujmy, co mam na myśli używając słowa „nietechniczny”. Mówiąc wprost, odnoszę je do siebie, sam czuje się bowiem taką osobą, pracując na co dzień w zespole tworzącym oprogramowanie. Mimo, że poruszam się sprawnie w tym obszarze, to nigdy nie potrzebowałem poznawać szczegółowych rozwiązań implementacyjnych. Czy to wpływa w jakiś sposób na moją pracę? Z pewnością.

• • •

Product Owner na retrospektywie

Zdziwiło mnie pytanie jakie usłyszałem od jednego z początkujących Scrum Masterów, który jednak miał już na swoim koncie kilka ładnych miesięcy praktycznej pracy na tym stanowisku: „Czy macie w zwyczaju zapraszać Product Ownerów na retrospektywy?” Jakież było jego zdziwienie, kiedy skierowałem go do „Przewodnika po Scrumie”, a tam przeczytał:

• • •