On 25 Maj, 14:59, Andrzej Jarzabek <a...@g...com> wrote:

> Pół żartem mogę
> powiedzieć, że masz tak dużo, bo nie stosujesz TDD.
>
> Z tego co rozumiem, to w S&W przez większość czasu powinienes nie mieć
> żadnych bugów w ogóle (o których wiesz).

I właśnie tak jest. Ale w ciągu całego czasu użytkowania systemu tych
bugów może się nazbierać - otwartych jest zwykle 0 lub 1, ale
zamkniętych stale przybywa.
Teraz wyobraź sobie, że masz kilku użytkowników, każdy na innej wersji
- baza zamkniętych już bugów jest konieczna chociażby po to, żeby móc
łatwiej rozpoznać duplikat przy zgłoszeniach od różnych użytkowników.

A oprócz bugów są też feature requesty, których może być kilka(naście/
dziesiąt) otwartych na raz. Czy jest sens używać osobnych systemów do
różnych typów zadań? Nie, bo różnica pomiędzy bugiem a feature
requestem jest jedynie *umowna* - czasami feature request potrafi mieć
wyższą wartość dodaną dla użytkownika, niż poprawka buga, więc nawet
nie ma sensu mówić, że bugi są ważniejsze.
W ten sposób dochodzimy do wniosku, że musi istnieć jakaś baza
interakcji z użytkownikiem (bugi, feature requesty, zapytania, itd.).

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

do góry

On May 26, 1:36 pm, Maciej Sobczak <s...@g...com> wrote:
> On 25 Maj, 14:59, Andrzej Jarzabek <a...@g...com> wrote:
>
> > Pół żartem mogę
> > powiedzieć, że masz tak dużo, bo nie stosujesz TDD.
>
> > Z tego co rozumiem, to w S&W przez większość czasu powinienes nie mieć
> > żadnych bugów w ogóle (o których wiesz).
>
> I właśnie tak jest. Ale w ciągu całego czasu użytkowania systemu tych
> bugów może się nazbierać - otwartych jest zwykle 0 lub 1, ale
> zamkniętych stale przybywa.

SIę gadza i o tym pisałem: ewidencjonowanie zamkniętych bugów to inna
sprawa. Nie wiem jakie masz w tym względnie doświadczenia, ale ja jak
rpacowałem nad jakimś projektem to praktyka była zwykle taka, że
otwartych bugów było dużo i w związku z tym utrzymywało się bazę
bugów, która służyła się do orientowania jakie bugi są jeszcze do
naprawienia, kto ma to zrobić, jaki jest priorytet plus jakieś traile
dotyczące tego
kiedy , przez kogo i w jakich okolicznościach zostały wykryte,
ewentualnych klientów, którym dany bug przeszkadza itd.

> A oprócz bugów są też feature requesty, których może być kilka(naście/
> dziesiąt) otwartych na raz. Czy jest sens używać osobnych systemów do
> różnych typów zadań? Nie, bo różnica pomiędzy bugiem a feature
> requestem jest jedynie *umowna*

Mimo to w używanych przeze mnie systemach do śledzenia bugów i
poprawek zwykle jest pozycja defect/enhancement.

> - czasami feature request potrafi mieć
> wyższą wartość dodaną dla użytkownika, niż poprawka buga, więc nawet
> nie ma sensu mówić, że bugi są ważniejsze.

A dla mnie jest z kolei sensowna sugestia, że w rozpoznanych tego typu
sytuacjach waga naprawy buga jest często niedoceniana.

Jakbym miał się określić jak należy w takiej sytuacji postępować, to
bym powiedział: jeśli się nie da szybko naprawić, to trzeba szybko
przerobi na feature. Poważnie - polegałoby to na tym, żeby w miarę
możliwości wyciąć kawałek funkcjonalności wokół tego buga,
poinformować klienta i dopisać dodanie z powrotem tej funkcjonalności
na listę stories/feature requests, do spriorytetyzowania w trakcie
następnej iteracji.

do góry

On 26 Maj, 17:01, Andrzej Jarzabek <a...@g...com> wrote:

> Jakbym miał się określić jak należy w takiej sytuacji postępować, to
> bym powiedział: jeśli się nie da szybko naprawić, to trzeba szybko
> przerobi na feature. Poważnie - polegałoby to na tym, żeby w miarę
> możliwości wyciąć kawałek funkcjonalności wokół tego buga,
> poinformować klienta i dopisać dodanie z powrotem tej funkcjonalności
> na listę stories/feature requests, do spriorytetyzowania w trakcie
> następnej iteracji.

No bez jaj.
Wracamy do tematu: w systemie przesyłania komunikatów jitter ma być
niezależny od awarii poszczególnych odbiorców. Okazuje się (bug), że
jednak nie jest.
Jaką funkcjonalność wokół tego buga wycinamy? Przesyłanie komunikatów?

To co napisałeś sugeruje, że system jest sumą swoich
"funkcjonalności", które są w miarę niezależne i można je osobno
dodawać (i testować). Tak jest tylko w programie do konwersji ASCII na
Morse'a i tym, które są jemu strukturalnie równoważne.

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

do góry

