Efektywne dostarczenie oprogramowania?

Dzisiaj jest deadline. Zdalny zespół programistyczny pracował kilka tygodni nad oprogramowaniem dla Ciebie. Otrzymujesz długo wyczekiwany dostęp do systemu.

Sprawdzasz i nie jesteś zadowolony z otrzymanych rezultatów. 
Wszystko, co było potrzebne, aby nie mieć tego problemu to zespół z doświadczeniem w technologii i pracujący w SCRUM.

Co to jest SCRUM

Wikipedia definiuje SCRUM jako iteracyjne i przyrostowe ramy postępowania. Jest to podejście stosowane w wielu firmach do budowania oprogramowania. Pełna definicja jest tutaj [https://pl.wikipedia.org/wiki/Scrum]

SCRUM rozwiązuje większość problemów pojawiających się przy tworzeniu oprogramowania

To jest moja opinia i wiele osób się z nią zgadza. Projekty komercyjne realizuję od 2008 roku. Na początku jako programista. Obecnie nadzoruję projekty na wysokim poziomie. 

Wprowadzenie metody SCRUM w Droptica rozwiązuje większość problemów. Jakich konkretnie?

Nasi programiści Drupala pracując w zespołach realizują złożone projekty, a tym samym napotykają na problemy.

Najważniejsze z nich to:

• Klient nie był regularnie informowany o postępie prac - klient nie był zadowolony. Sprinty, review, backlog refinement - to wszystko wymusza stały kontakt z klientem
• Zadania nie były przemyślane przed ich rozpoczęciem, przez to długo trwały - klient nie był zadowolony. Backlog refinement oraz planowanie - te zdarzenia zapewniają, że zespół musi się zastanowić nad realizacją każdego z zadań dokładnie.

SCRUM oszczędza pieniądze

Można zadać pytanie: w jaki sposób, skoro nie znamy dokładnego czasu i kosztu realizacji projektu na jego początku? Odpowiedź jest zawarta w poprzednim akapicie: 

• Regularne spotkania z klientem (Product Ownerem) wymuszają na nim zastanowienie się, jakie rzeczywiście zadania są potrzebne, a jakie można odrzucić.
• Analiza zadań przez zespół wspólnie z PO często pozwala na wymyślenie lepszych sposobów ich realizacji albo ich odrzucenia.

SCRUM często jest nazywany sztuką maksymalizacji niewykonanej pracy. Maksymalizujemy odrzucanie zbędnych zadań z punktu widzenia naszego biznesu. Robimy tylko to, co przynosi konkretną wartość dla systemu. Reszta do kosza.

Po co tyle spotkań?

Planowanie sprintu, daily scrum, retro, review, backlog refinement. Lista spotkań jest długa. Nie ma wątpliwości, że zajmują czas. Klient często oczekuje, że będzie płacił za programowanie, a nie za rozmowy i spotkania. 

Kiedyś myślałem tak samo. Jednak po testowym wdrożeniu SCRUM na jednym z projektów zmieniłem zdanie. Teraz wszystkie nasze projekty, dla klientów i wewnętrzne, chcę realizować w SCRUM. Widzę w tym dużą oszczędność czasu i pieniędzy. To samo potwierdzają klienci, z którymi pracujemy w SCRUM, a wcześniej nie mieliśmy konkretnego sposobu pracy.

Abraham Lincoln powiedział kiedyś “Gdybym miał osiem godzin na ścięcie drzewa, spędziłbym sześć na ostrzeniu siekiery”. 

Spotkania gwarantują dobre przemyślenie zadań, trzymanie się wspólnego kierunku i dążenie to tych samych celów biznesowych. Zdecydowanie warto.

Ile to będzie trwało i kosztowało?

Każdy klient zadaje to pytanie na początku. To jest trudne pytanie. Prędkość każdego z programistów jest inna, są różne warunki pracy, święta, urlopy, zmieniają się wymagania (od klienta, wymagania prawne, itp). Dłuższy projekt to też często zmieniająca się specyfikacja. Takie zmiany zmieniają koszt i czas. 

Story Points to rozwiązanie problemu. To bardzo dobre narzędzie do szacowania ilości zadań możliwych do realizacji w sprincie (etapie). Już po 2-4 sprintach widać średnią prędkość zespołu. Po takim czasie zespół zna dobrze projekt, zna dobrze klienta i plany na przyszłość. Zespół może z bardzo dużą dokładnością oszacować oczekujące w Backlogu zadania. Product Owner znając prędkość zespołu może to przeliczyć na ilość sprintów i całkowity koszt. 

W porównaniu do tworzenia szczegółowej specyfikacji na początku projektu, takie podejście daje lepsze efekty oszacowania. 

SCRUM nie wystarczy, jeśli zespół nie ma doświadczenia w technologii

Jeśli zespół będzie pracował w SCRUM, ale nie będzie znał się na technologii to nie będzie w stanie dostarczyć dobrej jakości oprogramowania w sensownym czasie. Dopiero połączenie SCRUM i zespołu doświadczonego w danej technologii daje bardzo znaczące efekty. Z takiego połączenia klient na pewno będzie zadowolony. 

Dlaczego zdalny zespół jest lepszy?

Czym się różni zdalny zespół od lokalnego zespołu? Właściwie tylko lokalizacją. Jeśli można mieć zespół lokalnie, to warto skorzystać z takiej opcji. Będzie wygodniej. 

Jednak na dzisiejszym rynku IT ciężko skompletować 2, 3 lub więcej specjalistów w krótkim czasie na większy projekt. Dlatego zastanów się nad zdalnym zespołem SCRUM. Zespołem, który już ma doświadczenie w pracy ze zdalnym klientem. Rozszerzając opcje do całego świata mamy większe możliwości wyboru.

Jak mogę monitorować co robi zespół oddalony o tysiące kilometrów?

SCRUM ma na to sposób: Sprint Burndown Chart. Jest to wykres, który jest codziennie aktualizowany. Widać regularnie tempo rozwoju projektu. Widać czy zespół zrealizuje plan sprintu. Jest to najlepsze narzędzie do monitorowania postępu prac. W Waterfall zazwyczaj o opóźnieniach dowiadujemy się na koniec większego etapu. W SCRUM, klient każdego dnia widzi jakie postępy zrobił zespół. Jest pewny, że zespół pracuje i dostarcza kolejne części oprogramowania. 

Jak się komunikować z zespołem?

W Droptica mamy na to 3 sposoby:
- Jira - to główny system do komunikacji, tutaj mamy wszystkie User Stories i zadania
- Slack - do krótkich pytań tekstowych, używany właściwie codziennie
- Skype/Google Hangouts/Zoom - do wideo rozmów z udostępnianiem ekranu

Te trzy formy komunikacji w 100% zapewniają bardzo dobrą komunikację między zespołem i Product Ownerem. 

Jeśli jest możliwość, to raz na jakiś czas zespół developerski spotyka się na żywo z Product Ownerem w naszym biurze lub w biurze klienta. Nasze biura są blisko lotniska, chętnie zapraszamy do nich klientów. 

Jak sprawdzić czy zdalny zespół SCRUM się sprawdzi w moim przypadku?

Jeśli masz projekt dla minimum 2-3 osób na kilka sprintów, to dobrze poprowadzony SCRUM dostarczy Ci bardzo dobrych efektów.

Jeśli nie jesteś pewny czy SCRUM się sprawdzi to przetestuj go. Zamów 2-3 sprinty i zobacz jakie otrzymasz efekty. Jest to mały koszt w skali wielomiesięcznych projektów, a takie podejście dostarczy jednoznacznej odpowiedzi na pytanie czy warto pracować w SCRUM.

Jeśli nadal masz wątpliwości odnośnie zdalnego zespołu SCRUM chętnie odpowiem na pytania i podzielę się doświadczeniami. Pisz śmiało na [email protected] lub zadaj pytanie w komentarzu.