Część trudności w pisaniu dokumentu specyfikacji przez klienta polega na tym, że klient często nie wie, jak tłumaczyć rzeczy, których chce klient, na język, który faktycznie opisuje to, czego potrzebuje klient. Chociaż klient może powiedzieć, że chce, aby pewne zachowanie istniało w systemie, na ogół nie jest tak bardzo zainteresowany drobiazgami, dopóki nie zobaczy, nie użyje i nie doświadczy oprogramowania działającego w sposób, który według niego nie do końca odpowiada jego wymagania.
Kiedy klienci opisują proces biznesowy, często pomijają wiele istotnych informacji. Często te informacje dotyczą rzeczy o procesie, który jest powszechnie rozumiany w konkretnej domenie klienta, a zatem jest brany za pewnik i często nie jest przekazywany programiście. Innym razem klient tak naprawdę nie wie, jak radzić sobie ze wszystkimi warunkami brzegowymi w systemie, i zwraca się do programisty o wskazówki. Czasami jest to prosty przypadek użyteczności, gdy klient myśli, że chce, aby coś działało w jeden sposób, ale później zmienia zdanie, gdy staje się jasne, że wszystko powinno działać inaczej.
Ok, wystarczy „relacji z klientami 101 dla programistów”. Pytanie brzmi, czy nadal warto korzystać z DSL czytelnego dla biznesu, aby zdefiniować sposób definiowania specyfikacji. Uważam, że z wytycznymi odpowiedź jest wstępna „tak” i mówię niepewnie, ponieważ następne pytanie, które przychodzi mi na myśl, brzmi: dlaczego miałbyś mieć klienta wytwarzającego DSL, skoro programista może łatwiej zdefiniować taki, który będzie zapewnić klientowi prosty, ale bogaty język, aby zdefiniować, jak system musi działać?
Kiedy podasz klientowi język do opisania, jak chciałby, aby system działał, skończysz na stwierdzeniach, które mówią coś w stylu:
"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".
Ten rodzaj oświadczenia kończy opisanie wymagania w bardzo jasny sposób, podając ogólny kształt, który klient zasadniczo chce, aby system przyjął, lub inny sposób patrzenia na to, że klient opisuje, czym jest system. Jeśli chcesz, aby klient pomyślał o czymś nieco dalej, możesz poprosić go o opisanie zasad, których musi przestrzegać ta funkcja, używając szeregu instrukcji podobnych do:
"Given 'some system state', When 'some action occurs', Then expect 'some result'
Znowu bardzo jasne opisy, tym razem o tym, jaksystem powinien się zachowywać. Chodzi o to, że nie zastąpi to konieczności wypełniania pustych pól przez programistę i wypowiadania się o dalszych szczegółach, o których klient może wiedzieć tylko peryferyjnie. Podczas gdy klient może być w stanie zostać „przeszkolony” przez programistę w zakresie opisywania funkcji i zachowań w przyjemnym, przyjaznym dla programisty formacie, klient tak naprawdę nie będzie miał umiejętności ani wiedzy do generowania znaczących przypadków testowych, ani do zapewnienia implementacji kod. Wydaje mi się, że o to chodzi w artykule Martina Fowlera, o którym wspomniał PO. Tak, sam program nie jest zapisywalny przez klienta, ale opis oprogramowania z pewnością może - i IMHO powinien - być napisany przez klienta. Za to, co jest warte, nie przeczytałem artykułu Fowlera, mówiącego, że klient nie powinien
Wydaje mi się, że my programiści czasami zapominamy, że nasi klienci są na ogół bardzo inteligentni, jeśli chodzi o rozumienie swoich firm i procesów biznesowych, z pewnością znacznie lepiej niż my. Kiedy nie mają programisty, który powiedziałby im, jak zbudować system oprogramowania, klienci zazwyczaj uciekają się do innych - być może mniej wydajnych - środków rozwiązywania konkretnych problemów zarządzania przedsiębiorstwem. Rozumiem przez to proste bazy danych (think Access) lub arkusze kalkulacyjne, a nawet ręcznie pisane księgi rachunkowe oraz dobrze zdefiniowane reguły i procedury zarządzania tymi procesami. To, czego brakuje wielu klientom, nie jest sposobem na określenie, jak system musi działać, ale raczej na tym, jak powinien zostać zbudowany , a co ważniejsze, jak skutecznie opisać reguły zachowania systemu osobom, którenie mają umiejętności, aby faktycznie zbudować system.
Jeśli rzeczywiście istnieje konsensus co do braku możliwości zapisu, to czy widziałbyś problem z narzędziem, które zamiast zaczynać od scenariuszy i ich instrumentowania, generowałoby scenariusze czytelne dla biznesu z rzeczywistych testów?
Myślę, że to źle patrzy na ten problem. Widziałbym duży problem z narzędziem generującym dokumentację z testów, gdyby dokumentacja ta miała w jakikolwiek sposób reprezentować specyfikację. Aby przetestować scenariusz, musisz go zrozumieć, dlatego scenariusz musi już istnieć, aby oboje mogli zdefiniować test. Jeśli opisujesz scenariusz w składni BDD, oznacza to, że już go określiłeś, dzięki czemu możesz instrumentować scenariusze tylko po fakcie. Jeśli z drugiej strony masz narzędzie, które pozwoli klientowi opisać system w ładnym, przyjaznym programistycznie DSL, i jeśli to narzędzie może zostać użyte do wygenerowania szablonów kodu, które będą użyte jako pakiet testowy, to „ Powiedzmy, że takie narzędzie miałoby wielką wartość. Nie zobaczyłby, że klient wyjęłby programistów z równania i pomógłby zmniejszyć wysiłek wymagany do spełnienia życzeń klienta i wygenerowania wymagań zakodowanych w teście w sposób BDD, a być może ułatwiłby zrozumienie życzeń klienta. Nie zastąpiłoby to jednak posiadania doświadczonego programisty, który pomógłby klientowi oddzielić potrzeby klienta od jego potrzeb.