Scrumban Przekierowano ze strony: Scrum-ban ang. Scrum-ban

W metodyce Scrumban bardzo duże znaczenie ma wizualizacja przepływu pracy, która zapewnia bieżący dostęp do informacji o projekcie wszystkim członkom zespołu. Charakterystyczny jest jej "demokratyczny" charakter, w odróżnieniu od narzędzi zarządczych wykorzystywanych w formalnych metodykach zarządzania projektami, gdzie "właścicielem" informacji jest Kierownik projektu.

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]

Główne różnice pomiędzy Scrumem a Kanbanem biorą się z faktu, że w Scrumie praca jest podzielona na sprinty (ang. sprints), które mają ściśle określony czasu trwania, podczas gdy w Kanbanie przepływ pracy jest ciągły. Jest to widoczne w tabelach etapów pracy, które w Scrumie są usuwane po każdym sprincie. W Kanbanie wszystkie zadania są zaznaczane na tej samej tabeli. Scrum koncertuje się na zespołach ze złożonym know-how, natomiast Kanban tworzy wyspecjalizowane, funkcjonalne zespoły.^[4]

Jako że Scrumban jest nowym modelem rozwoju oprogramowania, nie ma wielu przypadków zastosowania, które mogłyby posłużyć za referencje. Z drugiej strony Kanban jest stosowany przez takie firmy jak Microsoft czy Corbis.^[5]