Jak odnieść sukces na warsztatach specyfikacji BDD?

Dzisiaj próbowaliśmy wprowadzić BDD w naszym procesie tworzenia oprogramowania, prowadząc warsztat specyfikacji.

Na te warsztaty mieliśmy 2 programistów, 1 tester i 1 analityk biznesowy. Warsztaty trwały 1:30 i pod koniec udało nam się wymyślić kilka scenariuszy BDD dla naszej nowej funkcji. Staraliśmy się skoncentrować na znalezieniu scenariuszy, które moglibyśmy przeoczyć, i tych trudnych.

Pod koniec warsztatu niektórzy ludzie byli niezadowoleni z warsztatu.

Jeden z programistów uznał, że zmarnował czas, ponieważ analityk biznesowy dawał mu scenariusze i przeglądał je razem z nią. Analityk biznesowy nie czuł się pewnie z naszymi relacjami ze scenariuszy (miałem wrażenie, że moglibyśmy pominąć inne ważne rzeczy), ale co ważniejsze, uznał, że te warsztaty to także strata czasu, ponieważ sama mogła zrozumieć wszystkie te scenariusze i w krótszym czasie .

Te eksperymentalne warsztaty trwały 1:30, a pod koniec nie czuliśmy się wystarczająco pewni tego, co zrobiliśmy ... pewnie moglibyśmy spędzić na tym więcej czasu, ale szczerze mówiąc, większość ludzi wyczerpała się po 1 30:30 od burzy mózgów, aby znaleźć biznes rządzi z mózgu BA.

Moje pytanie brzmi więc, jak ten rodzaj warsztatu może faktycznie działać. W teorii, biorąc pod uwagę, że masz nową funkcję do opracowania, umieścisz drzewo „amigos” (dev / tester / ba) w tym samym pokoju, aby mogli współpracować przy pisaniu różnych wymagań dla nowej funkcji na przykładach. Widzę z tego wszystkie korzyści. Zwłaszcza w kontekście dzielenia się wiedzą i wspólnej wizji produktu / celu końcowego / zrealizowanej wizji.

Doszliśmy do wniosku z tego eksperymentu, że faktycznie bardziej opłacalne jest posiadanie licencjata do samodzielnej pracy nad przykładami, a dopiero potem przeglądanie / przerabianie scenariuszy przez 3 „amigos”. Dysponując licencjatem do samodzielnej pracy, czujemy się bardziej pewni, że nie umknie nam żadna rzecz + nadal możemy przeglądać scenariusze w celu podwójnego sprawdzenia. Nie uważamy, że prosta jednorazowa burza mózgów / celowe odkrycie jest w rzeczywistości wystarczająca, aby poważnie pokryć wszystkie wymagania dotyczące nowej funkcji. Analityk biznesowy jest właściwie najlepszą osobą do tego typu rzeczy. Najlepszą rzeczą, jaką możemy zrobić, to przejrzeć to, co napisała i sprawdzić, czy mamy wspólne zrozumienie (co może doprowadzić do przepisania niektórych jej scenariuszy lub dodania nowych, których mogła przegapić).

Jak więc sprawić, by działała efektywnie w praktyce ?

Jeśli możesz wyprowadzić scenariusze z opisu, gotowe.

Anty-wzorzec, który często widzę w BDD, to ludzie odczuwający potrzebę omówienia i spisania każdego szczegółowego scenariusza.

Niektóre scenariusze są tak dobrze zrozumiane, że wystarczy wyciągnąć je z krótkiego opisu. Na przykład, jeśli powiem „Chciałbym w tym tygodniu skorzystać z funkcji logowania”, wiesz, jak to powinno wyglądać. Wiesz, że istnieją scenariusze dla właściwego hasła, niewłaściwego hasła, niewłaściwej nazwy użytkownika. Tak naprawdę nie musimy ich omawiać ani szczegółowo ich ujmować.

