Czy dobrym pomysłem jest pisanie specyfikacji wymagań według historii?

Obecnie używamy zwinnych metod w moim obecnym projekcie i mamy mnóstwo takich historii:

• Jako asystent chcę zwrócić klientowi zwrot pieniędzy, aby mógł otrzymać pieniądze na żądanie

• Jako klient chcę zapłacić za zakup, aby otrzymać przedmiot.

Jak dotychczas to zrobiliśmy, wybieramy najważniejsze historie podczas każdego sprintu i opracowujemy je w szeregu specyfikacji wymagań formalnych (grupujemy niektóre historie, które są podobne razem w tej samej specyfikacji). W zależności od historii może to być tylko przycisk na ekranie lub cały przepływ pracy.

Problem polega na tym, że ponieważ jest tak wiele historii, nie jest od razu jasne, dla jakiejkolwiek części systemu, które historie się z tym wiążą.

Działa w czasach programistów, każdy sprint deweloperów otrzymuje specyfikację określającą, co należy zrobić i jakie zmiany należy wprowadzić. Ale jeśli chodzi o utrzymanie tej listy historii i testowanie, zaczyna się naprawdę ciężko śledzić błędy i ogólnie po prostu zachować specyfikacje, ponieważ jedna funkcja na ekranie mogła być udokumentowana w wielu różnych miejscach, ponieważ jest podzielone według historii.

Czy pisanie specyfikacji opartych na opowiadaniach to dobry pomysł? Czy napisaliśmy historie w niewłaściwy sposób?

Może to być kontrowersyjne, ale proszę bardzo!

Pracowaliśmy nad systemami czasu rzeczywistego, w których jeden z moich poprzednich szefów zasugerował, żebyśmy zrobili AGILE! Naprawdę łatwo było wygrać zarządzanie; łatwiej było jednak powiedzieć niż zrobić.

Koncepcja opowieści jest dobra - ale aby być bardzo otwartym, jest dość niejasna. Czym naprawdę jest historia? Prawdziwy problem polega na tym, że korzystanie z opowieści alone(i w dużej mierze tych samych przypadków użycia) ma kilka problemów - w następujący sposób:

1. Wymagania nie mogą znajdować się poza kontekstem (chyba że wykonujesz tak wiele powtórzeń). Istnieją założenia, wiedza ogólna i inne wymagania, które są również powiązane z danym wymaganiem; mają sens tylko w kontekście i tylko w określonym porządku. Wdrożenie najważniejszego z nich ma sens z biznesowego punktu widzenia, ale jeśli je przynajmniej złożysz - zachowaj pełne odniesienie od samego początku, kiedy je zbierzesz. Samo wymaganie jest złożone i nie jest tak naprawdę ograniczone do przypadku użycia / historii. Rzeczywiście historie są możliwe do działania, ale są też wymagania, które mogą nie być wykonalne, takie jak wydajność, ograniczenia, które należy spełnić, reguły biznesowe itp.

2. Wymagania muszą być odpowiednie pod względem wielkości i ilościowo, w przeciwnym razie nigdy nie będziesz potrzebować więcej niż 1 dużej historii! Co tworzy dokładnie 1 historię?

   • czy jest to jeden pełny szczegółowy scenariusz? (np. jedna historia, gdy bankomat odrzuca transakcję)
   • czy jest to jeden zestaw działań, które wykonuje użytkownik? (np. pełna historia wypłaty)
   • czy jest to jeden ekran w interfejsie użytkownika? (np. ekran wypłaty jako pełna historia).
   • Jak naprawdę obliczyć bardzo ostre reguły biznesowe za pomocą historii? Szczerze mówiąc, może to być dowolny z powyższych. Chodzi o to, jak bardzo ograniczony i szczegółowy jest twój osobisty styl. Jeśli to działa - jest w porządku;

3. Znajomość domeny jest naprawdę wymagana! Prosty przykład architekta, który zna różne właściwości szkła, stali i drewna. ta wiedza nie jest częścią dokumentu wymagań dla budynku, powiedzmy! Tak samo, jeśli piszesz oprogramowanie bankowe - istnieje cała masa koncepcji dotyczących bankowości. Mówiąc o nich, ponieważsamo wymaganie czyni go nietraktalnym, ponieważ nie mówi ci, co powinno robić oprogramowanie, a nie jak działa świat . Czy historia zawiera takie zawiłości domeny? czy to wyklucza?

