Przemyślenia
Jacek Wieczorek

Czy agile znaczy szybciej?

Nie. Nie, jeśli raz ustalone założenia będą realizowane bezmyślnie, sekwencyjnie, od A do Z, bez względu na zachodzące zmiany. Nie, jeśli nie będzie realnie oceniana wartość, którą chcemy dostarczyć. Nie, jeśli skupienie zespołu w trakcie iteracji będzie rozpraszane nieistotnymi tematami, „nagłymi zmianami” oraz szumem informacyjnym. Nie, jeśli agile będzie tylko modnym buzz-wordem. Agile może znaczyć szybciej Realne przyspieszenie wymaga dużej zmiany myślenia o rozwoju produktów po stronie biznesowej. Wymaga to wyjścia IT poza schemat „zrobię to co mi każą, bo w końcu za to mi płacą„. Wszyscy zaangażowani w proces tworzenia, muszą zrozumieć nowe zasady gry. Nie oznacza to, że deweloperzy zaczną

Czytaj dalej »
Techniki
Jacek Wieczorek

Pomysł na Planowanie Sprintu – praca w grupach

Najczęstszym zaobserwowanym przeze mnie sposobem na przeprowadzenie drugiej części Planowania Sprintu jest następujący scenariusz: Scrum Master wspomaga Zespół Deweloperski, który pracując jako jedna całość, przygotowuje plan wykonania Sprintu. Po kilkudziesięciu planningach przeprowadzonych w ten sposób, można zaproponować alternatywne podejście planowania, aby spotkanie to nadal było przyjemnym sposobem na przygotowanie się do Sprintu, a nie nudnym i powtarzalnym obowiązkiem. Jaki jest pomysł na drugą część Planowania Sprintu? Planowanie Sprintu w grupach. Co potrzebujemy? wydrukowane lub rozpisane na kartkach Historie Użytkownika bloczek kartek samoprzylepnych kilka kartek A4 kilka pisaków/długopisów pomieszczenie ze stołami Jak przebiega Planowanie? Dzielimy Zespół na dwie grupy Zadania wstępnie przyjęte na

Czytaj dalej »
Przemyślenia
Jacek Wieczorek

Wspaniały zespół czy grupa świetnych ludzi?

Znam zespół (A), który składa się z świetnych specjalistów. Są wszechstronnie rozwinięci technologicznie, bardzo inteligentni, a suma ich umiejętności pozwala rozwiązać każdy przedstawiony im problem. Każdy z nich to indywidualista, często tak silny, że potrafi zdominować całą grupę. W innym zespole (B), funkcjonuje grupa solidnych, rzetelnych deweloperów. Potrafią rozwiązywać problemy w jednej, głównej technologii, posiadając ogólną wiedzę na temat innych rozwiązań. Rozwiązują problemy na nieco niższym poziomie abstrakcji, aniżeli zespół A. Zespół A ma problemy, żeby dostarczyć działający software na koniec Sprintu. Zespół B dostarcza gotowe oprogramowanie w każdej iteracji. Jaka jest różnica? A to tylko grupa ludzi. B to

Czytaj dalej »

„Marsz ku klęsce” – Eward Yourton

Na tytułowy „Marsz ku klęsce” trafiłem zupełnie przypadkiem, przeglądając rekomendacje, które podsunął mi Amazon. Po kilku kliknięciach wiedziałem już, że książka została wydana również w Polsce. Nie zrażając się okładką – która jasno komunikuje, że została zaprojektowana w czasach, kiedy zamiast kanałów RSS czytało się Bajtka – kliknąłem „Kup Teraz”, ciesząc się, że już za kilka dni, książka wyląduje na mojej półce. Autor – uznany autorytet w dziedzinie inżynierii oprogramowania – skupia się w tej pozycji na analizie projektów, które z racji niekorzystnego kontekstu oraz kontrowersyjnego przydziału zasobów określa „marszami ku klęsce”. Zdaniem autora, często nie mamy wpływu na to,

Czytaj dalej »
Techniki
Jacek Wieczorek

Drugie dno szacowania

Większość osób nie lubi szacować pracy. Uzyskane wyniki bardzo często bywają błędne, stąd wielu z nich nie widzi większego sensu w szacowaniu, skoro finalnie i tak okazuje się to wyłącznie spekulacją. Idąc dalej, obawa przed możliwością niewywiązania się z obietnicy powoduje, że mało kto lubi odpowiadać na pytania o czas potrzebny na wykonanie pracy. Warto dostrzec jednak drugie dno szacowania, a mianowicie okazję do wymiany oraz pogłębienia wiedzy dotyczącej konkretnego zagadnienia. Korzyść ta jest szczególnie wyraźnie widoczna w samowystarczalnych, interdyscyplinarnych zespołach. Jak to wygląda w praktyce? Dowolne wymaganie poddawane jest szacowaniu na dwóch poziomach: Historii Użytkownika (wysokopoziomowe), oraz zadań technicznych (niskopoziomowe).

Czytaj dalej »