fbpx

Bug-Driven Development

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 🙂



1 Response

  1. To co w tym przede wszystkim jest to bardzo dobra metafora, dlaczego szybki feedback jest świetną metodą na zweryfikowanie czego klient tak naprawdę potrzebuje. Oczywiście metafora bardzo przerysowana, jednak dzięki temu sedno wyraźniej widać. Choć pewnie znajdzie się kilka firm, gdzie zastosowanie dosłowne tego podejścia byłoby możliwe.