Podobnie mogę powiedzieć: „Oto formularz rejestracji użytkownika. Musimy mieć możliwość tworzenia nowych użytkowników, umożliwienia im edycji swoich danych i samodzielnego usuwania, z tym wyjątkiem, że usunięcie nie powinno faktycznie zostać usunięte, powinno po prostu oznaczyć je jako usunięte aby mogli odzyskać swoje konta, jeśli chcą ”.

I możesz zapytać: „Czy odzyskiwanie konta jest częścią tej funkcji?”

„Mogą to być dwie funkcje, jeśli chcesz”.

„Okej, więc mamy scenariusze tworzenia, czytania, aktualizacji, usuwania; to powinno być dość łatwe. Porozmawiajmy o odzyskiwaniu konta; to brzmi bardziej interesująco”.

Ogólnie rzecz biorąc, jeśli opis zachowania jest wystarczający, aby zespół deweloperów wyprowadził scenariusze, nie musisz ich omawiać. Możesz to zrobić, jeśli istnieją jakiekolwiek wątpliwości, ale możesz po prostu uchwycić, które scenariusze musisz zapamiętać, jeśli w ogóle je uchwycisz.

Jeśli nigdy wcześniej tego nie robiłeś lub nie masz pewności, omów scenariusze.

Skoncentruj się na obszarach, które są niezwykłe, szczególnie jeśli istnieją funkcje, których nigdy wcześniej nie robiłeś. To fantastyczne miejsca do prowadzenia rozmów i zapisywania wszelkich zaskakujących przykładów. Zwykle mam dwa pytania, które zadaję na podstawie szablonu BDD:

Biorąc pod uwagę kontekst
Kiedy zdarzenie ma miejsce,
wtedy powinien nastąpić wynik.

• Czy jest jakiś inny kontekst, który dla tego samego wydarzenia daje inny wynik?
• Czy jest jakiś inny ważny wynik?

Jeśli wszyscy przy stole wyglądają na znudzonych, funkcja, o której mówisz, jest prawdopodobnie dobrze zrozumiana. Często wystarczy powiedzieć: „Powinno działać jak X , ale zamiast tego z Y ”. Tak nazywa Dan North wzór Ginger Cake ; to jak przepis na ciasto czekoladowe, ale z imbirem zamiast czekolady.

Nawet jeśli interesariusz biznesowy jest w stanie sam opracować scenariusze, to naprawdę ważne jest, aby zespół programistów mógł z nim rozmawiać, podnosić i internalizować jego język. Język ten zostaje następnie wprowadzony do kodu, umożliwiając im lepsze rozmowy w przyszłości i pomagając początkującym w projekcie zrozumieć, co się dzieje. Jeśli deweloperzy nie znają języka, nie będą go używać .

Jeśli interesariusz biznesowy lub analityk naprawdę nie chce tracić czasu na rejestrowanie rzeczy podczas sesji, wolę, aby programiści spisali scenariusze we współpracy z testerami, a następnie poprosili go o przejrzenie. Jest to bardziej prawdopodobne, aby odkryć nieporozumienia niż na odwrót.

Czasami BDD nie działa.

Inną możliwością jest znalezienie scenariusza, którego interesariusz biznesowy nie jest pewien. „Och, nie myślałem o tym! Nie jestem pewien.” Zamiast próbować nakłaniać firmę do karania i karać ją z całą pewnością, warto w tym momencie porzucić BDD i spróbować czegoś prostego, aby uzyskać opinie i dać przedsiębiorstwu coś, co może powtórzyć. Łatwo się zmieniaj i pisz scenariusze, gdy lepiej zrozumiesz, co się dzieje.

Dobrze wykonane BDD może naprawdę pomóc w wykryciu miejsc niepewności. Ponieważ każdy projekt, który warto wykonać, ma jakiś aspekt, który jest nowy i nigdy wcześniej nie był wykonywany, jest gdzieś niepewność. Jeśli skupisz się na wykorzystaniu scenariuszy do celowego odkrycia niewiedzy , nauczysz się szybciej, a nauka zwykle zajmuje dużą część czasu poświęcanego na projekt.