4. Modelowanie świata jest warunkiem, którego nie do końca wspiera.
   Istnieje wiele literatury na temat modelowania, która koncentruje się na zrozumieniu, jak działa świat, jest wiedzą podstawową. Modelowanie stanowi solidny fundament, na którym wymagania zyskują wyraźne znaczenie; jednak coś takiego powinno być z góry. Niestety, większość zwinnych praktyk odmawia wartości w modelowaniu z góry w interesie szybszych i szczuplejszych dostaw; ale nadal uważam, że jest to poważna przeszkoda dla programu, gdy wszystko musi się skalować. Wiele projektów kończy się niepowodzeniem nie dlatego, że modelowanie jest nieistotne - ale doświadczeni inżynierowie znają je w swoich głowach i nie potrzebują wyraźnych wskazówek.

Więc przychodzę do twojego pytania:

Czy pisanie specyfikacji opartych na opowiadaniach to dobry pomysł? Czy napisaliśmy historie w niewłaściwy sposób?

Myślę, że historie użytkowników mają wartość jako wyraźny werdykt wydany przez klienta. Ale jeśli są źle zorganizowane i niewystarczająco szczegółowe (lub niejasne), istnieje problem. Chyba że masz większą strukturę, aby zgromadzić szersze zrozumienie (znajomość domeny) i zakres (całkowita specyfikacja). Historie użytkowników tylko dla segmentów lub elementów w większym takim systemie.

PS: Mam dokładną opinię na temat przypadków użycia (jak pokazano na owalnych schematach), które, jeśli nie umieścisz ich w odpowiednim kontekście i przy odpowiedniej szczegółowości, nie wykonają żadnej dobrej pracy. (Nazywam je bezużytecznymi skrzynkami ). Jedynym wiarygodnym źródłem, które sprawia, że ​​pisanie przypadków użycia jest naprawdę skalowalne i znaczące, to Pisanie skutecznych przypadków użycia przez Cockburn

> Writing specs by stories? a good idea?

Tak, jeśli potrafisz zarządzać współzależnościami i priorytetami swoich historii.

Oto artykuł o mapach historii, które mogą pomóc w uporządkowaniu wielu historii użytkowników i zarządzaniu nimi.

W chwili pisania tej odpowiedzi zdałem sobie sprawę, że nie chodzi o testowanie, ale o dokumentację. Najpierw powinieneś przeczytać manifest zwinny :

[Cenimy] działające oprogramowanie w porównaniu z obszerną dokumentacją

Powinieneś więc uczynić swoje specyfikacje wykonywalnymi, tj. Napisać je jako w pełni zautomatyzowany zestaw testów.

Czy pisanie specyfikacji opartych na opowiadaniach to dobry pomysł?

Tak jest, imho. Nazywa się to „programowaniem opartym na zachowaniu” lub „specyfikacją przez przykład”. W rubinie jest świetny ogórek narzędziowy , który bardzo pomaga.

Problem polega na tym, że ponieważ jest tak wiele historii, nie jest od razu jasne, dla jakiejkolwiek części systemu, które historie się z tym wiążą.

Dlaczego chcesz, żeby to było jasne? Mam na myśli, czy naprawdę potrzebujesz macierzy identyfikowalności „test / kod”? Zaletą pisania testów jako specyfikacji jest to, że nie potrzebujesz osobnej identyfikowalności „wymagań / testów”, ponieważ testy stają się wymaganiami. Do celów testów integracyjnych powinieneś traktować swoje oprogramowanie jako całość, a nie jako oddzielne części.

Może być potrzebne narzędzie pokrycia, aby sprawdzić, czy istnieją „martwe” moduły, części systemu nieobjęte testami specyfikacji. Ale tak naprawdę nie powinno cię obchodzić, jakiej specyfikacji odpowiada ten konkretny kod. Powinno być odwrotnie: z konkretnej specyfikacji powinieneś wiedzieć, która część systemu odpowiada jej. Nie powinieneś martwić się o pewne powielanie specyfikacji. A jeśli zastosujesz zasadę DRY do swojego kodu, dziesiątki specyfikacji wykonają ten sam kod.

