Spis treści
Zadanie ukończone = Kryteria Akceptacyjne + Definition of Done
W Ageno większość wymagań definiujemy za pomocą User Story, kryteriów akceptacynych i projektów UX/UI. Aby móc powiedzieć, że dane wymaganie zostało wykonane, musi zostać wcześniej skrupulatnie zweryfikowane pod kątem:
- Definition of Done – uniwersalne kryteria, które muszą spełnić wszystkie wymagania na przestrzeni całego projektu (bardziej ogólne).
- Kryteriów Akceptacyjnych – przyporządkowane kryteria do danego wymagania (bardziej szczegółowe).
Czym jest Definition of Done?
Definition of Done to zbiór wymagań, które muszą być spełnione, aby uznać zadanie za zakończone. W Ageno określiliśmy jasne kryteria Definition od Done dla różnych typów zadań / obszarów.
Standardowe Definition of Done w Ageno w zależności od obszaru
Kryteria ogólne dla wszystkich zadań
- Zadanie jest w zgodne z opisanymi wymaganiami, User Story i Kryteriami Akceptacji.
- Kod jest schludny, sformatowany, zgodny ze standardami jakości i dobrymi praktykami programistycznymi.
- Wszystkie zmiany zostały przetestowane.
- Kod przeszedł code review i został zaakceptowany przez innego członka zespołu.
- Zadanie zostało wdrożone na środowisko staging.
- Dokumentacja została zaktualizowana.
Kryteria dla zadań frontendowych
- Zadanie jest zgodne z projektem graficznym interfejsu (UX/UI).
- Strona działa prawidłowo na najnowszych wersjach wspieranych przeglądarek.
- Kod HTML jest semantycznie poprawny i możliwie zgodny ze standardami W3C oraz przyjętymi standardami (np. ESLint, Prettier).
- Nazewnictwo klas i zmiennych jest semantyczne, czytelne i spójne, zgodne z wytycznymi frameworka (np. Magento 2)
- Responsywność (RWD) jest przetestowana i funkcjonuje prawidłowo na różnych rozdzielczościach dopasowując się do ekranu.
- Wszystkie elementy aktywne (klikalne), mają swoje stany np. linki, przyciski (hover, active, focus, disabled itp.).
- Brak jest błędów w konsoli przeglądarki.
- Zadanie spełnia wymogi rozporządzenia o dostępności (WCAG).
Kryteria dla zadań związanych z integracjami i API
- API zwraca poprawne dane zgodnie z dokumentacją.
- Przeprowadzono testy integracyjne potwierdzające poprawność działania.
- Logowanie błędów działa poprawnie, ułatwiając diagnostykę problemów w przyszłości.
Kryteria dla danych (np. dummy data)
- Dane kontaktowe – Jeżeli to możliwe, użyty został prawidłowy adres, e-mail i telefon.
- Placeholder – Zaślepka zdjęcia dla zdjęć produktowych ustawiony dla projektu z logo firmy.
- Blank State – Obsługa wszelkich pustych stanów. Np. Brak produktów w kategorii, brak wyników wyszukiwania itp.
- Tłumaczenia — Wszystkie treści w witrynie, które powinny posiadać tłumaczenia, zostały przetłumaczone.
- Sierotki – Teksty statyczne nie zawierają sierotek na końcu wiersza (whitespace).
Definition of Done może się różnić w zależności od projektu
Definition of Done (DoD) powinno być dostosowane do specyfiki każdego projektu. Jak wszystkie elementy Agile, DoD podlega inspekcji i adaptacji. Wraz z dojrzewaniem zespołu i rozwojem projektu, jego kryteria powinny być aktualizowane, aby zapewnić coraz wyższą jakość dostarczanego oprogramowania. Jeśli w danym projekcie nie ustalono indywidualnego DoD, obowiązuje standardowa definicja zawarta w tym artykule.
Podsumowanie
Definition of Done to fundament, który określa, kiedy wymaganie, wraz z Kryteriami Akceptacyjnymi, można uznać za w pełni zrealizowane.
Taki scenariusz nie powinien mieć miejsca:
— Dlaczego ten przycisk na stronie produktu nie jest responsywny RWD i źle się zachowuje na urządzeniu mobilnym? — Project Manager
— Przecież nie było napisane na karcie, że ten button ma być responsywny, nie było projektu! — Frontend Developer
Przestrzeganie DoD minimalizuje ryzyko błędów i poprawia jakość dostarczanego oprogramowania, co przekłada się na lepszą współpracę w zespole i większe zadowolenie klientów.