Ponadto odkryłem, że im więcej zespołów programistów współpracuje w ten sposób, tym bardziej biznes jest przygotowany na zaufanie do nich z niepewnością i tym więcej innowacji zaczyna się pojawiać. Innowacyjne firmy ze swojej natury mają dużą niepewność w swoich projektach.

Jakiś czas temu napisałem post na blogu w Cynefin , który naprawdę pomaga mi zrozumieć, gdzie konwersacje będą najbardziej skuteczne. Jeśli ją przeczytasz i zrozumiesz cztery domeny, oto zasady, których używam:

• Proste i skomplikowane rzeczy (znane) są często dobrze zrozumiałe i nie trzeba szczegółowo omawiać scenariuszy.

• Bardzo złożone rzeczy (nieznane) w ogóle nie są rozumiane. Możesz to odkryć, rozmawiając o scenariuszach. Brak pewności oznacza, że ​​BDD nie będzie tutaj działać, więc powtarzaj coś, co łatwo zmienić, i zamiast tego uzyskaj szybką informację zwrotną. Każda praktyka, która zachowuje twoje opcje, jak testowanie AB, jest również świetna w tej przestrzeni.

• BDD działa doskonale w przestrzeni pomiędzy (poznawalnej) jako mechanizm przekazywania wiedzy i odkrywania dwóch pozostałych przestrzeni. To nie jest młotek i nie wszystko jest gwoździem. W rzeczywistości, jeśli możesz skoncentrować czas na rozmowach na czymkolwiek, to nie chodzi o przykłady, które możesz znaleźć; chodzi o znalezienie przykładów, których nie możesz .

Długość spotkania nie jest twoim problemem. Spotkania trwają długo. ALE wszyscy powinni wyjść z tego z poczuciem pewności siebie. To, że tego nie zrobili, jest twoim problemem.

Proponuję krótkie spotkanie w celu omówienia wymogu. Zaplanuj drugie spotkanie kilka dni później, aby wszyscy wiedzieli, że do tego czasu muszą się przygotować.

Następnie BA i tester powinni wymyślić swoje scenariusze, ponieważ oboje patrzą na oprogramowanie na bardzo różne sposoby. Poproś, aby zapisali je na kartach i umieścili je gdzieś na tablicy, przynajmniej na dzień przed drugim spotkaniem, pozwól wszystkim przejrzeć swój czas i przemyśleć to. Wyrzuć wszystkie duplikaty, odłóż wszystkie scenariusze, które nie zostały wzięte pod uwagę.

Nie wyrzucaj niczego, z czym się nie zgadzasz, ale oznacz to jako sporne. Jeśli bardzo krótka rozmowa z osobą, która to napisała, pomoże, zrób to, ale w większości ocal.

NASTĘPNIE zorganizuj spotkanie dotyczące planowania / projektowania. Miej solidny porządek na to spotkanie (zacznij od stosu kart, połóż sporne na górze) i nie pozwól, aby zboczyło z toru. Upewnij się, że opuściłeś to spotkanie, a wszystkie punkty sporne zostały rozwiązane.

Zawsze upewnij się, że wszyscy na spotkaniu są przygotowani na temat tego spotkania!

Nigdy nie używaj spotkania do „burzy mózgów” razem. Marnuje każdy czas.

Ogólny przepis na skuteczne spotkania:

• niech ktoś przygotuje przedmioty do dyskusji
• wymagają, aby wszyscy uczestnicy studiowali (nie tylko czytali) te elementy
• zbieraj komentarze wcześniej i wymagaj od wszystkich uczestników ich przestudiowania (a nie tylko przeczytania)
• zorganizować spotkanie w celu podjęcia decyzji

Informacje o skargach ...

Zacznijmy od tych:

Jeden z programistów uznał, że zmarnował czas, ponieważ analityk biznesowy dawał mu scenariusze i przeglądał je razem z nią.

