Prezentacja agile telco

Preview:

DESCRIPTION

Zarządzanie Agile w projekcie uruchomienia operatora MVNO

Citation preview

Lessons learned

Agile a projekty Telco

Zarządzanie Agile w projekcie uruchomienia operatora MVNO

GaduAIR

Od Stycznia 2008 do Maja 2009

ale o co chodzi ?

kim jesteśmy ?Grzegorz Machniewski

• Do lipca 2010 dział Telco w GG (dyrektor IT)

• Przed GG IBM, Outbox

• Po GG Voiceware S.J., Moberia sp. Z o.o., XEO Games sp. Z o.o.

Dawid Mielnik

• Do lipca 2010 dział Telco w GG (dyrektor)

• Przed GG Citi, DRSA

• Po GG Voiceware S.J., Moberia sp. Z o.o.

usługi internetowe a usługi telekomunikacyjne

typowe..

software to niewielka część

• 5 zespołów, ok 15 osób

• Zespoły software

• BSS, VAS

• Zespoły nie software

• Core Network, VoIP, Operations

zewnętrzni dostawcy i partnerzy

• Huawei

• AMG

• Polkomtel

• Gemalto

• Arvato

• Call Center Poland

• Kolporter, Billbird, Euronet, Polski Tytoń, Sprint, ... (dystrybucja)

• Allegro, Effortel

wewnętrzne działy • "klienci"

• Business

• Marketing

• Sprzedaż

• Zarząd

• Księgowość

• Bezpieka

• "dostawcy"

• Admini

• Server dev

• Web dev

• GG klient dev

• Mail dev

• QA

SCRUM się nie sprawdzał

Planowanie sprintow wyzwaniem

• organizacyjne - 5 zespołów o skrajnie różnych taskach

• określenie zakresu który był by realizowalny przy tak wielu zmiennych, zależnosciach nie będących po kontrolą zespołów

SCRUM się nie sprawdzał

Problemy z odbiorami od zewnętrznych dostawców• Terminy - częste obsówy

• Funkcjonalność - nie działa lub działa nie zgodnie z zamówieniem, albo działa bardzo niestabilnie

SCRUM się nie sprawdzał

Inne problemy z dostawcami• Komunikacja

• Długie czasy rozwiązywania niektórych problemów

• Rotacja zespołu dostawcy

SCRUM się nie sprawdzał

Problemy z terminami od wewnętrznych dostawców

• Konieczność wpasowania się w inne harmonogramy nie do końca spójne z naszymi

• Walka o kompromisy i nadawanie wyższych priorytetow dla naszych taskow, a nastepnie ich egzekwowanie

SCRUM się nie sprawdzał

Zmienne wymagania wewnętrznych klientow i

biznesu

SCRUM się nie sprawdzał

Dużo nieprzewidywalnych pożarów które rozwalały sprint

SCRUM się nie sprawdzał

(dodatkowa refleksja)

Metodologia Agilowa to mniej papierologji i formalności

a to niestety działa na naszą niekorzyść z dostawcami

SCRUM się nie sprawdzał

... czego finałem było:• Planowania sprintów były długotrwałe i w nudne dla

wiekszości osób (analogicznie z retrospekcją)

• Żadnego sprintu nie udało sie zamknąć w czasie, a zdażały się takie w których żaden backlog nie został zrealizowany z uwagi na nieprzewidziane rzeczy

• Frustracja u nas, w zespołach i u naszych klientów wewnętrznych - napięte stosunki z dostawcami

• Zawalane terminy

Postanowiliśmy coś z tym zrobić ...

Krok 1• Skasowaliśmy ogólne planowania na korzyść szybkich planowań w

indywidualnych zespołach

• Każdy zespół mial indywidualny backlog i sprint

• Rozluźniliśmy trochę pojęcie sprintu i wszystkego co się z tym wiąże

• Zaczęliśmy codziennie priorytetyzowac zadania zgodnie z tym co sie pojawialo

• Zaczęliśmy definiować nowe stany dla taksów które czekały na coś niezaleznego od zespołu

... Jak się pózniej okazało zmieżaliśmy w stronę ScrumBana• Przełomowe było 1 spotkanie Agile Warsaw

poświęcone Scrum vs. Kanban

• Okazuje się że to jest narzędzie którego potrzebujemy

• Zauważyliśmy że niektóre praktyki naturalnie sami wcześniej zaczęliśmy stosować

• Szkoda ze tak późno się o tym dowiedzieliśmy

SrumBan dużo bardziej się sprawdzał

Krok 2 - przejście na ScrumBana• Zlikwidowaliśmy sprinty i ich planowania, na korzyść

planowania, estymacji i priorytetyzacji ad-hoc - codziennie

• Narzucenie limitów na ilość tasków w statusie WIP na osobę

• Wywłaszczenia / najwyższy priorytet dla fackupów i błędów ponad zwykłe taski

• Rearanżacja zespołów - 3 zespoły: devel, telco i operacje

• Indywidylne statusy tasków dla każdego zespołu

Task board Telco

Task board Devel

Task board Operacje

ScrumBan - obserwacje• Mieliśmy przyjemność pracować w nowej aranżacji przez 2

miesiące

• Ewidetnie zmniejszył sie poziom frustracji związany z samym procesem

• Widać było ewidentny wzrost produktywności i jakości w pracy zespołów

• Skrócił się czas od zgłoszenia do realizacji jakiegoś tematu przez dział

• ScrumBan nie rozwiązał wszystkich naszych problemów, ale większość związanych z procesem, zwiększajac komfort pracy

Pytania?

Dziękujemy.

Recommended