On 05/26/2011 02:36 PM, Maciej Sobczak wrote:
> On 25 Maj, 14:59, Andrzej Jarzabek<a...@g...com> wrote:
>
>> Pół żartem mogę
>> powiedzieć, że masz tak dużo, bo nie stosujesz TDD.
>>
>> Z tego co rozumiem, to w S&W przez większość czasu powinienes nie mieć
>> żadnych bugów w ogóle (o których wiesz).
>
> I właśnie tak jest.

No nie wiem. Jak kompilujesz soft na AIX 4.3 i nagle na 6.1 przestaje
działać jak trzeba, a najnowszy system, jakim dysponujesz, to 5.3, to
"choćby skały srały", taki bug będzie wisiał.

I to nie jest sytuacja hipotetyczna, dla mnie bread and butter. Więc
wiszą. Poprawia się to, co się da poprawić.

JD

do góry

On 26/05/2011 19:29, Maciej Sobczak wrote:
> On 26 Maj, 17:01, Andrzej Jarzabek<a...@g...com> wrote:
>
> No bez jaj.
> Wracamy do tematu: w systemie przesyłania komunikatów jitter ma być
> niezależny od awarii poszczególnych odbiorców. Okazuje się (bug), że
> jednak nie jest.
> Jaką funkcjonalność wokół tego buga wycinamy? Przesyłanie komunikatów?

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

do góry

On 27.05.2011 06:52, Andrzej Jarzabek wrote:
> On 26/05/2011 19:29, Maciej Sobczak wrote:
>> On 26 Maj, 17:01, Andrzej Jarzabek<a...@g...com> wrote:
>>
>> No bez jaj.
>> Wracamy do tematu: w systemie przesyłania komunikatów jitter ma być
>> niezależny od awarii poszczególnych odbiorców. Okazuje się (bug), że
>> jednak nie jest.
>> Jaką funkcjonalność wokół tego buga wycinamy? Przesyłanie komunikatów?
>
> 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ć.

A jak w core będzie bug? To co? Też dasz jako ficzer do dodania (w
przyszłości aplikacja będzie działać?)

--
wer <",,)~~
http://szumofob.eu

do góry

On May 27, 11:34 am, "b...@n...pl" <b...@n...pl> wrote:
> On 27.05.2011 06:52, Andrzej Jarzabek wrote:
>
> > On 26/05/2011 19:29, Maciej Sobczak wrote:
> >> On 26 Maj, 17:01, Andrzej Jarzabek<a...@g...com>  wrote:
>
> >> No bez jaj.
> >> Wracamy do tematu: w systemie przesy ania komunikat w jitter ma by
> >> niezale ny od awarii poszczeg lnych odbiorc w. Okazuje si (bug), e
> >> jednak nie jest.
> >> Jak funkcjonalno wok tego buga wycinamy? Przesy anie komunikat w?
>
> > 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 .
>
> A jak w core b dzie bug? To co? Te dasz jako ficzer do dodania (w
> przysz o ci aplikacja b dzie dzia a ?)

No, jeśli masz buga, który powoduje, że centralna funcjonalność
twojego programu nie działa, lub działa niepoprawnie lub niestabilnie,
to prawdopodobnie powinieneś to jednak poprawić w pierwszej
kolejności, nawet jeśli to jest trudne. :)

do góry

On May 26, 10:11 pm, Jędrzej Dudkiewicz <jedrzej.dudkiew...@nospam-
gmail.com> wrote:
>
> No nie wiem. Jak kompilujesz soft na AIX 4.3 i nagle na 6.1 przestaje
> działać jak trzeba, a najnowszy system, jakim dysponujesz, to 5.3, to
> "choćby skały srały", taki bug będzie wisiał.
>
> I to nie jest sytuacja hipotetyczna, dla mnie bread and butter. Więc
> wiszą. Poprawia się to, co się da poprawić.

To, że soft nie działa na wersji systemu, której nie wspierasz, to nie
bug.

do góry

Andrzej Jarzabek wrote:

> On May 26, 10:11 pm, Jędrzej Dudkiewicz <jedrzej.dudkiew...@nospam-
> gmail.com> wrote:
>>
>> No nie wiem. Jak kompilujesz soft na AIX 4.3 i nagle na 6.1 przestaje
>> działać jak trzeba, a najnowszy system, jakim dysponujesz, to 5.3, to
>> "choćby skały srały", taki bug będzie wisiał.
>>
>> I to nie jest sytuacja hipotetyczna, dla mnie bread and butter. Więc
>> wiszą. Poprawia się to, co się da poprawić.
>
> To, że soft nie działa na wersji systemu, której nie wspierasz, to nie
> bug.

To zalezy jakie sa wymagania.

--
Michal

do góry

On May 27, 4:00 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
>
> > To, że soft nie działa na wersji systemu, której nie wspierasz, to nie
> > bug.
>
> To zalezy jakie sa wymagania.

No, ja bym nie uznawał, że program, który nie realizuje w danym
momencie wszystkich wymagań ma bugi. W takim ujęciu program, który
dopiero zaczął powstawać jest cały jednym wielkim bugiem. Oczywiście
można w ten sposób o tym myśleć, ale jednak z punktu widzenia takich
zaganień jak niezawodność warto według mnie rozróżniać między
usuwaniem bugów a dodawaniem funkcjonalności. W każdym razie takie
rozróżnienie występuje w metodologii Shore&Warden.

do góry