Chapters
Agile development oprogramowania jest trochę jak podróż dookoła świata z plecakiem. Pozwól, że wyjaśnię.
Rozwój oprogramowania na zamówienie jest dość skomplikowanym procesem, całkowicie różnym od jakiegokolwiek innego doświadczenia w naszym codziennym życiu.
Podczas moich interakcji z potencjalnymi klientami często rozmawiam z osobami, które mają niesamowite pomysły na swoją pierwszą startup, ale nie mają wcześniejszego doświadczenia w rozwoju oprogramowania. Jeśli jesteś jedną z nich - ten artykuł jest dla Ciebie.
Jak więc wyjaśniam Agile development oprogramowania w stosunkowo prosty sposób?
Za pomocą analogii.
W tym artykule dowiesz się kilku rzeczy na temat Agile w rozwoju oprogramowania:
- jakie są podobieństwa między Agile w rozwoju oprogramowania a bardzo długą wyprawą z plecakiem,
- dlaczego szacunki są formą wykształconego przypuszczenia eksperta, a nie stałym zakresem i wyceną kosztów,
- dlaczego niemożliwe jest przewidzenie i zaplanowanie wszystkiego z góry (i dlaczego tak naprawdę nie chciałbyś tego robić)
- jaka jest alternatywna metoda (Waterfall)
- dlaczego nie możesz ustalić stałego kosztu projektu Agile
Co ma wspólnego podróż dookoła świata z Agile software development?
W tym przypadku myślę o takim rodzaju podróży, kiedy zabierasz plecak, aby odwiedzić kilka krajów na półkuli i chcesz zobaczyć jak najwięcej, a może nawet o podróży backpackerskiej dookoła globu.
Wypiszmy kilka głównych podobieństw między podróżą a tworzeniem twojego pierwszego produktu:
- Obie są dość różne od naszych zwykłych zakupów lub aktywności
- To raczej kosztowne sytuacje, które zdarzają się raz w życiu, i chcesz z nich wyciągnąć jak najwięcej i zrobić to dobrze za pierwszym razem
- Obie są procesami długoterminowymi, a nie pojedynczymi zakupami
- Obie oznaczają robienie czegoś unikalnego, czego prawdopodobnie nikt wcześniej nie zrobił
- W obu scenariuszach niemożliwe jest poznanie lub zaplanowanie wszystkiego z góry
- Musisz być przygotowany na akceptację zmian i dostosowywanie swoich planów w trakcie
Jedna uwaga w mojej metaforze: możesz zaplanować i wyruszyć w podróż sam, ale nie możesz stworzyć swojego oprogramowania samodzielnie. Musisz zrekrutować własny zespół projektowy i deweloperski lub uzyskać pomoc zewnętrzną od agencji zajmującej się rozwojem oprogramowania.
Załóżmy więc dla przykładu, że nie możesz (lub po prostu nie chcesz) zaplanować podróży samodzielnie i potrzebujesz zewnętrznej pomocy. Dlatego decydujesz się na współpracę z agencją turystyczną specjalizującą się w w pełni dostosowanych doświadczeniach backpackerskich. Pomogą Ci nie tylko w stworzeniu planu podróży, ale także zajmą się wszystkimi formalnościami, rezerwacjami i wydatkami, podczas gdy Ty będziesz podróżować, abyś mógł naprawdę skupić się na maksymalnym wykorzystaniu swojej podróży.
Planowanie podróży z agencją
Zanurzmy się głębiej - jak to właściwie będzie wyglądać?
Możemy sobie wyobrazić kilka spotkań z agencją, aby ustalić Twoje oczekiwania, budżet, główne priorytety, oczekiwane standardy zakwaterowania, kraje i miejsca, które chcesz odwiedzić, oraz korzyści, które są dla Ciebie ważne, aby agencja mogła zrozumieć Twoje potrzeby i na tej podstawie zaproponować najlepsze doświadczenie dla Ciebie.
Podobnie, rozmawiając z partnerem w zakresie rozwoju oprogramowania, weźmiesz udział w kilku spotkaniach (może w Warsztacie Projektowania Produktu), gdzie agencja omówi Twoje pomysły, oczekiwania, potrzeby i cele oraz pomoże dostosować plany do Twojego budżetu.
Agencja przedstawi Ci plan lub przegląd tego, co się wydarzy, oferując różne możliwości i sugerując kierunki. W tym momencie jest to szkic z oszacowanym czasem i kosztami oraz informacjami na wysokim poziomie.
W środowisku rozwoju oprogramowania, to odpowiadałoby wstępnej wycenie. Agencja szacuje elementy i funkcje opisanego zastosowania, opierając się na informacjach (możliwości i ograniczenia biznesowe oraz technologiczne) dostarczonych przez klienta w danym momencie, najlepiej jak potrafi.
Przygotowanie a gotowość do dostosowania się do zmieniających się okoliczności
Załóżmy, że Twój pierwotny plan podróży zakładał wizytę w Japonii po zakończeniu wycieczki po Tajlandii. Ale okazuje się, że utknąłeś w Bangkoku, ponieważ wszystkie loty do Tokio zostały odwołane na kilka następnych dni. Musisz dostosować swoje plany.
Jednak impuls do zmiany nie musi być koniecznie zewnętrzny. Może tak bardzo spodobał Ci się Bangkok, że po prostu chcesz tam zostać dłużej. A może wręcz przeciwnie - wolałbyś wykreślić niektóre punkty z listy Tajlandii, aby spędzić więcej czasu w Tokio? A może po rozmowie z lokalnymi mieszkańcami zdałeś sobie sprawę, że w pobliżu jest miejsce, które musisz zobaczyć, o którym wcześniej nie słyszałeś, i chcesz dodać je do swojej listy?
W każdym z tych przykładów - to nie był Twój początkowy plan, ale sytuacja się zmieniła i musisz na nią zareagować. Wszystko, co musisz zrobić, to poinformować agencję, aby mogła dostosować plany na podstawie Twojej opinii i szybko zająć się wszystkim za Ciebie.
To samo może się zdarzyć w trakcie rozwoju Twojego projektu. Priorytety niektórych funkcji mogą się zmienić; możesz dodać nowe funkcje lub uczynić te pierwotnie zaplanowane bardziej złożonymi. Sytuacja na rynku może się zmienić i zmusić Cię do dostosowania swojego produktu do nowych regulacji lub preferencji użytkowników, lub po prostu coś przeoczyłeś.
Os estimate, które ustaliłeś na początku, to ogólny plan działania. Daje ogólne zrozumienie zakresu, czasu i kosztów, ale pozostaje elastyczny.
Jeśli cokolwiek się zmieni, możesz działać i dostosować harmonogram oraz koszty i reagować odpowiednio. Nie jesteś zmuszony do realizacji sztywnego planu stworzonego w innych okolicznościach. Mówiąc prościej, pozwala Ci podejmować najlepsze decyzje na bieżąco, nie wiążąc Cię nierealistycznym sztywnym planem od samego początku.
Mając to na uwadze, nie możemy zapomnieć, że naturalną konsekwencją jest to, że takie zmiany wpływają również na czas i koszty. Nie możesz oczekiwać, że zostaniesz kilka dni dłużej w tym samym hotelu, nie wydłużając długości wycieczki i nie zwiększając swojego budżetu. Musisz albo zwiększyć budżet i harmonogram, albo zrezygnować z niektórych innych punktów na swojej liście, aby to zrekompensować. To dokładnie ta sama historia z rozwojem oprogramowania.
Jakie są alternatywy? Kilka słów o podejściu Waterfall
Wyobraźmy sobie, że nie czujesz się komfortowo z niepewnością w planie i kosztach. Chcesz mieć bardzo ustalony plan za stałą cenę. Co wtedy robisz?
Zamiast zaczynać od ogólnego zarysu i pozostawać elastycznym przez całą podróż, musisz zaplanować wszystko z wyprzedzeniem, aż do najmniejszych szczegółów i trzymać się tego, niezależnie od tego, co się wydarzy.
Oznacza to planowanie na miesiące do przodu, wszystkie szczegóły zakwaterowania, bilety na autobusy/pociągi, jakie atrakcje zobaczysz, o której godzinie i jak długo. Nawet co będziesz miał na śniadanie, lunch i kolację. Każdy pojedynczy dzień i aktywność są zaplanowane i ustalone co do godziny, miesiące przed faktyczną podróżą, zapisane w umowie, bez możliwości zmiany. Spróbuj to sobie wyobrazić.
To (w zasadzie) jest podejście Waterfall i stała cena w rozwoju oprogramowania. Jest bardzo mało miejsca na dostosowania, szczególnie w czasie rzeczywistym. Musisz zaplanować wszystko na samym początku, a potem trzymać się tego ściśle, niezależnie od zmieniającego się otoczenia czy sytuacji wokół Ciebie i Twojego produktu.
Nie tylko to. W większości przypadków podejście Waterfall okazuje się droższe niż Agile, a są dwa główne powody tego stanu rzeczy.
Pierwszym z nich jest łagodzenie ryzyka. Praca w modelu Waterfall i stałej ceny oznacza, że agencja musi zrekompensować ryzyko, o którym mówiliśmy wcześniej (wewnętrzne i zewnętrzne), aby uniknąć strat finansowych w takim projekcie. To po prostu przekłada się na wyższą cenę, niezależnie od tego, czy zmiany rzeczywiście nastąpią, czy nie oraz w jakim stopniu. Agencja musi uwzględnić wszystkie najgorsze możliwe scenariusze i wycenić je.
Drugim powodem jest dodatkowy nakład pracy i formalności. Nie tylko dokumentacja projektu przed rozpoczęciem projektu jest nieporównywalnie bardziej skomplikowana i rozbudowana, ale także umowa oraz cała dokumentacja i procedury projektowe w trakcie projektu. Każda prośba o zmianę w oryginalnym planie wymaga własnego procesu: oszacowania, opisania i sformalizowania w dokumencie prawnym (np. Aneks do Umowy, Prośba o Zmianę itp.). Wszystkie dodatkowe czynności wykonywane przez agencję mogą wydawać się „darmowe” - mogą nie być wymienione w ofercie ani umowie, mogą być po prostu grzecznie nigdy nie wspomniane. Ale biorąc pod uwagę, że wszystkie one zajmują czas, możesz być pewien, że zostaną uwzględnione przez agencję w ostatecznych kosztach.
Kiedy metoda Waterfall działa?
W projektach software'owych - w niektórych przypadkach, projekty, to podejście wciąż istnieje.
Zwłaszcza dla dużych korporacji i wielkich firm, które mają znacznie większe budżety niż właściciele startupów, sektor rządowy, to podejście czasami działa. Tego typu instytucje zazwyczaj mają również wewnętrzne możliwości (własne wyspecjalizowane zespoły), które posiadają umiejętności, zasoby i czas na przygotowanie obszernej dokumentacji technicznej przed rozpoczęciem projektu.
Najlepsza dokumentacja projektu software'owego w metodzie Waterfall, jaką kiedykolwiek widziałem, miała około 300 stron i dotyczyła tylko części front-endowej aplikacji. Była tak szczegółowa, że zawierała nawet makiety wszystkich ekranów aplikacji z dokładnymi i precyzyjnymi opisami najmniejszych detali (w tym rozmiarów i kolorów przycisków).
To jest całkiem inne niż podejście Agile, gdzie kluczowe są szybkość, efektywność i zwinność. Ale dla organizacji z czasem, zasobami i budżetami na to podejście - to może naprawdę działać.
Ale w pełnej sprawiedliwości, widzimy coraz więcej nawet największych firm decydujących się na wybór Agile w rozwoju oprogramowania ze względu na wszystkie jego korzyści. Osobiście miałem przyjemność współpracować z jedną z firm z Wielkiej Czwórki nad dużym projektem rozwoju oprogramowania w metodzie Agile. To nie jest zaskoczeniem - Agile to preferowany sposób na rozwijanie nowoczesnego oprogramowania z jakiegoś powodu.
Dlaczego więc nie ustalić stałej ceny na projekt Agile?
Osobiście spotkałem się z sytuacjami, w których klient słyszał o wszystkich korzyściach płynących z Agile, ale aby zminimalizować niepewność, oczekiwał, że agencja zaproponuje stałą cenę.
Tak wspaniale to brzmi, tak samo sprzeczne, jak w rzeczywistości jest.
Czy możesz sobie wyobrazić agencję podróży backpackerskich, która zgadza się pokryć wszystkie Twoje koszty, podczas gdy Ty masz absolutną swobodę zmiany, modyfikacji i przedłużania swojej podróży potencjalnie w nieskończoność? To dosłownie sytuacja z nieograniczonym czekiem.
Jeśli zakres może się zmieniać - nie możesz mieć ustalonej ceny. Jeśli chcesz zdefiniować zakres i cenę - odbierasz elastyczność i zwiększasz ogólne koszty.
Innymi słowy, próba zastąpienia wad podejścia Agile korzyściami z przeciwnego podejścia Waterfall byłaby jak próba włączenia i wyłączenia światła jednocześnie. Jeśli możemy pominąć fizykę kwantową w tej dyskusji, mam nadzieję, że zgodzisz się, że to po prostu niemożliwe.
Jak maksymalnie wykorzystać Agile?
Podobnie jak w przypadku doświadczenia z plecakami - zacznij od poznania swojego budżetu, szacowanego czasu i kosztów. Bądź gotowy do dostosowania się i wykorzystaj tę elastyczność na swoją korzyść. Zmieniaj, dostosowuj, dodawaj, usuwaj, zastępuj. Reaguj na bieżąco w zależności od aktualnych potrzeb i sytuacji.
Znajdź agencję, której możesz zaufać. Taką, która od samego początku będzie miała silny nacisk na zrozumienie Twoich potrzeb i celów, poczujesz, że działają na tej samej fali co Ty.
Radziłbym również upewnić się, że agencja, którą wybierzesz, ma silne zdolności w zakresie Agile Project Management. Potrzebujesz kogoś w zespole projektowym, kto pomoże Ci śledzić i zarządzać budżetem oraz monitorować postępy. Innymi słowy - mieć osobę dedykowaną minimalizowaniu ryzyk i wad pracy w Agile, przy jednoczesnym zachowaniu wszystkich korzyści.
Bo, w końcu, Agile wywodzi się z pierwotnego podejścia Waterfall z powodu poważnego problemu, z którym się borykał. I dlatego zdecydowana większość projektów programistycznych dzisiaj realizowana jest metodami Agile. Agile to po prostu najtańszy i najefektywniejszy sposób tworzenia produktów cyfrowych.
Sprawdź także
- Agile: Maksymalizacja wartości biznesowej przy ograniczonym budżecie — W modelu agencji dotyczącego rozwoju oprogramowania, ograniczony budżet nie jest wyrokiem śmierci dla projektu. To bardziej sprawdzian rzeczywistości, który określa, czy projekt jest opłacalny dla klienta.
- Jak wybrać ramy Agile dla swojego projektu? — Nasza starsza menedżerka projektów Agile, Paulina Piechaczek, wyjaśnia, jak ocenić metodę, która najlepiej pasuje do tego, co masz na stole.
Może Ci się również spodobać
Jesteśmy dostępni dla nowych projektów.
