blog.testowka.pl

To jest tak proste, że aż się prosi by to uprościć.

opublikowany przez 05, Gru, 2011, w kategoriach Agile, Scrum, XP

Agile jest niezwykle nieskomplikowanym podejściem do wytwarzania oprogramowania narzucającym jedynie niezbędne minimum zasad w zupełności wystarczających do zbudowania mocnych i stabilnych podstaw na bazie których można wprowadzać pewne modyfikacje i ulepszać istniejące procesy.

W zasadzie Agile samo w sobie nie jest metodyką – to sposób myślenia (mindset), sposób codziennej pracy,  oparty na czterech filarach spisanych w postaci Manifestu Agile:

Ludzie i ich wzajemne interakcje ponad procedury i narzędzia.
Działające oprogramowanie ponad wyczerpującą dokumentację.
Współpraca z klientem ponad negocjację umów (tworzenie kontraktów).
Reagowanie na zmiany ponad ścisłe realizowanie planu.

To minimum zasad często samo w sobie staje się pokusą tego by je jeszcze bardziej ograniczyć. Postulaty manifestu Agile chociaż wydawało by się proste bardzo często są błędnie interpretowane co prowadzi do wdrożeń zwinnych metodyk zarządzania projektami kończących się porażką lub nie dających oczekiwanych (lub możliwych do osiągnięcia) efektów. Na Manifeście Agile opiera się wiele „zwinnych” metodyk i praktyk takich jak Scrum czy Programowanie Ekstremalne (XP). Metodyki te są same w sobie bardzo proste – zawierają tylko podstawowe zasady, których przestrzeganie gwarantuje wzrost efektywności zespołów developerskich. Niemniej jednak dla niektórych wydaje się to tak proste, że staje się bez znaczenia i niektóre praktyki są pomijane.

W ten sposób powstaje coś takiego jak ScrumBut: „Używamy Scrum, ale nie mamy codziennych spotkań”, „Używamy Scrum, ale nie mamy czasu na retrospekcje”, „Używamy Scrum ale nasz manager mówi nam co i ile będziemy robić w tej iteracji” etc.  Podejście typu „Weźmiemy trochę tego, trochę tamtego a resztę pozostawimy tak jak w modelu kaskadowym” powoduje, że wprowadzane zmiany nie mają szans działać w pełni o ile w ogóle cokolwiek polepszają.

Transformacja organizacji w stronę Agile to proces długofalowy, który wymaga wielu poświęceń i wyrzeczeń, a przede wszystkim wymaga otwartości na zupełnie nowe podejście do wytwarzania oprogramowania a także często wymaga od wdrażających możliwości wprowadzania zmian nie tylko w samym IT.

Gwoli ścisłości: to nie jest tak, że metodyki nie wdrażane w pełni nie będą działały w ogóle – będą, tylko efekty takiego wdrożenia będą dużo mniej stabilne i dużo mniej widoczne. Kilkukrotnie widziałem sytuacje w których metodyki pomimo tego, że wdrożone niekompletnie lub nieprawidłowo same się regulowały i ostatecznie coraz bardziej przypominały podręcznikowe wdrożenia, niestety widziałem też sytuacje, w których niecierpliwość spowodowana brakiem widocznych, obiecywanych efektów prowadziła do całkowitej rezygnacji z dalszego podążania w kierunku Agile.

Powyższy post jest rozwinięciem pierwszej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.


2 Comments for this entry

  • KaTe

    Trudno nawet mówić o wdrożeniu agile. To jest zmiana kultury organizacyjnej na taką która opiera się na odpowiedzialności – ale nie w sensie że jak coś pójdzie nie tak to szukamy winnego, tylko jak coś pójdzie nie tak to zabieramy się do roboty i naprawiamy to, obojętne czyja to wina. Jest to cholernie trudne (szczególnie dla polaków z naszymi uwarunkowaniami historycznymi w stronę zwalania winy na innych) i eliminuje politykę, która dla wielu jest równoznaczna z uznaniem i/lub grubszym portfelem.

    A co do upraszczania, to niektórzy mówią nawet o ScrumButt 🙂

  • szynka

    Przede wszystkim używanie tak uproszczonych zasad wymaga od ludzi:
    a) pewnej inteligencji,
    b) jednoznacznego rozumienia tych zasad w grupie współpracujących ze sobą ludzi,
    c) wzajemnej szczerości,
    d) pracowitości
    e) dobrej woli
    i pewnie jeszcze wielu innych czynników. Na pierwszy rzut oka i w teorii wydawałoby się że to podstawowe zasady w ogóle jakiejkolwiek dobrej współpracy międzyludzkiej. Natomiast często styczność z rzeczywistością pokazuje, że niestety te podstawy okazują się wręcz idylliczne. Wydaje mi się, że to właśnie z tego powodu w wielu organizacjach powstaje aż tyle procedur – niestety naprawdę duża większość ludzi nie spełnia w/w podstaw. Z tego powodu ktoś kiedyś stwierdził „hej skoro oni nie myślą napiszmy procedury, które zrobią to za nich” niestety w wielu organizacjach prowadzi to do tego, że w pewnym momencie procedury są przekomplikowane i wzajemnie wykluczające („niestety” nad nimi też pracowali ludzie, którzy – ah to niesamowite – też popełniają błędy).
    Podsumowując z obserwacji mojej wynika, że scrum nie jest dla wielu, a raczej powiedziałabym, niestety, jest dla niewielu. (przynajmniej jeśli chodzi o nasz kraj, w którym niestety już w szkole nas uczą, że krętactwo się opłaca :/). Albo mamy mało zasad i roztropnych ludzi, albo dużo zasad i „mniej roztropnych” ludzi ;>.
    Niestety ci roztropni to 10-20% całego spłeczeństwa w IT ta statystyka faktycznie jest trochę większa ale poza tym musimy też współpracować z tzw. „biznesem”, który jest odbiorcą naszej pracy i który za nią płaci. Zakładając, że w naszym dziale/firmie trafilibyśmy/dobralibyśmy sobie ludzi z tych 20%, pytanie brzmi na ile nasi kontrahenci są „roztropni” i na ile my jesteśmy od nich zależni?
    Być może istnieje jakiś „złoty środek”… tylko jak optymalizować tak wielowymiarową funkcję?

Skomentuj