Paul Klipp o praktykach agile dla polskiego e-biznesu

Paul Klipp o praktykach agile dla polskiego e-biznesu web.gov.pl

„Agile” to słowo, które coraz częściej pojawia się w książkach i artykułach na temat procesów software developmentu. Ale co tak naprawdę za nim stoi?

O tym, co sprawia, że biznes jest lean lub Agile i jak polskie start-upy i e-przedsiębiorstwa mogą wykorzystać to podejście do usprawnienia swojej codziennej prac opowiada Paul Klipp, amerykanin, który od wielu lat mieszka w Krakowie, odpowiadając za poczynania wielu software'owych przedsiębiorstw.

Zanim przejdziemy do dania głównego – krótka lekcja dla wszystkich niezaznajomionych z pojęciem agile software development.

  • Agile to specyficzne podejście do produkcji oprogramowania, które zakłada stopniowe dostarczanie kolejnych komponentów, w opozycji do zwyczajowego dostarczania całego oprogramowania za jednym razem. Każdy projekt dzielony jest na funkcjonalne elementy (tzw. „user stories”). Najpierw ustala się ich priorytetowość, a następnie dostarcza regularnie, jeden po drugim. To podejście określane jest jako „agile” (pol. zwinny), gdyż pozwala na testowanie każdego elementu osobno przed implementacją. Testowanie i użytkowanie oraz wynikający z niego feedback są nieodłącznymi elementami procesu, podczas gdy w podejściu tradycyjnym odbywają się już po dostarczeniu oprogramowania.
    Agile opiera się na 12 podstawowych zasadach, opublikowanych w 2001 roku jako Agile Manifesto. Scrum jest jednym z podejść w ramach Agile. To rodzaj struktury wykorzystującej owe podstawowe zasady. Mówiąc w skrócie, Agile to rdzeń filozofii wytwarzania oprogramowania, a Scrum to jedna z możliwych jego implementacji.

Zapytaliśmy Paula, jak można wykorzystać zasady Agile w polskich realiach software developmentu.

Web.gov.pl: W jaki sposób polskie start-upy mogą skorzystać z praktyk zwinnych? Czy spotkałeś się w Polsce z ich praktyczną implementacją?

Paul Klipp: Wydaje mi się, że problemy z jakimi zmagają się praktycy Agile w Polsce, są takie same jak wszędzie. Do pewnego stopnia winię za to Scruma. Agile to pojęcie niejednoznaczne, oparte na zasadach dzielenia się i transparentności.

Dostaliśmy do rąk wspaniały zestaw reguł, które wskazały nowy sposób wytwarzania oprogramowania. Dzięki Kentowi Beckowi otrzymaliśmy listę współzależnych praktyk programowania, które przekładają się na wartość produktów. Menedżerowie nie zrozumieli jednak ich zalet. Pozbawiona klarowności teoria jest trudna do przełożenia na praktykę. Problemem okazały się trudności ze zrozumieniem biznesowych korzyści tych działań.

Wtedy popularność osiągnął Scrum, bo oferował niewielki zbiór zasad – głównie podział na role i obowiązki. Pięć minut wystarczy, by wytłumaczyć to podejście menedżerowi. Niestety, Scrum jest często postrzegany jako synonim Agile, a jednocześnie coś, co tyczy się tylko zespołu developerów. W rezultacie Agile jest szufladkowane pomiędzy poziomami biznesowymi – wszyscy w organizacji powyżej i poniżej zespołu developerskiego nie muszą być „zwinni”. Agile powinno być traktowane jako sposób, w jaki ludzie współpracują, by zbudować produkt.

Podobne artykuły:

W środowisku, w którym więcej uwagi poświęcasz narzędziom i technikom, niż regułom i wartościom, pojawią się konflikty i tarcia. A to powoduje frustrację. Widzę to w Polsce.

To objawia się zwykle na dwa sposoby. Zewnętrzne firmy, bądź wewnętrzne zespoły developerskie, otrzymują zadanie skorzystania ze Scruma, ale jednocześnie sztywno ustala się terminy i budżet projektu. Mówi im się: „Chcemy, abyście byli Agile, chcemy, byście elastycznie podchodzili do nowych pomysłów, ALE jednocześnie chcemy, byście to wszystko zrobili do tego dnia, za takie i takie pieniądze.”

