„Software as a journey” – wyprawa po dobre oprogramowanie

„Software as a journey” – wyprawa po dobre oprogramowanie

Powiedzmy to otwarcie i szczerze. Tworzenie oprogramowania nie jest łatwe.

Potwierdza to rzeczywistość projektowa. Jak podają dane, najbardziej rzetelnego badania skuteczności projektów The Standish Group International Inc. – Chaos Report, tylko co piąty projekt IT kończy się w planowanym czasie, budżecie i zakresie. Pozostałe, albo w ogóle się nie udają, albo napotykają trudności i przekroczenia.

Dlaczego tak się dzieje? Czy można to zmienić i podnieść swoje szanse na sukces?

My wierzymy, że tak, a powodzenie projektu zależy od podejścia do jego realizacji oraz wspierających je metod i narzędzi. Proces budowy dedykowanego oprogramowania postrzegamy jako wspólną podróż z Klientem, podczas której dążąc do wspólnego celu, coraz lepiej się poznajemy, rozumiemy i wspieramy. Stąd nazwa „Software as a journey”, która trafnie oddaje nasz sposób pracy.

Przepis na sukces w projekcie software’owym

Na szczęście czasy, kiedy po miesiącach pracy nad dokumentacją i kolejnych nad implementacją, by w końcu na testach odkryć, że nikt nie pamięta po co i dla kogo powstała większość funkcji, albo że system jest już nikomu niepotrzebny, przechodzą powoli w zapomnienie.

Nasz sposób pracy, który sprawdził się w dziesiątkach różnych projektach opisaliśmy w koncepcji “Software as a journey” . Czy jest on najlepszy? Nie mówimy, że tak, ale potwierdzamy, że jest skuteczny.

Dlaczego? Ponieważ zakłada, że najważniejsze jest zrozumienie prawdziwego celu biznesowego budowanego oprogramowania – w ten sam sposób i przez wszystkich uczestników projektu; a następnie ciągłe pilnowanie i korygowanie jego aktualności. Pomaga w tym iteracyjny tryb pracy, czyli częste i regularne opracowywanie i przekazywanie do używania gotowych mniejszych fragmentów systemu w kolejności zgodnej z priorytetami biznesu.

Efekt? Zaczynając projekt z pewną wizją, na końcu może powstać coś zupełnie innego. Coś, czego potrzebujesz teraz, a nie coś, co wydawało się potrzebne na początku prac. Dlatego bez względu na to, jak szybko zmieni się otoczenie rynkowe, oferta czy strategia firmy, budowany system będzie użyteczny i przyniesie oczekiwane korzyści.

Jak to osiągnąć? Umiejętnie dobierając na każdym etapie procesu wytwórczego odpowiednie narzędzia, metody i techniki projektowe. W „Software as a journey” proponujemy ich sprawdzony w praktyce zestaw, który najlepiej wspiera zwinne metody pracy. W zależności od charakteru i złożoności projektu można skorzystać ze wszystkich narzędzi lub dowolnie je dobierać.

Jakie korzyści dla projektu niesie taki sposób pracy? Jak zmienia poszczególne etapy procesu wytwórczego? Jak wpływa na zespół i komunikację? O tym w dalszej części artykułu.

Cel projektu

Zapewne znacie to z własnego doświadczenia: „Jest problem w firmie. Trzeba coś zrobić, jakiś system, który ten problem zaadresuje. Idziecie do IT, które mówi: Spiszcie wymagania biznesowe. My potem nad tym popracujemy. Zrobimy przetarg. Zbierzemy oferty. Spotkamy się z wybranymi dostawcami.”

Dostawca wybrany, system wykonany. Tylko w międzyczasie zmienił się rynek, procesy lub przepisy. Odeszli ludzie, którzy definiowali wymagania. Nowi pracownicy nie wiedzą, po co powstała część funkcjonalności, podczas gdy brakuje tych naprawdę potrzebnych.

„Software as a journey” proponuje inaczej. Wystarczy na na początku cel i ogólna wizja przebiegu procesu. Na warsztacie metodą Event Storming z udziałem biznesu, IT i dostawcy wspólnie, pod okiem doświadczonego facylitatora, ustalany jest przebieg procesu biznesowego. Krok po kroku, a w zasadzie karteczka po karteczce, na ścianie pojawiają się kolejne zdarzenia i zależności. Dodawane są przykłady i definicje pojawiających się pojęć biznesowych. Powstaje ogólny obraz systemu, którego cel i zakres wszyscy rozumieją tak samo.

Jest on przy okazji podstawą do zbudowania „backlogu”, czyli spriorytetyzowanej listy wszystkich zadań, jakie należy wykonać na poszczególnych etapach (sprintach), aby otrzymać finalny produkt.

W czasie trwania projektu, w zależności od zmieniających się warunków otoczenia biznesowego, elastycznie można zmieniać priorytety i zakres prac do wykonania w poszczególnych sprintach – dodawać nowe potrzebne funkcje lub rezygnować z tych, które straciły aktualność.

Horyzont czasowy i budżet projektu

Wspomniany backlog wraz z mapą historyjek użytkowników (story mapping), które są szczegółowo opisanymi z perspektywy użytkownika poszczególnymi funkcjami systemu, daje pogląd na to, jak będzie rozkładała się kolejność tworzenia tych funkcji i ile czasu należy na to przeznaczyć. Na tej podstawie szacowane są ogólne ramy czasowe i budżetowe projektu.

