JavaDevMatt.pl – Mateusz Kupilas

Programista, przedsiębiorca, gamedev, bloger.

Praca z dużym klientem (Puma) – system zarządzania cyklem życia produktów sportowych

Razem z Sii przygotowałem dzisiaj dla Was wpis o współpracy z dużym klientem z branży artykułów i odzieży sportowej, jakim jest firma Puma. Ten ogromny producent obuwia i odzieży sportowej szukał partnera, który byłby w stanie dostarczyć rozwiązanie szyte na miarę: system do zarządzania cyklem życia produktów sportowych. Obecnie we wszystkie zadania realizowane przez Sii dla Pumy zaangażowanych jest ponad 70 inżynierów.

Z dzisiejszego wpisu dowiedziecie się, jak ewoluowały metody pracy z klientem, jakie technologie i narzędzia zostały wykorzystane przez Sii oraz poznacie najważniejsze wnioski z takiej współpracy.

Zapraszam! 🙂

Ewolucja metodyki pracy

Sii rozpoczęło swoją współpracę z Pumą na początku roku 2014. Pierwszy projekt był realizowany jeszcze w 100% w metodyce waterfall. Dopiero później zaczęto stosować zwinne metodyki, by lepiej mierzyć powtarzalność wykonywanej pracy i dokładniej planować kolejne kroki. Głównym współczynnikiem omawianym z klientem jest stosunek procentowy zaplanowanych zadań (popularnych “ticketów/tasków”) do tych zrealizowanych („dowiezionych”). To bardzo dobry sposób na usprawnianie estymacji pracy i budowanie powtarzalnego procesu.

Nie należy obawiać się takiego współczynnika jako potencjalnego “kija”, którym klient może poganiać wykonawcę. Główna korzyść, jaką daje stosowanie takiej metryki, to realne planowanie daty dostarczenia funkcjonalności. Służy to zarówno klientowi, jak i zespołowi programistycznemu.

Z książkowo zaimplementowanym Scrumem jest jak z Yeti – podobno istnieje, ale nikt go nigdy nie widział (albo nie dostarczył wiarygodnego nagrania). W tym projekcie stosujemy elementy tej metodologii, które się sprawdziły (wspomniane powtarzalne i mierzalne iteracje), ale daleko tu do typowego podręcznikowego Scrumu. Specyfika współpracy z klientem wymusza kompromisy i naginanie metodologii (czasami trzeba przerwać Sprint ze względu na zmianę wymagań w już zaplanowanych zadaniach) – taka jest rzeczywistość i trzeba się do niej dostosować. Na to wszystko nakłada się również chęć budowania relacji z klientem, więc sprawa nie jest taka prosta, jak w książkach.

W tym miejscu zainteresowanych odsyłam również do starszego wpisu na blogu o moich
doświadczeniach ze Scrumem:

Organizacja pracy, czyli scrum w praktyce

System zarządzania cyklem życia produktu

Zespół developerski otrzymał projekt, którego celem było stworzenie aplikacji webowej wspierającej zarządzanie cyklem życia produktu: od pomysłu, poprzez wszystkie stadia rozwoju, po przygotowanie go do wejścia na rynek i późniejsze zarządzanie produktem. Aplikacja miała zastąpić stare rozwiązanie typu fat-client oparte na Lotus Notes. Projekt był nie lada wyzwaniem. Zespół inżynierów Sii podjął się zadania, by w 9 miesięcy dostarczyć pierwszą wersję produktu na podstawie kilkunastostronicowej prezentacji powerpointowej, przygotowanej przez klienta.

W tym przypadku tradycyjny model waterfall nie miał prawa się sprawdzić – nie wchodziło w grę inne podejście niż coś “agile’owego”.

Rozwój współpracy po terminowym „dowiezieniu” pierwszego projektu

Po terminowym „dowiezieniu” rozwiązania, inżynierowie Sii zaczęli przechodzić na coś bliższego Kanbanowi. Pracy dla nich jest więcej niż kiedykolwiek: cały czas rozwijają zbudowane aplikacje i tworzą nowe. Zespół pracujący z Pumą rozrósł się z kilkunastu do ponad 50 osób. Taki zespół byłby oczywiście za duży, więc podzielono pracę na mniejsze zespoły, z których każdy ma swojego Product Ownera. Istnieje również współdzielony zespół QA (kompetencje zarówno manualne, jak i automatyczne), którym zarządza Test Lead.

Dodatkowo z boku jest zawsze ktoś pełniący rolę łączącą trochę Scrum Mastera i Single Point of Contact dla klienta (w przypadku spraw o wyższej ogólności niż realizacja konkretnych zadań projektowych). Na co dzień z klientem komunikują się Product Ownerzy, ale powszechny jest też bezpośredni kontakt z członkami zespołów. By usprawnić współpracę, cyklicznie organizowane są warsztaty, na których spotykają się kluczowe osoby poszczególnych zespołów z przedstawicielami klienta. Na takich warsztatach ma miejsce burza mózgów i omawianie planów na najbliższą przyszłość.

