Author: Beata Nowakowska (page 1 of 2)

Tania zmiana

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

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

Zmiana przekonań jest trudna, bo 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. 

1

Continue reading

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!

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

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.

pablo (2)

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.

4315444

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.

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!

Po co nam dobry Product Backlog?

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.

we-can-do-it

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!

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!

Cała prawda o czystym kodzie

clean code

Czysty, czytelny, zwinny soft

Czysty kod jest ważny!

Wie 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  lub sonara.
  2. Jest też mnóstwo mądrych wytycznych. Moje ulubione to wytyczne Misko Havery – Code Reviewers Guide . Podstawą są też wytyczne zebrane w słynnej książce Uncle Boba 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.

clean code

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. 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

“Popatrz na nich, nic nie dostarczą”

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 ( o czym pisałam już tutaj), że autonomia jest warunkiem absolutnie koniecznym do wytworzenia wydajnego środowiska pracy.

Co gorsza niby to wiemy, niby poczytaliśmy u klasyków coachingu ale 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!

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!
Older posts

© 2017 Brass Willow Blog

Theme by Anders NorenUp ↑