“NoEstimates”
Jedną z najbardziej wartościowych prezentacji w mojej opinii była „NoEstimates - Alternatives to Estimates” Henri Karhatsu. Idea NoEstimates nie przeciwstawia się całkowitemu zakazowi używania estymacji. Postulat ten podpowiada kiedy nie trzeba używać estymacji, w jakich momentach można zachować się inaczej bez wsparcia się wynikiem z estymacji i co robić, aby nie odwoływać się do estymacji.
Z sesji wybrałbym następujące punkty:
1 Nie zawsze w projekcie sytuacja wymaga podania estymacji czasowej zadania. Warto najpierw zastanowić się:
Czy dany problem jest rozwiązywalny,
Czy warto go teraz rozwiązać,
2 Czasami też warto najpierw zadać pytanie:
Jak ważne jest to zadanie w porównaniu do innych zadań.
Jaki jest możliwy deadline na to,
I jakie są konsekwencje przekroczenia deadline-u. (http://blog.karhatsu.com/2014/10/cost-of-delay-and-artificial-deadlines.html)
3 Można też zastanowić się jak pomóc w inny sposób w podjęciu decyzji niż podawanie estymacji (odsyłam do posta na ten temat http://blog.karhatsu.com/2014/03/need-to-estimate-part-ii.html ).
4 Kiedy nie trzeba wyliczać estymacji czasowej?
Jeśli zespół cyklicznie dostarcza funkcjonalności, User Story na czas, które są estymowane np. w punktach to można przyjąć, że estymacja czasowa zadań jest zbędna.
Na poparcie tego stwierdzenia można przytoczyć definicje “Manifesto for Agile”, w którym nie ma słowa o estymacji (http://agilemanifesto.org/ ) , a wręcz “Agile Manifesto" zawiera odważne sformułowanie, aby odnajdywać lepsze drogi do tworzenia oprogramowania:
“We are uncovering better ways of developing software by doing it and helping others do it.”
Po prostu to robić, a nie tylko zakładać.
5 #NoEstimates hash tag został utworzony w celu dyskusji nad tym tematem.
Definicja Woody Zuill #NoEstimates jest to hash tag związany z tematem odkrywania alternatyw co do “wymagania estymacji” w celu podjęcia decyzji podczas tworzenia oprogramowania.
Odsyłam do autora blogu na ten temat: http://blog.karhatsu.com/2014/06/about-definition-of-noestimates.html
6 Zostały przedstawione nierówności, które dają do myślenia:
Chęć otrzymania czegoś != Potrzebowanie czegoś
"Potrzebowanie" estymacji != Potrzebowania estymacji
7 Inny temat do zastanowienia:
Estymacja - > Fałszywa pewność, rzadko redukuje niepewność
Najlepszy sposób na usunięcie niepewności w tworzeniu oprogramowania -> przekazywanie działającego software-u.
Przykład: Jeśli chciałbyś zainwestować w projekt, który wy estymowany został na 1 milion dolarów. Czy wydałbyś 50k więcej, aby dowiedzieć się więcej o projekcie (drip funding).
Można wykorzystać podejście Build-Measure-Learn (LeanStartup - Eric Ries)
Podsumowując. NoEstimates zawiera proste, a czasem banalne porady, które jeśli są używane częściej niż zwykle, mogą pokazać, uwypuklić prawdziwe problemy w procesie, produkcie, zamiast łudzić się, że będzie dobrze w wyznaczonym przez NAS czasie!
“Fail”
Spośród prezentacji, które przedstawiały ciekawostki, konkrety, akcentowały coś co już wiemy chciałbym przedstawić sesje “What went wrong (and what can we learn form it)”.
Czasami mimo najlepszych chęci, poprawnych decyzji produkt poniósł całościowo totalną porażkę.
Wyobraźmy sobie, że projekt stworzenia i wdrożenia samolotu Boeing 787 Dreamliner opóźnił się o 5 lat, a koszt projektu końcowy został przekroczony o 500% względem prognozowanego na 32 miliardy dolarów. Możemy, pomyśleć, że takie sumy, projekty nas nie dotyczą. Jeśli te firmy i inne osoby spoglądają na te porażki i powody z jakich się zrodziły to warto abyśmy my na to spojrzeli i mogli wyciągnąć wnioski.
Porażka projektu Dreamliner spowodowana była skupieniem się tylko na wartości dla akcjonariuszy. Projekt początkowo był nastawiony tylko na zdobycie maksymalnych oszczędności. Niestety takie podejście sprawiło, że pojawiły się opóźnienia, których nikt nie był w stanie oszacować.
W kolejnym przykładzie Kate Terlecka przygotowała świetne zdjęcia, które pokazują jak przy tworzeniu produktu ważne jest myślenie w pierwszej kolejności o kliencie.
Czy wiadomo, że wielką porażką potentata samochodowego Volswagena było świetne auto Volkswagen Phaeton?
Otóż powód tej porażki związany był z tym, że Volswagen zaprojektował i stworzył auto perfekcyjne, ale nie dla klienta, który był skojarzony z ich marką. Nikt, go po prostu nie chciał kupić.
Na koniec tej sesji przytoczony został cytat Charles Darwin, który według mnie najlepiej obrazuje jak ważne jest w firmie, produkcie i procesie jak np. Agile dostosowywanie się do zmian:
"it is not the strongest of the species that survives. nor the most intelligent . but rather the most adaptable to change"Charles Darwin
Podsumowanie
Moim zdaniem najodważniejszą prezentację przedstawił Paweł Skolimowski z tematem "A dead Scrum Master is a useless Scrum Master". Według mnie trzeba mieć dużą odwagę i pasję, aby prezentować trudny temat porażek Scrum Mastera na podstawie własnego cennego doświadczenia. Paweł przedstawił jak ważne jest realistyczne wdrażanie praktyk scrum-owych przez dobry kontakt z klientem, zaufanie, budowanie więzi czyli po prostu przez wprowadzenie oddolnych zmian. Dla mnie była to najlepsza prezentacja.
W mojej opinii udział w konferencji nie był czasem straconym ponieważ konferencja poruszała trudne elementy pracy w Agile oraz te strefy pracy z projektem, produktem w grupie na które trzeba zwrócić większą uwagę.
O organizacji konferencji:
Biorąc pod uwagę tematykę, można było stworzyć więcej interakcji z uczestnikami, np. brakowało choć sprawdzenia, czy formuła po pierwszym dniu odpowiedziała na potrzeby słuchaczy lub czy “klienci” mają inne wymagania. W końcu Agile jest to zwinne dostosowywanie się do wymagań klienta. :-)
----------------
Jeśli zainteresował Cie temat/zawartość post-a i mógłbyś wpisać mi swój komentarz, aby ten post był lepszy. Proszę wypełnij formularz:
Google formTwój komentarz jest szalenie ważny dla mnie.
Mail jest opcjonalny i może służyć tylko do współpracy nad tym artykułem. Z mojej strony mogę zapewnić Cię, że dane nie zostaną udostępnione.
DZIĘKI
Brak komentarzy:
Prześlij komentarz