Dołącz do Governautów, zarejestruj się
Załóż konto
Reklama

Drogi użytkowniku!
Wygląda na to, że używasz rozszerzenia blokującego reklamy.
W Governice nie stosujemy nachalnych reklam. Możesz bezpiecznie odblokować je na naszej stronie ;-)
Czym jest projekt? Jakie są standardy zarządzania projektem? Do czego służy Strenght Deployment Inventory? W znalezieniu odpowiedzi na te pytania pomocne będą informacje zamieszczone w tym dziale. Z artykułów dowiedzieć można się również czym jest PRINCE2, SCRUM czy Komitet Sterujący.
Scrumban Przekierowano ze strony: Scrum-ban ang. Scrum-ban
Scrumban (Scrum-ban) - model produkcji oprogramowania bazujący na metodach Scrum i Kanban. Scrumban jest szczególnie odpowiedni do prowadzenia projektów utrzymania lub projektów, w których przewiduje się częste i nieoczekiwane zmiany wymagań użytkownika lub błędy programowania. W takich przypadkach ograniczone czasowo sprinty modelu Scrum nie są tak znacząco przydatne, ale codzienne spotkania Scrumowe i, w zależności od zespołu oraz sytuacji, inne praktyki tej metody mogą być stosowane. Łączy się je ze znanymi z modelu Kanban elementami jak wizualizacja etapów pracy czy ograniczenia równoczesnej realizacji wymagań użytkownika i usuwania błędu programowania. Używając tych metod przepływ pracy zespołu (ang. team's workflow) jest skierowany w sposób, który pozwala minimalizować czas ukończenia każdej historii użytkownika lub naprawy błędu oprogramowania a z drugiej strony zapewnia, że każdy członek zespołu ma ciągłe zatrudnienie.[1]
Wizualizacja procesu
Aby ukazać każdy etap pracy, zespoły pracujące w tym samym miejscu często używają samoprzylepnych karteczek lub wielkich, białych tablic. W przypadku zdecentralizowanych zespołów, wykorzystuje się specjalizowane narzędzia takie jak Assembla, ScrumWorks, Rational Team Concert lub JIRA w konbinacji z GreenHopper. Pozwalają one prezentować historie użytkowników (ang. user stories), defekty (ang. defects) i zadania (ang. tasks) podzielone na oddzielne frazy. Wiele zespołów, mimo dostępności narzędzi informatycznych, korzysta równocześnie z klasycznych tablic przenosząc na nie informacje z programów. Wynika to z psychologicznego oddziaływania wiszącej w pomieszczeniu tablicy na zespół.
W najprostszym przypadku zadania i/lub historie użytkowników są podzielone na trzy etapy pracy:
- nierozpoczęty
- w trakcie
- ukończony
Jednak, w miarę potrzeb, zespoły mogą dodać więcej etapów pracy (takich jak: zdefiniowany, zaprojektowany, przetestowany lub dostarczony). Te dodatkowe fazy mogą być pomocne jeśli jakaś część pracy staje się wąskim gardłem i nie można podnieść wartości granicznych niedokończonej pracy. Bardziej konkretny podział zadań umożliwia również pracownikom specjalizowanie się w określonej fazie pracy.
Nie ma żadnych zbiorów wartości granicznych dla niedokończonej pracy. Zamiast tego każdy zespół musi zdefiniować je indywidualnie metodą prób i błędów. Jeśli będzie miała zbyt małą wartość pracownicy będą bezczynni z braku pracy, natomiast wartości zbyt wysokie prowadzą do kumulacji dużych ilości niedokończonej pracy, co z kolei wydłuża czas ukończenia.[2] Warto zapamiętać i stosować w tym zakresie zasadę, że żaden z członków zespołu nie powinien mieć więcej niż dwa zadania równocześnie ale nie wszyscy członkowie zespołu muszą mieć dwa zadania jednocześnie.[3]
Scrum vs Kanban
Stosowanie
Zobacz też
Linki zewnętrzne
- Scrum-ban, Wikipedia en
Bibliografia
- Corey Ladas: Scrumban - Essays on Kanban Systems for Lean Software Development
- Henrik Kniberg: Kanban vs Scrum. How to make the most of both, Crisp, Version 1.1., 29.06.2009 r.
- Corey Ladas: Scrum-ban, Leansoftwareengineering.com
ostatnia modyfikacja 20 sierpnia 2016 r.