Najważniejszą pozycję w takim harmonogramie zajmuje termin i zakres przygotowania MVP, czyli minimalnej wersji działającego oprogramowania. Przekazanie takiego wyposażonego w najbardziej niezbędne funkcje produktu jego prawdziwym użytkownikom, pozwala szybko sprawdzić czy system spełnia oczekiwania, czego brakuje lub co należy poprawić. Uwagi te od razu uwzględniane są w pracach nad kolejnymi funkcjonalnościami.

Na bieżąco widzisz, co w ramach pierwotnie oszacowanej kwoty otrzymujesz w poszczególnych sprintach i czy idzie to w pożądanym kierunku. W każdym momencie możesz zareagować i dokonać zmian.

Współpraca – zespół i komunikacja

Bliska współpraca strony zamawiającej i wykonującej system, już od samego początku, sprawia, że zaciera się podział pomiędzy nimi i powstaje jeden wspólny zespół. Za sukces czy niepowodzenia wszyscy czują się odpowiedzialni. Nie ma przepychanek i wzajemnych oskarżeń.

Jak to jest możliwe?

Sposób pracy, który dzieli projekt na mniejsze, zazwyczaj 2-3 tygodniowe sprinty, wyznacza rytm spotkań i interakcji pomiędzy stronami. Każdy nowy sprint rozpoczyna sesja planistyczna, podczas której wspólnie określany jest cel i zakres prac (backlog) na najbliższe tygodnie. Realizując poszczególne zadania coraz dokładniej opisujemy wymagania. W dobrym ich rozumieniu pomagają przykłady (np. wyliczeń) oraz makiety ekranów, które konstruujemy zgodnie z zasadami projektowania User Experience. Sprint kończy się prezentacją kolejnej wersji coraz bogatszego funkcjonalnie działającego oprogramowania. Niezależnie, odbywają się codziennie krótkie spotkania organizacyjne, na których pożądana jest obecność obu stron.

Szczególne znaczenie dla jakości i dynamiki całego projektu ma osoba po stronie zamawiającego Product Owner, która powinna być obecna na każdym spotkaniu, dostępna dla zespołu wykonującego i decyzyjna w sprawach dotyczących aspektów funkcjonalnych budowanego systemu. To zaangażowanie, może być czasochłonne, ale procentuje tym, że powstaje dokładnie to, co jest potrzebne.

Częsty, regularny kontakt i wymiana wiedzy scala zespoły w jeden współpracujący i współodpowiedzialny za powodzenie projektu team.

Obserwowanie postępów prac

Pewność, że projekt zmierza w dobrym tempie, kierunku a system poprawnie działa, wynika z tego, że oprogramowanie budowane jest przyrostowo i przygotowywane tak, aby się automatycznie testowało. Dzięki temu każda kolejna wersja systemu jest dobrze sprawdzona. Dlatego można ją od razu wdrażać (również automatycznie) i oddać użytkownikom do pracy. Opinie lub zastrzeżenia osób bezpośrednio korzystających z systemu, pozwalają szybko reagować i dokonywać odpowiednich zmian i usprawnień.

Codzienny kontakt oraz cykliczne sesje planowania i demonstrowania wytworzonego oprogramowania pozwalają poznać tempo pracy zespołu. Wzrasta ono z czasem, wraz z lepszym poznaniem wzajemnych możliwości i ograniczeń oraz z coraz sprawniejszą komunikacją.

Mając tę wiedzę, łatwiej monitorować postępy oraz przewidywać koszty poszczególnych wydań. Budżet jest całkowicie pod kontrolą. Już po kilku sprintach dość precyzyjnie udaje się szacować czas i środki na kolejne wzbogacenia funkcjonalne i dzięki temu racjonalnie podejmować decyzje biznesowe.

Podsumowanie

Dobre oprogramowanie, to takie, które realizuje cele biznesowe. Takie, którego wdrożenie pozwoli biznesowi powiedzieć co i w jakim stopniu się poprawiło, lub ile i czego udało się zaoszczędzić.

Dróg do powstania takiego rozwiązania może być wiele. „Software as a journey” jest jedną z nich. Skąd to wiemy? Pracując według tych zasad, osiągamy wraz z naszymi klientami sukcesy w ich projektach.

Nie ukrywamy, że dobre oprogramowanie powstanie tylko wtedy, gdy tworzone jest wspólnie, z zaangażowaniem obu stron projektu. Gdy własne doświadczenia zamawiającego i dostawcy łączą się w nową, wspólną dla wszystkich wiedzę. Przełożenie tej wiedzy na język programowania daje pożądany przez wszystkich efekt – dokładnie taki produkt, jakiego biznes potrzebuje w danej chwili.

Wydobywanie wiedzy oraz zamiana jej w działający system odbywa się ze wsparciem używanych przez nas, rekomendowanych technik i narzędzi. Dziś jest to zestaw, który najlepiej wspiera zwinne podejścia, m.in: Event Storming, User Story Mapping, Domain Driven Design czy Continuous Integration i Continuous Delivery. Niektóre zapewne poznajecie – wspomnieliśmy o nich w tekście. Pozostałe są po prostu „twardymi” kompetencjami nowoczesnego software house’u, o których biznes powinien wiedzieć, ale których znać nie musi.

Author: Elżbieta Con, Head of Marketing w Altkom Software & Consulting

1 gwiazdka2 gwiazdki3 gwiazdki4 gwiazdki5 gwiazdek (1 głosów. Średnia: 5,00 na 5)
Loading...

Czy podobał Ci się artykuł? Jeśli tak, udostępnij go w swojej sieci!

Dodaj komentarz

avatar
  Subscribe  
Powiadom o