Zasady architektoniczne jako "niefunkcjonalne" historie użytkowników

Question

Mam zamiar rozpocząć projekt pilotażowy w naszej firmie, aby wprowadzić zwinne praktyki, w tym wykorzystanie historii użytkowników. Po przeczytaniu dwóch książek Mike'a Cohna, Agile Estimating and Planning w szczególności i User Stories Applied, mam teraz jaśniejszy pomysł, jak postępować. Mam zaufanie do udoskonalania naszych technik wraz z praktyką.

Jest jednak jedna rzecz, która mnie nie przekonuje. In this blog post Mike Cohn definiuje określony typ historii użytkownika, który nazwał ograniczeniami, które można wykorzystać do zdefiniowania tzw. Wymagań niefunkcjonalnych. Osobiście nie podoba mi się słowo ograniczenie, a nawet użycie klasycznego szablonu "Jako ... chcę ..., więc ...".

Raczej będę się starał, aby klient pisać, zawsze na kartach, być może z powyższego wzoru, te, które Nick Różański i Eoin Woods nazywa, w ich fantastycznej książki Software Systems Architecture, zasady architektoniczne:

"Zasada architektoniczna to deklaracja wiary, podejścia lub intencji, która kieruje definicją architektury."

(one również dzielić te zasady w zasad biznesowych i zasad technologicznych, zróżnicowanie myślę, że nie powinien dbać o.)

Co chciałbym zrobić z tymi zasad kart jest umieszczanie ich obok naszej karty kart zaległych, aby zawsze były obecne podczas definiowania opowieści użytkowników i czynności planowania. Zachęcam również klientów i programistów do ich pobierania i umieszczania obok planszy iteracyjnej za każdym razem, gdy uważają, że karta może być przydatna jako przypomnienie dla zespołu.

Czy kiedykolwiek próbowałeś zastosować podobne podejście? Czy zniechęcasz go z jakiegokolwiek powodu? Czy masz jakieś sugestie w tej sprawie?

Answer 1

Czy kiedykolwiek próbowałeś zastosować podobne podejście? Nie próbowałem czegoś dokładnie takiego, ale kiedy byłem Scrumowym Mistrzem mojego zespołu, mieliśmy projekt całościowy i wizję architektoniczną (do której wszystkie zespoły były częścią), o czym przypomnieliśmy, podczas różnych inspekcji i adaptacji Sprintu, a także Projektu Scrumowego, podobnie jak podczas Retrospekcji, Spotkań Planowania Sprintu, a nawet spotkań Daily Scrum. Kilka sposobów, które nam przypomnieliśmy, to dodawanie gotowych kryteriów do zadań, które zawierały jedną zasadę do przestrzegania wytycznych architektonicznych, a także może być dodane jako mała notatka w Backlogach. W mojej sugestii poniżej wspomniałem, jak to było postrzegane z naprawdę wysokiego poziomu.

Czy odradzasz go z jakiegokolwiek powodu? Wcale nie. Mówię, że twoja sugestia jest dobra i powinieneś wypróbować ją na spotkaniu planistycznym. Zgodnie z sugestią Kena Schwabera i Jeffa Sutherlanda w Przewodniku po Scrumach, powinieneś sprawdzić i dostosować się podczas 3 punktów w Sprintu - "W Scrum są trzy punkty do kontroli i przystosowania." Codzienne spotkanie Scrumowe służy do sprawdzania postępu w Cel Sprintu i dostosowania, które optymalizują wartość następnego dnia roboczego Ponadto, spotkania Przeglądu Sprintu i Planowania są wykorzystywane do kontrolowania postępu w kierunku Celu wydania i dokonywania adaptacji, które optymalizują wartość następnego Sprintu. Retrospektywa Sprintu służy do przeglądu przeszłego Sprintu i określenia, jakie dostosowania spowodują, że następny Sprint będzie bardziej produktywny, satysfakcjonujący i satysfakcjonujący. "

