Tania zmiana

Chcesz zmienić swoją firmę, tylko że…

Zmiana nawyków jest trudna, szczególnie cudzych.

Zmiana przekonań jest trudna, siedzą w nas co najmniej od podstawówki.

Zmiana kultury jest trudna, bo to suma nawyków i przekonań.

Trudne, trudne, trudne…

Czy jest coś łatwego?

Otóż jest – zmiana otoczenia!

Supermarkety już dawno wpadły na to, jak zmienić zachowanie ludzi bez wpływania na przekonania i nawyki. sprawy skomplikowane i osobiste.

Zmień środowisko, a zmienisz zachowanie!

Wchodzę tylko po chleb.

Na mapie supermarketu jest oczywiście najdalej jak się da. Za to od wejścia promocje w natarciu. O faktycznie sporo tańsze… Muzyka wprawia w niefrasobliwy nastrój. Sztuczny aromat czekolady przypomina smaki dzieciństwa. Oooo książeczki, mój synek na pewno się ucieszy. Ostatecznie wychodzę z pełnym koszykiem lżejsza o 200zł i taka szczęśliwa.

Hamo sapiens to według etymologii nazwy “istoty rozumne”. Chcielibyśmy!  Faktycznie daleko nam do Strak Treck’owego Spoka. Działamy irracjonalnie. To brutalny fakt.

