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ń może przykładowo wyglądać tak: Każdy…

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 produktu w trakcie trwania tego…

Myśląc o modelowaniu architektury korporacyjnej bardzo często rozważa się wybór narzędzia do modelowania. Jednym z naturalnych kandydatów jest Enterprise Architect. Kandydatura Enterprise Architect'a bierze się zazwyczaj z faktu, że jest ona wykorzystywane przez szeroko rozumiane IT. IT dość często, w ramach inicjatywy oddolnej, próbuje wdrożyć elementy architektury korporacyjnej. Wspomniana powyżej sytuacja nie jest, w moim odczuciu, do końca idealna. W…

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 także z testowaniem. "Dobre zarządzanie…

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. Niezależność Niezależność historyjki użytkownika oznacza,…

W zeszłym tygodniu opisałem rejestr produktu. Dziś chciałbym przybliżyć temat jakości rejestru produktu. Dobry rejestr produktu jest DEEP. Akronim DEEP został stworzony przez Romana Pichlera i Mike’a Cohena ułatwiający zapamiętanie kryteriów służących do oceny jakości rejestru produktu. DEEP oznacza: Detailed appropriately - wystarczająco szczegółowy, Estimated - szacunkowy Emergent - nowo powstający (podaję za Pichlerem [2]) Prioritized - zawiera priorytety Roman Pichler w swojej…

Zgodnie z zapowiedziami Enterprise Architect doczekał się 13 wersji. Sparx Systems dziś opublikował finalną wersję tego popularnego narzędzia. Publiczna kompilacja ma numer 1305. Enterprise Architect 13 to nie tylko nowy interfejs nawiązujący do Office 2016, ale także i może przede wszystkim wsparcie Kanban oraz bardziej sensowne mechanizmy wspierające zarządzanie zmianą. O Kanbanie pisałem w Kanban w Enterprise Architect 13 część 1 oraz…

Pisząc o Scrum nie można zapomnieć o historyjkach użytkownika. Co prawda  Scrum nie określa sposobu opisywania elementów rejestru produktu i pozwala na dodanie tam różnych artefaktów to historyjka użytkownika stałą się jednym z symboli metodyki Scrum. "User story, czyli historia użytkownika, opowiada o kliencie lub użytkowniku korzystającym z produktu. Zawiera imię, krótki opis oraz kryteria akceptacji czy warunki, które muszą być…

No to się porobiło :-). Po tym jak odpaliłem facebooka i google+ dla bloga oraz zrobiłem listę mailingową, wpadłem na kolejny pomysł. Postanowiłem trochę poeksperymentować z formą i treścią. Teksty na tym blogu piszę od 9 lat więc przyszła kolej na video. Spokojnie jak na razie nie planuję podcastów :-).  Nagrałem krótki filmik o obecności Archimate 3.0 w Enterprise Architect 13.…

Rejestr Produktu  (ang. Product Backlog) zwany czasem zaległościami produktu,  to główny wykaz wszystkich funkcjonalności pożądanych w produkcie. Za dostarczenie wymagań w postaci rejestru produktu odpowiedzialny jest Właściciel Produktu. Rejestr produktu to "spis czekających na wykonanie historyjek z rejestru produktu z przypisanymi priorytetami" [1]. Podczas inicjacji projektu mamy jego zarys. Nie ma możliwości i wiedzy by projekt był dokładnie zdefiniowany.  Zazwyczaj podczas inicjacji projektu…

Close