Agile manifesto- krótka analiza

Napisałem ostatnio tekst o tym jak działa w dużych organizacjach przemiłe hasło Agile. Jednak trzeba usiąść i spojrzeć na źródło tego całego zamieszania. Należy przeczytać Agile Manifesto. Gdzie? O tutaj.

Ja jednak chciałbym przejść przez wszystko co tam napisane i odnieść się do realiów. Jednocześnie opowiedzieć o tym jak to się dzieje w normalnym świecie korporacyjnym, gdzie zwinność to slogan. Naprawdę, znam kilka firm pracujących zwinnie. Miałem nawet przyjemność zbudować dwa poważne rozwiązania w sposób zwinny. Zrobiłem to szybko, tanio i skutecznie. Nie do zabicia są te mechanizmy/systemy, a podobno zabić je trzeba 😉

 

Manifest programowania zwinnego

Odkrywamy nowe metody programowania dzięki praktyce w programowaniu

i wspieraniu w nim innych.

W wyniku naszej pracy, zaczęliśmy bardziej cenić:

Ludzi i interakcje od procesów i narzędzi

Działające oprogramowanie od szczegółowej dokumentacji

Współpracę z klientem od negocjacji umów

Reagowanie na zmiany od realizacji założonego planu.

Oznacza to, że elementy wypisane po prawej są wartościowe,

ale większą wartość mają dla nas te, które wypisano po lewej.

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

 

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

 

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

 

Teoria mówi, że najważniejsi są ludzie i relacje między nimi, to prowadzi do działającego softu, który osiągamy nie dzięki rozmowom przez prawników tylko przy stole, bo zawsze coś się może zmienić więc warto się uśmiechać, żeby te zmiany wprowadzić szybko i każdy był zadowolony.

Co mówi praktyka?

Ludzie i interakcje są nie istotne. W grę wchodzi polityka, animozje. Bywa tak, że ktoś jest po prostu zwykłym kutasem ale siedzi na stołku i no, ni cholery, nic nie zrobimy, trzeba się męczyć z debilem.

Działający soft? Tak. Ten punkt jest spełniony. Raczej w tym drugim zakresie. Nie ma dokumentacji. Soft raz działa, raz nie ale dokumentacji na pewno nie będzie.

Współpraca z klientem? Wolne żarty. Konia z rzędem temu, kto zrobił dobry zwinny kontrakt. To jest trudne, trzeba sobie ufać. Wiecie, to nie jest takie proste w biznesie. Najczęściej kończy się to na rozmowach przez prawników. Nic fajnego, a projekt w dupie.

Reakcja na zmiany? Tu podzielę się doświadczeniem. Biznes lubi zmiany. Są momenty, kiedy nie ma na nie wpływu, prawo się zmieni, trzeba szybko na rynek zareagować. Tak się dzieje. No i teraz co dalej? W sumie to prosto. Jeśli, którykolwiek prezes myśli, że my się nie dogadujemy pod stołem to jest ignorantem. Jeśli wysyłasz programistę do siedziby klienta to my ze sobą rozmawiamy. Nie jesteśmy trędowaci. To jeśli trzeba na szybko dopisać kilka linijek kodu to się dogadamy, nikt się o tym nie dowie, nie wystawisz za to faktury. Sorry, jesteśmy ludźmi, potrafimy rozmawiać. No chyba, że ktoś jest kutasem jak w punkcie pierwszym, to już trudno, projekt stoi i kwiczy.

 

Jakie ma założenia ten cały Agile? Proszę:

Najwyższy priorytet ma dla nas zadowolenie klienta

dzięki wczesnemu i ciągłemu wdrażaniu

wartościowego oprogramowania.

Zasada jest taka. Klient ma dostać coś szybko i już mieć możliwość korzystania z tego, po mimo tego, że jeszcze kupa roboty. W teorii tworzy się najłatwiejsze do zrobienia funkcjonalności, które dają już się wykorzystać, ale to nie jest proces gotowy. Powiedzmy stawiamy statyczną stronę, a potem dorabiamy do niej responsywność.

Praktyka? Korporacje boją się jak ognia topienia kasy. Jest to debilizm wysokiego poziomu, bo złotówki są oglądane z własnej perspektywy. Powiedzmy, że mam do zrobienia funkcjonalność za 20k PLNów i będzie za 3 m-ce. To na te 3 m-ce mogę zrobić coś taniego, powiedzmy za 5k. Przez te trzy miesiące biznes przyniesie 20k oszczędności, zrobi to szybciej niż zakładał, za 3 m-ce dowiezie już zgodnie z planem 50k oszczędności na pełnym rozwiązaniu. Dlaczego tak się nie dzieje? Bo trzeba by wydać 5k tylko po to, żeby zaraz wydać 30k. Budżet IT nie da 35k, po mimo tego, że biznes krzyczy: „Dej mnie to za piątkę, ja zrobię 60 tysi”. Nigdy tego nie zrozumiem.

 

