Zastosowanie podejścia Lean Agile w praktyce

Przykład portalu studenta

Kolegium społeczne chce stworzyć portal dla studentów, który będzie oferował usługi online. Zaproszono przedstawiciela studentów, pracowników z wydziału oraz członków zespołu administratorów portalu, aby utworzyć zespół uczestniczący w projekcie tworzenia portalu studenta. Oto notatki z pierwszej spotkania.

Spotkanie z interesariuszami

Agenda

• Zaproponuj funkcje dla portalu studenta
• Omów realność zaproponowanej listy funkcji
• Zidentyfikuj priorytety funkcji do zaimplementowania jako podstawowe, następna partia, pożądane …

Steve (Zespół programistów): Witamy… Chcemy, aby spotkanie było bardziej produktywne i skuteczne. Gdy proponujecie funkcje, które chcielibyście mieć, możemy użyć następującego formatu jako standardowego sposobu wyrażania: kto (kim jesteś), co (chcesz), i dlaczego (chcesz to zrobić)… Te funkcje zostaną zapisane jako historie użytkownika, które będą używane jako narzędzie komunikacji w całym projekcie.

Następnie przeprowadziliśmy mózgowy szturm, aby stworzyć listę historii użytkownika od różnych interesariuszy:

Przedstawiciel studentów: zapisz się na kursy, zapłać za opłatę za studia, zobacz harmonogram, edytuj harmonogram, zobacz kartę ocen, rezygnuj z kursów …

Przedstawiciel akademicki: dodaj informacje o kursie, edytuj informacje o kursie, usuń informacje o kursie …

Administrator portalu: zrób kopię zapasową informacji o kursie, edytuj status konta studenta

Teraz mamy kilka kart, które można uporządkować w rzędach i kolumnach

Priorytetyzacja zaproponowanych funkcji

Reprezentant programisty: Mamy listę priorytetowych historii użytkownika do zaimplementowania w kolejnej iteracji. Aby to zrobić, musimy szczegółowo przeanalizować każdą historię użytkownika, aby uzyskać więcej informacji. Przejdźmy przez pierwszą podstawową funkcję „zapisz się na kurs”

Otrzymaliśmy dodatkowe informacje od użytkowników końcowych na spotkaniu:

• Akademik: student musi być studentem stacjonarnym zapisanym na studiach
• Administrator: student musi podać poprawne dane logowania do konta
• Akademik: kurs nie jest pełen
• Akademik: wymagania wstępne dla kursu muszą zostać spełnione
• Administrator: kurs wybrany do dodania do harmonogramu nie może kolidować z terminem innego kursu
• Programista: jakie inne funkcje chcesz, by były grupowane razem z tą funkcją na liście w systemie docelowym?
• Student: rezygnuj z kursów, zobacz harmonogram, edytuj harmonogram.

Trzy C historii użytkownika

Dobre historie użytkownika to znacznie więcej niż tylko stwierdzenia. Standardowa historia użytkownika składa się z trzech części, powszechnie nazywanych trzema C. Pierwsze „C” każdej historii użytkownika powinno być zgodne z zasadniczym formatem: Jako [rola], chcę [zrobić coś], ponieważ [korzyści], co stanowi minimalną zawartość historii użytkownika do umieszczenia na karcie. Rozmowy to treść drugiego „C” historii użytkownika, która reprezentuje dyskusję między użytkownikami końcowymi, właścicielem projektu i zespołem programistów. W tych rozmowach zapisywane są rozmowy ustne lub inne przydatne informacje, takie jak e-maile, szkice, lub inne materiały związane z projektem. Ostatnie „C” historii użytkownika to potwierdzenie, które stanowi kryteria akceptacji używane do potwierdzenia, że historia użytkownika została poprawnie zaimplementowana i pomyślnie dostarczona.

Pozwól mi nieco rozwinąć, jak rozwijać część potwierdzenia historii użytkownika. Tutaj używamy najbardziej znanej szablonu zwanego Gherkin, który wykorzystuje wzór Given-When-Then, aby kierować pisaniem testów akceptacyjnych dla historii użytkownika:

