Unikaj tych 4 pułapek Agile: Wskazówki dla początkujących

Poznaj 4 najczęstsze błędy początkujących w Agile, których należy unikać. Oparte na ponad 10-letnim doświadczeniu.

Agile to najefektywniejszy sposób na budowanie innowacji

W porównaniu do innych podejść, w tym jego bezpośredniego przeciwieństwa, Waterfall, Agile pozwala na minimalizację czasu spędzonego na formalnościach i przygotowywaniu pełnej dokumentacji projektu (przed faktycznym rozpoczęciem projektu, co samo w sobie jest bardzo czasochłonnym i kosztownym procesem); a maksymalizuje zasoby wydawane na rzeczywistą pracę.

Tworzona jest prosta mapa drogowa, z uwagą poświęconą kluczowym funkcjom aplikacji. Ponieważ rozwijasz jasną wizję i kręgosłup produktu, można elastycznie podchodzić do mniejszych zadań i nadawać im różne (zmieniające się) priorytety.

Korzyści płynące z Agile były szeroko chwalone i udokumentowane, więc prawdopodobnie już je znasz. Zwiększa satysfakcję klientów, zatrzymanie użytkowników, pozwala budować namacalne wartości z Twojego produktu i zmniejsza ryzyko niepowodzenia dzięki szybszym iteracjom i reakcjom na zmiany w otoczeniu branżowym.

Szybsze iteracje oznaczają gotowość na nieoczekiwane zmiany, które mogą się pojawić.

Tak więc w zasadzie definiujesz, co robić, w miarę postępu, zamiast planować z wyprzedzeniem przez miesiące, próbując przygotować się na rzeczy, na które naprawdę nie można się przygotować (kryzysy, wcześniej wspomniane zmiany rynkowe, bezpośredni konkurenci aktualizujący swoją propozycję wartości lub praktycznie cokolwiek innego, co jest niemożliwe do przewidzenia na początku projektu).

Ale… Agile to nie panaceum na wszystkie problemy związane z rozwojem produktu

Jeśli tak to postrzegasz, mogłeś właśnie wpaść w pierwszą pułapkę i powszechne nieporozumienia zbudowane na hype.

Agile ma swoje wartości i zasady, które, gdy nie są przestrzegane, mogą sprawić, że produkt stanie się fiaskiem, lub przynajmniej znacznie utrudnić proces rozwoju.

W EL Passion pracujemy w Agile od ponad 10 lat, a oto moje dwa grosze na temat tego, na co się przygotować, aby uniknąć błędów początkujących w Agile, które są naprawdę łatwe do popełnienia przez nowicjuszy, ale także bardzo łatwe do wyeliminowania, gdy wiesz, na co się decydujesz.

Pułapka 1: Kiedy Product Owner nie ma czasu, aby być Product Ownerem

Product Owner (PO) jest głównym decydentem w procesie, odpowiedzialnym za przekazywanie wizji produktu zespołowi deweloperskiemu, maksymalizowanie wartości funkcji do opracowania, priorytetyzowanie pozycji w backlogu, aby osiągnąć równowagę między korzyściami dla biznesu a końcowymi użytkownikami.

Trochę jak kapitan statku, on/ona dowodzi, a raczej w tym przypadku: prowadzi załogę, aby pozostała na właściwej drodze. To dość oczywiste, że jeśli kapitan nie ma czasu, aby dowodzić statkiem, sprawy mogą pójść strasznie źle.

Tak, zespoły samoorganizujące się mogą pracować w pewnym stopniu niezależnie, ale priorytety muszą być ustalone, a ktoś musi mieć ostatnie słowo i zdecydować, co zostaje, a co odchodzi.

Na fundamentach udanego produktu cyfrowego stoi zespół, który rozumie wizję.