Bądźcie gotowi na zmiany wymagań

nawet na późnym etapie jego rozwoju.

Procesy zwinne wykorzystują zmiany

dla zapewnienia klientowi konkurencyjności.

To wbrew pozorom działa. Jeśli zespół jest zgrany to się takie rzeczy dzieją. Przychodzi PO i mówi, jest lipa, pomocy. Koleżanki i koledzy pomogą. Może w Jirze nie będzie, ale za to będzie na środowisku. Jesteśmy ludźmi. Po mimo wszystko. Po mimo tego co zdarza się myśleć managerom różnego szczebla.

Dostarczajcie funkcjonujące oprogramowanie często,

w kilkutygodniowych lub kilkumiesięcznych odstępach.

Im częściej, tym lepiej.

Z tym jest rożnie. Zależności jest od cholery. Część rzeczy robi się szybko. Inne miesiącami. Będę szczery. Nie mam zdania na ten temat. To w zasadzie jest takie łechtanie end usera. Trzeba mu dać raz na jakiś czas nową zabawkę, nowy obrazek. Tak w zasadzie powinno być. Działa to dobrze na morale. Koder widzi efekt, biznes widzi efekt. Doświadczenie mi mówi, że nie dobry back-end, a ładny front najlepiej łechta biznes. Z drugiej strony, ja się troszku na tyłach znam, średni ze mnie biznes w takim razie 😉

Zespoły biznesowe i deweloperskie muszą ściśle ze sobą

współpracować w codziennej pracy przez cały czas trwania

projektu.

To jest największy błąd podczas zwinnych projektów, przy których pracowałem. O to chodzi w tej metodologii, żeby podczas drugiego sprintu już się wszyscy znali i potrafili ze sobą pracować. Biznes nie może być tym, który jest jakąś postacią z cholera wie gdzie i wpada raz na jakiś czas. O ile programiści siedzą w jednym miejscu i zwykle nie robią nic oprócz programowania, to z biznesem jest różnie. Tutaj potrzebna jest ogromna zmiana w percepcji managerów. Trzeba dać tego biznesowego człowieka na 100% na cały czas trwania projektu. Tylko i wyłącznie dlatego, że bez niego to się wszystko będzie ślimaczyć. Tak się właśnie dzieje. Wrzucanie PO innych zadań jest skrajnie nieodpowiedzialną rzeczą. Nie można tak robić. Po prostu. Ten człowiek na cały czas trwania projektu ma siedzieć obok programistów, brać wszystkie potrzebne mu zasoby i działać. Nie ma tutaj miejsca na wysyłanie go na konferencję, zapraszanie na głupie spotkania czy proszenie o machnięcie slajdu. Przestańcie tak robić kierownicy. Popełniacie błąd.

Twórzcie projekty wokół zmotywowanych ludzi.

Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że

wykonają powierzone zadanie.

To jest robota Scrum Mastera. Ten człowiek nie jest nadzorcą niewolników jak to się uważa w debilnym podejściu niektórych jaśnie nieoświeconych. Robota Scruma jest cholernie ciężka. Sam znam dwóch, których mogę polecić. Panują nad wszystkim, wiedzą co się u nich dzieje w projektach, kto lubi piwo z sokiem i jakim, który deweloper nie przyswaja laktozy i to żeby przypomnieć PO o zapłaceniu za parking we wtorki, bo dzieciaka do przedszkola odwozi. Ten człowiek ma pilnować tego, żeby zespół nie był atakowany z boku. Nie ma tam miejsca na mówienie im jak to trudno się żyje. On ma usuwać przeszkody. Dostępy są potrzebne? Leć i załatwiaj. Skończyła się kawa? Skocz do sklepu. Tak ma działać Scrum Master.

I teraz dobra rada. Jeśli Scrum Master dostanie tysiaka miesięcznie, żeby kupić chłopakom i dziewczynom pizze, bo trzeba robić nadgodziny, załatwi lepszą kawę do ekspresu, pojedzie po zajebiste podkładki pod myszki lub ma retro zabierze ekipę na wódke to co projekt upadnie? Dajcie Scrumom kieszonkowe, które mogą rozwalić bez głupiego pytania się czy mogą. Dzięki nim, kluczowy deweloper nie powie w połowie projektu, że idzie tam, gdzie są trzy razy w tygodniu owoce.

Najbardziej efektywnym i wydajnym sposobem przekazywania

