Blog #białko to nie tylko Scrum czy inne zwinne metodyki. Dzielimy się tu praktyczną wiedzą dotyczącą różnych aspektów zwinnej pracy. A dziś zajmiemy się terminem Corner Case, opiszemy czym on jest i jak możemy go wykorzystać.
Po co dzielimy wymagania?
W ostatni wtorek mieliśmy okazję usłyszeć głos Artura, autora naszego nowego cyklu i dewelopera, który definiował problem z rozumieniem Scrum. Kwestie związane z rozwojem rozwiązań będą przedmiotem również dzisiejszego wpisu, spojrzymy na nie jednak z zupełnie innej strony.
Aby móc zrealizować jakąś zmianę, musimy ją wcześniej przygotować. Oczywiście, będziemy w tym pamiętać o słusznej idei pragmatyzmu. Nie chcemy przecież
Dzisiejszy wpis możecie potraktować jako wstęp do zagadnienia dzielenia wymagań. O tym, że warto dzielić wymagania na mniejsze nie muszę nikogo przekonywać. Po pierwsze, zapewniamy, że mieszczą się one w Sprincie. A po drugie, dzięki małym wymaganiom co stały okres (Sprint) otrzymujemy nową wartość. Warto więc wydzielić najmniejszą z możliwych części. I zawsze, kiedy o tym piszemy czy mówimy pada sakramentalne pytanie… „Ale jak?”
Corner Case
Sposobów dzielenia wymagań jest wiele. Od dzielenia na czuja, które czasem wychodzi źle, do dzielenia w oparciu o kryteria akceptacji i wzorce podziału. Tych ostatnich uczymy na naszych warsztatach dotyczących wymagań. Dziś natomiast podejdziemy do dzielenia z punktu widzenia Corner Case, czyli próby zidentyfikowania konkretnych przypadków szczególnych w spektrum działania wymagania.
Corner Case występuje, gdy wiele zmiennych środowiskowych lub warunków znajduje się jednocześnie na skrajnych poziomach. Nawet jeśli każdy pojedynczy parametr mieści się w zakresie określonym jako bezpieczny. Przykład? Aplikacja, którą projektujemy ma obsłużyć do jednego miliona użytkowników i być gotowa do obsługi dwóch milionów transakcji dziennie. Czy to oznacza, że pracując nad rozwiązaniem musimy być od razu gotowi na powyższe warunki? Nie! Wszystko zależy od przyjętych założeń. Te, definiowane przez biznes i zapisywane w wymaganiu wyznaczać nam będą kierunek realizacji wymagania lub właśnie jego części!
Sformułowanie „Corner Case” dotyczy sytuacji, gdzie nagle znajdziemy się w skrajnym miejscu z wielu różnych punktów widzenia (stąd ten róg). Przypomnijcie sobie ostatnią większą awarię czy katastrofę. Zwykle nie jest winny tylko jeden czynnik. Potrzeba, żeby zadziało się dużo mało prawdopodobnych rzeczy na raz. W tym miejscu należy wspomnieć, że prócz spojrzenia na wymaganie z tego punktu widzenia możemy również zidentyfikować Edge case (warunek brzegowy – tylko jeden parametr), Boundary case, Base case i inne, ale o nich napiszę już wkrótce. Obiecuję.
„Bo to nie jest takie proste!”
Dzielenie wymagań to nie jest najprostsza z rzeczy. Wiemy o tym od samych zespołów, które za prawie każdym razem zwracają uwagę na brak umiejętności w tym zakresie. Ale przykład, który dziś podaję jest jednym z najprostszych, które możemy wykorzystać. Potencjalnie wszystko dostajemy na tacy – mamy zestaw warunków brzegowych i musimy „tylko” zastanowić się, które są zbędne, a które zapędzą nas… w kozi róg. Dobrze zdefiniowane wymaganie zawierało będzie konkretne warunki dotyczące poszczególnych parametrów, ale dla nas będzie to kierunkowskazem.
Tutaj dochodzimy do zagadnienia długu technologicznego. Bo czym innym, jak nie zaciąganiem kredytu, będzie odłożenie realizacji pełnego wymagania na później? Zróbmy w pierwszej kolejności prostą wersję rozwiązania, spełniającą wszystkie parametry w części albo np. jeden parametr w całości. Zbierzmy informację zwrotną, a następnie zaplanujmy realizację drugiej części wymagania na później. Jeśli oczywiście na to „później” jest czas.
Wstęp do dzielenia
Dzielenie wymagań to zagadnienie, które angażuje cały Scrum Team. Z jednej strony Deweloperzy często nie chcą realizować małych wymagań, bo nie czują, że one coś dają i nie są z nich dumni. Lubią za to skupić się na „swoim” wymaganiu i realizować je choćby i przez pół roku. Z drugiej strony Product Owner, jako frequent releaser i value maximizer chciałby otrzymywać nową wartość często. Ba, chciałby ją nawet skomercjalizować.
Musimy znaleźć złoty środek, zapewnić zadowolenie całego Scrum Teamu i pomóc mu realizować jego zadania. Celowo powyżej nie wspomniałem o Scrum Masterze. Jest on odpowiedzialny za efektywność zespołu, powinien więc facylitować potrzebę dzielenia wymagań. Ma w tym pośredni cel, bo przecież to PO gwarantuje zrozumienie wymagań znajdujących się w Backlogu Produktu. Czy mniejsze wymagania nie wzmacniają tego rozumienia? Na pewno!
Tym postem chcemy także zachęcić Was do udziału w naszym weekendowym szkoleniu dotyczącym zarządzania backlogiem, które zbliża się wielkimi krokami. Na pewno zagadnienie dzielenia wymagań, w tym praktyczne techniki będą miały tam swoje miejsce. Obserwujcie nasze profile na Facebook oraz LinkedIn i czekajcie na więcej szczegółów. A jeśli nie macie czasu siedzieć na social mediach, wystarczy zapisać się na naszą listę mailingową. Wtedy macie pewność, że nic Was nie ominie.