Jeśli chodzi o narzędzia związane z obecną organizacją pracy, do spisywania wymagań używana jest JIRA i Confluence (Wiki). Do komunikacji: Slack i Skype for Business.

Technologie wykorzystywane w pracy

Do webserwisów wykorzystywane jest czyste EJB 3.2.

Bazy danych: baza to IBM DB2 w wersji 11. Cały ciężar logiczno-biznesowy jest przerzucony na stronę javową. Do zapisu danych wykorzystywany jest Hibernate, natomiast zapytania SQL pobierające dane są wysyłane przez JDBC jako natywne zapytania (w teorii są szybsze niż Hiberante).

IDE: projekt został rozpoczęty w Eclipse, ale obecnie migruje na InteliJ.

Najważniejsze biblioteki: klient nie chce się uzależniać od zbyt wielu zewnętrznych bibliotek, jeśli nie jest to naprawdę konieczne. Stosowane są głównie podstawowe rzeczy: XBean, JSR173, Log4j i  JUnit.

Co wykorzystywane jest do generowania raportów? Do prostych tabelarycznych exportów wykorzystywany jest plugin od Vaadina (Excel Exporter). Do bardziej skomplikowanych zrzutów używany jest JasperReports.

Do front-endu aplikacji wykorzystywany jest Vaadin (aktualnie w wersji 7, niebawem v.8). Vaadin generuje cały front-end z kodu pisanego w Javie.

Testowanie – testy jednostkowe są pisane z wykorzystaniem JUnit i Mockito. Do najważniejszych narzędzi testerów należą: Testrail, Selenium, JMeter, Postman, Fiddler, SoapUI, Chrome Dev Tools, Docker (wykorzystywany zarówno do testów i developmentu).

Co z Continuous Integration? Tu wykorzystywany jest Jenkins + Maven. Powoli planowane jest również wykorzystywanie jakiegoś managera do skryptów.

Oprócz tego niezastąpiony GIT jako system kontroli wersji.

Najważniejsze wnioski z pracy z dużym klientem

Praca przy tak dużych projektach uczy cierpliwości.

Jeśli nie tworzy się własnego produktu, który jest po prostu kupowany niejako “z półki”, to trzeba liczyć się z tym, że “wchodzi” się do organizacji, która ma już swoje dobrze zdefiniowane struktury i procesy biznesowe (czasami o różnym stopniu dojrzałości). Tyczy się to również procesu wytwarzania oprogramowania, który bardzo często jest daleki od optymalnego. Zwłaszcza w organizacjach, których główna działalność odbywa się na innym polu.

Żeby się „dotrzeć”, usprawnić istniejące procesy i pracować nad wdrażaniem lepszych praktyk, niezbędna jest cierpliwość. Nie wszystko z podręczników i szkoleń da się wprost przełożyć na realia danej organizacji albo jest to niewarte ceny wdrożenia, którą trzeba w zamian zapłacić. Nie chodzi tu wyłącznie o kwestie materialne, ale również o relacje z partnerem po drugiej stronie. Liczba zmiennych, które w takim projekcie mają wpływ na to, jak wygląda proces tworzenia oprogramowania sprawia, że wprowadzanie zmian jest często znacznie wolniejsze niż oczekiwaliśmy.

Zdarza się również, że niektórzy są tak skupieni na metodykach i freamworkach, że prawie całą swoją uwagę poświęcają ich implementacji. Zapominają przy tym o sednie projektu, który jest wspólnie realizowany. To, co wynosi się z projektów, które Sii realizuje dla Pumy, to zasada, że trzeba stale pracować nad procesem. Należy także starać się go usprawnić i przy tym wszystkim uzbroić się w cierpliwość, bo u większości klientów/projektów jest to proces długotrwały.

Materiał powstał we współpracy z firmą Sii.

2 thoughts on “Praca z dużym klientem (Puma) – system zarządzania cyklem życia produktów sportowych

  • Mateusz napisał(a):

    Nie miałem nigdy styczności z dużą korporacją. Bardzo ciekawy wpis pełen tricków, które z pewnością można przenieść na mniejszą firmę.

  • Pracownik napisał(a):

    Szkoda że w projekcie są równi równiejsi. Technologia to nie wszystko. Różnice między zespołami i lokalizacja są mocno widoczne. Co prowadzi do wielu zgrzytów w zespole. Technologicznie też nie można sobie poszaleć. Większość osób ma tylko i wyłącznie klepać kod nie wyrywając się z szeregu.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *