W poprzednim wpisie dotyczącym kanban pisałem o jego założeniach. Dziś chciałem opisać podstawowy element kanban: tablicę. Tablica prezentuje: Kto nad czym pracuje Nad czym sam pracujesz Ile zadań jest realizowanych równolegle Tablica wizualizuje nam stan realizacji zadania. O zadaniach szerzej już w kolejnym poście. Teraz tylko wspomnę, że zadania w Kanban to karty, które powinny/mogą […]
Tablica zadań w Kanban Czytaj dalej »
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
Sprint Burndown Chart – Wykres Spalania Sprintu Czytaj dalej »
Postanowiłem końcówkę 2016 ogłosić na moim blogu rokiem Agile. Listopad i grudzień poza wpisami dotyczącymi Scrum będzie dostarczał wiedzy na temat Kanban. Niniejszy artykuł otwiera cykl tekstów na temat Kanban. O Kanban pisałem już w 2014. Te wpisy traktuję jako odświeżenie i uzupełnienie tematu. Planuję 7-8 tekstów na ten temat, które będę co tydzień publikował. Zacznijmy od początku. Czym jest
Kanban – podstawowe pojęcia i zasady Czytaj dalej »
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
Release Burndown Chart – Wykres Spalania Wydania Czytaj dalej »
Jak wynika z poglądowych badań przeprowadzonych we wrześniu 2015 r. średnia zarobków architektów korporacyjnych w Polsce wynosi brutto 15.300 zł (przy medianie 13.000 zł brutto). Dla porównania średnie zarobki analityków wynoszą 11.100 zł brutto). Badania te potwierdziły również przypuszczenie, że sporo polskich organizacji wdrożyło już u siebie wybrane mechanizmy zarządzania architekturą IT/korporacyjną. Jednocześnie obecnie z
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ń
Task Board – Tablica Zadań Czytaj dalej »
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
Sprint Backlog – Rejestr Sprintu Czytaj dalej »
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
Narzędzie do modelowania architektury korporacyjnej Czytaj dalej »
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
Historyjki użytkownika a wymagania Czytaj dalej »
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 »