Masz jakieś sugestie w tej sprawie? Czy mogę bezpiecznie założyć, że ten "zwinny" projekt w twojej firmie dopiero się zaczyna i nie masz jeszcze solidnego projektu wizji projektu? Jeśli tak, proponuję zorganizowanie dwutygodniowego warsztatu planowania uwalniania projektu. Celem tego warsztatu byłoby pozyskanie wszystkich zainteresowanych stron, organizacji producentów, menedżerów i kierowników projektów w jednym miejscu i opracowanie historii i wizji superużytkownika, a także pozostałych zaległości z podziałem na superużytkowników. Historia Superużytkownika wizja wysokiego poziomu celu projektu. Jeśli już to zrobiłeś, zignoruj ​​tę sugestię, ale moim punktem widzenia jest to, że wizja wysokiego poziomu lub historia superużytkownika mogłaby/powinna mieć część, która wspomina przestrzeganie zasady architektonicznej określonej w twojej firmie.

Zalety tego? Zainteresowana osoba bierze udział w architektonicznym i technicznym aspekcie produktu od Historii Superużytkownika, co pomaga w dobrym zrozumieniu wizji między biznesem a stroną techniczną, a nie można żyć bez drugiego.

Mogłem celowo próbować rozszerzyć odpowiedź poza zakres pytań, aby uzyskać informacje zwrotne na temat moich pomysłów.

Dzięki, Sid.

Answer 2

To był temat rozmowy, którą zobaczyłem w styczniu tego roku w Fabryce Architektów. Śledziłem to. Była to "Business Driven Architecture: przykład z bieżącego uruchomienia" autorstwa Lee Ingrama. Nie mogę znaleźć slajdów, ale mówił o idei nadrzędnych zasad, które określają, w jaki sposób należy spełnić wymagania.

Miał rzeczy takie jak multi-tenancy i white-labeling. Dzięki usłudze sieciowej dla wielu dzierżawców musisz od samego początku planować segregację/izolację użytkowników. Podobnie, jeśli chcesz mieć możliwość oznaczania białymi etykietami swojej usługi, wiele innych rzeczy musi być konfigurowalnych (styl, etykiety itp.). Oba mają wpływ na niemal każdą historię.

Answer 3

Bardzo polecam Jeff Patton's presentation on user story mapping.

Wyjaśnia nie tylko dokładny opis tego, jakie historie służą celom (lub jak im się podoba), jak budować relacje lub zależności między opowieściami i jak sobie z nimi radzić.

Answer 4

Robię to w sposób, który opisałeś. Mam zdefiniowane ograniczenia na kartach (inny kolor). Ograniczenia nie są zapisywane w formacie historii użytkownika, ale jako proste zdanie, takie jak:

• System będzie obsługiwał maksymalne wykorzystanie 30 użytkowników.
• Przywóz musi być uruchamiany codziennie.
• Wszystkie filtry i wyniki wyszukiwania muszą znajdować się na tej samej stronie.

Jeśli klient ma pewne specjalne wymagania, które nie są bezpośrednio związane z pojedynczym użytkownikiem, ale ma szerszy efekt, to piszę je jako ograniczenia. Te ograniczenia nie są szacowane i nie są częścią zaległości produktu. Używamy ich, aby przypomnieć niektóre wymagania dotyczące implementacji dla prawdziwych historii użytkowników.

Answer 5

Ta ogólna idea "zasad" (lub ograniczeń) wydaje się być dobra. Widziałem, co się dzieje, gdy rzeczy, które naprawdę powinny być w tej klasie - np. "System musi osiągnąć określony, określony ilościowo poziom wydajności" - po prostu zostaje wrzucony do zaległości i zagubiony pośród wszystkich innych "fabularnych" historii: nikt się nie martwi wydajność (ponieważ "wszystko jest w porządku ... jest gdzieś taka historia"), a potem, gdy ktoś w końcu to odbierze (co dziwne, te rzeczy zawsze trwają do końca, pomimo wysokiej wartości dla klienta), niemożliwe zadanie przez kilka dni, od których oczekuje się historii, i prawdopodobnie tylko możliwe do zrealizowania przy poważnej rearchitekcji systemu, który powinien był zostać zrobiony dużo wcześniej i teraz ma ogromny koszt naprawy.