Kategoria: Przemyślenia

Przemyślenia

Obszar działania coach’a

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 oraz zagadki. Zespół najczęściej zna odpowiedzi na swoje problemy, a nawet jeśli nie, to jest w stanie sam zdobyć potrzebne informacje. Jedyne, czego potrzebuje, to lekkiego wsparcia, naprowadzenia, usłyszenia odpowiedniego pytania.

Nie mogę dać rozwiązania na tacy. Nie mogę również pozostać obojętnym wobec ich problemów. Mogę oświetlić ciemną drogę, ale to nadal ich droga. Kierunek podróży określają sami. Ja tylko trzymam latarkę.

 

Czytaj dalej
Przemyślenia

5 mitów dotyczących agile’a

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 będziemy robić szybciej

Oprogramowanie może być dostarczane wcześniej. Nie zawsze jednak agile znaczy szybciej – wiele zależy od zrozumienia organizacji, co tak naprawdę znaczy zwinność. W odpowiednio przygotowanych warunkach, przy ścisłej współpracy IT oraz biznesu, wartość płynąca z gotowego oprogramowania może ujawnić się wcześniej, niż miało by to miejsce w przypadku klasycznego modelu kaskadowego.

3. Agile jest dobry, ale dla startupów

Przykłady taki firm jak Yahoo! czy Salesforce pokazują, że Scrum oraz inne praktyki agile’owe znajdują zastosowanie również w dużych, rozbudowanych przedsiębiorstwach. Może być to sposób na przywrócenie pierwotnej – zatraconej na skutek rozrostu – dynamiki firmy w obszarze wytwarzania oprogramowania.

4. Kadra kierownicza nie jest już nam potrzebna

Nie jest prawdą, że średni szczebel zarządzania w firmie nie jest potrzebny. Co więcej, aktywne działanie managementu w Scrumie jest potrzebne jak nigdy dotąd. Tworzenie przestrzeni do działań, pomoc w usuwaniu przeszkód czy wsparcie rozwoju pracowników to tylko część obowiązków managera w środowisku agile’owym.

5. W końcu nie musimy planować

Na kiedy to będzie?” to znienawidzone pytanie w zespołach deweloperskich. Niektórzy postrzegają agile’a jako możliwość ucieczki od planowania i odpowiadania na trudne pytania dotyczące terminów. Nic bardziej mylnego – planowanie w agile’u jest dostępne na wielu poziomach i stanowi stały element każdej iteracji, bez względu na jej długość.

Photo by Febiyan on Unsplash

 

Czytaj dalej
Przemyślenia

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ą szybciej pisać kod. Nie znaczy to, że magicznie znikną wszystkie problemy, które blokują i spowalniają pracę. Nie wynika to również z tego, że dla kogoś agile jest fajny, a waterfall zły.

Zrozumienie, co to jest agile, musi być identyczne – zaczynając od zespołu zespołu, poprzez kierownictwo, dyrektorów, na właścicielu konkretnego biznesu kończąc.

W innym przypadku, oprócz nazwy, nie zmieni się nic.

 

Czytaj dalej
Przemyślenia

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 prawdziwy zespół.

Subtelna różnica, która decyduje o efektach. Zespół przeciętnych, solidnych deweloperów jest w stanie zrobić o wiele więcej, niż grupa gwiazd. Przykład celowo przedstawiłem jaskrawo.

Kiedy efekty pracy nie osiągają poziomu, do którego dążymy, warto zastanowić się, czy jednym z powodów nie jest fakt, iż pracujemy tak naprawdę (jeszcze) z grupą, a nie z prawdziwym zespołem.

 

Czytaj dalej
1 5 6 7