On 17/12/2011 15:30, Roman W wrote:
> On Dec 17, 8:53 am, Maciej Sobczak<s...@g...com> wrote:
>> Dokumentacja nie służy do redukcji ilości bugów, więc to, że jakieś
>> tam metody redukują tą ilość skuteczniej niż dokumentacja nie może
>> prowadzić do żadnych sensownych wniosków. W szczególności nie do
>> takich, że dokumentacji może nie być.
>
> Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
> co jest bugiem, a co nie. Jak programista Agile ma eliminowac bugi,
> kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu? "On-
> site customer representative" mu o tym za kazdym razem powie? Przeciez
> to wiaze programiscie rece -- z kazda zmiana w kodzie musi leciec do
> "on site customer representative", bo a nuz zmiana ktora chce
> wprowadzic w kodzie zmieni zachowanie systemu w sposob ktory jest
> nieakceptowalny dla OSCR - a programista sam tego sprawdzic nie ma
> gdzie, bo czniamy dokumentacje.

Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
długo, żeby zrozumieć co program ma robić, a jeśli nie jest w stanie
zrozumieć czy ewentualne zachowanie jest prawidłowe, czy nie, to
rozmawia z OSCR jeszcze trochę.

Na podstawie takiej rozmowy programista razem z OSCR tworzą acceptance
test, który weryfikuje istotne askpekty funkcjonalności. Jeśli
programista zmieni program tak, że przestaje przechodzić testy, które
wcześniej przechodził, to może skonsultować się z OSCR w kwestii
ustalenia, czy testy są błędne i należy je zmodyfikować.