• (Given.. i) pewne kontekst
• (When.. i) wykonywana jest pewna akcja
• (Then.. i) wykonaj pewne akcje

Narzędzia takie jak Cucumber i frameworki testowe Jbehave zachęcają do używania szablonu Given/Then/Then do przeprowadzania testów automatycznych, choć może być również używany wyłącznie jako heurystyka, niezależnie od tego, czy będzie używane narzędzie.

Zbierzmy wszystkie informacje dotyczące historii użytkownika „zarejestruj kurs” i umieśćmy je w formacie 3Cs:

Teraz połóżmy informacje do UeXceler, który zawiera konwersję i potwierdzenie, które wcześniej opracowaliśmy.

Dzielenie Epyku na Historie Użytkownika

Jeśli dokładniej przeanalizujemy historię użytkownika „zarejestruj kurs”, możemy odkryć, że jest zbyt duża, by mogła zostać umieszczona w sprintie. Możemy ją traktować jako Epyk (większą historię użytkownika), którą można podzielić na grupę powiązanych mniejszych historii użytkownika. Możemy podzielić epik na zadania – nazywam to podział poziomy, albo alternatywnie możemy podzielić epik na scenariusze i nazywać to podział pionowy.

Podział poziomy

Tradycyjny sposób budowania dużego funkcjonalności polegał na rozkładaniu jej na zadania, które należało wykonać na poziomie warstw architektonicznych. Na przykład model widok kontrola (MVC) lub architektura klient-serwer, aby zapewnić rozdzielenie odpowiedzialności dla architektury systemu, a następnie dopasować ją do architektury n-warstwowej, takiej jak interfejs graficzny, logika sterowania, model obiektowy, mapowanie obiektowo-relacyjne, warstwy bazy danych itd. Istnieje wiele elementów architektury n-warstwowej, a ja tutaj wymienię tylko kilka:

• Pozwala nam rozwijać wysokiej jakości ekspertyzę w jednej z warstw architektonicznych
• Inne aplikacje będą mogły wykorzystywać funkcjonalność udostępnianą przez Twoje warstwy.
• Będziesz mógł rozłożyć swoje warstwy na wiele fizycznych poziomów. Może to mieć bardzo duży wpływ na Twoją aplikację poprzez poprawę wydajności (czasem), skalowalności i odporności na błędy.
• Utrzymanie Twojej aplikacji jest łatwiejsze dzięki niskiemu sprzężeniu między warstwami.
• Dodawanie nowych funkcjonalności do Twojej aplikacji jest łatwiejsze.
• Warstwy sprawiają, że Twoja aplikacja jest łatwiejsza do testowania.

Istnieje duża liczba pomyślnych implementacji opartych na architekturze n-warstwowej, takich jak Ruby on Rails i architektura oparta na usługach internetowych.

Historie użytkownika i podział poziomy

Mając lub korzystając z korzyści architektury n-warstwowej dla naszego systemu, ma ona pewne wady, gdy używamy jej w podejściu do historii użytkownika. Często prowadziła do bardzo wolnego cyklu zwrotu informacji, w zależności od rozmiaru funkcjonalności, ponieważ czekamy, aż każdy z osobna skończy swoją część, by ją zintegrować i upewnić się, że działa. Termin „poziome cięcie” odnosi się do wykorzystania tego podejścia warstwowego jako głównej metody rozkładania dużych funkcjonalności.

Podział pionowy

Aby przyspieszyć cykl zwrotu informacji, możemy wziąć epik i podzielić go na kilka scenariuszy użytkownika, które przebijają się przez każdą z warstw architektonicznych. Możemy rozłożyć prawie każdą funkcjonalność na kawałki, tak aby zbudowanie, zintegrowanie i przetestowanie wszystkich elementów zajęło maksymalnie kilka dni. Każdy kawałek składa się z wszelkich prac, które należy wykonać w danej warstwie architektonicznej, a także wszelkich testów i integracji, które mogą być potrzebne, by przygotować go do wypuszczenia.

