Po powrocie z pracy, spędzam czas ze swoją 3,5 letnią córką. Gramy w gry, układamy puzzle, rozwiązujemy zagadki. Dziecko w tym wieku rozumie zaskakująco dużo spraw. Uzyskanie odpowiedzi na niektóre pytania, wymaga zadania odpowiednich pytań oraz umiejętnego poprowadzenia rozmowy. Podczas rozwiązywania zagadek, gdy odpowiedź nie pada od razu, podpowiadam pierwszą literę. Inaczej formułuję pytanie. Szukam analogi, podobieństw, skojarzeń, które mogłyby pomóc. Zachęcam ją do pomyślenia, przypominając, że doskonale zna odpowiedź. Zazwyczaj – prędzej czy później – pada poprawna odpowiedź. Obserwuję błysk w oku oraz wielką satysfakcję. Podobnie widzę rolę coach’a w zespole. Codzienna praca w grupie to nieustanne wyzwania, problemy

Agile. Dla jednych jedyne słuszne podejście do tworzenia oprogramownia, dla innych wyłącznie marketingowo opakowany chaos. Podczas rozmów jednych i drugich pada wiele śmiałych stwierdzeń. Nie wszystkie z nich są prawdziwe. Poniżej pięć mitów dotyczących agile’a, które słyszę najczęsciej: 1. Wreszcie nie musimy tworzyć dokumentacji To, że kompletna dokumentacja nie istnieje w momencie, gdy zasiadamy do kodu nie oznacza, że nie ma jej w ogóle. To, że może nie mieć postaci 30-stronicowego dokumentu nie znaczy, że nie wiadomo, co trzeba zrealizować w projekcie. Zgodnie z najlepszymi praktykami, w agile’u dokumentacja powstaje ad-hoc, w konkretnym wymiarze, na wymaganym poziomie szczegółowości. 2. Teraz projekty

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ą

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