Odcinek 6 serii: AgileBA w praktyce wdrożenia WMS
Typowe wymaganie ze specyfikacji WMS:
„System powinien umożliwiać zarządzanie lokalizacjami magazynowymi.”
Brzmi poprawnie. I nic z tego nie wynika. Kto zarządza? W jakiej sytuacji? Co ma być dzięki temu lepiej? Po czym poznamy, że to działa?
Takie zdania da się odhaczyć na liście, ale nie da się ich sensownie zaprojektować, przetestować ani ocenić pod kątem wartości. A w projekcie WMS, w którym o sukcesie decyduje codzienna praca ludzi na hali, to za mało.
Czym jest wymaganie w AgileBA
Zacznijmy od definicji, bo jest bardzo praktyczna: wymaganie to usługa, funkcja lub właściwość, której ktoś potrzebuje. Mogą to być także ograniczenia, reguły biznesowe i inne elementy, które trzeba uwzględnić, żeby zaspokoić potrzeby użytkowników.
Warto pamiętać, że AgileBA dzieli wymagania na kilka kategorii:
- Ogólne wymagania biznesowe: reguły dla wszystkich projektów, np. polityki firmy, ograniczenia prawne
- Wymagania polityk technicznych: standardy, których musi przestrzegać każde rozwiązanie, np. platforma sprzętowa
- Wymagania funkcjonalne: co system ma robić, bez określania, jak
- Wymagania niefunkcjonalne: jak dobrze i na jakim poziomie, np. wydajność, niezawodność, dostępność, czas reakcji
W projekcie WMS ta ostatnia grupa bywa niedoceniana. „System ma wskazywać lokalizację” to wymaganie funkcjonalne. „Wskazanie ma pojawić się w czasie, który nie spowalnia pracy na rampie” to niefunkcjonalne, a w praktyce równie ważne.
Historyjka użytkownika: prosty format
AgileBA proponuje jeden, bardzo prosty format zapisu:
Jako <rola> chcę <wymaganie lub funkcja> aby <rezultat / wartość>
Przykład z magazynu (ilustracyjny):
Jako magazynier chcę, żeby system wskazał mi lokalizację, w której mam odłożyć paletę, aby nie tracić czasu na szukanie wolnego miejsca i nie blokować korytarza.
Jedno zdanie. Kto, czego potrzebuje i po co.
Najważniejsze jest to ostatnie „aby”. To ono łączy wymaganie z wartością biznesową i pozwala później ocenić, czy w ogóle warto je realizować, a jeśli tak, to w jakiej kolejności. Wymaganie, do którego trudno dopisać sensowne „aby”, często okazuje się zbędne albo źle sformułowane. To jedna z najtańszych metod odsiewania pomysłów, które „wydają się potrzebne”, ale nikt nie potrafi powiedzieć po co.
Kryteria INVEST: jak sprawdzić, czy historyjka jest dobra
AgileBA podaje popularny zestaw kryteriów INVEST. Dobra historyjka jest:
| Litera | Kryterium | Co to znaczy w praktyce |
|---|---|---|
| I | Independent (niezależna) | Można ją zrealizować bez czekania na dziesięć innych |
| N | Negotiable (negocjowalna) | Szczegóły rozwiązania można omawiać, to nie jest wyrok |
| V | Valuable (wartościowa) | Ktoś odniesie z niej realną korzyść |
| E | Estimable (możliwa do oszacowania) | Zespół potrafi powiedzieć, ile pracy to zajmie |
| S | Small (mała) | Mieści się w jednym Timeboxie |
| T | Testable (możliwa do przetestowania) | Wiemy, po czym poznamy, że jest gotowa |
Ostatnie kryterium ma bardzo praktyczną konsekwencję.
Kryteria akceptacji: odwrót karty
W AgileBA historyjkę często zapisuje się na karcie. Na awersie jest sama historyjka, a na rewersie kryteria akceptacji, czyli konkretne warunki, po spełnieniu których uznajemy, że historyjka jest gotowa.
Dla naszego przykładu mogłoby to wyglądać tak (ilustracyjnie):
- System nie proponuje lokalizacji, która jest zajęta lub zablokowana
- System uwzględnia strefę przypisaną do danej grupy towarowej
- Gdy w strefie nie ma wolnego miejsca, magazynier dostaje jasny komunikat, co robić dalej, zamiast pustego ekranu
Analityk Biznesowy zapewnia mierzalne kryteria akceptacji dla każdego wymagania, uzgodnione z interesariuszami. Ich brak to najczęstsze źródło sporów na etapie odbioru: „wydawało mi się, że to jest w zakresie”.
Hierarchia: Temat, Epik, Historyjka
Historyjki nie powstają od razu w idealnej postaci. Na początku projektu pojawiają się duże, ogólne pomysły, które AgileBA porządkuje w trzy poziomy:
Temat (Theme): zbiór powiązanych historyjek lub epików. To nie historyjka, tylko nagłówek porządkujący, np. „przyjęcie towaru”.
Epik (Epic): duża, ogólna historia, zwykle zbyt obszerna, żeby zmieścić się w jednym Timeboxie, np. „przyjęcie dostawy z awizacją”.
Historyjka użytkownika (User Story): na tyle szczegółowa, żeby ją oszacować, i na tyle mała, żeby zmieścić się w Timeboxie (zazwyczaj 2-4 tygodnie pracy, wyjątkowo 6).
Dzięki temu nie musimy na starcie rozpisywać wszystkiego do poziomu szczegółów. Epiki dzielimy na historyjki dopiero wtedy, kiedy zbliża się ich realizacja. To ta sama zasada just in time, o której była mowa w poprzednim odcinku.
„Jako magazynier” to dopiero początek
Jest jeszcze jeden element, o którym warto wspomnieć. W historyjce piszemy „jako magazynier”, ale magazynier magazynierowi nierówny. Doświadczony pracownik i osoba tymczasowa, która pierwszy raz widzi skaner, potrzebują innych komunikatów, innego poziomu szczegółowości i innego tempa.
AgileBA proponuje tu Persony: opis typowego użytkownika z jego upodobaniami, niechęciami, obawami i potrzebami, najlepiej tak realistyczny, żeby można było go „spotkać na korytarzu”. Wrócimy do tego w jednym z kolejnych odcinków.
Rola Analityka Biznesowego: kto jest właścicielem wymagań?
Tu pojawia się częste nieporozumienie. Analityk Biznesowy nie jest właścicielem wymagań. Jest ich strażnikiem i „mistrzem”. Odpowiada za Listę Wymagań z Priorytetami: jej jakość, kompletność i spójność, a także za to, żeby zarządzanie jasnym, użytecznym i przyrostowo zmieniającym się zestawem wymagań było faktycznie wykonywane.
Własność wymagań powinna być zaakceptowana przez przedstawicieli biznesu: Wizjonera i Ambasadora Biznesowego. To oni zatwierdzają wymagania, a Analityk pomaga je wydobyć, uporządkować i opisać.
Różnica jest subtelna, ale ważna. Jeśli Analityk „jest właścicielem”, to gdy po uruchomieniu okaże się, że czegoś brakuje, biznes mówi: „przecież to analityk pisał”. Jeśli właścicielem jest biznes, odpowiedzialność jest tam, gdzie powinna.
Praktyczne wskazówki
- Piszcie historyjki razem z ludźmi z hali. Magazynier napisze „aby” lepiej niż jakikolwiek analityk.
- Zaczynajcie od „aby”. Jeśli nie potrafisz go sformułować, zatrzymaj się i zapytaj, po co to wymaganie w ogóle istnieje.
- Nie dzielcie wszystkiego od razu. Epiki mogą poczekać na szczegółowy podział do momentu, w którym zbliża się ich realizacja.
- Dopisujcie kryteria akceptacji od razu. Później będzie trudniej, a wspomnienia różnych osób zaczną się rozjeżdżać.
Pytania kontrolne
- Czy nasze wymagania odpowiadają na pytanie „kto i po co?”, czy tylko „co system ma umożliwiać”?
- Czy każda historyjka ma kryteria akceptacji, które da się sprawdzić?
- Czy ktoś z hali uczestniczył w pisaniu historyjek, czy powstały w całości przy biurku?
- Czy wiemy, kto jest właścicielem wymagań po stronie biznesu?
To szósty odcinek serii łączącej metodykę AgileBA z praktyką wdrożeń WMS. Kolejny odcinek: MoSCoW na magazynie, czyli dlaczego nie wszystko musi być gotowe na starcie i jak podejmować decyzje, co przesunąć na później.
A jak wyglądały wymagania w Waszych projektach? Lista „system ma umożliwiać”, czy historyjki z perspektywy ludzi, którzy będą w nim pracować?