metodyki zwinne

Codzienny Scrum (ang. The Daily Scrum) to szybkie spotkanie, w którym biorą udział wszyscy członkowie Zespółu Scrum oraz Mistrz Scrum. Każdego dnia sprintu zespół odbywa spotkania („Codzienny Scrum”). Spotkania odbywają się na ogół w tej samej lokalizacji i o tej samej porze każdego dnia. Sytuacją pożądaną jest, aby codzienne scrumy odbywały się z rana, gdyż

Wykres Spalania Sprintu (ang. Sprint Burndown Chart) jest graficznym przedstawieniem pracy pozostającej do wykonania w trakcie trwania Sprintu. Zasada tworzenia wykresu spalania sprintu jest bardzo podobna do tworzenia wykresu spalania wydania. Na pionowej osi umieszczamy łączną liczbę godzin, którą uzyskaliśmy po zsumowaniu poszczególnych zadań w sprincie. W zaprezentowanym przykładzie jest ich 400. Następnie, każdego dnia w

Wykres Spalania Wydania (ang. Release Burndown Chart) śledzi postęp zespołu deweloperskiego pod względem realizacji planu wydania. Wykres spalania wydania to podstawowy artefakt służący do śledzenia i przewidywania postępu w metododyce Scrum. „Wykres spalania pozwala na śledzenie i przewidywanie postępów projektu. Na podstawie szybkości z poprzednich sprintów wykres spalania wydania przewiduje przyszłość, aby zespół scrumowy mógł dostosować produkt

Tablica Zadań (ang. Task Board) pokazuje całość pracy wykonywanej przez zespół podczas sprintu. Jest ona stale aktualizowana w trakcie sprintu- jeżeli ktoś myśli o nowym zadaniu, pisze nową kartę i umieszcza ją na tablicy. W trakcie lub przed Codziennym Scrumem, zmienia się szacunki (w górę lub w dół) i przemieszcza się karty na tablicy. Tablica zadań

Rejestr sprintu  (ang. Sprint Backlog) to lista zadań, które Zespół Scrum zobowiązuje się wykonać w bieżącym sprincie. Pozycje rejestru sprintu są przeniesione z Produkt Backloga przez zespół, w oparciu o priorytety ustalone przez Właściciela Produktu. „Rejestr sprintu opisuje poprzez zestaw szczegółowych zadań, w jaki sposób zespół planuje zaprojektować, zbudować i przetestować dany podzbiór cech z rejestru

Pisząc jakąkolwiek specyfikację wymagań a rejestr produktu i rejestr sprintu są taką specyfikację należy uwzględnić wymagania niefunkcjonalne. O ile sama historyjka użytkownika zazwyczaj reprezentuje wymagania funkcjonalne to, w moim odczuciu, drobny problem jest z wymaganiami niefunkcjonalnymi, które reprezentują oczekiwania na poziomie systemu. Brak wymagań niefunkcjonalnych lub ich niedostateczna ilość są często źródłem problemów z programowaniem a

W zeszłym tygodniu pisałem o dobrych cechach Rejestru Produktu. Dziś chciałbym przybliżyć dobre cechy historyjki użytkownika. Dobra historyjka użytkownika powinna spełniać kryteria INVEST. INVEST to: Independent – niezależność Negotiable – negocjowalność Valuable – wartościowość Estimatable – ocenialność Sized correctly – dobry rozmiar Testable – testowalność Połączenie tych cech pozwala na budowanie sensownych i użytecznych historyjek użytkownika.