Agile 2.0, czyli współpraca zdefiniowana na nowo

Paweł Huryn

Agile 2.0, czyli współpraca zdefiniowana na nowo
Maj 6, 2019 Paweł Huryn
Agile 2.0, czyli współpraca zdefiniowana na nowo

Według badania Project Management Institute z 2018 roku, metodyki zwinne lub hybrydowe stosuje ponad 46% organizacji. Z kolei wg badania Forbes Insights z 2017 roku ponad 92% senior executives uważa, że zwinność jest kluczowa dla sukcesu w biznesie.

Słowa takie jak Agile, SCRUM, Kanban czy XP są modne, cytowane i odmieniane przez wszystkie przypadki. W środowisku jest “hype”. Widać też systematyczny wzrost zainteresowania tematyką. Zainteresowanie “agile” w ujęciu czasowym w ciągu ostatnich 5 lat (na podstawie Google Trends):

Czy naprawdę Agile to rozwiązanie bez wad? A jeśli nie, to na co powinien uważać Zamawiający?

Uporządkujmy fakty. Agile to ogólny manifest z 2001 roku, dotyczący zasad wytwarzania oprogramowania. Metodyki takie jak SCRUM, Kanban czy XP to konkretne implementacje tego manifestu. Obecnie stosuje się je uniwersalnie, zarówno w IT, jak i w biznesie.

Zwolennicy Agile słusznie wskazują, że otoczenie biznesowe przedsiębiorstw nieustannie się zmienia. Aby pozostać konkurencyjnym trzeba elastycznie reagować na zmiany, pojawiające się wyzwania i szanse. Konieczne jest szybkie osiąganie rezultatów w produktywny, efektywny kosztowo sposób.

Dużym błędem jest jednak moim zdaniem utożsamianie pojęć “zwinność organizacji” i “zwinne prowadzenie projektów w organizacji”. W dalszej części artykułu skupię się jednak wyłącznie na wykorzystaniu Agile zgodnie z jego pierwotną definicją, czyli do tworzenia oprogramowania, oraz na wadach i zaletach takiego podejścia.

Agile w tworzeniu oprogramowania

Dlaczego warto działać zwinnie? Agile to doskonała odpowiedź na wady tradycyjnego, ciężkiego modelu kaskadowego, w którym wszystkie detale należy szczegółowo zaplanować i opisać przed przystąpieniem do realizacji. Weźmy na przykład projekt wyjazdu na wakacje. Wiemy, gdzie chcemy jechać. Rezerwujemy przelot i  hotel. Określamy budżet na posiłki i miejsca, które planujemy zobaczyć. Czy ktokolwiek planuje jednak każdy posiłek, każdą atrakcję czy zakupioną pocztówkę? No właśnie, nie wszystko można z góry określić.

Szczegółowe planowanie w projektach IT okazuje się jeszcze trudniejsze, bo mamy do czynienia z kwestiami z pogranicza biznesu i technologii, gdzie nie każdy mówi tym samym językiem. Co więcej, bardzo często zdarza się, że wizje, cele i wymagania poszczególnych interesariuszy znacznie się od siebie różnią. Wydłuża to czas realizacji i sprawia, że zarządzanie zmianą w projektach typu “waterfall” przy określonym budżecie i harmonogramie bywa sporym wyzwaniem.

Właśnie dlatego podejście Agile jest niezastąpione w sytuacji zmieniających się wymagań. Zmiany nie tylko są akceptowane, ale wręcz uznawane za nieodłączny element procesu wytwórczego. Stawia się na bliską współpracę i dobrą komunikację, zamiast tworzenia zbędnych dokumentów i długofalowych planów. SCRUM zakłada pracę w krótkich cyklach wytwórczych, w których implementujemy funkcje ważne w danym momencie, oraz częste dostarczanie działającego oprogramowania. Ma to zapewnić zadowolenie Klienta i sukces projektu.

Na czym więc polega problem?

Wady podejścia Time & Material

Upraszczając, trudno jechać na wakacje rezerwując promocyjny przelot i hotel na pierwsze 3 dni, bez określonego budżetu, planu i bez rezerwacji biletu powrotnego. Czy ktokolwiek z nas zdecydowałby się na taką podróż?

Agile oznacza w praktyce podejście „Time & Material”, czyli w uproszczeniu: płacenie na bieżąco. Najważniejsze wady tego tradycyjnego podejścia to w mojej ocenie:

  • Jednostronne ryzyko – W tradycyjnym podejściu Agile ryzykuje tylko Klient. Rozwiązanie jest idealne dla dostawcy usług, który co miesiąc wystawia fakturę za przepracowane godziny.
  • Przerzucenie odpowiedzialności – To na Kliencie spoczywa obowiązek priorytetyzacji wymagań, koordynacji pracy zespołu, zarządzania ryzykiem, godzenia interesariuszy oraz ciągłej weryfikacji uzasadnienia biznesowego. Ponieważ zwykle nie posiada on specjalistycznej wiedzy i doświadczenia, jest to zadanie niezwykle trudne i dość mało efektywne.
  • Zbędne koszty – Bez wizji całości, ostatecznego kształtu oprogramowania Klient narażony jest na koszty, których w innym przypadku mógłby uniknąć. Istnieje ryzyko zapętlenia się w niekończącym się cyklu tworzenia, zmiany koncepcji i założeń i modyfikowania programu, co wymaga nakładów finansowych.
  • Niedookreślony harmonogram – Zespół developerów pracuje “optymalnie” i “zwinnie”, regularnie dostarczając działające oprogramowanie, jednakże z racji braku założeń odnośnie do funkcjonalności oprogramowania, proces ten może trwać nieustannie. Pojawia się zatem pytanie kiedy oprogramowanie uzyska ostateczny kształt? Kiedy zacznie przynosić oczekiwaną wartość biznesową?

