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.

• • •

Sztuka pisania oprogramowania

Świat programistyczny desperacko domaga się lepszego stylu pisania – pisze Joel Spolsky we wstępie tejże książki, zaznaczając że stanowi ona jego zdaniem zbiór najlepszych treści związanych z oprogramowaniem, powstałych na przestrzeni ostatnich lat.

• • •

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ę?

• • •

Scrum, czyli jak robić dwa razy więcej, dwa razy szybciej

Pamiętam gdy zobaczyłem po raz pierwszy ten tytuł, uznałem go za przewrotny, ciekawy sposób na dotarcie do różnych grup ludzi, którzy wcześniej z różnych względów nie chcieli mieć do czynienia ze zwinnymi sposobami prowadzenia projektów. Wszak hasła: więcej i szybciej są motorami napędowymi niektórych menedżerów, czyż nie? Ba, kto nie chce mieć więcej i szybciej?

• • •

Scrum i nie tylko. Teoria i praktyka w metodach agile.

Książkę tę nabyłem jako początkujący Scrum Master, niejako przez przypadek, w jednej z popularnych sieciówek. Była jedną z bardzo niewielu polskich pozycji traktujących o agile, co w zasadzie było dla mnie jedynym wabikiem do jej zakupu. Nieoczekiwanie  stała się jedną z moich ulubionych pozycji, którą często wertuję w prawo i w lewo żeby sobie przypomnieć pewne rzeczy.

• • •

Fifty Quick Ideas to Improve your User Stories

To rzecz nie tylko o User Stories i wszystkim co związane z tworzeniem wymagań dla tworzonego oprogramowania, a w zasadzie nie tyle tworzeniem wymagań, co uzyskaniem dokładnie tego, czego oczekuje klient. To książka przede wszystkim o tym jak dobrze wytwarzać oprogramowanie w sposób przyrostowy – iteracyjny i inkrementacyjny, o tym jak w najszybszy możliwy sposób uzyskać oczekiwane efekty.

• • •

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.

• • •