On 27 Maj, 06:52, Andrzej Jarzabek <a...@g...com> wrote:

> W tym przypadku to banał: że jitter jest niezależny od awarii
> poszczególnych odbiorców. Fizycznie nic nie trzeba wycinać, po prostu
> skreślasz to z ficzerów, jakie posiada twój produkt i wpiszusz na listę
> ficzerów, które trzeba dodać.

To już kumam ten agile. Chodzi o to, żeby nie mówić "w projekcie jest
N bugów", tylko "w projekcie jest 0 (!) bugów i N brakujących
ficzerów". Czad.

To jest zwykła kreatywna księgowość w wydaniu dla project managerów.
Takie szuranie zadaniami nie wnosi kompletnie nic do projektu, może
tylko porawić komuś humor. Słabe. Będę się trzymał procesów, które
nazywają rzeczy po imieniu i gdzie zespół czuje się odpowiedzialny za
swoje fakapy: ficzer to coś, czego jeszcze nie zrobiłem a bug to coś,
co zrobiłem ale spieprzyłem i co muszę poprawić i uczciwie przemyśleć,
jeśli chcę zrobić jakikolwiek postęp. Umiejętność nazwania buga bugiem
jest fundamentalna z punktu widzenia uczciwości i rzetelności
zawodowej i jeśli tego się nie promuje, to ja nie wiem, gdzie my
zmierzamy.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On 27/05/2011 21:58, Maciej Sobczak wrote:
> On 27 Maj, 06:52, Andrzej Jarzabek<a...@g...com> wrote:
>
>> W tym przypadku to banał: że jitter jest niezależny od awarii
>> poszczególnych odbiorców. Fizycznie nic nie trzeba wycinać, po prostu
>> skreślasz to z ficzerów, jakie posiada twój produkt i wpiszusz na listę
>> ficzerów, które trzeba dodać.
>
> To już kumam ten agile. Chodzi o to,

Nie wiem co kumasz. Ja na pewno nie mówiłem o tym, o co chodzi w agile.

> żeby nie mówić "w projekcie jest
> N bugów", tylko "w projekcie jest 0 (!) bugów i N brakujących
> ficzerów". Czad.

Jeśli już, to o to, żeby mówić "w projekcie jest N działających
ficzerów". Bug w optymistycznym przypadku może powodować, że program
danego ficzera nie ma, w mniej optymistycznym powoduje, że próba użycia
ficzera daje jakieś niepożądane skutki, poczynając od wywalenia się
programu, poprzez produkowanie błędnych danych, a kończąc na
nieprzewidywalnym działaniu dowolnych pozostałych ficzerów.

Jeśli program ma opcję w menu, albo jeśli można mu wpisać do
konfiguracji element, który powoduje wywalanie albo destabilizację to
nie jest "brakujący ficzer" tylko jednoznaczny bug. Niekiedy może tak
być, że lepiej w takiej sytuacji wyciąć daną pozycję w menu i usunąć
cały kod ją obsługujący, niż naprawiać buga.

> To jest zwykła kreatywna księgowość w wydaniu dla project managerów.
> Takie szuranie zadaniami nie wnosi kompletnie nic do projektu, może
> tylko porawić komuś humor.

Oczywiście, że wnosi. Pozwala np. podjąć decyzję, czy lepiej mieć dany
feature, czy inne. Z drugiej strony zapobiega dostarczaniu do produkcji
programów, które nie mają bugów, zamiast takich, które niby mają jakiś
feature, ale on nie działa. W ten sposób klient może na podstawie listy
ficzerów zdecydować, czy chce używać danego produktu, czy nie.

> Słabe. Będę się trzymał procesów, które
> nazywają rzeczy po imieniu i gdzie zespół czuje się odpowiedzialny za
> swoje fakapy: ficzer to coś, czego jeszcze nie zrobiłem a bug to coś,
> co zrobiłem ale spieprzyłem i co muszę poprawić i uczciwie przemyśleć,
> jeśli chcę zrobić jakikolwiek postęp. Umiejętność nazwania buga bugiem
> jest fundamentalna z punktu widzenia uczciwości i rzetelności
> zawodowej i jeśli tego się nie promuje, to ja nie wiem, gdzie my
> zmierzamy.

Ja uważam - i to jest moje prywatne zdanie, a nie żadne 'agile', że w
pewnych sytuacjach to, czy coś jest czy nie jest bugiem, zależy od
udokumentowanej funkcjonalności programu.

do góry