[tools] Pivotal Tracker - bardzo ciekawe
marcin naglik
Przez przypadek natrafilem dzis na ciekawe narzedzie.
Co wazne darmowe i (mam nadzieje) bez zadnych haczykow
http://www.pivotaltracker.com/
Screencast:
http://www.pivotaltracker.com/learnmore
Nie jest to zadna reklama, bo nie mam nic z pivotallabs wspolnego (a
szkoda).
W kazdym razie jakby ktos uzywal jakos bardziej intensywnie to prosze
o opis wrazen.
Pozdrowienia,
Marcin
Daniel Drozdzewski
Wyglada niezle... Osobiscie nie uzywalem ani nie slyszalem o nich
przed Twoim postem.
Nie do konca wiem, czy ocenianie danego zadania w tylko czterech
kategoriach (latwe, srednie, trudne, b.trudne) jest dobre no i ze
screencastu wynika ze napewno wypusty (ale rowniez podejrzewam, ze
bug'i i chore'y) nie maja przypisanych punktow. Jestem ciekaw, co stoi
za takim podejsciem, skoro owe zadania ze swojej natury maja niezerowy
koszt. Skoro cos wymaga czas oraz wkladu pracy, nigdy nie jest tak, ze
przychodzi za darmo.
Czy ktos spotkal sie wczesniej z takim podejsciem? Jesli tak, czy
moglby ten ktos wytlumaczyc dlaczego ocenia sie pewne zadania jakoby
kosztowaly one przyslowiowe nic.
Z podzienkowaniami,
Daniel
2009/11/6 marcin naglik <marcin...@googlemail.com>:
Daniel Drozdzewski
Adam Pohorecki
W odpowiedzi na drugie pytanie: niektórym zadaniom (szczególnie bugom)
przypisuje się zazwyczaj estymację 0, nie dlatego, że do ich wykonania
nie potrzeba czasu, tylko dlatego, żeby zróżnicować zadania na mające
wartość biznesową (ficzery) i takie które choć trzeba wykonać, to nic
nowego dla użytkownika nie wnoszą. Zwróć także uwagę, że takie
"zerowe" zadania mają wpływ na velocity (odpowiednio ją obniżając) -
dzięki takiemu potraktowaniu bugów, możemy powiedzieć że velocity
zespołu oznacza jak szybko może on implementować funkcjonalności dla
użytkownika, jak również pozwala to na lepsze zobrazowanie tego jak
technical debt wpływa na velocity zespołu.
Pozdrawiam,
Adam Pohorecki
2009/11/6 Daniel Drozdzewski <daniel.dr...@gmail.com>:
Daniel Drozdzewski
> Staaaaaare:) Estymacja 4 poziomowa jest tylko jedną z kilku do wyboru.
> W odpowiedzi na drugie pytanie: niektórym zadaniom (szczególnie bugom)
> przypisuje się zazwyczaj estymację 0, nie dlatego, że do ich wykonania
> nie potrzeba czasu, tylko dlatego, żeby zróżnicować zadania na mające
> wartość biznesową (ficzery) i takie które choć trzeba wykonać, to nic
> nowego dla użytkownika nie wnoszą. Zwróć także uwagę, że takie
> "zerowe" zadania mają wpływ na velocity (odpowiednio ją obniżając) -
> dzięki takiemu potraktowaniu bugów, możemy powiedzieć że velocity
> zespołu oznacza jak szybko może on implementować funkcjonalności dla
> użytkownika, jak również pozwala to na lepsze zobrazowanie tego jak
> technical debt wpływa na velocity zespołu.
>
> Pozdrawiam,
> Adam Pohorecki
Osobiscie uwazam, ze ocenianie bugow jako zero nie jest najlepsze -
bardziej dokladna estymacja owych pozwala obrazowac kilka rzeczy, jak
np. stosunek pomiedzy czasem spedzonym na wykonanie danej
funkcjonalnosci a czasem poswieconym na naprawianie bugow,
wprowadzonych poprzez implementacje owej. Jest to nie najlepszy, ale
jeden z wyznacznikow jakosci procesu. Co wiecej, raz taki stosunek
zmierzony mozna probowac polepszac, np. dodac w danej iteracji
dodatkowe wymogi, ktore to zadecyduja o zakonczeniu zadania (np.
prezentacja danej funkcji testerom, ktorzy to zadaja kilka pytan,
probuja kilku klikniec, gdzie podejrzewaliby bledy i jesli taki krotki
test powiodl sie, mozna uznac zadanie za zakonczone) i zobaczyc, czy
ilosc czasu poswiecanego naprawom zmniejszyla sie w stosunku do czasu
poswieconego wdrazaniu.
Pytanie o tym, czy jezeli cos nie jest "ficzerem" nic nie wnosi dla
uzytkownika, jest rowniez natury filozoficznej. Jak dla mnie jakosc
oprogramowania czy tez ilosc bledow w danym sofcie jest bardzo waznym
parametrem, ktory wnosi ogromnie duzo dla uzytkownika. Osobiscie
jestem za podpinaniem wymogow niefunkcjonalnych jako wlasnie
funkcjonalnych. Ilosc upadkow danego systemu w miesiacu jest jak
najbardziej obserwowalna, mierzalna i z tego co wiem, kazdy chcialby
ja miec rowna zero. Tak samo z predkoscia czy tez bezpieczenstwem,
ktore to same w sobie nie sa osobnymi funkcjami w produkcie. Ale to
moje osobiste zdanie, wiec prosze nie strzelajcie do pianisty.
Do raportowania, obliczania predkosci itp. liczenie pewnych parametrow
projektu tylko dla funkcji albo tylko dla bug'ow winno sie odbywac na
podstawie tego, ze wrzucajac nowe zadanie przypisuje mu sie kategorie
BUG albo FEATURE. Oznacza to ze system "wie" co jest co i wystarczy go
o te konkretne rzeczy zapytac. Starajac sie "kodowac" czy cos jest
bugiem czy nie w ilosci punktow, jest wedlug mnie zamglaniem obrazu.
Daniel
Daniel Drozdzewski
Marcin Zajączkowski
> Hej,
> Przez przypadek natrafilem dzis na ciekawe narzedzie.
> Co wazne darmowe i (mam nadzieje) bez zadnych haczykow
>
> http://www.pivotaltracker.com/
Jakiś czas temu trafiłem na to narzędzie (bardziej usługę) i wyglądało
ciekawie, jednak AFAIR było dostępne tylko w wersji hostowanej (nie było
aplikacji do pobrania do uruchomienia u siebie lokalnie na serwerze). To
może być problemem dla wielu firm, które nie chciałyby trzymać swoich
(poufnych) danych na zewnętrznych serwerach i mieć wpływ na %
dostępności rozwiązania.
Pozdrawiam
Marcin
>
> Screencast:
> http://www.pivotaltracker.com/learnmore
>
> Nie jest to zadna reklama, bo nie mam nic z pivotallabs wspolnego (a
> szkoda).
> W kazdym razie jakby ktos uzywal jakos bardziej intensywnie to prosze
> o opis wrazen.
>
> Pozdrowienia,
> Marcin
>
To poniżej to reklama i nie ma konieczności jej czytania.
----------------------------------------------------
Oszczędzaj na kredycie.
Nie przepłacaj!
Porównaj oferty: http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Ffinansomat.html&sid=907
Andy Brandt
2009/11/6 Daniel Drozdzewski <daniel.dr...@gmail.com>:
> Osobiscie uwazam, ze ocenianie bugow jako zero nie jest najlepsze -
[...]
> o te konkretne rzeczy zapytac. Starajac sie "kodowac" czy cos jest
> bugiem czy nie w ilosci punktow, jest wedlug mnie zamglaniem obrazu.
W pełni się zgadzam. My stosowaliśmy taką praktykę w paru projektach,
że bugi duże były wrzucane na backlog i podlegały normalnemu
procesowy, natomiast na bugi małe (zwłaszcza wykrywane podczas
sprintu) alokowaliśmy explicite czas tworząc meta-backlog-item "Bugs
for sprint XX" i pod niego podczepialiśmy w naszym narzędzi
(http://www.bananascrum.com/) meta-taski z zaalokowaną ilością godzin
na bugi. W trakcie sprintu członkowie zespołu zmniejszali te
"meta-godziny" a dopisywali jako zamknięte taski zrobione bugi.
Nieco wysiłku, ale:
- wszystkie bugi przepływają przez sprinty jawnie,
- historia jest prawidłowa, duże bugi mają estymaty w Story Points,
które potem można wziąść i zobaczyć w historii sprintów, uwzględnić
przy velocity itp.,
- podobnie czas na bugi małe jest brany pod uwagę np. w burndown,
- alokowanie z góry czasu na małe bugi pomaga nie rozmieniać się na
drobne w trakcie sprintu.
--
Regards,
Andy
http://www.codesprinters.com/
http://www.andybrandt.net/
Wave to me: akbr...@googlewave.com
Paweł Lipiński
My znowu nie umieszczamy jawnie bugów w backlogu (product), bo koszt
ich naprawy i tak sam się policzy (w sprint backlogu mamy, choćby po
to żeby dobrze iterację zaplanować, z resztą napisałeś po co to tam)
Po prostu jeśli jest ich więcej (lub są większe) to nasz efektywność
(czy jakkolwiek by tłumaczyć velocity) automatycznie się zmniejsza
(bierzemy mniej do iteracji). Jeśli jest to stały trend to efektywność
trwale się obniża.
Andy, po co wam w ogóle te bugi w historii? Może czegoś nie dostrzegam.
pzdr
Paweł
PS. wiem, że to moja Warszawska złośliwość, ale po naszemu jest wziąć
a nie wziąść. Choć nie wiem co wy tam w tym Krakowie macie :-P
--
www.pragmatists.pl
blog.pawellipinski.com
Wiadomość napisana przez Andy Brandt w dniu 2009-11-06, o godz. 21:55:
Bartek Kobyłecki
http://www.linkedin.com/pub/bartek-kobylecki/0/502/534
http://www.goldenline.pl/bartosz-kobylecki
"What would you do today, if it was the last day of your life?"
Andy Brandt
2009/11/7 Paweł Lipiński <lipinsk...@gmail.com>:
> Andy, po co wam w ogóle te bugi w historii? Może czegoś nie dostrzegam.
Chodzi mi o to, że jawne planowanie bugów "większych" włącznie z
szacowaniem w SP powoduje, że widoczna w historii velocity (rozumiana
jako ile SP było w poprzednich sprintach) jest bliższa rzeczywistości.
Oczywiście, to jest religijna dyskusja czy velocity ma nam pokazywać
naszą prędkość działania ogólnie czy tylko w odniesieniu do product
backlogu w sensie ścisłym. Ja uważam, że ogólnie - w końcu poprawianie
błędów to także praca.
Nota bene jawne alokowanie z góry czasu na sprintach na "małe" bugi
wynikło z takiej sytuacji, że w długich projektach dzieje się zwykle
tak, że gromadzą się różne "małe" bugi, głównie niekrytyczne
niekompatybilności z przeglądarkami i inne takie rzeczy. Je też trzeba
"sprzątać", ale w pewnym momencie było tak, że parę sprintów okazało
się przeszacowanych i pod koniec nie było co robić. Zamiast spojrzeć
na backlog czy nie dałoby się czegoś stamtąd wziąść zespół robił sobie
przez ostatnie dni sprintu same "małe" bugi. Wyznaczenie górnego
limitu czasu na to spowodowało, że było tu więcej dyscypliny i nie
było krycia tego, że się nie ma co robić pod "robieniem bugów".
Zarazem, dzięki temu w sprintach dopakowanych zawsze jednak parę
"małych" bugów zostało załatanych, co uważam za dobrą rzecz bo jednak
dług techniczny trzeba spłacać.
> PS. wiem, że to moja Warszawska złośliwość, ale po naszemu jest wziąć
> a nie wziąść. Choć nie wiem co wy tam w tym Krakowie macie :-P
Mi się wydaje, że wziąść jednak ale ja się nie znam. Z tym, że ja w
zasadzie to nie jestem z Krakowa. :) Ja ty tylko mieszkam, a Krakusem
trzeba się urodzić.
Paweł Lipiński
>> Andy, po co wam w ogóle te bugi w historii? Może czegoś nie
>> dostrzegam.
>
> Chodzi mi o to, że jawne planowanie bugów "większych" włącznie z
> szacowaniem w SP powoduje, że widoczna w historii velocity (rozumiana
> jako ile SP było w poprzednich sprintach) jest bliższa rzeczywistości.
> Oczywiście, to jest religijna dyskusja czy velocity ma nam pokazywać
> naszą prędkość działania ogólnie czy tylko w odniesieniu do product
> backlogu w sensie ścisłym. Ja uważam, że ogólnie - w końcu poprawianie
> błędów to także praca.
Ale velocity służy przecież do planowania wykonania backlogu, terminów
wdrożeń, określenia co da się na kiedy itp.
Jeśli dorzucasz i szacujesz bugie, to zakładasz, że będzie ich cały
czas średnio tyle samo (tych dużych). Co pewnie nie jest prawdą, jeśli
dbasz o jakość. Do tego uniewidaczniasz wtedy co jest nową przynoszoną
wartością, a co fixami. Tak więc wszystkie planowania, które będziesz
bazował na tych danych będą przeszacowane (jeśli nie będzie jednak
tylu grubych błędów). W najlepszym wypadku skutkuje to po prostu
zmniejszeniem dokładności oszacowań i zwiększeniem ryzyka pomyłki (i
to tym większym im bardziej długosiężne te plany będą).
Poprawianie błędów to oczywiście także praca, ale jednak
"niezasłużona" bo nie przynosząca nowej wartości - jeśli pracujecie
T&M to nie powinniście za nią pobierać pieniędzy, nie? Wliczając to w
zwykły backlog gubicie tę informację (chyba, że jakoś oddzielnie ją
śledzisz).
Inna kwestia to czy to faktycznie duże bugi czy po prostu nowe/
zmienione wymagania / niezrozumienie ich w pierwszej wersji. Wtedy
jest to dodawanie wartości, a więc "normalna" praca.
A może jakoś inaczej to liczycie?
> Zarazem, dzięki temu w sprintach dopakowanych zawsze jednak parę
> "małych" bugów zostało załatanych, co uważam za dobrą rzecz bo jednak
> dług techniczny trzeba spłacać.
A od kiedy bugi to dług techniczny? (Uppps religijna dyskusja...) Dług
techniczny (tak jak ja go rozumiem) to wtedy, gdy mówimy: mamy mało
czasu, więc świadomie omijamy jakąś praktykę np. pair programming czy
tdd (świadomie zaniżając tak jakość). Albo gdy podejmujemy świadomie
decyzje techniczne np. pisze się kawałek UI w php, bo to szybciej niż
w javie. Albo w końcu (niskopoziomowo) np. rezygnuje z pełnego parsera
tekstu na rzecz wykrywania magicznych ciągów znaków, a "kiedyś zrobi
się to dobrze".
A bugi to bugi a nie dług.
(Tak, tak, wiem, że to jest czepiactwo, ale "Dług Techniczny" stał się
słowem-kluczem do tłumaczenia niedbałości i śmietnika w kodzie, więc
nazywajmy rzeczy po imieniu.)
> Mi się wydaje, że wziąść jednak ale ja się nie znam. Z tym, że ja w
> zasadzie to nie jestem z Krakowa. :) Ja ty tylko mieszkam, a Krakusem
> trzeba się urodzić.
Jednak to jest "wziąć" (nawet mój słownik mailowy tak mówi, a on nie z
Warszawy)
pozdrawiam
Paweł
Andy Brandt
2009/11/7 Paweł Lipiński <lipinsk...@gmail.com>:
>>> Andy, po co wam w ogóle te bugi w historii? Może czegoś nie
>>> dostrzegam.
>>
>> Chodzi mi o to, że jawne planowanie bugów "większych" włącznie z
>> szacowaniem w SP powoduje, że widoczna w historii velocity (rozumiana
>> jako ile SP było w poprzednich sprintach) jest bliższa rzeczywistości.
>> Oczywiście, to jest religijna dyskusja czy velocity ma nam pokazywać
>> naszą prędkość działania ogólnie czy tylko w odniesieniu do product
>> backlogu w sensie ścisłym. Ja uważam, że ogólnie - w końcu poprawianie
>> błędów to także praca.
>
> Ale velocity służy przecież do planowania wykonania backlogu, terminów
> wdrożeń, określenia co da się na kiedy itp.
[...]
> Poprawianie błędów to oczywiście także praca, ale jednak
> "niezasłużona" bo nie przynosząca nowej wartości - jeśli pracujecie
> T&M to nie powinniście za nią pobierać pieniędzy, nie? Wliczając to w
> zwykły backlog gubicie tę informację (chyba, że jakoś oddzielnie ją
> śledzisz).
Niewątpliwie coś w tym jest, co piszesz. Ale jak pisałem wyżej - to
jest kwestia "religijna" - ważne jest raczej, żeby mieć tego
świadomość. Tak w ogóle przejrzałem sobie backlogi historyczne z paru
projektów i prawdę pisząć nie znalazłem więcej niż parę "dużych"
błędów na backlogu jawnie - a i te nie były nasze (praca na kodzie,
którego nie zaczynaliśmy). Więc chyba nie jest tak źle.
>> Zarazem, dzięki temu w sprintach dopakowanych zawsze jednak parę
>> "małych" bugów zostało załatanych, co uważam za dobrą rzecz bo jednak
>> dług techniczny trzeba spłacać.
>
> A od kiedy bugi to dług techniczny? (Uppps religijna dyskusja...)
Dobra, ja to widzę jako dług techniczny na zasadzie, że coś robiliśmy
ale nie wyłapaliśmy i trzeba poprawiać. Coś takiego jak świadome
zaniżanie jakości to nie jest żaden dług tylko po prostu wymuszone
polityką (a czasem wprost przez klienta) zgniłe kompromisy. Ale jako
się rzekło - nie będę się upierał.
> (Tak, tak, wiem, że to jest czepiactwo, ale "Dług Techniczny" stał się
> słowem-kluczem do tłumaczenia niedbałości i śmietnika w kodzie, więc
> nazywajmy rzeczy po imieniu.)
To jest problem wszystkich słów-kluczy.
>> Mi się wydaje, że wziąść jednak ale ja się nie znam. Z tym, że ja w
>> zasadzie to nie jestem z Krakowa. :) Ja ty tylko mieszkam, a Krakusem
>> trzeba się urodzić.
> Jednak to jest "wziąć" (nawet mój słownik mailowy tak mówi, a on nie z
> Warszawy)
Wychodzi na to, że masz rację: http://www.wsp.krakow.pl/konspekt/19/jezyk19.html
Ale biorąc pod uwagę zacne towarzystwo (Mickiewicz, Asnyk, no no)
wstydzę się tylko trochę.