Nadchodzący Enterprise Architect to sporo nowości. Przegląd nowości opisałem https://wolski.pro/2016/07/nadchodzi-enterprise-architect-13/
Dziś będę chciał opisać bardziej szczegółowo jeden aspekt a mianowicie możliwość użycia Kanban.
O Kanban (https://wolski.pro/kanban/) pisałem w 2014. Dla przypomnienia zacytuję definicję ze strony http://www.system-kanban.pl/
Jest to japońska metoda kontroli procesu produkcyjnego oparta wyłącznie na rzeczywistym zużyciu materiałów. Kanban umożliwia redukcję zapasów w hali produkcyjnej, które są wymagane do zoptymalizowanego działania produkcji. Celem systemu jest kontrola i redukcja kosztów magazynowania materiałów, zwiększenie dostępności materiałów i wyeliminowanie przestojów produkcji spowodowanych brakiem wymaganych materiałów.
Twórca Kanban myślał przede wszystkim o produkcji w fabryce. W świecie informatyki wytworzenie oprogramowania jest procesem zbliżonym do procesu jaki zachodzi w fabryce. Zasadniczą różnicą jest fakt, że w fabryce mamy materiały w magazynie a w świecie informatyki mamy wymagania. Pisząc o wymaganiach i Kanban mam na myśli backlog i podejście Agile do procesu wytwórczego oprogramowania. Świetnie zostało to opisane http://www.poddrzewem.pl/do-poczytania/kanban-wprowadzenie.
Innymi słowy Kanban pozwoli wizualizować pracę i śledzić postępy projektu w oparciu o historyjki użytkownika. Oczywiście zamiast historyjek użytkownika można zastosować przypadki użycia.
Jak Enterprise Architect 13 wspiera Kanban? Otóż oferuje on zestaw diagramów pozwalających na wizualizację backlogu.
W Enterprise Architect są cztery diagramy:
Basic – podstawowy przepływ pracy – zasadniczo jest widokiem dla członka zespołu – analityka, programisty, testera itp.
Backlog – umożliwia wizualizację i priorytezację takich elementów jak: user stories, defects, feature, change
Iteration – wizualizuje fazę „produkcji” dla całego Sprintu
Complete – pozwala zwizualizować stan artefaktu po zakończonym procesie wytwórczym.
Fajną opcją jest również to, że na elementach używanych na diagramach można zwizualizować jego stan
Wartości atrybutów opisujących artefakty zależą od od miejsca położenia elementu na poszczególnych diagramach i zmieniają się autonomicznie.
Priorytet jest z backlogu. Natomiast Faza pochodzi z diagramu iteracja
Wartą użycia jest funkcja resources, która pozwala przypisać dany artefakt wielu osobom. Ponadto każdy z członków zespołu może mieć własny diagram przepływu pracy.
W ten to sposób product owner i scrum master mogą śledzić postępy prac poszczególnych osób a także stan poszczególnych artefaktów.
Dla porównania prezentuję widok Admina – programisty – historyjkę ma w backlogu, Michał analityk ma wspomnianą historyjkę oznaczoną jako zrobioną a na diagramie obrazującym sprint omawiana historyjka jest w fazie „In progress”
W Enterprise Architect możemy zdefiniować odpowiednią liczbę artefaktów jakie mogą być realizowane w danym momencie np.: tylko 2 historyjki mogą być testowane
W taki oto sposób historyjki użytkownika zaczynają wreszcie sensownie funkcjonować. Cieszy mnie również fakt, że powoli zaczyna się era wizualnego modelowania przepływu pracy.
Reklama