Potwierdza to wielu autorów. Pisze o tym Linda Raising, (http://masteringbusinessanalysis.com/episode-30-myths-and-patterns-of-organizational-change-interview-with-linda-rising/), Daniel Kahneman w “Thinking, Fast and Slow” czy Miłosz Brzeziński w “Wy wszyscy moi ja”.

Warto z naszą wrodzoną irracjonalnością dojść do ładu.  Malcolm Gladwell w książce Blink pokazuje, że większość podświadomych mechanizmów, które pozwalają nam podejmować decyzję w milisekudach powstała w ciągu milionów lat ewolucji. Co więcej, są sytuacje, kiedy w naszym zmienionych środowisku warto im zaufać!

To gdzie jesteśmy wpływa znacząco na nasze zachowanie, a nawet na nasze zdrowie. Profesor Ellen Langer przeniosła grupę 8 staruszków do roku 1959. W jaki sposób? Tworząc środowisko łudząco przypominające im młodość. Meble, książki, gazety, programy w telewizja, radio, ubrania. Brak luster, a zamiast nich swoje zdjęcia z młodości.

Wynik? Badani w ciągu 5 dni zmienili się nie do poznania. Trzymali się prosto, nabrali zręczności, poprawił im się wzrok i słuch. Ciała wydawały się… młodsze.

Miłosz Brzeziński w swojej książce “Wy wszyscy moi ja” Przytacza wiele badań, z których wynika, że:

W czymkolwiek umieścisz ciało, umysł za tym podąży.

Zobaczmy w czym umieszczają ciała zespołów programistycznych znani giganci:

Biura Googla wyglądają jak przedszkola:

Jest po temu bardzo dobry, racjonalny powód. Dobry deweloper to kreatywny deweloper. Potrafi znaleźć nowatorskie rozwiązanie problemu, który przed nim stoi. A najbardziej kreatywne są właśnie dzieci. Google tworzy, więc środowisko, w którym deweloperzy poczują się lekko jak dzieci.

Google robi też wszystko, aby ich zespół czuł się absolutnie wyjątkowy. Pracowników czeka długa i ciężka rekrutacja, naprawdę dobra pensja, mnóstwo bonusów, luksusowe biuro. Poczucie wyjątkowości to jeden z najskuteczniejszych sposobów, by dać ludziom naprawdę silną motywację.

Wspomniany już Miłosz Brzeziński przytacza w “Głaskologii” eksperyment dotyczący poczucia wyjątkowości. Dzieci z podstawówki poddano testom na inteligencję, po czym dokonano podziału ich na te inteligentne i te mniej inteligentne aby rozwijały się w grupach o zbliżonym poziomie. Po jakimś czasie zaobserwowano, że te inteligentne faktycznie osiągają lepsze wyniki w nauce, a tym gorszym się pogarszają. Nie byłoby w tym nic dziwnego gdyby nie podzielono ich na te grupy losowo.

Jak więc stworzyć środowisko które pozwoli naszym zespołom pracować wydajnie?

To co sobie ułatwiamy robimy częściej i chętniej.

Google znowu świeci przykładem. W pewnym momencie ekipa firmy rozrosła się znacząco. Pod względem wagi. Spowodował to swobodny dostęp do darmowych słodyczy.Trzeba było działać, ale skasowanie słodyczy nie wchodziło w grę. Spróbowano więc czegoś łatwiejszego. Słodycze były dalej dostępne, ale w słoikach, które obowiązkowo trzeba było po sobie zakręcać. Spożycie cukierków spadło dramatycznie. Jesteśmy leniwi. Robimy to, co nam wypada po drodze. Sprawdzono, że osoby, które trzymają słodycze na widoku są o 30% grubsze, niż te, które trzymają je w szafkach lub, w ogóle nie trzymają ich w domu.

A co z tworzeniem oprogramowania?

Firma ThoughtWorks w ramach zachęcania swoich programistów do pracy w parach stworzyła specjalne stanowiska wspierające taką praktykę.

Valve zachęca swoich deweloperów do samodzielnego wybierania produktu, który będą tworzyć. Dając biurka na kółkach.

Wszystko to brzmi bardzo pięknie, ale my nie chcemy, żeby deweloperzy sami sobie wybierali produkty, a na biura “googlowe” zwyczajnie nas nie stać.

Więc, co my mamy zrobić?

Ważne na widoku!

Za co tak naprawdę płacimy naszym drogim deweloperom? Za wymyślanie. Tworzenie produktów. Żeby to zrobić muszą o tym sporo myśleć. Warto im to ułatwić, przypominając o produkcie, który tworzą, bo o innych rzeczach przypomni im internet i mąż/żona. Niech więc tam gdzie przechodzą znajdą się:

• aktualne backlogi zadań,
• modele biznesowe,
• ustalenia z ostatnich spotkań,
• mnóstwo miejsca, które można zużyć w tym celu.

Udowodniono też, że im bardziej nasze miejsce jest nasze, tym czujemy się w nim lepiej, bardziej u siebie. Jeżeli więc możemy dać ludziom możliwość zaaranżowania przestrzeni, umieszczenia w niej swoich bibelotów, narzędzi, książek, planszówek – dajmy im ją.  Szczególnie w skali zespołu, który w tej sposób tworzy swoją tożsamość i dzięki temu będzie lepiej wspierać się w rozwiązywaniu problemów, które przed nimi postawimy.

To samo możemy zrobić z produktem. Koncepcja War Room jest znana z dobrze zarabiających firm, które w ten sposób ułatwiają koncetrację na istotnych sprawach. (https://library.gv.com/why-your-team-needs-a-war-room-and-how-to-set-one-up-498e940e3487#.xa1ukkmx6)

Nieważne z głowy

A co warto zdjąć z głów deweloperów? Problemy baletnicy: niewygodne biurka, niewygodne klawiatury, za małe monitory i tak dalej… Banał, prawda?

Warto policzyć ile kosztuje to firmę, która o to nie dba. Weźmy prosty przykład. Toaleta zawsze zajęta. Bo jest jedna. Każdy, zanim się zdecyduje, spróbuje się wstrzymać na conajmniej pół godziny. Nie pracuje w tym czasie efektywnie. Potem już musi, więc stoi. Kosztuje nas to spokojnie godzinę każdego dewelopera dziennie. W skali miesiąca każdy pracuje o dwa i pół dnia krócej, i jeszcze ma o czym ponarzekać z kolegami.

Podobnie z fusami od kawy. Tak możesz narzekać, że ludzie nie myją po sobie, bo to flejtuchy, marnując swój oraz ich czas na sprzątanie i narzekanie, lub zatrudnić panią Helenkę, która nie dość, że zrobi to 5 razy taniej, to jeszcze z uśmiechem, który poprawi humor zapracowanym ludziom.

Na koniec najważniejsze.

Kreatywność, skupienie i relaks.

Przyznam się, że biura Googla zawsze wydawały mi się zbyt krzykliwe, żebym umiała się w nich skupić, a czasem przecież trzeba.

I tu sprawa biura się komplikuje. Wydajne miejsce pracy powinno wspierać trzy tryby pracy, w które wpada nasz umysł. Praca kreatywna, praca w skupieniu, oraz relaks i budowanie relacji.

1. Praca kreatywna jest kluczowa w tworzeniu produktów, gdyby nie ona ciągle powtarzalibyśmy znane rozwiązania.
2. Ale kiedy już wykrzykniemy “Eureka!”, trzeba lecieć i realizować. Bo dobrych pomysłów  jest stanowczo za dużo ww stosunku do zrealizowanych dobrych pomysłów. Potrzebujemy wtedy koncentracji, którą wspiera zupełnie inne środowisko.
3. Pisaliśmy linijki czystego kodu i dopadło nas zmęczenie. Fajnie by było usiąść, zjeść coś, pogadać. Może nawet pochwalić się nowym rozwiązaniem. Jeżeli miejsce pracy, w którym się znajdujemy, nie daje nam ku temu okazji, lub nie jest to w nim akceptowane, nie sposób wrócić do stanu w którym będziemy produktywni. Jeśli jednak wspiera relaks i budowanie relacji to zregenerujemy się znacznie szybciej.

Jakie warunki mają spełniac te trzy przestrzenie? Znowu tu posłużę się danymi zebranymi przez Miłosza Brzezińskiego:

Kreatywność

• wysokie sufity,
• przestrzeń,
• dużo światła (najlepiej dziennego),
• artystyczny nieład,
• sporo kolorów z przewagą zielonego,
• przyjemne dźwięki (kreatywny umysł nie znosi ciszy),
• kwiaty,
• radiatory informacji (wykresy, monitory, wykazy),
• tablice, flipcharty, mazaki, taśmy, nożyczki itd. wszystko co może się przydać do wspólnego myślenia,
• zabawki, gry,
• najlepiej pozbyć się krzeseł, wielkich stołów.

Skupienie – klimat biblioteczny

• porządek,
• cisza,
• sporo światła,
• wielki monitor, a najlepiej monitory,
• wygodne krzesło i podnóżek,
• brak jakichkolwiek rozpraszaczy,
• open space jest fatalnym rozwiązaniem.

Relaks i relacje

• wygodne kanapy, a nawet miejsce gdzie można się położyć,
• miła i spokojna muzyka,
• dostęp do kawy, herbaty,
• brak radiatorów informacji, tutaj odpoczywamy.

Kończąc, nie ma tańszego sposobu na zwiększenie wydajności niż zapewnienie ludziom środowiska, które tę wydajność wspiera. Powodzenia!

Czy warto suszyć i całować Backlog?

W jednym z moich poprzednich artykułów pisałam o tym, że:

W Scrumie za jakość odpowiada zespół deweloperski.

Pisałam też o tym że dobry Produkt Backlog, delikatnie mówiąc, ułatwia sprawę. W interesie zespołu jest więc wspomagać PO jak tylko może w utrzymaniu porządnego Product Backlogu. Nie dotyczy to tylko osób wykonujących zadania związane z biznesem. Programistom też się przyda dobre źródło informacji o produkcie.

Do czego?

Będę to powtarzać do znudzenia.

Każda osoba w zespole deweloperskim podejmuje codziennie dziesiątki decyzji. Mogę one wspierać wizję Product Ownera i jego priorytety lub… coś całkiem innego.

Co? Na przykład chęć szybkiego wyjścia z pracy, chęć zaimponowania kolegom bardziej skomplikowanym rozwiązaniem, chęć powiedzenia następnego dnia że już jest zrobione. Każdy z nas chce być bohaterem. Nie ma w tym nic złego. Sztuka polega na tym aby razem z Product Ownerem doprowadzić do takiej motywacji, aby koncentracja na produkcie była czymś zupełnie oczywistym, a inne rzeczy nie zaprzątały nam głowy.

Product Owner jest ekspertem od wizji. Deweloperzy są ekspertami od jakości. Jakość kodu jest ściśle związana z jego czytelnością. Zarówno dobrzy programiści jak testerzy i analitycy biznesowi są w kwestii czytelności absolutnymi ekspertami. Jak więc mogą pomóc Product Ownerowi osiągnąć przejrzystość w Backlogu? Otóż okazuje się, że zgrabnie ujęte zasady związane z czytelnością, które ułatwiają utrzymanie czystego kodu programistom z powodzeniem można zastosować do Backlogu. Mówię tu o trzech zasadach.

 

DRY czyli z angielskiego “Don’t reapet yourself”

a po polsku “Nie powtarzaj się”.

“Czekaj, tam jest ten opis, skopiuje się…” – to jest ten moment w którym należy ingerować, bo inaczej Doktor Copy-Paste zamieni Product Backlog w niekończącą się litanię powtarzających się fragmentów dokumentacji. Oczywiście nie dokładnie takich samych, bo świat się zmienia. Klient zmienia zdanie. Rynek się zmienia. Dokumentacja też się zmienia, ale przeważnie tylko jedna kopia, czasem dwie, jeśli o nich pamiętamy. Rzadko wszystkie. Więc jeśli chcesz mieć dostęp do rzetelnych informacji, trzymajmy każdą z nich dokładnie raz. A kopiować można jakiś odnośnik do niej.

KISS czyli “Keep it simple stupid”,

czyli “Niech będzie tak proste, że aż głupie”.

Czy warto poświęcać czas na wygładzanie opisów w Product Backlogu. Na szlifowaniu ich tak, żeby każdy klient użytkownik i deweloper je zrozumiał. Na ślęczeniu przy nich tak długo, że zrozumiemy je nawet jak siądziemy do nich za rok czasu.

Odpowiedź brzmi TAK.

Z dwóch powodów. Służy to użytkownikom i autorowi:

1. Użytkownikom bo Product Backlog stanowi plan – do planu zagląda się często. Aby go doszlifowywać, weryfikować i wreszcie realizować. Zagląda tam sporo osób. Użytkownicy, klienci, deweloperzy, zarząd a przede wszystkim autor. Powinien być więc tak prosty i przejrzysty jak tylko się da. Aby nie marnować czasu odbiorców i zachęcać do korzystania. Jeśli będzie się kojarzył z kodeksem, to nikt tam nie zajrzy i będzie mnóstwo niespodzianek. Product Owner będzie miał niespodziankę jeśli nie dostanie tego co chciał, bo deweloper nie zajrzał. Klient będzie miał niespodziankę jak nie dostanie tego co chciał, bo nie zajrzał i nie zauważył, że go nie zrozumiano i tak dalej. Jeżeli do planu nie zagląda się często i nie jest potrzebny wielu osobom, to coś jest nie tak. Planujemy na zbyt długie okresy czasu? A może nie mamy kontaktu z odbiorcami? Nie zbieramy od nich informacji zwrotnej? Możliwości jest wiele. Optymalny Product Backlog jest krótki, zwięzły, aktualny, zmienia się często i jest używany.
2. Przydaje się też autorowi bo proces klaryfikacji opisu klaryfikuje wizję autora. Czy zdarzyło wam się skasować przypadkiem wyniki swojej pracy, przez co byliście zmuszeni do wykonania jej jeszcze raz? Mi się zdarzało. Bardzo często efekt pracy był dużo lepszy niż pierwotna wersja. Co więcej moje zrozumienie tematu staje się o niebo lepsze. Tak samo jest z kodem i tak samo jest z Produck Backlogiem. Praca nad nim sprawia że, wizja staje się coraz wyraźniejsza i dokładniejsza. Czasem sprawia też, że wizja zmienia się bo autor odkrywa coś czego wcześniej nie wiedział, lub wpada na lepszy pomysł. Konieczność wyrażenia czegoś w prosty sposób, doprowadza do zrozumienia tego lepiej. Warto poświęcić na to czas. Jeżeli wasz Product Owner nie spędza mnóstwa czasu wpatrując się w Product Backlog, to wiedzcie, że coś niedobrego się dzieje z produktem.

YAGNI czyli “You aren’t gonna need it”,

po polsku “Nie, nie będziesz tego potrzebował”.

Product Backlog jest centralnym punktem informacji o produkcie. Wydaje się więc, że powinien być duży. To nie prawda. Powinno być tam wszystko co ważne, krótko i zwięźle, a nie wszystko co kiedykolwiek ktoś wymyślił. Nadmiar informacji jest świetnym sposobem na ukrycie tego co jest ważne, tyle, że w przypadku Product Backlogu intencja jest odwrotna. Chcemy to przejrzyście pokazać. Tak jak dobry deweloper uczy się w pewnym momencie kasować kod, który napisał bo okazuje się, że nie jest używany, tak i Product Owner uczy się kasować rzeczy, których jednak nie będzie realizował. Niezależnie od tego jak dużo czasu poświęcił na ich zaplanowanie. Wiem to trudne, ale warto. Przy okazji uczymy się, że nie warto planować szczegółów tego, co będziemy robić za pół roku i nie warto trzymać tego planu jeżeli już go mamy, bo i tak za pół roku zrobimy to inaczej. Za pół roku będziemy innymi ludźmi dosłownie lub w przenośni.

Oczywiście nie tylko te zasady czystego kodu z powodzeniem można stosować do Product Backlogu. Czytelność w obu przypadkach jest kluczowa, programiści wykorzystajcie więc swojej doświadczenie w utrzymaniu czystego i czytelnego kodu i pokażcie jak to robić waszym Product Ownerom. Nie z altruizmy. Zróbcie to bo jest to w waszym interesie.

Po co nam dobry Product Backlog?

W Scrumie za jakość odpowiada zespół deweloperski.

Dobre i złe strony równouprawnienia.

Własnie tak. Dobrze czytacie. Zespół. Nie manager. Nie Produkt Owner. Nie Scrum Master.Zespół deweloperski. Czas zdjąć koronę niewiniątek z tych na dnie łańcucha pokarmowego i przyjąć zarówno dobre i złe strony równouprawnienia.

Dobre?

• Decyzyjność. To zespół decyduje jak wykonane zostanie rozwiązanie i nikt nie ma prawa się w te decyzje wtrącać. Dzięki pracom Dana Pinka opisanym w jednym z moich poprzednich artykułów (klik) wiemy że jest to coś krytycznego dla naszej motywacji.
• Profesjonalizm. Zespół już nie jest tylko wykonawcą czyiś poleceń, tworzy autonomiczną samo-zarządzającą jednostkę. Mini firmę, która jako jedyna jest w stanie stworzyć inkrement.
• Szacunek. Jeżeli oba powyższe udało się osiągnąć szacunek pojawi się jako konsekwencja.

Złe?

• Za te wszystkie decyzje które od teraz podejmuje zespół trzeba wziąć odpowiedzialność. Co to znaczy? To znaczy że zespół chyli głowy jeżeli coś z jakością jest nie tak. To zespół mówi w jakim czasie da się to naprawić. To zespół dba o to żeby mieć możliwość zadbania o jakość i domaga się od Product Ownera i Scrum Mastera aby wypełniali swoje odpowiedzialności.

Jeżeli zespół nie podźwignie z ziemi tej odpowiedzialności innym trudno będzie pozostawić mu decyzyjność.

Warto więc Product Ownerowi ułatwić przekazanie decyzyjności pokazując się z jak najbardziej odpowiedzialnej strony i zadbać o dobry Product Backlog. Product Owner potrzebuje od zespołu informacji zwrotnej aby taki stworzyć. Zespół bez dobrego Product Backlogu nie stworzy właściwego inkrementu. Dzięki tej współpracy redukujemy złożoność i tak już skomplikowanego problemu tworzenia oprogramowania.

Product Backlog for Dummies

Co więc na temat Product Backlogu wiedzieć należy:

1. Jest to JEDYNE źródło informacji na temat tego co będzie robił zespół deweloperski. Trzymamy w nim WSZYSTKIE rzeczy do zrobienia. Tak, aby każdy mógł sprawdzić co będzie robione i co jest od czego ważniejsze (wiem wiem, nie wszystko interesuje wszystkich, dlatego dobry mechanizm filtrowania może się przydać).
2. Trzymamy w nim porządek! To znaczy:
3. Jest SPRIORETYZOWANY. Czyli elementy mają określoną kolejność, mam tu na myśli porządek zupełny: nie ma dwóch elementów na tym samym poziomie. Czemu tak? Bo tak jest prościej. Niewielkim wysiłkiem Product Ownera skracamy dyskusje, które mogłyby wybuchnąć pod jego nieobecność.  To w jakiej kolejności spod rąk zespołu będą wychodzić gotowe funkcje jest tak kluczowe, że warto aby było tak jasne i przejrzyste jak tylko się da.
4. Jest KRÓTKI. Wydaje się sprzeczne, mamy tam trzymać tam wszystko co jest ważne i jednocześnie dbać o to żeby był krótki? Ta dyscyplina się opłaca. Zmusza nas do realnego planowania na rozsądny(tzn. rozsądnie krótki) okres czasu. Tak, żeby plan nam służył, a nie siedział w Backlogu i się kurzył. Na górze rzeczy drobne i dobrze rozpisane. Na dole duże i niedopracowane, ale te które chcemy nieustannie rewidować i uzupełniać bo są ważne. Na trzymanie mglistych planów, które może zrealizujemy a może o nich zapomnimy też warto mieć jakiś sposób. Jeden z fajniejszych, które widziałam to trzymanie ich wszystkich w ostatnim elemencie Product Backloga. W ten sposób nie przeszkadzają i jednocześnie o nich nie zapominimy.
5. Jest CZYTELNY. Kolejny banał, nad którym naprawdę warto się pochylić. Z Backloga ma korzystać każdy zainteresowany produktem, szkoda marnować czas tych wszystkich osób. Szczególnie swój własny, zdarzyło wam się ślęczeć nad własnymi notatkami próbując je zrozumieć? A co dopiero osoby które ich nie tworzyły. Backlog jest dokumentem publicznym, służy wszystkim osobom zaangażowanym w tworzenie produktu. Jest narzędziem nieustannej komunikacji Product Ownera z resztą świata. Nieczytelny nie będzie używany. Drogi Product Ownerze, jeżeli nie dostajesz od zespołu tego o co prosisz, sprawdź czy jasno wyrażasz swoją prośbę (zanim zdążysz jasno wyrazić swoją opinię o produktywności zespołu…). Czytelny Backlog skoncentruje uwagę osób zaangażowanych w tworzenie produktu na kluczowych dla niego rzeczach. Każdy z deweloperów podejmuje dziesiątki decyzji w ciągu dnia: Jak podzielić funkcjonalności? Gdzie umieścić przycisk? Jak zoorganizować informacje? Jak nazwać zbiór testów? Do kogo dzisiaj zadzwonić itd. Każda z tych decyzji może wspierać obecny plan rozwoju produktu lub się z nim mijać. Znajomość i zrozumienie planu jest podstawą tego aby mu służyła.
6. Jest DOSTĘPNY. Najgorsza wersja nieczytelności to niedostępność. Backlog ma być tam gdzie większość osób się go spodziewa. Tam gdzie się przyzwyczaili że jest. A jeżeli się jeszcze nie przyzwyczaili, to tam gdzie się o niego będą potykać (jak trzeba to dosłownie). Ludzie nie pytają gdzie jest? To albo jest tam gdzie trzeba, albo z niego nie korzystają. Jak nie korzystają to produkt się nie rozwinie. Bo każda z dziesiątek małych decyzji jakie deweloperzy podejmują każdego dnia będzie podjęta na podstawie złych przesłanek.
7. Jest WYESTYMOWANY. Podobnie jak z priorytetyzacją. Łatwe do osiągnięcia, np. za pomocą białych słoni (klik: http://tastycupcakes.org/2009/09/sizing-game/). A dając z kolei Product Ownerowi lepszy obraz sytuacji i skracająca mnóstwo niepotrzebnych dyskusji.
8. Jest AKTUALNY i UŻYWANY przez wszystkich zainteresowanych projektem. To jest nagroda za powyższe.

 

Tak jest po prostu łatwiej!

Wygoda i zwinność jaką osiągamy za zachowanie powyższych jest nieoceniona.

Szczególnie dla zespołu deweloperskiego. Niestety wymaga mnóstwo pracy od Product Ownera. A to co wymaga pracy wymaga i motywacji. Na niespełnieniu tych kryteriów cierpi odpowiedzialny za jakość zespół. Bo bez dobrego Backloga nie ma dobrego jakościowo produktu.

Dlatego namawiam was zespoły. Zadbajcie o siebie i otwarcie informujcie swoich Product Ownerów o tym jak wam się korzysta z Produkt Backloga!

Cała prawda o czystym kodzie.

Czysty, czytelny, zwinny soft

Czysty kod jest ważny!

Wiem o tym każdy, kto spędził w jednym projekcie więcej niż dwa lata. Jeżeli kod jest czysty – czyli czytelny, to da się go zmienić w sensownym czasie a aplikacja bez trudu nadąży za zmieniającym się rynkiem. Wygląda i zachowuje się po prostu dobrze! Co najmniej dobrze. Czy podbija rynek jak błyskawica zależy od innych czynników. Jadnak czysty kod jest warunkiem koniecznym.

Jak rozpoznać czysty kod?

“Boże, jakie to brzydkie! Czy ja to naprawdę napisałem? Co to w ogóle robi?!”

Jest kilka sposobów sprawdzania czy kod jest czysty.

1. Można sprawdzić aplikacją np. testability explorer (https://code.google.com/p/testability-explorer/) lub sonara (http://www.sonarqube.org/).
2. Jest też mnóstwo mądrych wytycznych. Moje ulubione to wytyczne Misko Havery – Code Reviewers Guide (http://misko.hevery.com/code-reviewers-guide/). Podstawą są też wytyczne zebrane w słynnej książce Uncle Boba Clean Code (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1446560534&sr=8-1&keywords=clean+code).
3. To są świetne sposoby,  ale nie wystarczą. Nic nie zastąpi najważniejszej wytycznej: naszego rozumu. To ludzie będą zmieniać ten kod, więc to ludzie muszą go zrozumieć. Jeśli tylko chcecie napiszę wam kawałek kodu, który przejdzie wszystkie testy, spełni wszystkie warunki a i tak go nie zrozumiecie. Sprawdzanie czytelności przez ludzi jest mniej wygodne, ale tylko ono odpowiada na pytanie czy kod jest czytelny i łatwy do zmiany.

 

Czysty kod jak sumienie.

Sam wiesz czy jest czyste. ale nie zawsze się przyznasz.

Z drugiej strony czytanie kodu jest może czasem mniej wygodne … ale dość łatwe. Doświadczony programista najczęściej w głębi duszy wie, czy to co napisał jest dobre czy słabe.Czasem przyznajemy się nawet w komentarzach (polecam: http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered). Wiemy też, kiedy przesadzamy z dopieszczaniem kodu. I najczęściej się nie mylimy.  Ostateczny osąd powinien wydać jednak ktoś inny niż autor kodu. Może to być kolega z zespołu, który siedzie obok w parze lub ktoś, komu przypadło code review.

Odwagi!

Negatywny feedback

A co jeśli tak nie jest i trzeba powiedzieć, że coś jest do poprawki? Zgroza.Trudno mówić takie słowa!

Dawanie negatywnego feedbacku jest trudne. Wymaga odwagi. Robimy to tylko wtedy jeśli mamy odpowiednią motywację i poczucie bezpieczeństwa. Dwa warunki konieczne.

Czystość kodu

Pokaż mi swój pokój koderów a powiem ci jaki masz kod!

Motywacją jest chęć dostarczenia Product Owner’owi wartościowego produktu i zadbania o klientów, których zespół zna i lubi. A poczucie bezpieczeństwa pojawia się w dobrze zgranym zespole.

Dlatego czystość kodu można poznać też po zachowaniu zespołu:

• jest głośno, w ciągu dnia słychać dyskusje na temat polityki przeplatane z dyskusjami na temat czystego kodu i jak najlepiej zaimplementować daną funkcjonalność,
• często słychać wybuchy śmiechu,
• część ludzi usilnie próbuje odciąć się od dźwięku za pomocą słuchawek,
• i tak ktoś im przeszkadza co jakiś czas pytając jak coś działa, jak nazywa się metoda która coś robi,
• w dyskusjach biorą udział ludzie związani z biznesem, z testowaniem i każdą możliwą branżą, która jest ważna dla produktu, który tworzą,
• nie widać napięcia czy stresu – no chyba, że wywołanego ciekawą dyskusją.

Można to poznać nawet po tym jak wygląda pokój w którym jest zespół:

• pierwszy rzuca się oczy ogromny monitor z wyświetlonym “continus integration”,
• ściany są wypełnione, są tam wykresy, diagramy i mnóstwo śmiesznych, mądrych lub słodkich rzeczy w zależności od preferencji zespołu,
• często widać kilka tablic suchościeralnych z wynikami burzliwych dyskusji lub burzy mózgów,
• na biurkach są książki tematyczne i przeróżne gadżety.

Generalnie widać że mieszka tu wesoła gromada, która lubi swoją pracę,

Problem życzliwego pasażera

Trudno uwierzyć, że właśnie takie zespoły są wydajne. Takie zachowanie kojarzy nam się z lenistwem. Dlatego naprawdę dobre zespoły często są niszczone przez mało doświadczonych kierowników, którzy widząc taką luźną atmosferę zaczynają się wtrącać w to jak zespół wykonuje swoją pracę. A wiemy przecież od Dana Pinka (a jak ktoś nie wie to polecam wpis: http://blog.brasswillow.pl/2015/11/03/czwarty-element-motywacji-o-czym-zapomnial-pink/), że autonomia jest warunkiem absolutnie koniecznym do wytworzenia wydajnego środowiska pracy.

Co gorsza niby to wiemy, niby poczytaliśmy u klasyków coachingu ale też stare korpo przyzwyczajenia biorą górę. Ja sama biję się w piersi. Na jednym z pierwszych szkoleń z czystego kodu, obserwując taki zespół zagadałam do swojej co-trenerki. “Popatrz na nich, nic nie dostarczą”. Po czym zaczęłam zaglądać im przez ramię i próbować coś podpowiadać, zespół jednak twierdził, że są na dobrej drodze i zagadywał mnie na zupełnie nie związane ze szkoleniem tematy. Ostatecznie wymieniliśmy się informacjami na temat ulubionych gier (Herosi!). Gdy czas minął z ciężkim sercem poprosiłam ich o prezentację wyników pracy. Zespół ten jako jedyny ukończył zadania, które dla nich przygotowałam. Ich rozwiązania były zgrabne, czytelne i nie przesadzone. Wierzcie mi więc, wiem jak trudno jest zostawić taki zespół w spokoju. Wiem też, że warto!

Olivia Fox Cabane

Chciałabym dzisiaj przedstawić tym z was którzy jej jeszcze nie było Olivie Fox Cabane.
Jest to moja osobista bohaterka, która pokazuje że aby być człowiekiem charyzmatycznym nie wystarczy samemu być fascynującym, potrzeba jeszcze pokazać innym ich wyjątkowość.

Chcesz sprawdzić co nauka wie o charyzmie?
Polecam wykład Olivii. Jest pełen ciekawych historii, wyników badań i przydatnych wskazówek:

Dla tych którzy już obejrzeli krótkie podsumowanie.

Charyzma ma trzy składniki:

– OBECNOŚĆ – Jeżeli twój rozmówca zauważy, że myślisz o czymś innym, a zostaniesz odebrany niepozytywnie. Okazuje się że masze mózgi radzą sobie świetnie z wychwytywaniem tego. Wystarczy pokazać że odpływamy na 17 milisekund, aby mózg rozmówcy to zauważył i przekazał do świadomości w postaci „wrażenia”. A jak ułatwić sobie bycie obecnym? Na przykład koncentrując się na czymkolwiek w zasięgu widzenia, to przełączy twój umysł na tu i teraz.

– WŁADZA – Szukamy oznak władzy u naszych rozmówców. Jakich? Np. oznak bogactwa, statusu społecznego, analizujemy też języka ciała. Na przykład ile nasz rozmówca zajmuje przestrzeni. Jeżeli przyjmiemy postawę władzy, przekonamy o niej nie tylko innych, ale też siebie. Nasze ciało uwolni chemiczną reakcje związaną z pewnością siebie, co jeszcze ułatwi nam sprawę.

– CIEPŁO – Czyli komunikat o tym jak dużo władzy którą mamy wykorzystamy na rzecz odbiorcy. Olivia twierdzi że nie da się go udawać. Nasz mózg jest mistrzem w wychwytywaniu sygnałów ciepła od innych. Dla nas – zwierząt stadnych jest to krytyczne dla przetrwania. Bądźmy więc autentycznie ciepli dla siebie nawzajem.

Uśmiech

Nie tylko śmiech to zdrowie. Uśmiech też. Oczywiście mamy na to badania 🙂

1. Amerykańscy naukowcy sprawdzili jak wpływają różne rodzaje uśmiechu na stres. W tym celu polecili badanym wykonywać stresującą dla nich czynność i jednocześnie się uśmiechać. Różnie, całą twarzą i tylko ustami. Naturalnie i sztucznie (tylko fizycznie). Okazało się że każdy rodzaj uśmiechu nawet najbardziej wymuszony obniża tętno, czyli obniża poziom stresu. Źródło.

2. Sprawdzono też jaki uśmiech ma związek z atrakcyjnością. Pokazano zdjęcia tych samych osób uśmiechniętych lub nie sporej grupie statystycznej. Która wersja była uznana za bardziej atrakcyjną. Myślę że odpowiedź jest oczywista. Wiemy też czemu. Sprawdzono co się dzieje w mózgu osoby obserwującej uśmiech. Okazuje się że aktywuje się ośrodek nagrody, Uśmiechając się więc nagradzamy odbiorców, nawet jeżeli uśmiechamy się ze zdjęcia Źródło.

3. Ciekawym badaniem było też porównanie ile żyli gracze którzy mieli szersze uśmiechy na kartach bejsbolowych. Okazało się że ci którzy mieli szerokie uśmiechy żyli około 6 lat dłużej. Źródło.

Co mi więc pozostało poza 🙂

Rewolucje

Moje życie jest historią o rewolucjach. Urodziłam się w wielopokoleniowej rodzinie, w małej wsi. W domu pełnym babć i dziadków. Zanim skończyłam 5 lat wszyscy niestety odeszli, a u mnie wykryto wadę serca. Był to bardzo trudny czas dla mojej mamy. Nie było łatwo o zabieg. Oczekiwanie miało wynosić kolejne 5 lat. Mogłam w tym czasie umrzeć. Jednak dzięki determinacji mojej mamy udało się przeprowadzić operację w ciągu roku. Pojechałam na nią do Warszawy. Spędziłam w szpitalu kilka tygodni. Mama została w domu, bo nie było jej stać na hotel w Warszawie. Wyjechałam jako otwarta i wesoła mała dziewczynka. Wróciłam jako twarda i uparta młoda kobieta. To była pierwsza rewolucja w moim życiu.

Czasem zastanawiam się czy historie wszystkich współczesnych ludzi są tak usiane rewolucjami jak moja. Naszych przodków na pewno nie były. Rodzili się i umierali w tych samym domach. Pracowali na roli przez całe życie. Nie mieli możliwości, wzięcia rozwodu, przeprowadzki, zmiany zawodu. My mamy. Nasze życia są ciekawsze. Przyjemniejsze. Wygodniejsze. Z drugiej strony usiane niepewnością i całkiem nowymi rodzajami stresu.
A przecież nasze mózgi kształtowały inne wyzwania, bardziej podobne do wyzwań naszych przodków: praca ma roli, polowania, zbieractwo. Czy to nie stąd fala nałogów, depresji i samobójstw? I czy to sytuacja bez wyjścia?

Na szczęście mózg ludzki przede wszystkim nauczył się dostosowywać do zmieniających się warunków. Trzeba mu tylko trochę pomóc i nakierować jego genialną możliwość dostosowania na właściwe tory. Ja znalazłam dwa narzędzia, które to umożliwiają.
Pierwszym jest coaching, który poprzez rozmowę wydobywa kreatywność i najwyższy potencjał ludzi i zespołów. Drugim jest Scrum, który korzysta z coachingu i daje ramy do stworzenia środowiska optymalnego do wytwarzania konkretnego produktu przez konkretnych ludzi.
Tymi dwoma narzędziami zajmuje się zawodowo. Staram się pomagać ludziom z nich korzystać, pomagam im zmieniać się dokładnie tak jak sobie tego życzą i tworzyć genialne środowiska pracy. O Scrumie, coachingu i o naszych genialnych ludzkich mózgach będę czasem tu pisać.