Niczego się nie wyrzekaj, do niczego się nie przywiązuj...

Dzisiaj doznałem efektu "AHA" w pewnym obszarze. Jako że temat uniwersalny, postanowiłem się nim podzielić. Jest to niejako kontynuacja wpisu sprzed roku.

Kiedyś przeczytałem zdanie "Niczego się nie wyrzekaj, do niczego się nie przywiązuj". Filozoficzne stwierdzenie, które choć ze wszelkich miar wydawało mi się być słuszne, to jednak na tyle abstrakcyjne, że trudno było mi je przełożyć na pragmatyczne zastosowanie. Jednak teraz odkryłem jego praktyczny sens i wagę.

Kiedyś nie lubiłem wstawać rano. Nienawidziłem. Mógłbym siebie nazwać "osobowość sowa" - lubię siedzieć w nocy, ale rano nie ściągniesz mnie z łóżka. Po kilku latach i wpływu czynników zewnętrznych w postaci dzieci, chcąc nie chcąc zacząłem musieć wstawać rano. Co więcej po kilku miesiącach wstawanie rano przestało być dla mnie udręką. Owszem lubię posiedzieć w nocy, ale jak trzeba wstać rano, to nie ma większego problemu. I tu mnie olśniło...

Kiedyś byłem tak bardzo zidentyfikowany z myślą, że wstawanie rano to udręka i to nie jestem JA, że już na samą myśl o porannym wstawaniu byłem zły. A już jak wstałem rano, to lepiej nie podchodzić. Teraz nie robi mi to różnicy. Czuję, że w tym obszarze dysponuję przestrzenią wyboru, nie koniecznością. Poczułem wielką ulgę. To właśnie oznacza "Niczego się nie wyrzekaj, do niczego się nie przywiązuj".

I zobaczyłem w jaki wielu miejscach ma to zastosowanie... Nie tylko w ramach projektów programistycznych ;-)

Read More

Unknown 13:43  No comment

Jak ja nienawidzę tych standupów...

Oj nierzadko to słyszę... że to strata czasu, że tylko odrywa od pracy, że to nic nie wnosi...

Bo rzeczywiście czasami tak jest. Dlaczego nie lubimy standupów?

* Trans - większość czasu pracujemy w transie - nie lubimy z niego wychodzić, bo dla większości z nas to jak wyjście w krótkim rękawku na ulicę w mroźną noc. To boli.

* Jeszcze nie skończyłem - o czym mam mówić, jeśli nie skończyłem? Nie wiem, ile to jeszcze zajmie, a w ogóle dajcie mi wszyscy spokój. Nie lubimy mówić o czymś, czego nie skończyliśmy, a szczególnie jeśli ma się okazać, że praca mi zajmie dłużej niź to było przewidziane. Obawiamy się oceny. Tutaj wiele zależy od ScrumMastera (lidera) i atmosfery w zespole, czy tego typu spotkanie nie jest ukierunkowane na generowanie poczucia winy.

* Spotkania (jakiekolwiek) to nie jest skill, który mamy świetnie opanowany. A w zasadzie nie tyle spotkania, co komunikacja, rozmowa. Kiedy 90% swojej aktywności zawodowej spędzasz przed komputerem, to automatycznie Twój mózg przestaje trenować umiejętności komunikacyjne, a co nie trenowane - zamiera. Nie lubimy posługiwać się czymś, co umarło ;-)

To po co robić te spotkania (z punktu widzenia programisty)? Właśnie dlatego ;-)

* Potrzebujesz umieć wychodzić z transu, żeby kompletnie nie zerwać kontaktu ze wszechświatem.

* Potrzebujesz być w stanie przełączać się między szczegółami a abstrakcją (ogółem), bo inaczej będziesz tworzył świetny soft, tylko że bezużyteczny dla końcowych użytkowników. To codzienne spotkanie daje Ci szansę, na to aby na chwilę przetrzeć umorusaną węglem twarz i zadać sobie pytanie: to w dobrą stronę kopiemy?

* Jeśli nie będziesz trenował umiejętności komunikacji, to po dłuższym czasie, zginiesz w odosobnieniu i będziesz jedyną osobą, która wie co robisz. Może będziesz robił fascynujące rzeczy, ale one będą fascynujące tylko dla Ciebie. W tym przypadku nie ma innej rady, jak dużo trenować, czyli rozmawiać ;-)

Zacząłem od perspektywy programisty. Z punktu widzenia Scrum Mastera (lidera) i Product Ownera (klienta) jest to bardziej oczywiste. Dzięki tym spotkaniom są w stanie dowiedzieć się, co się dzieje.