Działa w czasach programistów, każdy sprint deweloperów otrzymuje specyfikację określającą, co należy zrobić i jakie zmiany należy wprowadzić. Ale jeśli chodzi o utrzymanie tej listy historii i testowanie, zaczyna się naprawdę ciężko śledzić błędy i ogólnie po prostu zachować specyfikacje, ponieważ jedna funkcja na ekranie mogła być udokumentowana w wielu różnych miejscach, ponieważ jest podzielone według historii.

Nierzadko zdarza się, że setki testów integracyjnych są niszczone przez jedną małą zmianę w kluczowym module. Właśnie tam wkracza testowanie jednostkowe.

Powinieneś tak ustrukturyzować swoje testy, abyś mógł stwierdzić, czy dany test spełnia wysokie wymagania, czy tylko jego subtelne szczegóły. Jeśli to drugie, należy oddzielić ten test od pakietu testów integracyjnych. Celem testów jednostkowych jest zlokalizowanie błędów. Tak więc, jeśli wprowadzisz błąd, nastąpi jeden i tylko jeden błąd testu.

Czy napisaliśmy historie w niewłaściwy sposób?

Myślę, że wystarczy uporządkować swoje historie w epopeje według użytkownika, np. „Klient”, „Asystent” lub według funkcji / ekranów / przepływów pracy („Zakup”, „Zwrot”).

I znowu testy specyfikacji nie zastępują testów jednostkowych. Czytaj więcej

Wspomniałeś o problemie i sposobie jego rozwiązania, ale zapomniałeś wspomnieć o kilku przykładach specyfikacji i grupowania oraz o tym, jak jest to związane ze sposobem, w jaki rozwijasz swój produkt.

Pisanie specyfikacji według opowiadań? dobry pomysł?

Agile tego nie zabrania. W zwinnym możesz robić wszystko, czego potrzebujesz, aby zapewnić maksymalną wartość biznesową w zrównoważonym tempie. Więc jeśli pisanie specyfikacji jest czymś, czego potrzebujesz, aby zapewnić większą wartość biznesową, to jest absolutnie w porządku.

Twój przykład pokazuje dwie historie użytkowników. Być może są one w jakiś sposób powiązane z logiką biznesową, ale jest to bardzo częsty scenariusz.

Jeśli potrzebujesz funkcji bactrack do historii użytkowników, możesz ponownie użyć wszystkiego, co najbardziej ci odpowiada, w tym dokumentacji, niektórych diagramów lub „specyfikacji”, ale musisz być przygotowany, że utrzymanie tych artefaktów będzie cię kosztować, gdy złożoność opracowanej aplikacji będzie wzrastać. Zatem jedynym pytaniem, na które musisz odpowiedzieć w tym przypadku jest: jeśli nie użyję moich specyfikacji, czy będzie nas to kosztowało więcej? Jeśli odpowiedź brzmi tak, wybrałeś lepszą opcję.

Zwinność sprawdza się najlepiej w przypadku małych i średnich projektów z małym zespołem, w których cała architektura odbywa się jako wiedza ukryta dzielona w zespole. Podczas planowania iteracji przejdziesz przez wybrane historie, omówisz wpływ na bieżącą implementację i napiszesz niektóre zadania potrzebne do ukończenia historii. Prawdziwą dokumentacją w takim przypadku będzie zestaw testów z automatyczną akceptacją i testami integracji / testów jednostkowych. Gdy twój SW lub zespół powiększy się, milcząca wiedza będzie musiała częściowo przejść do jakiejś dokumentacji.

To tutaj abstrakcja odgrywa ważną rolę. Musisz spojrzeć na historie z poszanowaniem odpowiedniej perspektywy. Zbierz rzeczowniki i czasowniki w wypowiedziach i potwierdź je. Nie możesz oprzeć swoich modeli na osobistych założeniach. Zwróć również uwagę na szczegóły.

Pisanie specyfikacji opartych na historiach użytkowników nie może być dokładne. Musisz wykopać dodatkowe szczegóły, a czasem zignorować szczegóły, które nie są istotne. Specyfikacje należy zapisać, gdy model jest kompletny i dokładny po potwierdzeniu przez analityka.