Prawie każdy słyszał o Test Driven Development czy Feature Driven Development. Ale czy słyszeliście o Business Driven Development? Pierwsze skojarzenie może sugerować, że tego, co będziemy robić jest biznes. Tylko czy chodzi tu o nasz biznes, czy klienta?
BiDiDi, czyli Business Driven Development
Skrót BDD, dotyczy nie tylko Business Driven Development. Istnieje inna metoda, której nazwę możemy zapisać za pomocą tego skrótowca. Jest nią oczywiście Behaviour Driven Development, ale o nim opowiemy w jednym z kolejnych wpisów na naszym ruchliwym blogu.
Czym jest nasz dzisiejszy bohater? Business Driven Development jest metodą, która zrównoważa biznes i osoby odpowiedzialne za wytworzenie rozwiązania. Wychodzimy w niej od biznesowych strategii, na podstawie której modelujemy biznesowe wymagania i cele. Ten model stanowi wkład do rozwiązania IT, które w założeniach ma przecież wspierać biznes naszego klienta.
Brzmi znajomo? Pewnie, że tak. Mówi o tym jedna z 12 zasad zwinnego tworzenia oprogramowania, o których ostatnio dużo mówiliśmy na naszym Facebooku i LinkedInie.
Business Driven Development to metoda skupiająca się na wspieraniu celów organizacji naszego klienta i spełnianiu jego oczekiwań. Wszystkich? To zależy! Złe użycie metody spowoduje, że będziemy realizowali wszystkie „zachcianki” naszego klienta i tworzyli wodotryski.
Niewątpliwą korzyścią z Business Driven Development są dobre relacje z interesariuszem. Czuje on, że jest dla nas kimś istotnym, że liczymy się z jego zdaniem. Widzi też, że to jego organizacja jest źródłem wymagań dla tworzonego rozwiązania, że nie próbujemy wcisnąć na siłę „pudełka”.
Co może pójść nie tak?
Rzeczy, które mogą się nie udać jest całkiem sporo. Pisaliśmy już o upartym kliencie oraz o konsekwencjach takiej postawy. A to tylko czubek góry lodowej.
Co zrobić, jeśli klient uprze się na implementację czegoś, co z naszego punktu widzenia jest „niemożliwe” (czyt. drogie) lub wiemy, że nie da mu korzyści biznesowej (czyt. zbędne)? Powinniśmy mu odmówić czy wręcz przeciwnie, argumentując nasze stanowisko – skłonić do zmiany decyzji?
Co w przypadku, gdy wymagania klienta wykraczają poza przyjęte ramy czasowe oraz budżet projektu. Czy powinniśmy spróbować zmieścić wymaganie w założonym czasie i pieniądzach (np. poprzez nadgodziny), czy jednak spróbować je okroić zostawiając te najważniejsze dla naszego klienta.
Możemy też wyobrazić sobie, że na kanwie ciągle zmieniających się, a jednocześnie mało treściwych wymagań, rozpocznie się proces „rozkładu” naszego zespołu, który tak długo budowaliśmy. Ci bardziej ambitni poszukają miejsca, w którym ich zdanie nie będzie pomijane.
Porozmawiajmy o… wymaganiach
Jednak nie taki wilk straszny jak go malują. Business Driven Development nie jest niczym nowym dla zwinnych projektów. Agile Manifesto mówi wprost:
Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania
Pomińmy na chwilę aspekt czasu, a skupmy się na wartości dostarczonego rozwiązania. Jeśli odpowiednio podejdziemy do pracy z wymaganiami, istnieje duże prawdopodobieństwo, że wpiszemy się z podejściem BDD w zacytowaną przeze mnie powyżej zasadę zwinności.
Niezbędny jest tutaj jednak świadomy Product Owner, posiadający wizję i znający aktualny stan Product Backlogu. PO nie powinien biernie przyglądać się kolejnym pomysłom biznesu, ale poprzez rozmowę i odpowiednią argumentację pokazać, że aktualnie zgłaszane przez klienta potrzeby stoją w sprzeczności (lub też nie) z zamodelowaną wcześniej biznesową strategią.
To z kolei wzmacnia wspólne zrozumienie biznesu na linii Zespół Deweloperski – Product Owner – Interesariusze.
Nie dajmy sobie wejść na głowę
To wystarczy, aby z Business Driven Development zrobić użyteczne narzędzie do wspierania satysfakcji osiąganej przez klienta. Nie róbmy wszystkiego, z czym się do nas zgłosił. Skupmy się na tym, co wspiera jego biznes. Sam przecież nam o tym powiedział w momencie, w którym modelowaliśmy strategie, wymagania i cele. Od tego BDD się zaczyna.
W słowniku interesariusza nie powinno istnieć wyrażenie
„Chcę, bo chcę!”
a jeśli już istnieje, idealną kontrą będzie pytanie
„Co się stanie, jeśli tego nie zrobimy?”
Źle pojmowany Business Driven Development spowoduje więcej szkód, niż pożytku. Nawet, jeśli na początku będzie się wydawało, że wszystko „gra”. Szybko jednak okaże się, że obu stronom nie pasuje taki układ. Klient zacznie wymagać realizacji absolutnie wszystkich wymagań. Natomiast Zespół Deweloperski będzie widział zbliżającą się górę lodową, ale nie podejmie żadnych kroków, aby uniknąć zderzenia.
Jak na Titanicu. A wszyscy wiemy, jak ta historia się skończyła.