Można działać lepiej, co potwierdzają statystyki. Według raportu PMI (przywołanego wcześniej) organizacje wdrażające formalne zarządzanie projektami lepiej realizują cele, mieszcząc się w budżecie i zaplanowanym czasie.

Agile 2.0

Firmy coraz częściej poszukują alternatyw, łączących zalety klasycznych  i zwinnych metodyk. A jak podchodzimy do tworzenia oprogramowania w APN Promise?

Proponujemy naszym Klientom odpowiedzialne, autorskie podejście Agile 2.0, w którym dobrze znaną metodykę Agile uzupełniliśmy o kilka kluczowych założeń:

  • Planujemy. Przed przystąpieniem do pracy upewniamy się, że dobrze rozumiemy potrzeby i problemy Klienta. Aktywnie doradzamy i porównujemy dostępne opcje. Angażujemy przy tym ekspertów z wiedzą dziedzinową, np. Eksperta ds. energetyki.
  • W wyniku spotkań i wspólnej pracy powstaje ogólna analiza adresująca wszystkie kluczowe wymagania, które wynikają bezpośrednio z uzasadnienia biznesowego. Zawiera ona również listę założeń pozwalających na określenie ich pracochłonności.
  • Dla ustalonego w procesie analitycznym zakresu przedstawiamy wiążącą wycenę. Wymagania dzielimy na etapy i podajemy harmonogram. Zobowiązujemy się do wykonania wszystkich uszczegółowień i poprawek w ramach zwinnej implementacji poszczególnych etapów. Jeśli jednak na którymś etapie prac potrzebna okaże się znacząca zmiana lub wprowadzenie nowej, nieuwzględnionej wcześniej funkcjonalności, zrealizujemy ją po zmodyfikowaniu pierwotnego planu i uzyskaniu jego akceptacji. Dzięki temu Klient w każdej chwili kontroluje budżet i termin realizacji prac.
  • Tak jak w SCRUM, wdrożenie podzielimy na 2-4 tygodniowe sprinty. Po każdym dostarczymy Klientowi działające rozwiązanie. Nasi specjaliści UX / UI dbają o nowoczesny wygląd i łatwość obsługi aplikacji. Oprogramowanie musi spełniać Twoje wymagania, dlatego jesteśmy otwarci na opinie i komentarze w każdym momencie trwania projektu.

Frontem do Klienta

Uważam, że tradycyjny T&M nie jest korzystny dla każdego i działa dlatego, że rynek jest niezwykle chłonny. Firmy proponujące taki model pracy pełnią de facto funkcję agencji pracy tymczasowej i użyczają swoich pracowników w zamian za określoną dniówkę. Nie wpasowuje się to w naszą filozofię odpowiedzialności i budowania realnej wartości, realnej korzyści dla Klienta. Naszym celem jest wsparcie Klientów w całym procesie, począwszy od analizy, aż po wsparcie powdrożeniowe.

Na rynku zauważamy coraz większą świadomość. W rozmowie ze mną jeden z dyrektorów dużej instytucji finansowej podsumował niedawno: „Właśnie po to biorę firmę IT, aby kompleksowo ogarnęła projekt”.

Agile 2.0 to zdecydowanie korzystniejsze, odpowiedzialne podejście. To dla nas nie tylko sposób wytwarzania oprogramowania, ale także przejaw filozofii dbania o Klienta. Postawiliśmy na partnerskie relacje i wsparcie. Duże organizacje zaufały nam i powierzyły kierowanie swoimi projektami, ponieważ bierzemy pełną odpowiedzialność za ustalony zakres, jakość i terminową realizację prac w modelu zwinnym. Czujemy się odpowiedzialni za sukces projektu.

Zapraszamy do kontaktu

Odwiedź naszą stronę, aby dowiedzieć się więcej lub umówić się na rozmowę:
https://www.promise.pl/oferta/obszary-biznesowe/software/

Podziel się

Autor: Paweł Huryn

Paweł Huryn

Paweł Huryn

Ostatnie artykuły autora

Agile 2.0, czyli współpraca zdefiniowana na nowo

Agile 2.0, czyli współpraca zdefiniowana na nowo

Według badania Project Management Institute z 2018 roku, metodyki zwinne lub hybrydowe stosuje ponad 46% organizacji. Czy tradycyjne podejście Agile wystarczy? Paweł Huryn wyjaśnia, dlaczego my preferujemy ulepszone podejście Agile 2.0.

Skontaktuj się z autorem

 

Administratorem danych gromadzonych z wykorzystaniem formularza jest A.P.N. Promise S.A. Podane przez Ciebie dane będą przetwarzane w zakresie niezbędnym do podjęcia kontaktu lub realizacji określonego żądania zgodnie z art. 6 ust. 1 lit. b RODO przez okres niezbędny dla realizacji Twojego zgłoszenia. Wszelkie informacje w zakresie przetwarzania podanych przez Ciebie w formularzu danych oraz posiadanych uprawnieniach znajdziesz w Polityce prywatności. Kliknij i dowiedz się więcej jeżeli informacje podane powyżej nie są dostatecznie jasne!