Brak obecności PO w projekcie wiąże się z kosztownym ryzykiem. Zespół nie ma połączenia z wizją produktu ani perspektywą końcowego użytkownika i może spędzać czas na budowaniu funkcji, które są mniej ważne dla klienta lub projektować je inaczej, niż klient sobie to wyobrażał.

Oba scenariusze są, krótko mówiąc, nie tylko stratą czasu dla wszystkich, ale także bardzo bolesną stratą budżetu.

Rozwiązanie jest, jak zawsze, proste w teorii i znacznie trudniejsze do wdrożenia w praktyce (szczególnie dla osób, które nie są przyzwyczajone do pracy w środowiskach Agile). PO musi upewnić się, że jest w stanie poświęcić około 1–2 godziny dziennie na projekt (może to być nieco więcej w pierwszym tygodniu rozpoczęcia projektu).

Pułapka 2: Nie rozumienie za co się płaci w umowie Time & Materials

Istnieje bardzo powszechne nieporozumienie, że podczas współpracy z firmą zajmującą się rozwojem oprogramowania płaci się za funkcjonalności, które zostaną dostarczone. Ale to nieprawda w środowisku Agile, a często także w umowie Time & Materials.

Istotą umowy Time & Materials jest to, że płacisz za czas zatrudnionego zespołu, tak jak robisz to przy zatrudnianiu pracowników wewnętrznych. Funkcjonalności, które tworzą, są oczywiście namacalnym wynikiem ich pracy, a Ty możesz je widzieć w czasie rzeczywistym w miarę postępu prac. Mimo to, jesteś obciążany kosztami za godziny, a nie za końcowy rezultat.

To nieporozumienie czasami prowadzi do poważnych nieporozumień, a w skrajnych przypadkach może zagrozić projektowi.

Rozwiązanie: bądź świadomy za co naprawdę płacisz i że w każdym przypadku, gdy potrzebujesz więcej czasu zespołu, będzie to czas płatny, nawet jeśli oznacza to pracę nad funkcjami, które zostały ukończone. Możesz również zarezerwować mały bufor w swoim budżecie na ukończone zadania na drobne poprawki i ulepszenia. Jeśli masz oczekiwania dotyczące jakichkolwiek gwarancji, upewnij się, że porozmawiasz ze swoim partnerem tak szybko, jak to możliwe, najlepiej przed rozpoczęciem współpracy, ponieważ może to wymagać zupełnie innej konfiguracji.

Umowa Time and Materials jest w rzeczywistości najefektywniejszym sposobem na płynne mierzenie postępów.

Pułapka 3: opóźnianie wydania aplikacji

Ciągłe dostarczanie leży u podstaw podejścia Agile. Chcesz wprowadzić swoją aplikację na rynek tak szybko, jak to możliwe, nawet z ograniczoną liczbą funkcjonalności, nawet w niedoskonałej formie, aby mieć dobrą podstawę do dalszego rozwoju, ale z aplikacją już dostępną.

Załóżmy, że twój pomysł na produkt jest rozbudowany, a rozwój pełnego zakresu zajmie około 10 miesięcy. Agilowe podejście polegałoby na podzieleniu pracy na mniejsze części, priorytetyzacji funkcji i wydaniu aplikacji wcześniej niż później.

Dlaczego? Z twoją aplikacją już na rynku zyskujesz dostęp do rzeczywistych opinii użytkowników bez konieczności przeprowadzania sesji testów użytkowników i możesz kierować dalszym rozwojem na podstawie tych opinii. Z perspektywy biznesowej możesz zacząć budować swoją przewagę konkurencyjną wcześniej, a oczywiście zaczynasz szybciej kapitalizować swoją inwestycję. Jedna rzecz, o której należy pamiętać:

Rozwój oprogramowania nie jest zakończonym procesem. Raczej jest to ciągłe doskonalenie tego, co już zostało zrobione.