To właśnie robił w warsztacie. Wydaje mi się to więc nastrojową i złą wymówką. Podejrzewam, że ten programista po prostu nie lubi żadnej (lub obu) kontroli warsztatu i jego ograniczeń w planowaniu.

Analityk biznesowy nie czuł się pewnie dzięki naszemu scenariuszowi (miał wrażenie, że moglibyśmy przeoczyć inne ważne rzeczy)

Czym to się różni od tego, kiedy robi to po swojej stronie i czy dokonała przeglądu przez programistę, poza tym, że oglądało to więcej osób? Podejrzewam, że jest to wynik chaosu na warsztatach. Zyskasz pewność, że masz wystarczającą liczbę testów, wdrażając je i integrując. Nigdy nie możesz być pewien, że znalazłeś wszystkie błędy, a jeśli chodzi o zasięg, najlepszym sposobem byłoby zobrazowanie ich w swoich historiach użytkowników.

ale co ważniejsze, uważała, że ​​te warsztaty to także strata czasu, ponieważ mogła samodzielnie i w krótszym czasie wymyślić wszystkie te scenariusze.

Tak, całkowicie samodzielnie, w otoczonym murem ogrodzie i bez dzielenia się wiedzą. Podczas gdy te przyszłe warsztaty mogą być bardziej produktywne, ponieważ wszyscy uczestnicy mają niewielką wiedzę na temat tego, jak podejść do tych rzeczy.

Może tym razem spotkanie było powolne, to nie znaczy, że zawsze tak będzie. Jako osobista osoba z zewnątrz, po przeszkoleniu, aby to zrobić, mam większą pewność, że zasięg był lepszy na warsztatach z 3 uczestnikami o różnych poglądach niż z jednym dyktatorem.

Ponadto, jeśli już teraz istniała potrzeba, aby programista z nią zapoznał się z tymi scenariuszami, jestem prawie pewien, że tam iz powrotem jest znacznie szybsze i wydajniejsze w warsztacie niż używanie „Robię swoje rzeczy sam i daję to ty, przejrzysz to sam i wrócisz do mnie i zróbmy to jeszcze raz ”.

Propozycje

• Bądź pozytywny i podkreśl, że jeśli proces jest prawidłowy, będziesz w tym lepszy.

• Staraj się usprawnić warsztat i utrzymywać go na właściwym poziomie.

• Być może dajmy trochę miejsca na analizę „samotnego wilka”, rozpoczynając warsztaty ze wszystkimi, którzy sami projektują kilka scenariuszy (jeszcze lepiej przed warsztatami), a następnie segreguj i łącz je.

A jeśli nie uważasz, że taka burza mózgów jest potrzebna, dobrze: poproś BA o samodzielną pracę, ale przynajmniej dokonaj przeglądu jako warsztatu. Im więcej, tym lepiej, gałki oczne zacytować Erica S. Raymonda 's Prawo Linusa :

Given enough eyeballs, all bugs are shallow.

Masz już dość dobre odpowiedzi, więc skupię się na jednym małym aspekcie, który do tej pory został przeoczony. Rola każdego z Trzech Amigos powinna być w stanie dostarczyć na sesję. Każdy z nich oferuje wartość na różne sposoby, każdy rozumie inny zestaw ograniczeń.

Ogólnie rzecz biorąc, BA powinien być w stanie wprowadzić główną szczęśliwą ścieżkę do sesji, powinien także być w stanie przedstawić główne scenariusze awarii z perspektywy biznesowej. Specjalista w dziedzinie testów powinien być w stanie zidentyfikować przypadki skrajne i dodatkowy scenariusz niezbędny do udowodnienia, że ​​system działa we wszystkich okolicznościach. Zadaniem programisty nie jest tak naprawdę dodawanie scenariuszy, choć często robią to z powodu awarii technicznych, ich praca również zapewnia pełne zrozumienie wymagań, więc przekazują implikacje i wdrażają wymaganie przy minimalnej dodatkowej komunikacji.