Jednak warto mieć w zanadrzu takie pytanie kontrolne: czy te spotkania coś wnoszą? Jeśli po kilku ostatnich spotkaniach czujesz się tak, jakbyś na śniadanie od kilku dni przeżuwał resztki tekturowego pudełka, to znaczy, że coś jest nie tak. To spotkanie ma służyć temu, żeby powiedzieć o tym, co się RZECZYWIŚCIE dzieje, co się zmienia i jakie są problemy. Jak w przypadku dobrej spowiedzi, potrzebny jest przyzwoity rachunek sumienia, czyli 2-3 minuty, aby zastanowić się nad tym co robisz, a nie: przychodzić jak na łapankę i generować coś co, będzie dobrze brzmiało.

Kochani! Nie bójmy się rozmawiać! (wiem... to nie jest łatwe...)

P.S. Czasami słyszę pytanie: a jak nasz zespół to 2-3 osoby, to mamy robić TE standupy? Jeśli wczytasz się w powyższy tekst, to znajdziesz odpowiedź. A w skrócie: może to nie być potrzebne, jeśli w inny sposób:

• techniczni członkowie zespołu wychodzą regularnie z transu, przechodzą na wyższy poziom myślenia o tym co robią (zadają sobie w jakiejś formie pytanie: po co ja to robię?) i rozmawiają z liderem, klientem i ze sobą nawzajem o tym, co robią, z czym są problemy.

P.S.2 Czasami spotkania się nie kleją. Powodów może być kilka. Np. członkowie zespołu wypowiadają się zbyt ogólnikowo. Natomiast jest jeszcze jedna rzecz, która się pojawia dość często:

• spotkania się nie kleją, jeśli spotkanie jest zorganizowane dla osób, które nie pracują nad tym samym celem (zadaniem, grupą zadań). Np. Zespół składa się z 9 osób, natomiast realizowane są mini projekty 2-3 osobowe i niejako każdy podzespół pracuje na własną rękę (mimo że pracujemy nad tym samym produktem). Wtedy wspólne spotkania będą nudne dla większości osób, gdyż nie będą zbyt zainteresowane tym, co się dzieje u innych.

Read More

Unknown 09:39  1 comment

Zespół w Scrumie

Zespół, w zespół, zespół, w zespół... Przyszedł czas rozprawić się z zespołem po tematach Product Owner i Scrum Master. Ten temat można by przemaglować po wieloma różnymi kątami. Jednak nie w tym rzecz.
W czym?:

• zespół ma być nieduży - bo wtedy komunikacja jest prostsza i łatwiej się zorganizować;

• zespół to nie składak ("w projekcie X jestem na 30%, w projekcie Y na 50%..."), to nie działa, ludzie są niezaangażowani i sfrustrowani. Z dwojga złego już lepiej zorganizować jeden zespół, który robi dwa projekty;
• zespół się konstytuuje miesiącami - jeśli tzw. zespół jest konstruowany na 2-3 miesięczne projekty, a później rozwiązywany, to nie ma zespołu. Jest grupa ludzi. Mechanizmy zespołowe wtedy nie działają;
• rozproszone zespoły to duże wyzwanie i nieczęsto to dobrze wychodzi. Rozproszone zespoły międzynarodowe (a już w różnych strefach czasowych w szczególności) to nigdy dobrze nie wychodzi. NIGDY. Nie widziałem takiego zespołu, a sporo już widziałem. I nie jest to kwestia umiejętności zorganizowania takiego zespołu. Mieszanie różnych narodowości, pracujących zdalnie to nienajlepszy pomysł - bariera przestrzenna jest wielokrotnie wzmacniana barierą językową i kulturową;
• zespół musi mieć wyraźną przewagę ludzi doświadczonych i sprawnych nad osobami niedoświadczonymi. Chociaż nawet ze studentów można zrobić świetny zespół, tylko wymaga to ogromnie wiele wysiłku (na tyle dużo, że jest to nieopłacalne);
• czy zespół ma być samoorganizujący? trzeba wielu czynników, aby mieć dobry zaczyn, aby doprowadzić do takiej formy działania zespołu, a to się rzadko zdarza. Dlatego kluczową rzeczą jest to, że:

Osoby współtworzące zespół, powinny co najmniej współdecydować odnośnie tego co się dzieje podczas realizacji feature'ów (m. in. co się da zrobić, w jakim czasie, w jaki sposób i jak zorganizować sobie pracę).

 
Amen. 

Read More

Unknown 13:18  No comment