Bezpośrednim ryzykiem zapomnienia o „myśleniu MVP” jest wydłużenie i opóźnienie początkowego wydania aplikacji oraz spalanie budżetu na dopracowywanie wszystkiego do perfekcji. Rzeczywistość pracy z produktami cyfrowymi nauczyła mnie i przypomniała wiele razy, że nie można nauczyć się pływać na zimnej twardej ziemi. Po prostu musisz skoczyć.

Rozwiązanie? Nie komplikuj już skomplikowanego procesu.

Wybierz proste rozwiązanie, a następnie buduj na jego podstawie. Zachowaj myślenie i dyscyplinę, aby wydać aplikację tak szybko, jak to możliwe, nawet jeśli oznacza to pewne kompromisy. Twój partner w rozwoju oprogramowania jest tam, aby doradzić ci w najlepszej technologii, z wszystkimi zaletami i wadami dalszego rozwoju oraz rozszerzania go zgodnie z twoim planem biznesowym.

Jak mówi Pamela Zave: „Celem inżynierii oprogramowania jest kontrolowanie złożoności, a nie jej tworzenie.”

Pułapka 4: Poleganie na początkowej wycenie, podczas gdy zakres projektu ulega znacznym zmianom 🤔

Początkowa wycena jest przygotowywana, aby dać ci ogólne pojęcie o tym, ile czasu i pieniędzy potrzebnych jest do ukończenia projektu.

Jest przygotowywana na podstawie zrozumienia zakresu pracy, które musi być wykonane, przed rozpoczęciem projektu. W EL Passion często ma to miejsce po Warsztacie Projektowania Produktu. Jednak ten zakres pracy, ponownie, może ulegać zmianom podczas rzeczywistego rozwoju.
Nowe funkcje mogą być wymagane, zakres tych pierwotnie omówionych zostanie sprecyzowany lub zmieniony, niektóre funkcje mogą zostać usunięte lub zmienione ich priorytety. Wszystkie te rzeczy wpływają na czas i budżet.

Musisz pamiętać, że zmiana zakresu może oznaczać dwie rzeczy. Albo zmieni się końcowa cena i data zakończenia projektu, albo będziesz musiał wykreślić niektóre elementy początkowej wyceny, zanim budżet się wyczerpie.

Kluczowe jest tutaj uświadomienie sobie, że wszelkie zmiany w projekcie, całkowicie naturalnie, wpływają na całkowity czas rozwoju i cenę.

A rozwiązanie: w miarę postępu projektu i zmian, powinieneś coraz mniej polegać na początkowej wycenie — znacznie lepiej jest przenieść swoje myślenie na bieżące prognozy oparte na wydajności zespołu i pozostałej zaplanowanej pracy. Kiedy tylko myślisz o zmianie — porozmawiaj ze swoim zespołem deweloperskim, jak podejść do potrzebnej zmiany, abyście byli na tej samej stronie, jeśli chodzi o skutki, jakie to przynosi.

Pułapka nie tkwi w Agile, lecz w jego niewłaściwym stosowaniu

Agile zrewolucjonizował sposób, w jaki produkujemy oprogramowanie. Został doceniony, a jego wyniki udokumentowane przez największych w branży. Działa i może zdziałać cuda także dla Twojego produktu. Ale tylko wtedy, gdy jest stosowany z pełnym zaangażowaniem i świadomością, z poszanowaniem jego wartości i zasad.

Pułapki, o których wspomniałem, są powszechne wśród tzw. nowicjuszy Agile, napędzanych modą, ale często niewystarczająco poinformowanych.

Ale teraz, gdy je znasz, co cię powstrzymuje?

Sprawdź także

1. Najczęstsze błędy, których należy unikać podczas tworzenia aplikacji aby zobaczyć, co robić, a czego nie robić podczas tworzenia aplikacji
2. Kiedy zatrudnić agencję do rozwoju oprogramowania kilka pytań, które warto zadać sobie, gdy nie jesteś pewien, czy outsourcing IT to właściwy wybór