- Ale tego nie było w specyfikacji.
- Ok, ale to przecież oczywiste, że powinniście to zrobić.
- Jak to oczywiste?
- No, kurcze...
Niezliczoną ilość razy z pewnością słyszałeś powyższy dialog.
Chyba wciąż chodzi o to samo - o niedostateczne sprecyzowanie wymagań, a potem o zepchnięcie odpowiedzialności. Przyczyny wspomnianego stanu rzeczy są znane i maglowane wciąż na nowo: trudności komunikacyjne, brak czasu, brak zaangażowania klienta itd, itp. Pewnie chodzi o to, że z wymienionych powodów wymagania nie zostały dobitnie i jednoznacznie sformułowane.
A jeśliby tak ustawić sposób współpracy, że brutforsowo wymusi jednoznaczne formułowanie wymagań? który nie będzie polegał na dobrej woli i chęci zaangażowania, ale po prostu uniemożliwi sformułowanie niejednoznacznych wymagań? I tu jest właśnie miejsce dla Bug-Driven Development :)
No, wyobraź sobie następującą scenę:
Zaczyna się rozmowa z PO na temat nowego sprintu
- Skończyliśmy! - krzyczy uradowany Zespół
- Jak to? Pokażcie!
Zespół z namaszczeniem odpala przeglądarkę, na której widać...białą przestrzeń.
Zmieszany PO jąka - Ale tu nic nie ma...
- Jak to nie ma? - odpowiada pewny jak McGyver siebie Zespół.
- No, nie mogę się zalogować.
- Ok, mamy pierwszy bug - zespół skrupulatnie notuje coś na kartce.
- Czekaj, wrócimy za dziesięć minut.
- ?? - odpowiada PO.
Po chili grupa programistów wpada do sali spotkań.
- Już mamy! - wrzeszczą uradowani.
- Czyli co?
- Jak to co? Soft dla Ciebie! Co z tobą, Łosiu?
Odpalają przeglądarkę z pięknym ekranem logowania. PO z nadzieją w oczach loguje się do systemu i....
- Aaaa! $^!@#&(!
- Czy coś nie tak? - pytają z zaciekawieniem programiści.
- A gdzie panel użytkownika, do cholery!!
Na to szczęśliwy jak nigdy dotąd SM:
- Ok, chłopaki mamy drugiego buga!, spadamy.
Po czym rzuca przez ramię, do oniemiałego PO.
- Pół godzinki i jesteśmy, buźka!
i tak przez najbliższe cztery tygodnie.
To tak, pół żartem, pół serio, ale czuję, że coś w tym jest :)
