Prezentacja agile telco
0 likes665 views
Zarządzanie Agile w projekcie uruchomienia operatora MVNO
Prezentacja agile telco
- 1. Agile a projekty Telco Lessons learned
- 2. ale o co chodzi ? Zarządzanie Agile w projekcie uruchomienia operatora MVNO GaduAIR Od Stycznia 2008 do Maja 2009
- 3. kim jesteśmy ? Grzegorz Machniewski Dawid Mielnik • Do lipca 2010 dział Telco • Do lipca 2010 dział Telco w GG (dyrektor IT) w GG (dyrektor) • Przed GG IBM, Outbox • Przed GG Citi, DRSA • Po GG Voiceware S.J., • Po GG Voiceware S.J., Moberia sp. Z o.o., XEO Moberia sp. Z o.o. Games sp. Z o.o.
- 4. usługi internetowe a usługi telekomunikacyjne typowe..
- 5. software to niewielka część • 5 zespołów, ok 15 osób • Zespoły software • BSS, VAS • Zespoły nie software • Core Network, VoIP, Operations
- 6. zewnętrzni dostawcy i partnerzy • Huawei • AMG • Polkomtel • Gemalto • Arvato • Call Center Poland • Kolporter, Billbird, Euronet, Polski Tytoń, Sprint, ... (dystrybucja) • Allegro, Effortel
- 7. wewnętrzne działy • "klienci" • "dostawcy" • Business • Admini • Marketing • Server dev • Sprzedaż • Web dev • Zarząd • GG klient dev • Księgowość • Mail dev • Bezpieka • QA
- 8. SCRUM się nie sprawdzał
- 9. 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
- 10. 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
- 11. SCRUM się nie sprawdzał Inne problemy z dostawcami • Komunikacja • Długie czasy rozwiązywania niektórych problemów • Rotacja zespołu dostawcy
- 12. 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
- 13. SCRUM się nie sprawdzał Zmienne wymagania wewnętrznych klientow i biznesu
- 14. SCRUM się nie sprawdzał Dużo nieprzewidywalnych pożarów które rozwalały sprint
- 15. SCRUM się nie sprawdzał (dodatkowa refleksja) Metodologia Agilowa to mniej papierologji i formalności a to niestety działa na naszą niekorzyść z dostawcami
- 16. ... 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
- 17. 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
- 18. ... 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
- 19. 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
- 20. Task board Telco
- 21. Task board Devel
- 23. 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
- 24. Pytania?
- 25. Dziękujemy.