informacji zespołowi deweloperskiemu i wewnątrz niego jest

rozmowa twarzą w twarz.

Ważne, szczególnie w kontekście pracy zdalnej. Bywam zwolennikiem, ale nie w projektach, które wymagają współpracy. Tam, gdzie trzeba usiąść i się dopytać to sorry. Trzeba siedzieć w jednym miejscu i gadać ze sobą. Co można robić zdalnie? Ostatnio klepałem algorytmy pod zrzuty danych. To można robić z domu.

Działające oprogramowanie jest podstawową miarą postępu.

Truizm

Procesy zwinne umożliwiają zrównoważony rozwój.

Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie

utrzymywać równe tempo pracy.

Też truizm. Powiązany z punktem, przy którym pisałem o dostępności deweloperów. Na czas projektu rzuca się zabawki i robi się projekt. Tyle w temacie. Jeśli każda ze stron nie może zapewnić tej samej dostępności to jesteśmy w dupie. Biegniemy tak szybko jak najwolniejsze ogniwo.

Ciągłe skupienie na technicznej doskonałości i dobrym

projektowaniu zwiększa zwinność.

Niby też truizm ale szalenie istotny. Mam okazję teraz pracować z architektem, który projektuje jedno z moich rozwiązań. Gość przewiduje moje potrzeby. To jest niesamowite. Przychodzę po 6-7 sprintach i mówię, że czegoś potrzebuję. Ten mi wyciąga zza pazuchy gotowe rozwiązanie, mówi, że pracy przy tym niewiele i w sumie to on zakładał, że może to być potrzebne to podwaliny techniczne już mamy. Nie oddam człowieka za żadne skarby.

Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.

Tu się zatrzymam. Jeśli przez prostotę rozumiemy- wydaj jak najmniej kasy- to się mijamy z prawdą. W tej prostocie chodzi o to, żebyśmy korzystali i re-używali jak najbardziej nie skomplikowane z możliwych rzeczy. Po mimo chodzącej po mieście opinii, że programiści są jacyś inni to niestety tak nie jest. Każdy człowiek jest w zasadzie podobny. Tutaj trzeba iść w kierunku łatwych rzeczy, te z drugiej strony mogą nie być tanie. Cóż. Najważniejsza jest prostota, niech nawet kosztuje 5% więcej.

Najlepsze rozwiązania architektoniczne, wymagania i projekty

pochodzą od samoorganizujących się zespołów.

Prawda. Jeśli zespół siada i rozmawia to pojawiają się pomysły ludzi doświadczonych. Takich co to znają temat. Dlaczego? Bo tak. Najczęściej przy wódce. Życie. Nie zrobi tego żadne manager. Najlepsze pomysły to te oddolne, bo one wychodzą od praktyków, a nie tych którzy już dawno zapomnieli.

W regularnych odstępach czasu zespół analizuje możliwości

poprawy swojej wydajności, a następnie dostraja i dostosowuje

swoje działania do wyciągniętych wniosków.

To te słynne Retro. Nigdy mnie nikt nie zaprosił, bo jestem PO albo takich spotkań się w Scrum teamie nie robi. Jestem ciekaw jak to wygląda. I tu poproszę o jakiś komentarz na ten temat. Serio, nie wiem 😉

 

Coś słowem podsumowania?

Agile to świetny system robienia oprogramowania. Wymaga rozsądnych ludzi i stworzenia odpowiednich warunków pracy. Dzięki niemu można zrobić dużo, szybko i dobrze. Czy taniej? Powiedziałbym, że tak, chociaż z jakiegoś powodu ceny projektów idą w górę, a nie powinny.

Co przeszkadza? Niech sobie managery zrobią teraz rachunek sumienia. Pomyślcie ile razy mówiliście, że będzie super Agile i dojedzie taki super produkt ale:

– ludzie byli rozsiani po całym kraju

– pracownikom pozwalaliście w projekcie na 30-40% czasu

– odrzucaliście dobre i szybkie rozwiązania tylko dlatego, że trzeba było utopić jakieś śmieszne pieniądze

– zamiast pozwolić ludziom pracować to wymagaliście od nich statusów co pół dnia

– pozwalaliście osobom szkodzącym projektowi siedzieć i szkodzić dalej

– olewałeś time-box przewidziany na sprint i dowolnie zmieniałeś ludziom zadania

Jeśli zatrzymałeś się chociaż na chwilę, przy którymkolwiek zdaniu to nie robiłeś tego zwinnie. Udawałeś, pewnie klejąc kolorowe kartki na ścianie i odświeżając kupioną za kupę kasy Jirę. Gówno miałeś, a nie Agile.

Dodaj komentarz

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