Dobre cechy historyjek użytkownika

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. […]

Dobre cechy historyjek użytkownika Czytaj dalej »

Dobre cechy rejestru produktu

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

Dobre cechy rejestru produktu Czytaj dalej »

Enterprise Architect 13 został opublikowany

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 został opublikowany Czytaj dalej »

User Stories – Historyjki użytkownika

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

User Stories – Historyjki użytkownika Czytaj dalej »

Archimate 3.0 w Enterprise Architect 13

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

Archimate 3.0 w Enterprise Architect 13 Czytaj dalej »

Product Backlog – Rejestr produktu

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ł

Product Backlog – Rejestr produktu Czytaj dalej »

Mapowania wychodzące poza architekturę korporacyjną

Dwa tygodnie temu w poście poście Moje ulubione perspektywy w architekturze korporacyjnej przedstawiłem kilka diagramów opisujących architekturę korporacyjną z różnych perspektyw. Opisane perspektywy obejmowały architekturę biznesową, architekturę systemów informatycznych oraz architekturę technologiczną. Oprócz tego zaprezentowałem kilka diagramów prezentujących mapowania pomiędzy powyżej wymienionymi architekturami. W dzisiejszym wpisie postaram się zaprezentować mapowania artefaktów architektury korporacyjnej na wymagania architektoniczne, model

Mapowania wychodzące poza architekturę korporacyjną Czytaj dalej »

Product Owner – Właściciel Produktu

Właściciel Produktu (Product Owner) reprezentuje interesy wszystkich interesariuszy, określa cechy produktu i ustala hierarchię Product Backloga – rejestru produktu. „Osoby, które reprezentują perspektywę klienta w projekcie, odgrywają rolę Właściciela Produktu (…). Taki ktoś odpowiada za wymagania, ustala priorytety, odbiera pracę w sprintach” [4]. Właściciel Produktu ma następujące obowiązki: Określa cechy produktu; Jest odpowiedzialny za rentowność produktu

Product Owner – Właściciel Produktu Czytaj dalej »

Scrum Master – Mistrz Scrum

Mistrz Scrum (ang. Scrum Master), w literaturze określany również jako mistrz młyna, odpowiada za zapewnienie tego, aby Zespół Scrum żył wartościami i praktykami Scrum czyli, innymi słowy, on nadzoruje sposób wykorzystania metodyki. Mistrz Scrum chroni zespół poprzez zapewnienie tego, że nie podejmą oni zbyt wielkich zobowiązań w stosunku do tego, co mogą osiągnąć podczas sprintu.

Scrum Master – Mistrz Scrum Czytaj dalej »

Moje ulubione perspektywy w architekturze korporacyjnej

Na moich stronach przedstawiłem szereg perspektyw Archimate (https://wolski.pro/archimate-2-0/perspektywy/). Użycie ich wszystkich w danej organizacji jest oczywistym nieporozumieniem. Niejednokrotnie pisałem o tym, że w każdym projekcie należy wybrać kilka diagramów za pomocą których, zostanie opisany system. W przypadku Archimate – naczelnego języka do opisu architektury korporacyjnej, takie perspektywy (diagramy) należy wybrać również. Dziś postanowiłem podzielić się moimi ulubionymi

Moje ulubione perspektywy w architekturze korporacyjnej Czytaj dalej »

Scroll to Top