Month: Grudzień 2015

Tim Ottinger na AgileByExample2015

“Programiści wykonują pracę kreatywną, tak samo jak testerze czy kadra zarządzająca, i wszyscy podlegamy systemowi przyzwoleń. Czy się czegoś nauczymy, czy zdobędziemy nowe umiejętności i rozwiniemy nasze talenty zależy od tego czy czujemy, że mamy na to przyzwolenie.” Tim Ottinger opowiada dlaczego przyzwolenie jest supermocą menedżera i dlaczego należy ufać swoim zespołom.

28–30 wrze­śnia miała miej­sce kon­fe­ren­cja AgileByExample2015. Rok wcze­śniej zna­la­zła się w pierw­szej dzie­siątce naj­lep­szych kon­fe­ren­cji Agile na świe­cie. ABE2015 to kil­ka­dzie­siąt pre­zen­ta­cji i dys­ku­sji zgru­po­wane w trzy ścieżki: Zespół, Pro­dukt, Zarzą­dza­nie. Pierw­szego dnia kon­fe­ren­cji odbyły się także warsz­taty, czyli ABE Dojo na któ­rych można było dosko­na­lić swoje umie­jęt­no­ści praktyczne.

Brass Wil­low nie mogło tam zabrak­nąć! Byli­śmy nie tylko spon­so­rem kon­fe­ren­cji ale wśród pre­le­gen­tów i pro­wa­dzą­cych poja­wili się Kate Ter­lecka, Beata Nowa­kow­ska i Paweł Feliński.

Przy współ­pracy z orga­ni­za­to­rami ABE2015 zapro­si­li­śmy wie­lo­let­nich prak­ty­ków Agile do podzie­le­nia się swo­imi doświad­cze­niami i roz­wi­nęli tematy podej­mo­wane w ich wystąpieniach.

Łukasz Węgrzyn na AgileByExample2015

“Największym wyzwaniem pozostaje, żebyśmy wszyscy dobrze zrozumieli co znaczy zrobienie projektu w modelu zwinnym. Nie chodzi o to, żeby jakieś role nazwać nomenklatura scrumową albo agilową czy jakieś wydarzenia albo artefakty nazwać tak jak się nazywają w Scrumie, tylko, żeby realnie podejść do projektu w sposób możliwie elastyczny.” Łukasz Węgrzyn opowiada o budowaniu zwinnych umów dla zwinnych projektów.

28–30 wrze­śnia miała miej­sce kon­fe­ren­cja AgileByExample2015. Rok wcze­śniej zna­la­zła się w pierw­szej dzie­siątce naj­lep­szych kon­fe­ren­cji Agile na świe­cie. ABE2015 to kil­ka­dzie­siąt pre­zen­ta­cji i dys­ku­sji zgru­po­wane w trzy ścieżki: Zespół, Pro­dukt, Zarzą­dza­nie. Pierw­szego dnia kon­fe­ren­cji odbyły się także warsz­taty, czyli ABE Dojo na któ­rych można było dosko­na­lić swoje umie­jęt­no­ści praktyczne.

Brass Wil­low nie mogło tam zabrak­nąć! Byli­śmy nie tylko spon­so­rem kon­fe­ren­cji ale wśród pre­le­gen­tów i pro­wa­dzą­cych poja­wili się Kate Ter­lecka, Beata Nowa­kow­ska i Paweł Feliński.

Przy współ­pracy z orga­ni­za­to­rami ABE2015 zapro­si­li­śmy wie­lo­let­nich prak­ty­ków Agile do podzie­le­nia się swo­imi doświad­cze­niami i roz­wi­nęli tematy podej­mo­wane w ich wystąpieniach.

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!

Ewa Koprowska i Michał Kopyt na AgileByExample2015

“Przechodziliśmy przez frameworki w celu rozwiązania konkretnego problemu. Mówimy o zbudowaniu zwinnej organizacji w której używając wielu pomysłów i popełnianie błędów jest ważniejsze niż trzymanie się jakiegoś konkretnego frameworku. Ważne jest tez by na czele inspekcji i adaptacji stał jakiś człowiek lub jakiś zespół.”  Ewa Koprowska i Michał Kopyt o skalowaniu Scruma i problemach dużej skali.

28–30 wrze­śnia miała miej­sce kon­fe­ren­cja AgileByExample2015. Rok wcze­śniej zna­la­zła się w pierw­szej dzie­siątce naj­lep­szych kon­fe­ren­cji Agile na świe­cie.ABE2015 to kil­ka­dzie­siąt pre­zen­ta­cji i dys­ku­sji zgru­po­wane w trzy ścieżki: Zespół, Pro­dukt, Zarzą­dza­nie. Pierw­szego dnia kon­fe­ren­cji odbyły się także warsz­taty, czyli ABE Dojo na któ­rych można było dosko­na­lić swoje umie­jęt­no­ści praktyczne.

Brass Wil­low nie mogło tam zabrak­nąć! Byli­śmy nie tylko spon­so­rem kon­fe­ren­cji ale wśród pre­le­gen­tów i pro­wa­dzą­cych poja­wili się Kate Ter­lecka, Beata Nowa­kow­ska i Paweł Feliński.

Przy współ­pracy z orga­ni­za­to­rami ABE2015 zapro­si­li­śmy wie­lo­let­nich prak­ty­ków Agile do podzie­le­nia się swo­imi doświad­cze­niami i roz­wi­nęli tematy podej­mo­wane w ich wystąpieniach.

© 2017 Brass Willow Blog

Theme by Anders NorenUp ↑