Niestety, ci developerzy najczęściej się zgadzają, poddają się presji i reagują w jedyny możliwy sposób – poprzez przesadę w szacowaniu terminów, jednocześnie przyczyniając się do pogłębienia problemu.

To samo dzieje się wewnątrz firm, gdy zespołowi developerów mówi się, że mają dostarczyć produkt do określonego dnia, ale jednocześnie być otwarci na zmiany.

Podobne artykuły:

Myślę, że największym problemem jest to, że zdajemy się być bardziej zachwyceni samymi praktykami Agile, a już mniej jego wartościami. Kiedy takie podejście nie przynosi spodziewanych rezultatów mówimy, że Agile nie działa.

W przypadku kanban także mamy do czynienia ze sposobem, w jaki powinny przebiegać procesy developmentu. Równocześnie fakt, że należy rozważać go na wielu różnych poziomach, jest jasno zaznaczony. Właśnie dlatego przypadł mi do gustu. Od razu planuje się cały proces, nie tylko na poziomie zespołów. Analizuje się, co dzieje się ze z efektami pracy zespołu developerów oraz skąd napływają zadania, które powodują zaległości. Rzadko prowadzi to do konwersacji na takie tematy, ale na pewno je ułatwia. A to może doprowadzić do rozwijania się idei lean w całej organizacji, nie tylko w ramach zespołu developerskiego.

Jakich rad udzieliłbyś polskim start-upom i firmom zainteresowanym wcieleniem filozofii Agile w życie?

W tym wypadku sytuacja jest zupełnie inna. Nie jestem przekonany, czy praktyki Agile są odpowiednie dla start-upu. Jeśli tylko poświęcają wystarczająco uwagi jakości architektury swoich produktów, co ma bezpośrednie przełożenie na to, czy są one skalowalne, niekoniecznie muszą stosować się do zaleceń wynikających z praktyk Agile.

Jeśli cały zespół to dwóch, bądź trzech developerów, pracujących razem w jednym pomieszczeniu przez 60 godzin tygodniowo, właściwie żyjących i oddychających tym środowiskiem, to wcale nie potrzebują sesji przed burn down chart [rodzaj wykresu w podejściu Agile i Scrum – przyp. red.] by wiedzieć, że zmierzają we właściwym kierunku.

Podobne artykuły:

W przypadku start-upów bardziej przydatny może się okazać model lean oraz design thinking, rozmowy z klientami, zrozumienie użytkownika itp. Zamiast koncentrować się na dostarczaniu produktu w kolejnych fazach, należy skupić się na projektowaniu i przeprowadzaniu skutecznych testów, konstruowaniu założeń, poddawaniu ich w wątpliwość i testowaniu oraz nauce akceptowania, gdy okażą się błędne. Czasami zdarza się, że ktoś rozwija produkt i proponuje go wybranemu podzbiorowi użytkowników. Kiedy okazują się oni mało zainteresowani, ten ktoś reaguje pytaniem: „Co jest z tymi ludźmi nie tak? Poszukajmy innej grupy użytkowników!”

Miałem bardzo nieprzyjemne doświadczenie z przeprowadzaniem wywiadów konsumenckich. Była to firma kierująca swoją ofertę do start-upów typu lean. Jej sternicy także korzystali z tego podejścia. Nie mam tu na myśli polskiej firmy, ale nie wypowiem jej nazwy, gdyż myślę, że już o nich czytaliście. Wypróbowałem ich produkt, popatrzyłem na niego, pobawiłem się nim. Następnego dnia otrzymałem e-maila od CEO: „Dziękuję za wypróbowanie naszego produktu, bylibyśmy bardzo wdzięczni za Twoją opinię. Czy moglibyśmy porozmawiać na Skypie?” Zgodziłem się. Następnego dnia zadzwonił i zapytał się o moje doświadczenia. Odparłem, że spodziewałem się czegoś, co będzie działać w taki, a nie inny sposób. On na to: „Nie, nie, nie, to ma działać właśnie tak, to taki projekt.” Odpowiedziałem: „W porządku, ale w takiej formie nie uważam, że mi się to przyda.” On stwierdził: „Mylisz się. To jest bardzo przydatne. Po prostu nie rozumiesz.” Na zakończenie wywiadu usunąłem swoje konto.