Zazwyczaj podział poziomy dzieli funkcjonalności na historie użytkownika lub zadania na poziomie komponentu architektonicznego. Przykład: interfejs użytkownika front-end, bazy danych lub usługi backend. Natomiast pionowy kawałek prowadzi do działającej, demonstracyjnej oprogramowania, które dodaje wartość biznesową. Dlatego podział pionowy poprawia zdolność zespołu do dostarczania potencjalnie gotowego do wypuszczenia przyrostu produktu w każdym sprintie. Wyobraź sobie ciastko z warstwami śmietnika, czekolady, owoców i ciasta. Jeśli ciasto rozetnie się poziomo, twój znajomy dostałby tylko kawałek ciasta, czekolady, śmietnika lub owoców. Jestem pewien, że Twoi znajomi chcieliby kawałek z nieco wszystkich warstw. Otrzymywanie tylko jednej warstwy ciasta nie pozwala im poczuć prawdziwego smaku całego ciasta. Sposób bardziej przyjazny dla Twoich znajomych to tworzenie pionowych kawałków (pożądanej wartości).

Podział epiku poziomo zgodnie z celem

Pamiętaj, że konwersja dla historii użytkownika „zarejestruj kurs”, którą mieliśmy na spotkaniu z interesariuszami, została najpierw zaproponowana przez studentów (główna rola) i wspierana przez innych interesariuszy. Gdy analizowaliśmy szczegółowe informacje dotyczące historii użytkownika, odkryliśmy, że istnieje dość dużo informacji, które zostały zarezerwowane przez innych interesariuszy, którzy będą uczestniczyć w historii użytkownika jako wspierająca rola.

W rzeczywistości niektórzy studenci mogą nie dbać ani nawet nie chcieć ograniczeń ustanowionych przez osoby w roli wspierającej. Na przykład student zapomina hasło i wpisuje je niepoprawnie trzy razy, może nie chcieć przechodzić przez proces resetowania hasła, ale nadal ma pewność, że może spróbować kilka razy więcej, albo student nie chce mieć limitu na książki w bibliotece, lub okresu wypożyczenia itd. Osoby, które chcą ustawić pewne zasady biznesowe, ograniczenia dla zaproponowanych funkcjonalności jako swoje cele użytkownika, to właśnie te, które uczestniczą w historii użytkownika jako rola wspierająca. Funkcjonalność nie powinna działać wcale, jeśli zasady biznesowe i drugi cel nie zostaną nałożone na zaproponowaną funkcjonalność. Jeśli podzielimy epik poziomo zgodnie z celami aktorów pomocniczych na grupę historii użytkownika, możemy jednocześnie spełnić cele tych aktorów, uczynić historię użytkownika testowalną i otrzymać feedback bezpośrednio od odpowiedniej osoby.

Zbadajmy informacje z sekcji konwersji i potwierdzenia, aby zobaczyć, jak możemy podzielić większą historię „zarejestruj kurs” na grupę powiązanych historii użytkownika.

1. Student musi być zarejestrowanym studentem, jeśli nie, to nie otrzyma poświadczenia wydanego w powiadomieniu dla nowych studentów. Jeśli otrzymał powiadomienie, ale konto jeszcze nie zostało aktywowane, musi zarejestrować nowe konto online (oznaczone jako czerwony okrąg 1)
2. Jeśli zagłębimy się nieco głębiej w proces logowania, wiemy, że jeśli student poda dane logowania trzy razy niepoprawnie, musi przejść do „procesu resetowania hasła” (oznaczone jako czerwony okrąg 2 i 3)

Ogólny compartment historii użytkownika

Stwórzmy te historie użytkownika w UeXceler:

Historia użytkownika Logowanie konta jest tworzona w ogólnym compartmentie historii użytkownika. Oprócz historii użytkownika logowania tworzona jest również dwie inne powiązane historie użytkownika w tym samym compartmentie, są to „reset hasła” i „Utwórz nowe konto ucznia” z następujących powodów:

• W przypadku, gdy dane logowania konta zostaną niepoprawnie wprowadzone przez ucznia trzy razy, zostanie wyzwolona historia użytkownika „reset hasła”;
• a jeśli nowy uczeń jeszcze nie zarejestrował konta ucznia, może wyzwolić historię użytkownika „Utwórz nowe konto ucznia” w oknie logowania.