To także jeden z powodów, dla których organizuję ACE! Conference. Ludzie słyszą, że powinni przeprowadzać wywiady z klientami. Ale jeśli nikt nie nauczy ich jak to robić, ryzykują spaleniem mostów i zrujnowaniem swojej reputacji. Uważam, że odpowiednich umiejętności może nauczyć tylko doświadczony praktyk, najlepiej na spotkaniu twarzą w twarz lub na warsztatach. Moja porada dla start-upów byłaby następująca: skupcie się bardziej na tym, jak zaprojektować produkt, mniej na tym, jak go zbudować.

Co mogą zrobić polskie start-upy, by zwiększyć swoje szanse na powodzenie?

Zawsze powtarzałem, że przed polskimi start-upami stoją dwa zasadnicze wyzwania. W przypadku pierwszego z nich widzę zmianę na lepsze, ale wciąż jest w tym wiele prawdy – Polska to nieodpowiednie miejsce na porażkę. Chciałbym, aby na uniwersytetach częściej organizowano warsztaty z przedsiębiorczości. Najlepiej byłoby, gdyby każdy student IT jeszcze przed ukończeniem szkoły miał na koncie jeden nieudany start-up. Uniwersytety ewoluują, ale wciąż istnieje sporo rozbieżność między tym, co uczą w szkole, a tym, co dzieje się naprawdę, jeśli chodzi o prowadzenie start-upu.

Moim zdaniem musi się stać coś na kształt Netscape'a. Marc Andreesssen stworzył Netscape'a w oparciu o projekt Mosaic, który zapewnił mu ukończenie szkoły. Zarobił mnóstwo pieniędzy, a uniwersytet podał go do sądu. W rezultacie szkoły zaczęły się zabezpieczać, zapewniając sobie wcześnie prawa do projektów. Ale to jedynie odstraszało studentów, którzy zaczęli opuszczać szkołę, by rozpocząć swój biznes. Następnym krokiem była współpraca na zasadzie partnerstwa – uniwersytety tworzyły inkubatory, oferując wsparcie za pewne udziały w projekcie. Chciałbym zobaczyć to w Polsce. Polscy studenci pracujący w bezpiecznym środowisku, zdobywający w ten sposób praktyczne doświadczenie.

Drugim wyzwaniem jest fakt, że Polska to duży kraj, w którym dominuje język właściwie nieznany zagranicą. To potężna społeczność i szybko rozwijająca się gospodarka. 40 milionów ludzi to wystarczająco, by rozwinąć biznes. Po co więc próbować zagranicą, na niepewnym gruncie?

W kraju takim jak Estonia byłoby to nie do pomyślenia. Nikt nawet nie brałby pod uwagę otwarcia portalu społecznościowego, adresowanego tylko do estońskich uczniów – nie ma w tym biznesu. Jeśli rynek jest zbyt mały, należy skoncentrować się na internacjonalizacji od samego początku. Właśnie tak musi przebiegać proces myślowy także w Polsce.

  • Paul Klipp przyjechał do Krakowa w 2004 roku, by stanąć za sterami polskiego oddziału software house'u Lunar Logic. W ciągu kolejnych lat znacznie rozszerzył swoją działalność – założył swój własny start-up typu B2B (Kanbanery), oparty na systemie do zarządzania software developmentem kanban oraz zorganizował konferencję ACE! Conference dla developerów zainteresowanych „narzędziami i metodami ulepszania procesów software development. Ponadto zajmuje się także regularnym szkoleniem polskich przedsiębiorców i developerów w tym zakresie.

Artykuł pochodzi z serwisu web.gov.pl

Platforma Wspieramy e-Biznes Anna Spysz