1. Jako uczeń, chcę zalogować się do portalu ucznia, aby…
2. Jako administrator portalu, chcę zweryfikować, że osoba logująca się jest zarejestrowanym uczniem, aby…
3. Jako kierownik kursu, chcę zweryfikować odpowiedniość przed zezwoleniem na dodanie wybranego kursu do harmonogramu ucznia, aby…

Możemy uznać, że te trzy historie użytkownika zostały podzielone poziomo od epiki – „zarejestruj kurs”, ale te historie użytkownika spełniają cele niektórych aktorów pomocniczych, od których możesz otrzymać opinię i potwierdzić. Gdyby warunki wstępne nie zostały spełnione, główna historia użytkownika nie miałaby już żadnego sensu.

Można zauważyć, że umieściliśmy wszystkie te historie użytkownika w ogólnym compartmentie historii użytkownika, a przyczyną jest to, że mają one duże prawdopodobieństwo współdzielenia tych samych warunków wstępnych z innymi powiązanymi funkcjonalnościami (historiami użytkownika) na tym samym ekranie wywołania, takimi jak „zobacz harmonogram”, „edytuj harmonogram”, „wypisz kursy” itp.

Compartmenty przypadków użycia

W powyższym rysunku pozostały trzy oznaczone czerwonym kolorem: 4, 5 i 6. Są to scenariusze alternatywne epiki „zarejestruj kurs”. W przypadku, gdy którykolwiek z tych trzech warunków nie zostanie spełniony, pojawi się scenariusz alternatywny, który może zostać przedstawiony jako rozdzielona historia użytkownika. Możemy rozważyć podział poziomy lub pionowy, ale czy zawsze podział pionowy jest lepszy? Niekoniecznie – zależy to od sytuacji. Nie ma uniwersalnego rozwiązania, musimy rozważyć, który podejście jest bardziej odpowiednie dla Twojego przypadku. Pozwól mi to wyjaśnić nieco dokładniej.

Na przykład, jeśli chcesz przydzielić główną historię użytkownika jednemu programiście, a trzy historie użytkownika: logowanie, rejestracja nowego konta i reset hasła – drugiemu programiście. Możesz preferować, by osoba odpowiedzialna za główną historię użytkownika najpierw opracowała scenariusz „szczęśliwy” w bieżącym sprintie, a następnie stopniowo rozwijała scenariusze alternatywne w kolejnych sprintach tym samym programistą (o ile czas pozwala). Ale jeśli czas jest krótki, a jednocześnie uważasz, że jednemu programiście jest zbyt ciężko zarządzać całą epiką, możesz podzielić ją poziomo na zadania i przydzielić je równolegle kilku programistom.

Podział epiki na scenariusze

Jeśli rozważymy szczegóły scenariusza opisanego w sekcji potwierdzenia epiki, łatwo znajdziemy pionowe fragmenty dla grupy powiązanych historii użytkownika.

1. Jako kierownik kursu, chcę zweryfikować wymagania wstępne przed zezwoleniem na dodanie wybranego kursu do harmonogramu ucznia, aby…
2. Jako kierownik kursu, chcę sprawdzić dostępność kursu przed zezwoleniem na dodanie kursu do harmonogramu ucznia, aby…
3. Jako kierownik kursu, chcę zweryfikować dostępność slotu czasowego ucznia przed zezwoleniem na dodanie wybranego kursu do harmonogramu ucznia, aby…

Podział epiki na zadania

Jeśli chcemy rozłożyć epikę na mniejsze zadania do równoległego rozwoju w tym samym sprintie, następująco:

1. Sprawdź stan limitu kursu
2. Sprawdź wymagania wstępne kursu
3. Sprawdź slot czasowy

Teraz decyzja należy do Ciebie – jak podzielić epikę na historie użytkownika w procesie rozwoju agilnego. Możesz zobaczyć, że historia użytkownika „Zarejestruj kurs” i jej powiązane historie znajdują się w compartmentie przypadków użycia (Twojej epiki), nazywanym również „Zarejestruj kurs”, który służy jako miejsce zastępcze do umieszczenia wszystkich głównych historii użytkownika oraz tych, które zostały podzielone z głównej.