Zmóżdżam się nad tym, gdzie tkwi różnica między agilem, a tym, co ja uznaję za dobry projekt, choć nikt nie nazywa tego agilem.

Projekty agilowe vs. tradycyjne

W projektach agilowych pojawiło się wiele ról, spotkań, konceptów, które coraz bardziej popularyzują się w naszym świecie IT. Czasem mam wrażenie, że w różnych podejściach wiele problemów rozwiązuje się podobnie. Tylko w nieagilowych projektach takie rozwiązania nazywają się nieagilowo. I z tego tylko powodu są przez niektórych automatycznie odrzucane.

Magiczna skrzynka Product Ownera

Product Owner przekazuje zespołom, co mają robić. Skąd on to wie? Jak sobie radzi, kiedy ma do czynienia z bardzo złożonym problemem? Raczej się w to nie wchodzi w szczegółach. Zazwyczaj słyszę odpowiedź, że ma porozmawiać, wziąć ludzi do pomocy albo po prostu zrobić.

Tworzone rozwiązania mogą być prawdziwym wyzwaniem. W szczególności, jeśli angażują setki interesariuszy, wiele jednostek organizacyjnych, ogromny zespół wytwórczy, dziesiątki systemów informatycznych czy problemy o dużej złożoności.

Jak to ogarnąć? Powiedziałabym, że robiąc dobrą analizę – zbierając potrzeby i proponując rozwiązanie.

Trudno jednak zapanować nad złożonością, jeśli niemile widziane są dokumenty, modele, diagramy. Większość ludzi powie, że to nie problem. Niech PO robi to jak uważa. Są jednak tacy, co uciekają w popłochu widząc „nieagilowe” artefakty, jeszcze zanim sprawdzą czy przeszkadzają im w pracy czy może pomagają.

Jak dostarczać szybko odpowiedzi dla zespołu i szczegóły wymagań/user stories, kiedy działasz pod ścisłą presją pędzących sprintów?

Kiedy się pytam, jak oni to robią, to słyszę, że rozmawiają, komunikują się albo nie ma to znaczenia, liczy się efekt.

Gorzej, jeśli to Ty jesteś w roli tego PO i pytanie „JAK?” ma dla Ciebie ogromne znaczenie.

Radykalizm bierze się z traumy

Normalnie człowiek jest spokojny. Posłucha innych, powie swoje, rozważy różne opcje. Także taką, że ktoś może mieć lepszy pomysł. Są jednak ludzie, którzy automatycznie odrzucają wszystko inne, co nie mieści się w agilowej terminologii.

Jaką traumę mają zacietrzewieni agilowcy? Musieli widzieć szatańsko bezsensowny projekt.

Pamiętam pierwszy raz jak dotarło do mnie, co to znaczy robić dokument totalnie bez sensu. Rozmawialiśmy z przedstawicielem IT klienta. Pytał nas o szczegóły pól w naszej bazie danych, chociaż nigdy po swojej stronie nie miał z nimi do czynienia, bo dostawał interfejsem już przetworzony wynik. Tłumaczyliśmy mu to 2 razy, ale uparł się, że musi wypełnić szablon dokumentu, który go obowiązuje. Bardzo prosił, żebyśmy podali mu cokolwiek, bo będzie z tego rozliczany. OMG. Zrozumiałam wtedy, że można robić dokumenty zupełnie bez sensu.

Innymi przykładami były projekty publiczne, z którymi miałam do czynienia :) Z pięknie rozbudowaną dokumentacją, która nadawała się jedynie do zaorania. Ewentualnie jako bardzo wstępny materiał do rozmów (po dużej pracy wyciągania z tego potencjalnych kandydatów do rozmów o wymaganiach). Kuriozalne było to, że miałeś stworzyć sensowne rozwiązanie przydatne dla odbiorców i jednocześnie spełniać wymagania bzdurnego wstępnego dokumentu.

Ale i w zwykłych komercyjnych projektach nie brakuje rzeczy, które przerażają. Widziałam setki specyfikacji po setki stron, w których było wszystko, ale tego, co najważniejsze, to akurat nigdzie nie było. Jedno wymaganie było rozproszone w kilku miejscach dokumentu, a nawet po kilku dokumentach. Robić do tego impact analysis? Powodzenia. Szukać tam czegoś? Ja się gubię, a to przecież moja praca. Jak mają tam coś znaleźć developerzy?

A widziałeś te krzaczaste diagramy na 3 strony A4? Na całe ściany? Z 50 elementami i połączeniami niemal każdy z każdym?

Sama się nogami nakrywam jak widzę takie cuda.

Czy agile jest agile?

Z oddaniem sprawie można przesadzić.

Jeśli nie dopuszczasz do użytku narzędzi innych niż „agilowe” (jak tablice, specjalne wtyczki, jedynie słuszne aplikacje), mimo iż te inne byłby bliższe preferencjom komunikacyjnym zainteresowanych osób, to czy jesteś agilowy?

Jeśli wywalasz za drzwi człowieka, który potrzebuje informacji, żeby pracować i pomagać pracować zespołowi, to czy jesteś agilowy? Stawiasz na pierwszym miejscu ludzi czy podążanie za zdefiniowanym agilowym procesem?

Jeśli odrzucasz wszelką dokumentację, albo dopuszczasz tylko tablicowe zdjęcia, choć diagram UML pomógłby lepiej stworzyć działające oprogramowanie, to czy jesteś agilowy?

Jeśli w ogóle nie współpracujesz z klientem i nie masz informacji o jego rzeczywistych troskach, ale pracujesz na User Story i Epic Story na fajnym Kanbanowym boardzie, to czy jesteś agilowy?

Jeśli sztywno trzymasz się swoich agilowych zasad i nie przyjmujesz w nich zmian, choć będą one lepsze dla Twojej firmy, Twojego klienta, Twoich użytkowników, to czy jesteś agilowy?

Bądź interfejsem

Analityku, jak żyć w takim świecie? Bądź pan agile. Nie pisz za dużo dokumentów, nie rób bufoniastych diagramów, nie porządkuj za dużo i nie planuj! Ale odpowiadaj na wszystkie pytania zespołu. Szczegółowo. Bądź dostępny dla zespołu, poświęcaj mu czas. I rób te historyjki raz, raz, bo lecimy ze sprintami!

Na product ownera w dłuższych projektach szuka się chyba Chucka Norrisa.

W moim rozumieniu taka osoba robi nic innego jak analizę biznesową. I nie znam lepszego sposobu niż poznanie wszelkich technik, które w niej pomagają, a następnie efektywne sięganie po te, które w danej sytuacji są najbardziej przydatne.

Analizy nie robisz po to, żeby ją przekleić do Worda. Wiele osób tego nie rozumie. Myślą, że skoro zespół chce user story, to muszą zrobić tylko user story. Jeśli klient nie zapłacił, nie zamówił diagramów procesów, to nie robimy diagramów procesów.

Analizę robisz dla siebie. Żeby poskładać sobie wszystko w głowie. Żeby zrozumieć. O co tu chodzi, w czym jest problem, jak to ma działać. Robisz to dla siebie, żeby móc odpowiedzieć na pytanie, kiedy przyjdzie developer. Czy jego to interesuje czy zrobiłeś diagram czy nie? Czy opisałeś wymaganie tak czy śmak? Czy zagląda Ci na dysk? Interesuje go, że odpowiesz mu na pytanie.

Nie mam pojęcia jak w złożonym projekcie odpowiadać na trudne pytania bez przemyślenia, poukładania, wykonania „tradycyjnej” analizy.

Bądź dla zespołu interfejsem. Udostępniaj im to, czego potrzebują. A to, czego Ty potrzebujesz do wykonania zadania, zostaw dla siebie. Osłoń warstwą abstrakcji.

Najlepszy człowiek do pracy

Jakich ludzi najlepiej szukać do pracy w ważnym dla firmy projekcie? Najlepiej otwartych. Najlepiej takich, którzy znają agile, Scrum, PRINCE2, PMBOK, BABOK i cokolwiek tam jeszcze. Takich, którzy nie wzdrygają się przed rozwiązaniem tylko dlatego, że nazywa się tak a nie inaczej. Oceniają rozwiązanie po tym, czy jest skuteczne do ich potrzeb. I takiego nie zawahają się użyć.

Hania Tomaszewska
8 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Pracuję na etacie, prowadzę bloga, tworzę kursy, prowadzę szkolenia i konsultacje. Pomagam analitykom doskonalić warsztat pracy i rozwijać się, managerom układać procesy i rozwijać pracowników oraz przedsiębiorcom, aby rozwiązania IT wspierały ich działalność.

51 KOMENTARZE

  1. Haniu, nie jestem broń Boże kapłanem Scruma czy innych agile’owych frameworków, ale muszę wtrącić swoje trzy grosze.

    Przede wszystkim o agile’u mówimy wtedy, gdy funkcjonujemy wg manifestu agile, czyli np. elastycznie podchodzimy do zmian zakresu w projekcie, ważniejsza jest dla nas sensowność danej funkcji niż jej pierwotne założenia itd. To, że ktoś spotyka się na „daily”, rozpisuje „user stories” czy wprowadza rolę scrum mastera, nie oznacza, że działa zwinnie. Często mamy do czynienia z parodią agile’a – o czym mam wrażenie piszesz.

    Podobnie jest z Product Ownerem. Jest to inna rola niż analityk, mimo że zdecydowanie wymaga kompetencji analitycznych. Przede wszystkim, Product Owner jest decyzyjny – jest naczelnym szamanem produktu, jego władcą (często po prostu beneficjentem, klientem), określającym co ma zostać zrobione. Analityk, owszem, zbiera wymagania, przekuwa je na rozwiązania, jednak rzadko kiedy sam decyduje o tym, co wejdzie w zakres projektu (bo ma budżet i moc sprawczą).

    Ostatecznie pamiętajmy, że rola roli nierówna. Analityk (dotyczy to jakiegokolwiek stanowiska) w firmie A będzie się zajmował trochę czym innym niż w firmie B. Tak samo jest z agilem i jego praktykami. Każdy korzysta z nich trochę inaczej, przekuwając na swoją modłę i często – niestety – dochodzi do patologii.

    I jeszcze jedno: Scrum, Kanban czy inne agile’owe praktyki nie są wcale prościutkie do zrozumienia i wdrożenia. Nie wiem skąd wziął się Twój osąd, że wystarczy przeczytać kilka zdań czy broszurkę żeby móc z nich korzystać :)

    • Piotrze, dziękuję, że się podzieliłeś swoją opinią. Też mi się wydaje, że to nie do końca tak powinno działać. Ale jednak tak w wielu przypadkach działa i ludzię są przekonani, że są Agilowi. Nie byłoby w tym nic takiego, jeśli nie fakt, że od razu odrzucają wszelkie inne propozycje działania, tylko dlatego, że są „nieagilowe”. Myślę, że podobnie można powiedzieć o tych, którzy mają przykre doświadczenia z planami i specyfikacjami. Może nie widzieli dobrego prowadzenia projektu i analizy.
      Nie uważam, że praktyki agilowe są proste do zrozumienia czy dobrego stosowania. Szczerze mówiąc myślę, że trzeba mieć do tego bardzo dojrzały, uzdolniony i chętny do doskonalenia zespół. Co się często nie zdarza. Chodziło mi o to, że na start jest mało teorii do przeczytania. Ludzie czytają Scrum Guida i organizują sobie pracę. Żeby wdrożyć inne metody pracy często trzeba przeczytać bardzo pokaźne księgi. Mam wrażenie, że to ludzi odrzuca. Co ciekawe, właśnie, żeby dobrze robić Agila, pewnie trzeba przeczytać nie mniej stron. + eksperymenty i nauka z doświadczeń. Ale to zawsze powinno wystąpić, niezależnie od tego czy to agile/nie agile.

      • Zgadzam się. Metodyki i frameworki są po to, aby ułatwiać ludziom pracę. Same projektu nie zrealizują. Projekt może się udać zarówno z, jak i bez stosowania konkretnej metodyki. Położyć go również można, niezależnie od tego jak nazywamy nasz sposób działania.

        Ważne żeby kierować się zdrowym rozsądkiem i myśleć w trakcie pracy, a tego niestety czasem brak w zespołach i organizacjach. Hasło „Agile” jest według mnie dlatego tak popularne, bo ludzie nazywają nim chaos, który w okół siebie wytwarzają. „Nie masz sprecyzowanych wymagań? To nic, zróbmy to agile’owo”.

        A przecież nawet w takim Scrum Guide nie wyczytamy, że Agile = improwizacja. Wręcz przeciwnie :)

  2. Haniu,
    Fajny wpis choć więcej w nim pytań niż odpowiedzi ale może właśnie o to chodzi, żeby wywołać dyskusję :)
    Dodał bym do tego kilka tez:
    * metodyki adaptacyjne są trudniejsze do stosowania niż te bardziej tradycyjne podejścia. Wymagają zrozumienia, zaakceptowania i zmiany filozofii – a to jest trudne szczególnie gdy wyrosło się i stosuje się inne. Pozornie łatwiej maja świeżaki którzy startują od SCRUM ;)
    * metodyki adaptacyjne to zmiana filozofii software developmentu wynikająca z przemyśleń autorów manifestu nad doświadczeniami z ich projektów realizowanych tradycyjnie. Zrozumienie tej filozofii i tego co kryje się za konkretnymi zwinnymi pozornie prostymi praktykami to klucz do ich dobrego stosowania. Zgoda, że z filozofii zrobiła się ideologia, która w środowisku wykorzystywana jest do stygmatyzowania innych zarówno z dobrym jak i złym kontekście. Trochę potwierdza się myśl że lepsze jest wrogiem dobrego i że rewolucja pożera własne dzieci.
    * między agile i waterfall jest bardzo dużo miejsca na różnego rodzaju podejścia iteracyjne posiadające więcej mechanizmów stymulujących komunikację, informację zwrotną, adaptację, silne zespoły,
    * ciężko mówić o adaptacji agile jeśli nie mówimy o kontraktach i umowach sprzyjających takiemu modelowi pracy,
    * absolutnie nie jest prawdą, że w metodykach adaptacyjnych nie ma analizy :) Powinno być mniej niepotrzebnej analizy. Podobnie z architekturą

    • Mariusz, z tego, co wiem, to Ty masz duże doświadczenie z Agilem i z tradycyjną analizą także. Podzielisz się w artykule wnioskami i praktycznymi wskazówkami jak radzić sobie w złożonych problemach?

  3. Witam,
    miałem okazję pracować w mniej lub bardziej agile-owych organizacjach, także w roli Product Ownera (PO) :)
    Zdarzało mi się również pracować obok takich PO którzy uważali że „wszystko jest jasne”, „szkoda czasu na analizę, bierzmy się za kodowanie”, „dokumentacja jest zbędna”. Do czasu. W momencie gdy projekt był trochę większy, bardziej złożony i wchodziły rozbudowane procesy wszyscy dochodzili do wniosku że trzeba to spisać. Tylko jak? Później wchodziły notacje, diagramy, rysunki i cały formalizm. Zaskakujące jest to że zarówno klient jak i developerzy (że o PO nie wspomnę) przyjmowali taką dokumentację z radością i bardzo jej oczekiwali. Mimo iż na początku projektu nie chcieli „tracić” na nią czasu.

    Z mojego punktu widzenia to nie jest tak że analiza jest zabroniona w agile. Po prostu nie jest wymagana. Może to i błąd? Obecnie, dla mnie:
    PO = analityk + decyzyjność

    @Piotr Rawski , już sam Scrum Guide zakłada że SCRUM jest prosty do zrozumienia. Z definicji:
    Scrum is:
    * Lightweight
    * Simple to understand
    * Difficult to master

    Chodź mnie najbardziej w pamięci zapadł ostatni punkt z definicji.

    Miłego dnia

    • Cześć Karol.
      Tak mi się wydaje, że duża złożoność tak się właśnie kończy. Kto to wszystko ogranie? Może dopiero za jakiś czas przyjdzie ogólno-agilowa refeksja, że lepiej to spisać w jakimś porządku a nie tylko na rosnącym stosie fruwających kartek i zmazywalnych tablicach. Ciekawa ta Twoja historia :) Fajnie zobaczyć taki proces rośnięcia projektu.
      Dzięki za komentarz. Miłej reszty dnia :)

  4. Nic dodać, nic ująć Pani Hanno. Kiedyś tj. ok. 4 lata temu, kiedy wpadłem w młyny scruma ;-) miałem nadzieję, że to napięcie pomiędzy analizą a tzw. agile, to chwilowa aberracja i za chwilę przyjdzie moment otrzeźwienia. Niestety myliłem się. Trend do rezygnowania z systematycznej analizy, z modelowania procesów oraz dziedziny jest trwały. User stories czyli coś co kiedyś nazywano wymaganiami pierwotnymi, coś co stanowiło wejście do systematycznej analizy dzisiaj kończy proces definiowania wymagań i tylko tego oczekuje się od product ownera. Trafnie Pani pyta, jak można w tych warunkach odpowiadać na trudne pytania. Odpowiedź brzmi, nie można, ale równocześnie takie pytania na ogół nie padają – wszystkie sytuacje brzegowe wychodzą podczas implementacji. Złożoność problemu jest odkrywana małymi kroczkami. W efekcie projekty ciągną się miesiącami, a systemy nie mają żadnej logicznej struktury, a redundancja jest olbrzymia. Na szczęście jest refactoring – doskonały excuse dla wszystkich uczestników zwinnego procederu. Oczywiście tego typu metoda – bliska metodzie prób i błędów – wprost przekłada się na czas i koszty, ale tego na ogół się nie dostrzega, bo wszyscy są przekonani, że lepiej się nie da.

    Uwagi Pana Piotra, to dla mnie klasyka gatunku. Product Owner, o którym Pan pisze występuje tylko w rozwiązaniach startupowych, w dużych firmach podziału na stakeholderów i ludzi od realizacji nie da się uniknąć, bo księgowa nie ma czasu i ochoty na pilnowanie realizacji, a z kolei product owner pracujący z zespołem nie jest księgowym. Nawet kiedy wymyśla się jakieś features, to na końcu jakiś dyrektor, prezes, itp. muszą chcieć to zasponsorować, więc ta słynna decyzyjność PO jest w dużym stopniu mitem. Realny product Owner może mieć swoją wizję rozwiązania, ale musi ją ciągle negocjować z otoczeniem i w tym sensie powinien tak jak Pani Hanna mieć zdolności analityczne, by rozumieć wpływ swoich pomysłów na system.
    Tekst o trudnym Scrumie i Kanbanie również jest już mocno oklepany. Jeśli występuje jakaś trudność w tych podejściach, to polega ona na tym, że generują one coś, co w teoriach systemów nazywa się złożonością przypadkową, w odróżnieniu od tzw. złożoności esencjonalnej, której nie da się zredukować. Polega to na tym, że oferowane mechanizmy przewidziane w tych rozwiązaniach są nieadekwatne (za proste) w odniesieniu do wyzwań i problemów (w prostych projektach 2-3 osobowych pewnie nie ma to znaczenia, ale przy 20-100 osobach wszystko pęka). W efekcie powstaje spory chaos. Wszystko rozwiązuje się na groomingach, do których na ogół nikt się nawet nie przygotowuje. Po czasie scruma zaczyna się spontanicznie uzupełniać lub zaczyna się upgrade scruma do postaci LeSS, itp. Efekt na ogół i tak jest mizerny, bo nikt nie panuje nad wymaganiami – dla analizy w tych podejściach ciągle nie ma miejsca. Oczywiście nadal można wierzyć, że jakaś perfekcyjna implementacja scruma poradzi sobie ze wszystkimi problemami, ale jest to dla mnie przejaw naiwności, a nie realnej oceny sytuacji. Proszę mi wierzyć widziałem w akcji, na wewnętrznych szkoleniach największych guru światowego agile, niezwykle zaangażowanych scrum masterów, developerów i product ownerów mocno wierzących w nowy tren, którzy zaliczyli dziesiątki szkoleń i konferencji, przeczytali opasłe tomy dotyczące zwinności i wielu z nich uznawanych jest za polskie autorytety w dziedzinie zwinności, a pomimo tych wysiłków efekty naprawdę są dość przeciętne.

    Podsumowując, ten przydługi wpis: obawiam się, że agile to metodyczny regres, który potrafi bardzo dużo kosztować. Jednak jak w całym biznesie, czasami o wielu rzeczach decydują trendy, mody a nie dane, czy argumenty. Być może za kilka lat zasada: pomyśl, za nim coś zrobisz wróci ponownie do łask ;-)

    • Wow :) Dziękuję, że podzielił się Pan tymi obserwacjami. Ciekawie słyszeć jak inni to widzą ze swoich, odmiennych doświadczeń. Też ciekawa jestem przyszłości. Może stare podejścia były tezą, agile – antytezą, a teraz czekamy na syntezę?
      Pozdrawiam serdecznie!

      • Zgadzam się. Też uważam, że złoty środek jest możliwy, jednak istotne jest to, by nie pomijać istotnych etapów procesu wytwórczego, a z tym wiele zwinnych metodyk ma dzisiaj kłopot. Pan Mariusz pisze, że nie jest prawdą, że zwinne metodyki nie uwzględniają analizy oraz architektury. Być może istnieją takie podejścia, ale są one obecnie marginesem. Dowodem na to, może być słynny oksymoron: „architektura wyłaniająca się”, który tak często bywa przywoływany na szkoleniach ze scruma ;-).

        Pozdrawiam.

    • Metodyczny regres? Większość metodyk agileowych czerpie z filozofii LEAN Manufacturing (value-centric, flow, pull, leveling, small batches, just-in-time, itd.), które powstały na długo za nim ktoś w ogóle zaczął robić duże projekty IT.

      Product Owner który musi negocjować product backlog z różnymi interesariuszami to coś złego? Nie, to narzędzie do maksymalizacji jego wartości. Nie sprawdza się w dużych firmach? Dziwne, skoro firmy zatrudniające setki/tysiące programistów i dziesiątki/setki product ownerów stosują go z sukcesem. Wszystkie one się mylą?

      Agile nie sprawdza się w dużych projektach? Tak. Badania pokazują, że w projektach większych niż 10000 punktów funkcyjnych, wytwarzanie zgrzyta niezależnie od tego jaką metodę wybraliśmy. Tylko dlaczego z tego powodu mamy nie wytwarzać zwinnie w mniejszych projektach, których, zaryzykuję, jest znacznie więcej w naszej codziennej pracy?

      • Michale, nie jestem pewna, czy dobrze zrozumiałam Twój komentarz. Zgadzam się, że product owner musi negocjować. Niech to będzie i w product backlogu. Nie twierdzę, że się nie sprawdza. Mówię, że to trudne i że to nie jest jedyny sposób. Jeśli ktoś wszystko ogarnia, a nie robi inżynierskiego zarządzania wymaganiami, projektów i modeli, to chętnie go poznam i zapytam jak to robi.
        Nie pisałam też, że agile się nie sprawdza w dużych projektach. Głównym przesłaniem jest to, że w złożonych projektach nie widzę dużej różnicy między agilowym a innym sensownym projektem. I to, że wiele ludzi z automatu odrzuca coś, co się nie nazywa agilem, choć czasem właśnie nie ma dużej różnicy lub inne rozwiązanie może działać lepiej w danym przypadku.

      • Najwyraźniej Panie Michale mamy odmienne oczekiwania wobec pojęcia metodyka. Filozofia LEAN to dla mnie zbiór metafor, który bez operacjonalizacji niewiele w praktyce znaczy. Np. wskazane przez Pana hasło value-centric to tylko postulat, który jeśli nie zostanie zinterpretowany przez jakiś konkretny sposób działania, procedury, form definiowania celów może zostać uznany co najwyżej za banał. Operacjonalizacją agile jest np. scrum, który sugeruje zorganizować cały proces wytwarzania oprogramowania wokół kilku ról i szeregu rytuałów. Na tym poziomie można go moim zdaniem oceniać, bo jest to pewien konkret. Jak już pisałem wcześniej dla mnie rezygnacja z analizy jako istotnego etapu projektowania systemu, to świadectwo regresu, dowód braku zrozumienia na czym polega identyfikowanie wymagań, modelowanie, odkrywanie głębokiej struktury systemu itd. Efekty tego typu działania widzę na co dzień i choć wszyscy się starają, to pewnych braków wynikających ze wskazanego pominięcia na ogół nie potrafią przezwyciężyć.

        Argument z nieomylności większości nie jest bez znaczenia, ale jest mało merytoryczny. Proszę przyjrzeć się zjawisku mody, dominującego trendu, opinii publicznej. Wszystkimi tymi zjawiskami rządzą pewne prawidłowości z obszaru psychologii społecznej (m.in. konformizm), które z perspektywy tzw. myślenia krytycznego bywają po prostu niezrozumiałe, a mimo wszystko istnieją. Tak jest jak sądzę w dużym stopniu z agile. Przeżywamy rodzaj mody i dopóki nie pojawi się jakaś nowa moda lub fala krytyki nie spodziewam się jakiś istotnych zmian. Proszę zauważyć, że w wielu miejscach kiedy pojawia się decyzja o przejściu na scruma, często też pojawia się Pański argument: „przecież cały świat nie może się mylić” – mamy zatem rodzaj samospełniającej się przepowiedni. Co ciekawe, po pewnym czasie wszyscy są przekonani, że inaczej już nie można pracować. Obawiam się, że brakuje dziecka, które powiedziałoby: „król jest nagi”.

        • „Filozofia LEAN to dla mnie zbiór metafor”
          OK, a dopuszczasz fakt, że tak naprawdę o LEAN niewiele wiesz? LEAN Production System oraz LEAN Management System to zbiory liczące po kilkaset (sic!) narzędzi udoskonalanych od dziesięcioleci. Bardzo konkretnych, tyle że z oczywistych powodów to nie miejsce by wchodzić w szczegóły, rzuciłem więc tylko najważniejsze pryncypia. Jeśli dla Ciebie to jest zbiór metafor, tzn. że nie zadałeś sobie zbyt wiele trudu by go poznać. Zapraszam do jakiejkolwiek fabryki samochodów lub ich część na Śląsku. Zobaczysz prawdziwy LEAN, od najmniejszej czynności stanowiskowej, po zarządzanie fabryką.

          „rezygnacja z analizy jako istotnego etapu projektowania systemu, to świadectwo regresu” – i na tym polega Twój błąd. Żadne podejście agile’owe nie eliminuje czegoś takiego jak analiza. To że nie ma takiej roli/stanowiska/etapu nie oznacza, że nie można jej robić. Jeśli jakiś zespół bierze się za development nie rozumiejąc natury przedmiotu, za który się zabiera, to jest to dowód na niedojrzałość zespołu, a nie problem metody. To właśnie dlatego mówi się o tym „difficult to master”, bo wymaga od ludzi ogromnej dojrzałości i odpowiedzialności. Tak, w waterfallu jest przeświadczenie, że procedury i metody zabezpieczą nas przed ludzką niekompetencją. Tyle że to zabezpieczenie to jest dodatkowy koszt, za który płaci klient. W agile’u kładziemy nacisk na rozwój ludzkich kompetencji.

          • Hmm, właśnie przejrzałem Michale „Lean Software Development: An Agile Toolkit” i nie zauważyłem niczego, co jakoś szczególnie by mnie zaskoczyło (170 stron, przy czym spora część poświęcona jest waterfallowi -;)). Może nie są to tylko metafory, ale poziom tej książki nie odbiega szczególnie od dobrych rad scrum guide’a. Wątki analizy i architektury systemu pojawiają się w formie zdawkowej. Być może moje studia nad lean’em nie są zbyt głębokie, ale nie przypomina mi to Traktu logiczno-filozoficznego, który mógłby odmienić moje życie ;-). Co do przemysłu samochodowego się nie wypowiadam :P.

            „Jeśli jakiś zespół bierze się za development nie rozumiejąc natury przedmiotu, za który się zabiera, to jest to dowód na niedojrzałość zespołu, a nie problem metody.” – hmm, musiałbyś Michale zadać sobie pytanie, skąd bierze się dojrzałość. Tego typu stan nie bierze się znikąd. Masz dwie możliwości: albo będziesz przez 20 lat pracował, popełniał błędy, analizował je i wyciągał wnioski, albo weźmiesz na warsztat określoną metodykę i za jej pośrednictwem przeskoczysz co najmniej 15 lat eksperymentów – po to właśnie są metodyki, by pomóc zespołom realizować pewne działania niemal bezbłędnie. Jeśli zwinne metodyki wychodzą z założenia, że za nim zaczniesz z nich korzystać masz być już dojrzały i doskonale wiedzieć, co masz robić, to sorry, ale jest to dla mnie jakieś nieporozumienie.

            ——————————————
            Chapter 1. Eliminate Waste
            The Origins of Lean Thinking
            Tool 1: Seeing Waste
            Tool 2: Value Stream Mapping
            Try This
            Chapter 2. Amplify Learning
            The Nature of Software Development
            Tool 3: Feedback
            Tool 4: Iterations
            Tool 5: Synchronization
            Tool 6: Set-Based Development
            Try This
            Chapter 3. Decide as Late as Possible
            Concurrent Development
            Tool 7: Options Thinking
            Tool 8: The Last Responsible Moment
            Tool 9: Making Decisions
            Try This
            Chapter 4. Deliver as Fast as Possible
            Why Deliver Fast?
            Tool 10: Pull Systems
            Tool 11: Queuing Theory
            Tool 12: Cost Of Delay
            Try This
            Chapter 5. Empower the Team
            Beyond Scientific Management
            Tool 13: Self-Determination
            Tool 14: Motivation
            Tool 15: Leadership
            Tool 16: Expertise
            Try This
            Chapter 6. Build Integrity In
            Integrity
            Tool 17: Perceived Integrity
            Tool 18: Conceptual Integrity
            Tool 19: Refactoring
            Tool 20: Testing

  5. Pani Haniu również podzielam zdanie Panów, w większości Pana Mariusza, Pana Karola i Pana Piotra (ale bez ostatniego zdania) lub w pewnym sensie przyjmuję wypowiedź Pana Sceptyka, ale też nie do końca podzielam z nimi swoje zdanie.

    Tak, to jest temat (rwąca) rzeka. Zostałem zaintrygowany do wskoczenia w jej nurt :)

    Wtrącę na wstępie tylko, że korzenie Scruma sięgają wstecz, zanim jeszcze wzięto go pod parasol Manifestu Agile i przypisano do podejścia Zwinnego (Agile) oraz zdefiniowano jego ramy. Było to pierwotnie bardziej zamysł efektywnego zarządzania procesem produkcyjnym, niż próbą odzwierciedlenia go w zarządzaniu sterowanym planem.
    Teraz niestety coraz częściej widzę, że Scrum zaczyna być coraz częściej błędnie interpretowany, jak też inne środowiska zwinności lub ich skalowalne wersje.

    W poniższym komentarzu przyjmę do reprezentowania zwinności, środowisko Scrum, jako właśnie pomocne głównie do procesu wytwórczego i jeśli trzeba skalować to też do współzarządzania.

    Zaznaczam, że Scrum występuje tylko w swojej niezmienionej postaci.

    -Do rzeczy:

    Ad. 1 „Wielkie projekty agilowe”
    -Znając ogólnie metodykę PRINCE2, myślę, że jestem w stanie odpowiedzieć na Pani pytanie postawione na początku artykułu: „[…] Czym to się różni od innych metodyk, jak np. PRINCE2? ” oraz wyjaśnić nieścisłości powstałe w artykule, które wywołały dyskusję.

    Otóż, Scrum stawia na ludzi. Ich umiejętności, motywację, zaangażowanie, doświadczenie, samoorganizację i wiedzę (o Scrumie, w danej dziedzinie problemowej, techniczną) i więcej.

    Ale, czy ludzie, którzy zarządzają projektem za pomocą metodyki PRINCE2, „ręczą” za osoby sobie podległe (które mają różne poziomy umiejętności i nie koniecznie muszą wiedzieć co to PRINCE2 i czy wiedzą czym jest samoorganizacja, motywacja itd. itp.) w wykonywaniu swoich zadań?
    Nie.
    I dalej. Czy w PRINCE2:
    -ludzie Ci, szybki zaadoptują się na nieoczekiwane zmiany?
    Nie.
    -jeśli coś pójdzie nie tak to, czy wszyscy poczuwają się do odpowiedzialności zaadoptowania tych zmian?
    Nie.
    -występuje minimalizm formalności?
    Nie.
    -wszyscy mają prawo głosu w nieoczekiwanych sytuacjach?
    Nie.
    Mógłbym zadawać kolejne pytania, dla kontrastu, ale myślę, że widać o co mi chodzi.

    Ok, zatem do czego zmierzam?
    Pisała Pani kiedyś również dla kontrastu porównania: http://analizait.pl/2014/pmbok-vs-prince2-i-scrum/
    że Scruma można używać do procesu wytwarzania i np. innej metodyki do zarządzania tymi procesami oraz, że nic nie stoi na przeszkodzie łączenia Scruma z innymi metodykami pomocnymi do zarządzania projektami.
    Trochę to jest sprzeczne z tym o czym Pani napisała teraz.

    Nawet Twórcy Scruma nie negują dołączania innych technik i metodyk do ram Scruma, a nawet sugerują taką możliwość.

    Ale, żeby nie być gołosłownym: przykładowo (fakty) – firma opiera się na zarządzaniu projektami w oparciu o PRINCE2, ale są różne zespoły wytwórcze, które chcą pracować w oparciu o różne środowiska, czy podejścia: Scrum, XP, Lean, w oparciu o Model kaskadowy, „czy jak im się tam wydaje najlepiej, ale działa” itd. Czy można tak pracować?
    Jasne, że można.
    Czy ktoś daje gwarancję, że wszystko razem będzie pracowało jak w szwajcarskim zegarku?
    Niestety nie. Ale też nie jest potwierdzone, że to zadziała lub nie.

    Więc o co chodzi z LeSS (Large Scale Scrum), Scrum of Scrums, SAFe (Scaled Agile Framework)?
    A o to, że jeśli już mamy twarde fundamenty wypracowane przez małe zespoły w oparciu o środowisko Scrum, czy inne zwinne środowiska, to wtedy możemy zacząć je przenosić na wyższy poziom, opierając się cały czas na rdzeniu Scruma lub innego środowiska zwinnego, bez utraty pierwotnych zasad, założeń, celów, praktyk, wartości tych środowisk. Nie da się odpalić wszystkiego na raz.
    Przykład? Nie jest to jeszcze mój poziom doświadczeń, ale odsyłam do blogu Pana Mariusza Chrapko: http://mariuszchrapko.com/scrum-of-scrums-czyli-jak-koordynowac-zaleznosci-w-projektach-agile/

    Tak samo, aby zaadoptować Scrum w małym zespole potrzeba bardzo dużo ciężkiej i wspólnej pracy, aby coś zaowocowało. To też przejście na wyższy poziom zarządzania tymi zespołami, wymaga jeszcze większego nakładu pracy i zaufania. Ale jeśli wszystko razem „ładnie zagra” to gwarancję sukcesu mamy obiecaną przez Twórców Scruma.

    BTW1
    „Duże i złożone jest to, czego nie znasz.” – i tak i nie.
    -To coś może być duże i złożone, może być zarazem znane. Przykładowo Wieża Eiffla – jest duża i złożona. I jeśli posiadając odpowiednie materiały i chęci – chcę ją zbudować samemu, to było by to łatwiejsze niż np. zbudowanie Empire State Building – przecież też jest „duży i złożony”, ale nie jest już na tyle znany i łatwy do poznania, aby go zbudować samemu.

    Tutaj ważna jest umiejętność, wiedza i doświadczenie przeskakiwania między środowiskami i podejściami, tak aby wybrać odpowiednie do danego projektu rozwiązanie czy podejście.
    Nie da się wykorzystać jednego szablonu do wszystkiego.

    Ad. 2 „Magiczna skrzynka Product Ownera”
    -Skalowanie. Po to jest właśnie LeSS (Large Scale Scrum), Scrum of Scrums, SAFe (Scaled Agile Framework)? lub mówi o tym przytoczony artykuł powyżej, napisany przez Pana Mariusza Chrapko.

    Ad. 3 „Czy jestem waterfall’owa?”
    -Podejrzewam, że Pani po prostu jeszcze nie polubiła niepewności i trafiła na tych „złych”. Więc preferuje Pani strefę komfortu „sterowanego planem” i jest to zrozumiałe i dające jakiś poziom pewności.
    Ale jeśli Pani ma na myśli nieporządek w domu oraz Pani przykłady sytuacji życiowych – to Agile nie będzie dobrym porównaniem.

    Ja zwinność (Agile) w sytuacjach życiowych porównuje do takich sytuacji:

    Wyobraźmy sobie, że jestem w domu i kończę pakowanie paczki do nadania dla kuriera, który zaraz przyjedzie. Jest godzina 17:45. Spodziewałem się, że w tych godzinach przyjedzie. Zostawiłem sobie jeszcze jedno zadanie do wykonania współbieżnie (ale o nim poniżej).
    Mieszkam w bloku, który ma 9 pięter, ale ma też dwie windy do których, aby dojść trzeba przejść 10 metrowy korytarz. Winda zanim się zatrzyma na piętrze, otworzy drzwi i zamknie, zjedzie na parter i wypuści użytkownika, mija dobre 90 s. (nie wiesz/nie myślisz, czy po drodze Pani z dzieckiem w wózku nie zatrzyma Cię w windzie, aby wejść na 1 piętrze – jeszcze tego nie zakładasz, najwyżej będzie kilkanaście sekund więcej poślizgu). OK.
    Nagle dzwoni, kurier i mówi, że czeka na zakazie zatrzymywania oraz prosi o szybkie zniesienie paczki, ponieważ ma opóźnienie spowodowane, złapaniem wcześniej kapcia w oponie swojego samochodu. OK.
    Kończę pakować paczkę, zabieram kurtkę oraz receptę do wykupienia w aptece (to jest to zadanie). Z doświadczenia, wykonuję „myk” – idę zamówić windę, aby już przyjechała zanim zamknę drzwi od domu (i tak będę czekał). Kończę się ubierać, zabieram paczkę i zamykam drzwi, winda przyjechała.
    Idealnie zagospodarowany i ułożony w czasie prosty plan dostosowany do sytuacji.
    Wchodzę do windy wciskasz zero. Winda powoli zamyka drzwi..
    Iskierki w głowie zaczynają świecić i nagle przypominam sobie, że nie wziąłem telefonu (potrzebuje się skontaktować z kurierem jak go nie zobacz pod blokiem lub później może będę go potrzebować w aptece) i portfela (muszę zapłacić jakoś w aptece, które w najbliższym promieniu są otwarte tylko do 18:00).
    Co teraz zrobić? Jaką drogę wybrać? Jak rozdzielić priorytety? Co jest ważniejsze? Czy mogę z czegoś zrezygnować? Czy mogę coś przełożyć? itd.

    Załóżmy, że mamy w tej sytuacji takie możliwość:

    1. Zjeżdżam pokornie na dół. Wciskam 9 i wracam po portfel i telefon (kosztem czasu kuriera i swojego – zaraz apteki zostaną zamknięte). Otwieram drzwi, szukam portfela gdzie on jest? Jest. Czas leci. A jeszcze telefon, gdzieś tutaj był? Hmm. Jest!
    Idę zamówić windę. Czekam Jest. Drzwi się otwierają, wchodzę i wciskam 0. Szybko szybko poganiam windę itd. Biegnę lub tylko idę do kuriera.
    Opis dodatkowy: w tej sytuacji można by było wykorzystać trochę tzw. „zwinności” i sprytu, np. zastawić drzwi windy przesyłką, tak żeby winda poczekała, aby szybko zjechać później na dół oraz przypomnieć sobie między czasie gdzie jest telefon i portfel, aby nie szukać bez pomysłu pod wpływem stresu (nagła luka w pamięci, tyk tyk). Kurier czeka, apteka.. itd.

    2. Rezygnuje z apteki. Nie chce ograniczać czasu Kuriera. Ale, co jeśli nie znajdę go pod blokiem? Olał mnie i pojechał. Czy paczka i apteka może poczekać do jutra, czy poniosę koszta, odpalę samochód i pojadę do apteki 24h na końcu miasta. Ale co z paczką? Też jest ważna, ktoś tam na nią czeka. Obiecałem, że dojdzie na drugi dzień. itd. Wrócić się, zadzwonić po Kuriera, kupić leki i poczekać łaskawie na Kuriera? Strasznie to niepewne.

    3. Inicjuję włączenie tzw. ” opcji zwinności”. Szybka ocena sytuacji i prawidłowe działanie. Wciskam piętro 8 i 7. Powstrzymałem drzwi ręką i wybiegam z paczką pod ręką z windy. Przypominam sobie w tym czasie, gdzie mam portfel i telefon. Biegnę pod drzwi wejściowe, otwieram je, biorę szybko portfel i telefon. Zamykam drzwi i biegnę do klatki. Wiem, że zanim otworzą i zamkną się drzwi mija kilka dobrych sekund. Zbiegam na 8 piętro, widzę, że drzwi właśnie się zamykają -wciskam przycisk, aby się otworzyły ponownie. Udało się. Zjeżdżam na dół. Po drodze zatrzymując się tylko na 7 piętrze (wziąłem dodatkowy margines, czasu, aby plan się nie spalił-zaakceptowałem dodatkowy koszt). Po drodze na szczęście nie było przystanku na pozostałych piętrach. Kurier dostaje paczkę, podpisuje protokół odbioru, a ja biegnę do apteki, zostało 5 min do 18. Ale, nie wiem, czy nie będzie dużej kolejki. Na szczęście nie ma. Wykupuje receptę.
    Wracam do domu jestem zadowolony, wszystko się udało rzutem na taśmę. Misja wykonana.
    Opis dodatkowy: mogłem też ustawić przesyłkę w drzwiach, aby zastawiła drzwi i zrealizować podobnie powyższy plan, ale zasoby myślowe wybrały coś innego.
    Ok, ale co jeśli nie pamiętałbym gdzie jest telefon i portfel? – 8,7, 0. Zamawiam następną windę. Czas ucieka.
    Co jeśli nie było by kuriera lub byłby problem z przyjęciem paczki, bo właśnie Pan Kurier dostaje mandat? Co jeśli byłaby kolejka w aptece? Co jeśli byłaby Pani z dzieckiem w wózku na pierwszym piętrze lub co gorsza dziadek z babcią o lasce na trzecim. Zbiegać z pierwszego, trzeciego? – nie opłaca się, zyskam tylko kilka sekund lub skręce kostkę. Poganiać staruszków – nie wypada. itd itd. można tak w długo mieszając okoliczności tych trzech historyjek i więcej.

    Ścieżki mogą być bardzo złożone mimo tak prostej sytuacji, ale też są obarczone pewną dozą niepewności, napięcia, konieczności szybkiego podjęcia decyzji.

    Brzmi znajomo? Sytuacje, możliwości, dylematy itd., wypisz, wymaluj Projekt, ale na mniejszą skalę.

    To tylko pojedyncza sytuacja, ale co jeśli dodamy więcej powiązań?
    Na pewno pójdzie coś nie po naszej, docelowej myśli.
    Dlatego mamy te wszystkie metodyki i narzędzia. Ale czy potrafimy się nimi posługiwać i wykorzystać w 100% ich możliwości? Różnie to bywa.

    [..]
    „Skąd mam to wszystko wiedzieć? Muszę to sobie poukładać w głowie. Uporządkować. Zbudować logiczną konstrukcję, która oprze się naporowi trudnych pytań. Jeśli ja nie potrafię złożyć logicznej całości, jak developerzy mają to zbudować?”

    -Wydaje mi się, że nie dostaje Pani, wystarczająco dużo czasu na Analizę. Każdy się z tym boryka.
    Jest to problem Biznesu, który nie inwestuje w dobre Wymagania i Analizę oraz skupia się tylko na procesie wytwórczym (Biznes woła „produkujemy!”). Ale jak wiadomo różnie to bywa z Programistami, ale to oni odwalają ciężką pracę wytwórczą, Analitycy (muszą szybko przedstawić wymagania, aby dać pracę Programistom), Kierownicy projektów (zarządzać, pilnować, rozliczać zasoby ludzkie i materialne), wszyscy muszą ciężko pracować. Ale czy uda się pracować, tak jak w szwajcarskim zegarku? Hmm..

    OK, a czy Biznes rozumie zasady Trójkąta jakości (ograniczeń)? Czy ma świadomość skutków nagięcia, któregoś z wierzchołków?
    Nie (lub może..).
    Ale czy się tym przejmuje?
    Nie (lub może..).
    Biznes wie, że bez niego IT nie może istnieć, ale czy zawsze pamięta, o tym że ten właśnie Biznes, nie może żyć bez IT?
    Może wie, może nie. Może nie zdaje sobie z tego sprawy.
    Biznes płaci i wymaga – tj. pewne.

    Ad. 4 „Każdy radykalizm bierze się z traumy”
    -Przyczyny można znaleźć na przestrzeni całego mojego komentarza lub Panów i lub też Pani odpowiedzi pod te komentarze (jak pisałem ten komentarz czas leciał – adoptowałem i nanosiłem zmiany „zwinnie”, aby powstał produkt – mój komentarz).
    Ogólnie przyczyny te wynikają z chaosu w projektach IT oraz braku prawdziwej dojrzałości IT i Biznesu.
    Tak jest i będzie jeszcze długo zanim nauczymy się współpracować i komunikować oraz będziemy mieli wspólne cele i wartości.
    Czy można z tym walczyć? Zawsze można próbować.

    Ad. 5 „Czy agile jest agile?”
    -Klasyka problemów tradycyjnego podejścia oraz problemów adaptacji zwinności w organizacji :)

    [..]
    „Jeśli wywalasz za drzwi człowieka, który potrzebuje informacji, żeby pracować i pomagać pracować zespołowi, to czy jesteś agilowy? Stawiasz na pierwszym miejscu ludzi czy podążanie za zdefiniowanym agilowym procesem?”

    -Nie to jest po prostu brak dojrzałości takiej osoby i uprawianie pseudo zwinności.

    Spotkała się Pani prawdopodobnie z tzw. pseudo Scruem. Grupa osób postanowiła pracować według zasad środowiska Scrum i coś tam sobie po czytała, wybierając i wypierając wszystko co im pasuje lub nie (Pan Piotr coś pisał o tym i Pani wy wnioskowała w odpowiedzi do jednego z komentarzy -też musiał nanieść wzmiankę, do tego co już napisałem).

    -Doświadczyła Pani nie dojrzałości „Panów z IT” i jestem Pewny, że Ci Panowie, zanim zaczęli wykorzystywać niektóre ramy środowiska Scrum, wcześniej borykali się (lub nadal to robią) z problemami typu: „specyfikacja jest nie kompletna, ch….., „, „a czy było to w specyfikacji?” itd. itp., za bardzo takie osoby nie chciały też uczestniczyć w warsztatach (bo to strata czasu), potrafili tylko krytykować i zwalać winę za nie powodzenia na Analityka biznesowego lub Biznes.
    Panowie Ci zatem forsują przekonanie do minimalizmu dokumentacji, jednak nie są w stanie kontrolować tego co robią. Zapytani pewnie o szybkość swojego zespołu lub ostatnie wyceny IT – nie potrafili by odpowiedzieć na te pytania zbyt rzeczowo.

    Zespół Programistów, aby pozostał zwinny, musi być mały, tak jak cały Zespół.

    Wszystkie problemy wynikają z problemów adaptacyjnych, nieumiejętnego mieszania środowisk, mieszania faktów i wiedzy itd. czego skutkiem jest błędne rozumowanie ram środowiska np. Scrum, czy zwinności. Co w efekcie daje niezłe sprzężenie zwrotne.

    Ad. 6 „Bądź interfejsem”

    Tak jak pisałem Twórcy Scruma deklarują, że nadaje się on do wykorzystania jako ramy do innych metodyk, praktyk czy technik, więc nie wiem dlaczego „Przypadki użycia” nie zostały obronione w Pani sytuacji przed Zespołem Deweloperskim, jeśli zostały przedstawione w analizowanym/realizowanym projekcie.

    [..]

    Wszystko prawda, ale w środowisku Scrum, objęcie roli Product Ownera przez Analityka biznesowego to za mało. W najlepszym przykładzie mógłby być nim były Analityk biznesowy, który jest obecnie Kierownikiem Projektu.
    Nie pamiętam, ale ktoś kiedyś napisał, że wykonywana praca przez Analityka biznesowego, jest w stanie zapewnić pracę dla sześciu programistów i kontrolować przyszłe zmiany tej pracy. W Scrum zadziała to tylko wtedy jeśli taki Analityk ma duże uprawnienia.
    W przeciwnym wypadku można się bawić w Scrum i doświadczać problemów: Product Owner:
    – o zbyt małych uprawnieniach (Analityk biznesowy),
    -przepracowany (Kierownik projektów),
    -odległy (Kierownik projektów),
    -zastępczy (Analityk biznesowy), o podzielonych obowiązkach(Analityk biznesowy z funkcją Kierownika projektów),
    -komitet Product Ownerów (Kierownicy Projektów/Analitycy biznesowi).

    Ad. 7 „Najlepszy człowiek do pracy”
    I najlepiej, aby można było takich ludzi klonować :)

    BTW2
    Mam mniejsze doświadczenie od Pani w Analizie biznesowej, ale zaczynałem swoją karierę zawodową w projektach IT od hybryd podejścia tradycyjnego i zwinnego. Były i są to dość ciekawe doświadczenia. Przez to może inaczej do tego wszystkiego podchodzę i mam to inaczej poukładane w głowie.
    Co z tym zrobię? Nie wiem. Przyjmuję na razie jedną stałą: „zmiany” i „cisnę” do przodu. A jak się na tym przejadę, to też będzie zawsze jakieś doświadczenie :)

    Tak, więc na zakończenie proste podsumowanie i cytaty[URL] (też już to padło w komentarzach, ale zanim odpisałem minęło trochę czasu):
    Scrum jest prosty („prościutki”) do zrozumienia, ale bardzo trudny do opanowania (mam tu na myśli: problem adaptacji tego środowiska w organizacji) [przed wdrożeniem „czegoś”] (aby to coś wdrożyć, najpierw trzeba uzyskać wiedzę, potem ją opanować oraz posiadać już pewne umiejętności i dopiero wtedy to wykonać), czyli do wdrożenia.

    Cytaty ponadczasowe, niektóre dobrze wpisujące się w kontekst:
    http://lubimyczytac.pl/cytaty/31648/autor/albert-einstein

  6. Długość wpisu świadczy o ogromnych emocjach, jakie za nim stoją :-)

    W którymś z komentarzy już padło, że agile to przede wszystkim zmiana filozofii, kultury, czegoś o wiele bardziej głębszego, niż procesy, role, odpowiedzialności. Gdybym miał znaleźć jedno słowo, najlepiej opisujące różnicę między agile’em i waterfallem, to byłoby to słowo „pull”. Stara LEAN’owa zasada zasysania pracy, która jest kluczowa do eliminacji marnotrastwa. Bez niej, zostaje nam waterfall :-)

    Zapraszam do nas do firmy. Zobaczysz jak pracujemy, co to znaczy agile, opowiem Ci jak przechodziliśmy od waterfall’a, pokażę Ci zespół analityczny, który umie robić i use cases i user stories, i który wybiera sobie narzędzia i techniki za pomocą których chce zobrazować daną historyjkę, nie bojąc się takich dziwactw jak diagramy klas czy sekwencji. Pokażę jak agile w dużej firmie działa, i też gdzie nie działa.

    A jestem osobą, która do agile’a podchodziła bardzo nieufnie i która na własnej skórze przekonała się, że jest to po prostu o wiele bardziej produktywny sposób wytwarzania oprogramowania dla ZDECYDOWANEJ większości projektów, z którymi w firmie się borykamy (co nie znaczy, że wszystkich na świecie). Produktywny na każdym poziomie: jakości, satysfakcji ludzi, ROI, itd. Co nie zmienia faktu, że aby był produktywny, musi być robiony dobrze, jak wszystko za co się zabieramy.

    A na koniec wytłumaczę Ci dlaczego zrobienie dziesiątek kursów i przeczytanie dziesiątek książek nie jest wystarczające, aby zrozumieć co to znaczy „być agile”. A przynajmniej spróbuję :-)

  7. Odpowiadając na Twoje pytanie, tak to, że nigdy nie widziałaś Agile jest problemem. Stąd jak sama piszesz może rodzić się radykalizm przed nieznanym i trauma. No i pan od Agile rozłączył się bez słowa, to boli. No i ten Scrum Master co wyrzuca za drzwi. A próbowałaś poza spotkaniami zagadać z zespołem? Zespół potrzebuje Ciebie, czy Ty jego? :)
    Czym Agile różni się od PRINCE2? PRINCE2 zajmuje się sferą zarządzania, a Agile wytwarzania oprogramowania. Agiel to jest mindset, PRINCE2 zbiór praktyk i sposobów postępowania. Porównywalny z PRINCE2 jest PMI, czy dokładniej zbiór wiedzy PMBOK Wiesz, że jest PRINCE2Agile? :) Różnica jest też taka, że skupiamy się na dostarczaniu Produktu, a nie zarządzaniu projektem. Zespoły same organizują pracę i szacują, więc biorą odpowiedzialność. Waterfall jest kiepski pod tym względem, ze klient płaci, długo czeka na efekt i na końcu dostaje coś, czego nie potrzebuje albo nie chce. W Agile szybko dostanie wartość i szybko dojdziemy do porozumienia pokazując efekty na każdym kroku.
    Wrzucasz do wora spotkanie między-zespołowe (Scrum of Scrums) z SAFe (jak ułożyć całą organizację w Agile) i Less (podzielmy Produkt na obszary). Wow. Dobrze, że nie znalazłaś modelu Spotify i Nexusa. To dopiero abstrakcja :) No ale jak nie ma zrozumienia Agile i Scrum, to gdzie iść w skalowanie. Trochę inna skala i pomysły. Skąd w ogóle liczby 500 i 300? W SAFe w obrębie jednego pociągu jest 120 osób, czyli liczba Dunbara i nie znaczy to, że pracują ze sobą na co dzień. Więcej osób po prostu nie da się ogarnąć i poznawać nawet z twarzy tylko. Praca odbywa się w zespołach a Agile Release Train to taki zespół zespołów, który potrzebuje trochę koordynacji. Wyżej jest portfolio i finansowanie, które dają input.
    Tak, w wielu miejscach słowa Agile i Scrum są nadużywane, a w zespołach mnóstwo dysfunkcji. Niektóre sama wychwytujesz. To nie ma tak wyglądać. Czy to wina Agile i Scrum? Jeśli nie potrafią zastosować prostych ram, to PRINCE2 też nie pomoże. Waterfall ukrywał te problemy i opóźniał wybuch, teraz widać to bardziej i to kłuje w oczy. Scrum nie rozwiązuje problemów, on je uwidacznia. Większość organizacji woli zmienić Scrum niż siebie, bo ma brak odwagi do zmian.
    Analityk to jest specjalizacja w IT, a nie rola, więc nie ma potrzeby nazywania kogoś ze względu na specjalizację i zamykania w pudełku.
    Nigdzie nie jest napisane, że Analityk nie może być częścią wskroś-funkcjonalnego zespołu. Jeśli takie kompetencje są potrzebne, to czemu nie. Oczywiście lepiej by było, gdyby każdy Developer miał umiejętności analityczne.
    Teraz ten biedny PO :)
    Jak Product Owner dostarcza szczegóły user stories w ułamku sprintu lub sprint wcześniej mając do informacyjnego obskoczenia cały zespół?
    Korzystanie z User Story nie jest obowiązkowe. Dlaczego obskakuje zespół? Po co? Wymagania są tworzone i opracowywane cały czas. Product Owner jest odpowiedzialny za Product Backlog ale nie musi tego robić samodzielnie. Interesariusze mogą dostarczać szczegóły, lub może oddelegować cześć pracy do Zespołu Develoeprskiego, np. do analityka ;) Poza tym w środku Sprintu jest Product Backlog Refinement i zajmuje zespołowi max 10% capacity. I tutaj uszczegóławiamy wspólnie 1-2 Sprintów User Story.
    Jak on ogarnia zależności między elementami sytemu tworzonego przez kilkaset osób przez kilka lat? Jak ma czas być w stałym kontakcie z zadającym wiele pytań zespołem? I jak jeszcze spina to wszystko do kupy nie robiąc dokumentacji, której przecież nikt nie chce czytać?
    Duże systemy są dzielone na obszary, którymi zajmują się konkretne zespoły. W takim wypadku jest często jeden główny Product Owner i Area Product Owners (tak jest w LeSS) albo na poziomie Portfolio jest pewna hierarchia (SAFe). SAFe bardzo ładnie opisuje zależności w backlogu. Z resztą Dean napisał ksiązkę Agile Software Requirements zanim wydłbał SAFe. Widziałaś np. to: http://www.scaledagileframework.com/program-and-value-stream-backlogs/ ??
    Także PO nie ogarnia kilkuset osób ;) No chyba, że mowa o produkcie sprzedawanym bezpośrednio użytkownikom i chce z każdym osobiście porozmawiać :)
    Product Backlog jest dokumentacją wymagań i można tam wrzucać co potrzeba. Zespół też zwykle tworzy wiki i ma tam schematy, UML, BPMN i inne Visio, które mogą się przydać. Nikt nie broni. To co jest tylko zabronione, to siedzenie i dumanie, czyli Big Analysis Up-front. Po prostu zróbmy mały kawałek i sprawdźmy feedback.
    W Agile mamy zwykle osoby około 9-osobowe, więc przy większym PRODUKCIE musi ich być więcej niż jeden i muszą 1) zarządzać Product Backlog, 2) synchronizowąć iteracje i integrować przyrosty i tutaj pojawiają się tematy skalowania. Natomiast to co od dawna mówią guru od Scrum i Agile – nie masz tak dużego produktu, tylko ekosystem wielu mniejszych.
    Pozostaje mieć nadzieję, że trafisz w końcu na dobrą, zwinną organizację i ktoś Cię przytuli :)

    • „Odpowiadając na Twoje pytanie, tak to, że nigdy nie widziałaś Agile jest problemem. Stąd jak sama piszesz może rodzić się radykalizm przed nieznanym i trauma.”

      Ja tam we wpisie radykalizmu nie widzę, tylko nawołanie do tego żeby właśnie w niego nie popadać, co bardzo duża część środowisko agilowego nieustannie robi. Wszystko co nie pochodzi z ich myślenia o Agile’a jest ZŁE i jest waterfallem. Jak by metody adaptacyjne, czy oparte na empirizmie nie istniały wcześniej… Jak by wszystkie współczesne klasyczne metody na tym też się nie opierały…

      „No i pan od Agile rozłączył się bez słowa, to boli. No i ten Scrum Master co wyrzuca za drzwi. A próbowałaś poza spotkaniami zagadać z zespołem? Zespół potrzebuje Ciebie, czy Ty jego? :)”

      Mi się wydaje, że chyba ludzi w projektach potrzebują się nawzajem. I jak ktoś idzie ze sztandarami agile nad głową (scrum master) to powinno się być tego najlepszym przykładem.

      „Czym Agile różni się od PRINCE2? PRINCE2 zajmuje się sferą zarządzania, a Agile wytwarzania oprogramowania. Agiel to jest mindset, PRINCE2 zbiór praktyk i sposobów postępowania. Porównywalny z PRINCE2 jest PMI, czy dokładniej zbiór wiedzy PMBOK Wiesz, że jest PRINCE2Agile? :)”

      Porównywanie Agile do Prince2 nie ma sensu, bo to zupełnie jest do czego innego. Natomiast frameworków skalujących już jak najbardziej.

      „Wrzucasz do wora spotkanie między-zespołowe (Scrum of Scrums) z SAFe (jak ułożyć całą organizację w Agile) i Less (podzielmy Produkt na obszary).

      Nie są mieszane, tylko podane jako przykład.

      „Wow. Dobrze, że nie znalazłaś modelu Spotify i Nexusa.”

      Argumenty personalne (jak i niestety w wielu innych miejscach). Skąd wiesz że autorka nie zna tych modeli? Nie sprowadzaj proszę dyskusji do takiego poziomu.

      „Różnica jest też taka, że skupiamy się na dostarczaniu Produktu, a nie zarządzaniu projektem. Zespoły same organizują pracę i szacują, więc biorą odpowiedzialność. Waterfall jest kiepski pod tym względem, ze klient płaci, długo czeka na efekt i na końcu dostaje coś, czego nie potrzebuje albo nie chce.”

      Parafrazując Twoje własne argumenty ad personam – „chyba nie widziałeś dobrego projektu realizowanego w klasycznych metodykach”. Pryncypia PRINCE 2:
      – koncentracja na produktach
      – ciągła zasadność biznesowa
      – Zarządzanie etapowe
      Pod tym względem nie ma tu żadnej różnicy.

      „W Agile szybko dostanie wart.”
      Wielokrotnie (po stronie klienta) pracowałem z firmami, które szczyciły się i na rynku były uważne za wzór agile. Klienci mieli dokładnie te same problemy co zawsze – z otrzymaniem wartości, tylko było to często wielokrotnie droższe niż w podejściu klasycznym. W praktycznie każdej metodzie chodzi o to, żeby dostarczyć szybko wartość. Czy to „klasycznej”, czy agilowej. Tylko trzeba po pierwsze umieć ją zastosować, a po drugie mieć jakiekolwiek pojęcia o zarządzaniu i współpracy z ludźmi. I o to tak naprawdę chodzi.

      „Jak Product Owner dostarcza szczegóły user stories w ułamku sprintu lub sprint wcześniej mając do informacyjnego obskoczenia cały zespół?
      Korzystanie z User Story nie jest obowiązkowe. Dlaczego obskakuje zespół? Po co? Wymagania są tworzone i opracowywane cały czas. Product Owner jest odpowiedzialny za Product Backlog ale nie musi tego robić samodzielnie. Interesariusze mogą dostarczać szczegóły, lub może oddelegować cześć pracy do Zespołu Develoeprskiego, np. do analityka ;)”

      Dokładnie to samo robi się w klasycznych podejściach.

      „Poza tym w środku Sprintu jest Product Backlog Refinement i zajmuje zespołowi max 10% capacity. I tutaj uszczegóławiamy wspólnie 1-2 Sprintów User Story.”

      W klasycznym podejściu są to zwykłe, cykliczne zaplanowane spotkania uszczegóławiające z zespołem. Tylko nikt nie wymyślił dla nich fancy-nazw.

      „Jak on ogarnia zależności między elementami sytemu tworzonego przez kilkaset osób przez kilka lat? Jak ma czas być w stałym kontakcie z zadającym wiele pytań zespołem? I jak jeszcze spina to wszystko do kupy nie robiąc dokumentacji, której przecież nikt nie chce czytać?
      Duże systemy są dzielone na obszary, którymi zajmują się konkretne zespoły. W takim wypadku jest często jeden główny Product Owner i Area Product Owners (tak jest w LeSS) albo na poziomie Portfolio jest pewna hierarchia (SAFe). SAFe bardzo ładnie opisuje zależności w backlogu.”

      I dokładnie to samo robi się w klasycznych podejściach.

    • Korzystanie z User Story nie jest obowiązkowe.
      – czyli mogę zrobić diagramy i use case’y i dokumenty, jeśli mi to pomaga? Super. Ja też nie mam z tym problemu, ale wiele osób ma. Nie masz za dużo myśleć, ale masz dostarczać szybko dobrych odpowiedzi i brać odpowiedzialność za rezultaty.

      Wymagania są tworzone i opracowywane cały czas.
      – Niektóre rzeczy to banały. Raz, dwa i wiadomo. Niektóre są średnio skomplikowane. Inne bardzo skomplikowane, z mnóstwem powiązań i problemów do rozwiązania. Często wydaje się proste, a jak masz mówić o szczegółach, to dopiero się odkrywa złożoność i problematyczność. Pracując w czasie sprintu masz bardzo ograniczony czas. Musisz brać poprawkę na to, że decyzje nie zawsze będą dobre. Nigdy nie będą idealne. Ale czasem myśląc chwilę dłużej można pozbawić się wielu problemów.

      Product Owner jest odpowiedzialny za Product Backlog ale nie musi tego robić samodzielnie. Interesariusze mogą dostarczać szczegóły
      – Tu się dopiero zaczyna zabawa. Dostarczałeś kiedyś takie potrzeby do dużego złożonego projektu? Dostarczane szczegóły mogą być niespójne, niekompletne, nieaktualne, niewłaściwie spriorytetyzowane, sprzeczne, jednostronne. Gdzie szukać tych potrzeb? Jest też sporo pracy z samymi ludźmi. Musisz wiedzieć kogo zapytać, jak, kiedy, o kim zapomniałeś. Nie przynoszą ci wysokiej jakości szczegółów na tacy. Właśnie o to mi chodzi – że to trudne zadanie. Ty powiesz, że może to robić na różne sposoby. I OK. Ja jestem po tej stronie, że się zastanawiam jak to dobrze zrobić.

      lub może oddelegować cześć pracy do Zespołu Develoeprskiego, np. do analityka ;)
      – w filmie mówisz, że analityk jako tylko analityk nie jest potrzebny
      – dzielenie problemów między kolejne osoby powoduje jeszcze większe rozdrobnienie wiedzy i trudniejsze podejmowanie decyzji dobrych dla całości. Nie mówię, że to niewykonalne. Mówię, że to trudne i zastanawiam się jak to dobrze zrobić w takim układzie.

      Poza tym w środku Sprintu jest Product Backlog Refinement i zajmuje zespołowi max 10% capacity.
      – dla prostych problemów – OK. Zadziała.
      – co z problemem dochodzenia ciągle nowej wiedzy? Wtedy raz mówię developerowi – wiesz co? Zrób w lewo. A za chwilę. A nie, teraz jednak w prawo. Albo w lewo. Nie, w prawo. Nie irytuje to ludzi? Wiem, że to naturalne zjawisko, że się nie da wszystkiego przewidzieć i nawet jak się zrobi fajną analizę, to potem wychodzą niedociągnięcia i zmiany. Czasem jednak może warto pomyśleć chwilę dłużej i przesunąć 2 razy a nie 4 w to samo miejsce i z powrotem? I znowu – zastanawiam się jak to zrobić najlepiej w takim środowisku.

      Duże systemy są dzielone na obszary, którymi zajmują się konkretne zespoły. W takim wypadku jest często jeden główny Product Owner i Area Product Owners (tak jest w LeSS) albo na poziomie Portfolio jest pewna hierarchia (SAFe).
      – Podział na obszary, podział na zespoły, główny analityk, analitycy obszarów albo biznesowi reprezentanci obszarów wyznaczeni do podejmowania głównych decyzji. Mam to samo w innych projektach.

      Product Backlog jest dokumentacją wymagań i można tam wrzucać co potrzeba. Zespół też zwykle tworzy wiki i ma tam schematy, UML, BPMN i inne Visio, które mogą się przydać. Nikt nie broni.
      – No to właśnie tu mam wrażenie, że jak wrzucam to do dokumentu i modelu to jest za ciężko, a jak dokładnie to samo znajdzie się na wiki to już jest fajnie. Mimo, że to mogą być te same rzeczy.

      To co jest tylko zabronione, to siedzenie i dumanie, czyli Big Analysis Up-front. Po prostu zróbmy mały kawałek i sprawdźmy feedback.
      – a tak się dzieje często w projektach etapowych. I tak się często nie dzieje w projektach „agilowych”, bo mają Scrum meetingi i user stories, a feedback od klienta żaden. I znowu – chodzi mi o to, że „mamy agile” nie oznacza bycia super, a nazywanie tego inaczej – to już słabo. I żeby pomyśleć, czy się jest faktycznie agilowym.

      W Agile mamy zwykle osoby około 9-osobowe, więc przy większym PRODUKCIE musi ich być więcej niż jeden i muszą 1) zarządzać Product Backlog, 2) synchronizowąć iteracje i integrować przyrosty i tutaj pojawiają się tematy skalowania. Natomiast to co od dawna mówią guru od Scrum i Agile – nie masz tak dużego produktu, tylko ekosystem wielu mniejszych.
      – To samo może być i w innych projektach. Iterują. Integrują się w jeden produkt.

  8. Dodaje komentarz kolejny raz, coś mnie zblokowała moderacja..

    Pani Haniu również podzielam zdanie Panów, w większości Pana Mariusza, Pana Karola i Pana Piotra (ale bez ostatniego zdania) lub w pewnym sensie przyjmuję wypowiedź Pana Sceptyka, ale nie podzielam z nimi zdania – tak nie można pisać..

    Tak, to jest temat (rwąca) rzeka. Zostałem zaintrygowany do wskoczenia w jej nurt :)

    Wtrącę na wstępie tylko, że korzenie Scruma sięgają wstecz, zanim jeszcze wzięto go pod parasol Manifestu Agile i przypisano do podejścia Zwinnego (Agile) oraz zdefiniowano jego ramy. Było to pierwotnie bardziej zamysł efektywnego zarządzania procesem produkcyjnym, niż próbą odzwierciedlenia go w zarządzaniu sterowanym planem.
    Teraz niestety coraz częściej widzę, że Scrum zaczyna być coraz częściej błędnie interpretowany, jak też inne środowiska zwinności lub ich skalowalne wersje.

    W poniższym komentarzu przyjmę do reprezentowania zwinności, środowisko Scrum, jako właśnie pomocne głównie do procesu wytwórczego i jeśli trzeba skalować to też do współzarządzania.

    Zaznaczam, że Scrum występuje tylko w swojej niezmienionej postaci.

    -Do rzeczy:

    Ad. 1 „Wielkie projekty agilowe”
    -Znając ogólnie metodykę PRINCE2, myślę, że jestem w stanie odpowiedzieć na Pani pytanie postawione na początku artykułu: „[…] Czym to się różni od innych metodyk, jak np. PRINCE2? ” oraz wyjaśnić nieścisłości powstałe w artykule, które wywołały dyskusję.

    Otóż, Scrum stawia na ludzi. Ich umiejętności, motywację, zaangażowanie, doświadczenie, samoorganizację i wiedzę (o Scrumie, w danej dziedzinie problemowej, techniczną) i więcej.

    Ale, czy ludzie, którzy zarządzają projektem za pomocą metodyki PRINCE2, „ręczą” za osoby sobie podległe (które mają różne poziomy umiejętności i nie koniecznie muszą wiedzieć co to PRINCE2 i czy wiedzą czym jest samoorganizacja, motywacja itd. itp.) w wykonywaniu swoich zadań?
    Nie.
    I dalej. Czy w PRINCE2:
    -ludzie Ci, szybki zaadoptują się na nieoczekiwane zmiany?
    Nie.
    -jeśli coś pójdzie nie tak to, czy wszyscy poczuwają się do odpowiedzialności zaadoptowania tych zmian?
    Nie.
    -występuje minimalizm formalności?
    Nie.
    -wszyscy mają prawo głosu w nieoczekiwanych sytuacjach?
    Nie.
    Mógłbym zadawać kolejne pytania, dla kontrastu, ale myślę, że widać o co mi chodzi.

    Ok, zatem do czego zmierzam?
    Pisała Pani kiedyś również dla kontrastu porównania: http://analizait.pl/2014/pmbok-vs-prince2-i-scrum/
    że Scruma można używać do procesu wytwarzania i np. innej metodyki do zarządzania tymi procesami oraz, że nic nie stoi na przeszkodzie łączenia Scruma z innymi metodykami pomocnymi do zarządzania projektami.
    Trochę to jest sprzeczne z tym o czym Pani napisała teraz.

    Nawet Twórcy Scruma nie negują dołączania innych technik i metodyk do ram Scruma, a nawet sugerują taką możliwość.

    Ale, żeby nie być gołosłownym: przykładowo (fakty) – firma opiera się na zarządzaniu projektami w oparciu o PRINCE2, ale są różne zespoły wytwórcze, które chcą pracować w oparciu o różne środowiska, czy podejścia: Scrum, XP, Lean, w oparciu o Model kaskadowy, „czy jak im się tam wydaje najlepiej, ale działa” itd. Czy można tak pracować?
    Jasne, że można.
    Czy ktoś daje gwarancję, że wszystko razem będzie pracowało jak w szwajcarskim zegarku?
    Niestety nie. Ale też nie jest potwierdzone, że to zadziała lub nie.

    Więc o co chodzi z LeSS (Large Scale Scrum), Scrum of Scrums, SAFe (Scaled Agile Framework)?
    A o to, że jeśli już mamy twarde fundamenty wypracowane przez małe zespoły w oparciu o środowisko Scrum, czy inne zwinne środowiska, to wtedy możemy zacząć je przenosić na wyższy poziom, opierając się cały czas na rdzeniu Scruma lub innego środowiska zwinnego, bez utraty pierwotnych zasad, założeń, celów, praktyk, wartości tych środowisk. Nie da się odpalić wszystkiego na raz.
    Przykład? Nie jest to jeszcze mój poziom doświadczeń, ale odsyłam do blogu Pana Mariusza Chrapko: http://mariuszchrapko.com/scrum-of-scrums-czyli-jak-koordynowac-zaleznosci-w-projektach-agile/

    Tak samo, aby zaadoptować Scrum w małym zespole potrzeba bardzo dużo ciężkiej i wspólnej pracy, aby coś zaowocowało. To też przejście na wyższy poziom zarządzania tymi zespołami, wymaga jeszcze większego nakładu pracy i zaufania. Ale jeśli wszystko razem „ładnie zagra” to gwarancję sukcesu mamy obiecaną przez Twórców Scruma.

    BTW1
    „Duże i złożone jest to, czego nie znasz.” – i tak i nie.
    -To coś może być duże i złożone, może być zarazem znane. Przykładowo Wieża Eiffla – jest duża i złożona. I jeśli posiadając odpowiednie materiały i chęci – chcę ją zbudować samemu, to było by to łatwiejsze niż np. zbudowanie Empire State Building – przecież też jest „duży i złożony”, ale nie jest już na tyle znany i łatwy do poznania, aby go zbudować samemu.

    Tutaj ważna jest umiejętność, wiedza i doświadczenie przeskakiwania między środowiskami i podejściami, tak aby wybrać odpowiednie do danego projektu rozwiązanie czy podejście.
    Nie da się wykorzystać jednego szablonu do wszystkiego.

    Ad. 2 „Magiczna skrzynka Product Ownera”
    -Skalowanie. Po to jest właśnie LeSS (Large Scale Scrum), Scrum of Scrums, SAFe (Scaled Agile Framework)? lub mówi o tym przytoczony artykuł powyżej, napisany przez Pana Mariusza Chrapko.

    Ad. 3 „Czy jestem waterfall’owa?”
    -Podejrzewam, że Pani po prostu jeszcze nie polubiła niepewności i trafiła na tych „złych”. Więc preferuje Pani strefę komfortu „sterowanego planem” i jest to zrozumiałe i dające jakiś poziom pewności.
    Ale jeśli Pani ma na myśli nieporządek w domu oraz Pani przykłady sytuacji życiowych – to Agile nie będzie dobrym porównaniem.

    Ja zwinność (Agile) w sytuacjach życiowych porównuje do takich sytuacji:

    Wyobraźmy sobie, że jestem w domu i kończę pakowanie paczki do nadania dla kuriera, który zaraz przyjedzie. Jest godzina 17:45. Spodziewałem się, że w tych godzinach przyjedzie. Zostawiłem sobie jeszcze jedno zadanie do wykonania współbieżnie (ale o nim poniżej).
    Mieszkam w bloku, który ma 9 pięter, ale ma też dwie windy do których, aby dojść trzeba przejść 10 metrowy korytarz. Winda zanim się zatrzyma na piętrze, otworzy drzwi i zamknie, zjedzie na parter i wypuści użytkownika, mija dobre 90 s. (nie wiesz/nie myślisz, czy po drodze Pani z dzieckiem w wózku nie zatrzyma Cię w windzie, aby wejść na 1 piętrze – jeszcze tego nie zakładasz, najwyżej będzie kilkanaście sekund więcej poślizgu). OK.
    Nagle dzwoni, kurier i mówi, że czeka na zakazie zatrzymywania oraz prosi o szybkie zniesienie paczki, ponieważ ma opóźnienie spowodowane, złapaniem wcześniej kapcia w oponie swojego samochodu. OK.
    Kończę pakować paczkę, zabieram kurtkę oraz receptę do wykupienia w aptece (to jest to zadanie). Z doświadczenia, wykonuję „myk” – idę zamówić windę, aby już przyjechała zanim zamknę drzwi od domu (i tak będę czekał). Kończę się ubierać, zabieram paczkę i zamykam drzwi, winda przyjechała.
    Idealnie zagospodarowany i ułożony w czasie prosty plan dostosowany do sytuacji.
    Wchodzę do windy wciskasz zero. Winda powoli zamyka drzwi..
    Iskierki w głowie zaczynają świecić i nagle przypominam sobie, że nie wziąłem telefonu (potrzebuje się skontaktować z kurierem jak go nie zobacz pod blokiem lub później może będę go potrzebować w aptece) i portfela (muszę zapłacić jakoś w aptece, które w najbliższym promieniu są otwarte tylko do 18:00).
    Co teraz zrobić? Jaką drogę wybrać? Jak rozdzielić priorytety? Co jest ważniejsze? Czy mogę z czegoś zrezygnować? Czy mogę coś przełożyć? itd.

    Załóżmy, że mamy w tej sytuacji takie możliwość:

    1. Zjeżdżam pokornie na dół. Wciskam 9 i wracam po portfel i telefon (kosztem czasu kuriera i swojego – zaraz apteki zostaną zamknięte). Otwieram drzwi, szukam portfela gdzie on jest? Jest. Czas leci. A jeszcze telefon, gdzieś tutaj był? Hmm. Jest!
    Idę zamówić windę. Czekam Jest. Drzwi się otwierają, wchodzę i wciskam 0. Szybko szybko poganiam windę itd. Biegnę lub tylko idę do kuriera.
    Opis dodatkowy: w tej sytuacji można by było wykorzystać trochę tzw. „zwinności” i sprytu, np. zastawić drzwi windy przesyłką, tak żeby winda poczekała, aby szybko zjechać później na dół oraz przypomnieć sobie między czasie gdzie jest telefon i portfel, aby nie szukać bez pomysłu pod wpływem stresu (nagła luka w pamięci, tyk tyk). Kurier czeka, apteka.. itd.

    2. Rezygnuje z apteki. Nie chce ograniczać czasu Kuriera. Ale, co jeśli nie znajdę go pod blokiem? Olał mnie i pojechał. Czy paczka i apteka może poczekać do jutra, czy poniosę koszta, odpalę samochód i pojadę do apteki 24h na końcu miasta. Ale co z paczką? Też jest ważna, ktoś tam na nią czeka. Obiecałem, że dojdzie na drugi dzień. itd. Wrócić się, zadzwonić po Kuriera, kupić leki i poczekać łaskawie na Kuriera? Strasznie to niepewne.

    3. Inicjuję włączenie tzw. ” opcji zwinności”. Szybka ocena sytuacji i prawidłowe działanie. Wciskam piętro 8 i 7. Powstrzymałem drzwi ręką i wybiegam z paczką pod ręką z windy. Przypominam sobie w tym czasie, gdzie mam portfel i telefon. Biegnę pod drzwi wejściowe, otwieram je, biorę szybko portfel i telefon. Zamykam drzwi i biegnę do klatki. Wiem, że zanim otworzą i zamkną się drzwi mija kilka dobrych sekund. Zbiegam na 8 piętro, widzę, że drzwi właśnie się zamykają -wciskam przycisk, aby się otworzyły ponownie. Udało się. Zjeżdżam na dół. Po drodze zatrzymując się tylko na 7 piętrze (wziąłem dodatkowy margines, czasu, aby plan się nie spalił-zaakceptowałem dodatkowy koszt). Po drodze na szczęście nie było przystanku na pozostałych piętrach. Kurier dostaje paczkę, podpisuje protokół odbioru, a ja biegnę do apteki, zostało 5 min do 18. Ale, nie wiem, czy nie będzie dużej kolejki. Na szczęście nie ma. Wykupuje receptę.
    Wracam do domu jestem zadowolony, wszystko się udało rzutem na taśmę. Misja wykonana.
    Opis dodatkowy: mogłem też ustawić przesyłkę w drzwiach, aby zastawiła drzwi i zrealizować podobnie powyższy plan, ale zasoby myślowe wybrały coś innego.
    Ok, ale co jeśli nie pamiętałbym gdzie jest telefon i portfel? – 8,7, 0. Zamawiam następną windę. Czas ucieka.
    Co jeśli nie było by kuriera lub byłby problem z przyjęciem paczki, bo właśnie Pan Kurier dostaje mandat? Co jeśli byłaby kolejka w aptece? Co jeśli byłaby Pani z dzieckiem w wózku na pierwszym piętrze lub co gorsza dziadek z babcią o lasce na trzecim. Zbiegać z pierwszego, trzeciego? – nie opłaca się, zyskam tylko kilka sekund lub skręce kostkę. Poganiać staruszków – nie wypada. itd itd. można tak w długo mieszając okoliczności tych trzech historyjek i więcej.

    Ścieżki mogą być bardzo złożone mimo tak prostej sytuacji, ale też są obarczone pewną dozą niepewności, napięcia, konieczności szybkiego podjęcia decyzji.

    Brzmi znajomo? Sytuacje, możliwości, dylematy itd., wypisz, wymaluj Projekt, ale na mniejszą skalę.

    To tylko pojedyncza sytuacja, ale co jeśli dodamy więcej powiązań?
    Na pewno pójdzie coś nie po naszej, docelowej myśli.
    Dlatego mamy te wszystkie metodyki i narzędzia. Ale czy potrafimy się nimi posługiwać i wykorzystać w 100% ich możliwości? Różnie to bywa.

    [..]
    „Skąd mam to wszystko wiedzieć? Muszę to sobie poukładać w głowie. Uporządkować. Zbudować logiczną konstrukcję, która oprze się naporowi trudnych pytań. Jeśli ja nie potrafię złożyć logicznej całości, jak developerzy mają to zbudować?”

    -Wydaje mi się, że nie dostaje Pani, wystarczająco dużo czasu na Analizę. Każdy się z tym boryka.
    Jest to problem Biznesu, który nie inwestuje w dobre Wymagania i Analizę oraz skupia się tylko na procesie wytwórczym (Biznes woła „produkujemy!”). Ale jak wiadomo różnie to bywa z Programistami, ale to oni odwalają ciężką pracę wytwórczą, Analitycy (muszą szybko przedstawić wymagania, aby dać pracę Programistom), Kierownicy projektów (zarządzać, pilnować, rozliczać zasoby ludzkie i materialne), wszyscy muszą ciężko pracować. Ale czy uda się pracować, tak jak w szwajcarskim zegarku? Hmm..

    OK, a czy Biznes rozumie zasady Trójkąta jakości (ograniczeń)? Czy ma świadomość skutków nagięcia, któregoś z wierzchołków?
    Nie (lub może..).
    Ale czy się tym przejmuje?
    Nie (lub może..).
    Biznes wie, że bez niego IT nie może istnieć, ale czy zawsze pamięta, o tym że ten właśnie Biznes, nie może żyć bez IT?
    Może wie, może nie. Może nie zdaje sobie z tego sprawy.
    Biznes płaci i wymaga – tj. pewne.

    Ad. 4 „Każdy radykalizm bierze się z traumy”
    -Przyczyny można znaleźć na przestrzeni całego mojego komentarza lub Panów i lub też Pani odpowiedzi pod te komentarze (jak pisałem ten komentarz czas leciał – adoptowałem i nanosiłem zmiany „zwinnie”, aby powstał produkt – mój komentarz).
    Ogólnie przyczyny te wynikają z chaosu w projektach IT oraz braku prawdziwej dojrzałości IT i Biznesu.
    Tak jest i będzie jeszcze długo zanim nauczymy się współpracować i komunikować oraz będziemy mieli wspólne cele i wartości.
    Czy można z tym walczyć? Zawsze można próbować.

    Ad. 5 „Czy agile jest agile?”
    -Klasyka problemów tradycyjnego podejścia oraz problemów adaptacji zwinności w organizacji :)

    [..]
    „Jeśli wywalasz za drzwi człowieka, który potrzebuje informacji, żeby pracować i pomagać pracować zespołowi, to czy jesteś agilowy? Stawiasz na pierwszym miejscu ludzi czy podążanie za zdefiniowanym agilowym procesem?”

    -Nie to jest po prostu brak dojrzałości takiej osoby i uprawianie pseudo zwinności.

    Spotkała się Pani prawdopodobnie z tzw. pseudo Scruem. Grupa osób postanowiła pracować według zasad środowiska Scrum i coś tam sobie po czytała, wybierając i wypierając wszystko co im pasuje lub nie (Pan Piotr coś pisał o tym i Pani wy wnioskowała w odpowiedzi do jednego z komentarzy -też musiał nanieść wzmiankę, do tego co już napisałem).

    -Doświadczyła Pani nie dojrzałości „Panów z IT” i jestem Pewny, że Ci Panowie, zanim zaczęli wykorzystywać niektóre ramy środowiska Scrum, wcześniej borykali się (lub nadal to robią) z problemami typu: „specyfikacja jest nie kompletna, ch….., „, „a czy było to w specyfikacji?” itd. itp., za bardzo takie osoby nie chciały też uczestniczyć w warsztatach (bo to strata czasu), potrafili tylko krytykować i zwalać winę za nie powodzenia na Analityka biznesowego lub Biznes.
    Panowie Ci zatem forsują przekonanie do minimalizmu dokumentacji, jednak nie są w stanie kontrolować tego co robią. Zapytani pewnie o szybkość swojego zespołu lub ostatnie wyceny IT – nie potrafili by odpowiedzieć na te pytania zbyt rzeczowo.

    Zespół Programistów, aby pozostał zwinny, musi być mały, tak jak cały Zespół.

    Wszystkie problemy wynikają z problemów adaptacyjnych, nieumiejętnego mieszania środowisk, mieszania faktów i wiedzy itd. czego skutkiem jest błędne rozumowanie ram środowiska np. Scrum, czy zwinności. Co w efekcie daje niezłe sprzężenie zwrotne.

    Ad. 6 „Bądź interfejsem”

    Tak jak pisałem Twórcy Scruma deklarują, że nadaje się on do wykorzystania jako ramy do innych metodyk, praktyk czy technik, więc nie wiem dlaczego „Przypadki użycia” nie zostały obronione w Pani sytuacji przed Zespołem Deweloperskim, jeśli zostały przedstawione w analizowanym/realizowanym projekcie.

    [..]

    Wszystko prawda, ale w środowisku Scrum, objęcie roli Product Ownera przez Analityka biznesowego to za mało. W najlepszym przykładzie mógłby być nim były Analityk biznesowy, który jest obecnie Kierownikiem Projektu.
    Nie pamiętam, ale ktoś kiedyś napisał, że wykonywana praca przez Analityka biznesowego, jest w stanie zapewnić pracę dla sześciu programistów i kontrolować przyszłe zmiany tej pracy. W Scrum zadziała to tylko wtedy jeśli taki Analityk ma duże uprawnienia.
    W przeciwnym wypadku można się bawić w Scrum i doświadczać problemów: Product Owner:
    – o zbyt małych uprawnieniach (Analityk biznesowy),
    -przepracowany (Kierownik projektów),
    -odległy (Kierownik projektów),
    -zastępczy (Analityk biznesowy), o podzielonych obowiązkach(Analityk biznesowy z funkcją Kierownika projektów),
    -komitet Product Ownerów (Kierownicy Projektów/Analitycy biznesowi).

    Ad. 7 „Najlepszy człowiek do pracy”
    I najlepiej, aby można było takich ludzi klonować :)

    BTW2
    Mam mniejsze doświadczenie od Pani w Analizie biznesowej, ale zaczynałem swoją karierę zawodową w projektach IT od hybryd podejścia tradycyjnego i zwinnego. Były i są to dość ciekawe doświadczenia. Przez to może inaczej do tego wszystkiego podchodzę i mam to inaczej poukładane w głowie.
    Co z tym zrobię? Nie wiem. Przyjmuję na razie jedną stałą: „zmiany” i „cisnę” do przodu. A jak się na tym przejadę, to też będzie zawsze jakieś doświadczenie :)

    Tak, więc na zakończenie proste podsumowanie i cytaty[URL] (też już to padło w komentarzach, ale zanim odpisałem minęło trochę czasu):
    Scrum jest prosty („prościutki”) do zrozumienia, ale bardzo trudny do opanowania (mam tu na myśli: problem adaptacji tego środowiska w organizacji) [przed wdrożeniem „czegoś”] (aby to coś wdrożyć, najpierw trzeba uzyskać wiedzę, potem ją opanować oraz posiadać już pewne umiejętności i dopiero wtedy to wykonać), czyli do wdrożenia.

    Cytaty ponadczasowe, niektóre dobrze wpisujące się w kontekst:
    http://lubimyczytac.pl/cytaty/31648/autor/albert-einstein

    • Ciekawe, ciekawe. Czyli generalnie radzisz, żeby analityk programował, żeby być przydatny w agilu? Albo żeby programiści analizowali?

      O jakiego typu projekcie mówisz? Jak dużym? Kilkadziesiąt, kilkaset osób? Jaki model pracy? Na zlecenie dla zewnętrznego klienta czy własny produkt tworzony we własnej firmie? O jakiej branży mówisz? Czy takie osoby pracują w tej samej branży cały czas czy w różnych?

      Analizę można postrzegać jako pójście do odbiorcy, pogadanie z nim, zadanie pytań, dowiedzenie się po co jest ten ficzer. Można to rozumieć jako zapisanie tego w tej czy innej formie. Nie brzmi jak wielkie wyzwanie i faktycznie można by takie kompetencje dzielić z innymi. Tak samo jak analityk może napisać kod (bardzo duża część jest po infie). Ale nie wiem czy ten kod chciałbyś później utrzymywać :)

      Rozumiesz zapewne różnicę między programistą piszącym kod, który zazwyczaj mniej więcej dobrze się wykonuje a takim, którego uważasz za naprawdę dobrego programistę. Na pewno masz w głowie przykłady osób z tych dwóch grup. I wiesz jak bardzo różnią się oni od siebie – o ile poziomów, jaka przepaść potrafi między nimi być. I jak różną wartość wnoszą do pracy zespołu.

      Analiza to nie iść do klienta i zapytać po co mu to, a on odpowiada „po to”, a Ty mówisz „aha”. Żeby to naprawdę dobrze robić potrzebujesz dobrze znać się na zarządzaniu przedsiębiostwem (znać perspektywę zarządów), danej dziedzinie/branży, rynku, konkurencji, specyfice firmy klinenta, jego procesach, produktach, strukturze, podziale odpowiedzialności, procedurach pracy różnych ludzi, systemach, jakie są na rynku, systemach, jakie ma klient, do czego i jak ich używa, poziomie architektury, kodu, testów, danych, dobrze rozumieć ludzi, zupełnie różne osobowości, od prezesów po adminów, wzbudzać w nich chęć współpracy, zarażać wizją rozwiązania, odkrywać to, czego nikt ci nie mówi, albo mówi wręcz coś innego, być mądrym, kiedy każdy chce wykluczających się rzeczy, kiedy wymagania są przeciw prawu (w ogóle wiedz o tym, że są takie przepisy), kiedy najlepsze rozwiązanie dla Twojego działu powoduje poważne problemy w innym dziale (zauważ to zanim się to stanie, choć nikt ci może o tym nie powiedzieć) albo przekonywać do rozwiązań, które zlikwidują problem, kiedy kierownictwo ciśnie w stronę dziwactw, powierzchownych półśrodków albo zakopywania pod dywan. Nie wiem czy mi życia starczy, żeby to ogranąć.

      Czy znasz takich ludzi, którzy bardzo dobrze robią analizę i dobrze programują? I dzielią czas w projekcie pomiędzy te 2 rzeczy jednocześnie? Daj namiary, chętnie z nimi pogadam.

      • Eeej no Hania, teraz to już przesadziłaś :-)

        „… potrzebujesz dobrze znać się na zarządzaniu przedsiębiostwem (znać perspektywę zarządów), danej dziedzinie/branży, rynku, konkurencji, specyfice firmy klinenta, jego procesach, produktach, strukturze, podziale odpowiedzialności, procedurach pracy różnych ludzi, systemach, jakie są na rynku, systemach, jakie ma klient, do czego i jak ich używa, poziomie architektury, kodu, testów, danych, …”

        Pracuję w zawodzie analityka naście lat. Nie przesadzajmy mówiąc, że tak wygląda każdy projekt. Że robimy to wszystko kiedy bizes chce zrobić kilka nowych ficzerów :-) W ten sposób robi się projekty transformacyjne, które w danym przedsiębiorstwie zdarzają się raz na 5 lat. No chyba, że na Pomorzu tak się robi każdą analizę. Ale jeśli tak, to Panie Boże chroń mnie przed takimi analitykami, bo koszt takiej analizy musi być ogromny. I jako osoba, która dziś już jest na pozycji zamawiania analiz u innych, nie chciałbym wydawać pieniędzy na taką analizę tylko dlatego, że szablon analizy wymaga uzupełnienia tych wszystkich informacji.

        BTW, gwarantuję Ci, że jest sporo programistów, którzy pracują x lat w tej samej firmie, mają wystarczająco dużą wiedzę i doświadczenie by robić analizę „good enough”. Bo w agile’u nie chodzi o to, aby wszystko było idealne i odporne na wiele hipotetycznych sytuacji. Chodzi o to, aby było „good enough” z punktu widzenia celów, które mam do osiągnięcia. A „good enough” to jest np. potwierdzenie z zespołem dev kto co wie o produkcie/procesie/przedsiębiorstwie, następnie ustalić jakiej wiedzy zespołowi brakuje i tylko taką wiedzę uzupełnić. A nie dla zasady opisywać wszystko. W sytuacji gdy zespół SCRUM pracuje z tym samym Product Ownerem przez kilka lat, gwarantuję Ci, że mają wystarczająco dużą wiedzę biznesową i nabyli w międzyczasie wystarczająco dużo kompetencji analitycznych by robić sprawnie analizę.

        Ale pojechałaś mitem analityka jako osoby niezastąpionej :-) Przekonanie o byciu niezastąpionym jest pierwszym krokiem do zawodowej klęski. Pycha kroczy przed upadkiem :-) Na każdym kroku trzeba się podważać swą przydatność, bo dzięki temu się rozwijamy.

        • Michale, przeczytaj proszę jeszcze raz artkuł.
          Nie napisałam, że tak wygląda każdy projekt. I że powinno się robić ogromne analizy dla kilku ficzerów – wręcz przeciwnie. A o bezmyśmym wypełnianiu szablonów znajdziesz w artykule zdanie wprost przeciwne. Głównie pisałam tu o dużych i skomplikowanych projektach i potrzebie elastyczności.

          Dokłanie, chodzi o to, żeby było good dla celów klienta. Jeśli to proste i małe, to optymalniej jest robić mniej. Jeśli bardzo duże, złożone i ryzykowne, to warto się nad tym zastanowić i sprawdzić dokładniej.

          Tezę w artykule masz taką, że niektórzy dla zasady nie robią tego dokładniej, bo to nie jest „agilowe”. Bez względu na to, czy to lepsze rozwiązanie czy nie. I wytwarzający i klienci. Są ludzie, którzy robią tylko agilem, bo tak. Albo klienci, co nie kupią od ciebie projektu, jak nie ma słów kluczy agile, scrum i inne takie. Bez względu na to, jak sensowna byłaby alternatywa a nawet gdyby miał dokładnie to samo, ale bez słów kluczy.

          „Ale pojechałaś mitem analityka jako osoby niezastąpionej :-)” To Ty to powiedziałeś. Ja wiem, że to zawód, na który ma wpływ ogromna liczba czynników i ich ogarnięcie zajmuje czas. Nie tylko w czasie projektu, ale ogólnie – całe życie zawodowe. Bardziej tu widzę pokorę wobec tego, czego nie wiem, a ile tego jest. Ale każdy widzi, co uważa.

          Nie twierdzę, że nikt inny tego nie potrafi zrobić. Ja też potrafię programować. I działa. Dziwne natomiast byłoby dla mnie upieranie się, że przy bardzo trudnych projektach wezmę się za robienie krytycznych funkcji, bo tak jest agilowo. A takie jest niekiedy podejście.

          „Na każdym kroku trzeba się podważać swą przydatność, bo dzięki temu się rozwijamy.”
          Mam właśnie wrażenie, że nie ma takiej refleksji po stronie wielu ludzi tylko-i-wyłącznie-agilowych. Czy może się mylę i sam też potrafisz wskazać sytuacje, że jednak to nie jest najlepsze rozwiązanie?

          • W rzeczy samej tak pisałaś. I dlatego z Twoim artykułem zgadzam się o wiele bardziej, niż z Twoim ostatnim komentarzem :-) Tylko z kolei polemizując z Krystianem, używasz argumentów sugerujących, że każda analiza tak wygląda.

            „niektórzy dla zasady nie robią tego dokładniej, bo to nie jest „agilowe” – jeśli ktoś czegoś nie robi dla zasady, to jest idiotą, a nie agile’owcem. I prawdopodobnie zostanie tym idiotą do końca życia.

            To nie ma nic wspólnego z metodą. Tylko z postawą. Znam tylu samo twardogłowych waterfall’owców go agile’owców. Zawsze znajdą się ludzie, którzy będą coś robić „bo procedura wymaga”, a nie „bo widzę w tym wartość”. Nie uważam, by udział ludzi upartych, zamkniętych na nowości, myślących w ograniczony sposób był znacząco różny w tych grupach.

            Tylko nie da się rzeczowo dyskutować o plusach i minusach jakiejś metody, jeśli będziemy się przerzucać przykładami ignorantów, amatorów, partaczy i innych fujar. Jak to mawiają, poprzez egzemplifikację można udowodnić każdą tezę.

            „Ja wiem, że to zawód, na który ma wpływ ogromna liczba czynników” – i tu chyba jest pies pogrzebany. Bo dla mnie to nie zawód, tylko rola. I oczywiście, jeśli pełni ją „zawodowiec”, to jest znacznie większa szansa na sukces, niż gdy to zrobi amator. Ale i koszt zawodowca jest większy, więc ekonomiczne spojrzenie każe rozsądnie dobierać zawodowców i amatorów, w zależności od problemu. Dokładnie tak jak z kierowcami amatorami i zawodowcami. Nie każdy kto ma prawo jazdy, jest zawodowcem. Ale też i nie do każdej jazdy będziesz brać zawodowca, bo Cię najzwyczajniej nie będzie na to stać. I co więcej, zawsze zawodowiec poradzi sobie lepiej niż np. amator-tubylec, którego największym zasobem jest np. znajomość topografii danej organizacji.

          • Nie podważam plusów.
            Na tym polega wpis – na przypadkach, że nie zawsze agile znaczy super. A te przykłady pochodzą z osób, projektów i firm o generalnie bardzo dobrej agilowej reputacji.
            Każdy ma problemy, wady, porażki. Mogę Ci wymienić długą listę wad analityków.
            Nie podoba mi się natomiast na wstępie automatyczny odrzut, że coś nie jest „agilowe”. Nie twierdzę, że tak jest zawsze. Twierdzę, że się spotykam z tym. I to nie tak rzadko. I warto się zastanowić jak jest najlepiej, a nie z definicji odrzucać.
            Nie każę każdemu zatrudniać najlepszego analityka. Jeśli coś innego jest good enough to OK. Tak się właśnie dzieje w wielu miejscach. Analiza jest jeszcze mało znana w PL w porównaniu z innymi krajami.
            Zastanawiam się za to jak ogarnąć te potrzeby klienta w bardzo złożonym, wymagającym projekcie, jeśli się jest w takim środowisku, które jak widzi porządny diagram albo kawałek dokumentu to już to odrzuca.

          • „jak ogarnąć te potrzeby klienta w bardzo złożonym” – a zapytałaś o to klienta? zapytałaś czego potrzebują tacy developerzy? może forma dla nich nie jest zjadliwa? może oni nie chcą diagramu ani kawałka dokumentu? może chcą aby ktoś do nich przyszedł i im to opowiedział? albo zaprezentował na przykładzie? albo zaproponował by sami przez to przeszli i na własnej skórze poczuli na czym polega problem? jest tyle różnych form przekazywania informacji, czemu to akurat musi być diagram UML?

            „porządny diagram” – kto ocenia, że jest porządny i przydatny? Ty? czy ten, dla którego go robisz? a jeśli dla niego nie jest porządny bo nie tego potrzebował? czy na pewno robisz diagram dla niego? czy może jednak bardziej dla siebie i kochasz swoje dziecko miłością bezgraniczną, mimo że inni twierdzą, że go nie potrzebują? albo „dla zasady” bo gdzieś, ktoś Cię nauczył, że ten diagram jest baaaardzo potrzebny; na jakiej podstawie przypuszczasz, że wiesz lepiej niż developerzy, czego oni potrzebują do pracy?

          • „Jeśli coś innego jest good enough to OK” – tylko czemu mam nieodparte wrażenie, że rozmawiam z Fordem, który mówi mi, że mogę sobie wybrać samochód w dowolnym kolorze, pod warunkiem, że będzie czarny, a analiza może być good enough pod warunkiem, że to JA JAKO ANALITYK powiem co oznacza good enough i nikt, żaden developer w krótkich spodenkach, który na oczy nie widział „profesjonalnego” procesu wytwórczego, nie będzie mi mówił co ta analiza ma zawierać. A jak nie będzie chciał tego, co mu zaproponuję, to powiem, że jest twardogłowym agile’owcem.

            Zaczynam się zastanawiać czy, a rebours, nie prezentujesz równie twardogłowego stanowiska, które tak bardzo krytykujesz u osób po drugiej stronie :-)

            Napisałaś w artykule „Analizę robisz dla siebie. Żeby poskładać sobie wszystko w głowie.” I to jest święta prawda. I jak robisz ją dla siebie, możesz sobie wybrać dowolną formę, notację, metodę. Chcesz robić 100 diagramów? Rób.
            I tak samo w SCRUM. Zespół robi analizę dla siebie. I tak samo może sobie wybrać dowolną formę, notację, metodę. Chce robić 0 diagramów? Niech robi.

            Jeśli z powodu kiepskiej analizy popełni błąd, to się czegoś nauczy i następnym razem zrobi lepiej. A jeśli analiza okaże się wystarczająca, Ty się czegoś nauczysz i może następnym razem zamiast 100 diagramów, zrobisz 0. Koniec końców, wszyscy wygrywają, bo ktoś się czegoś nauczył :-)

          • „Zastanawiam się za to jak ogarnąć te potrzeby klienta w bardzo złożonym, wymagającym projekcie, jeśli się jest w takim środowisku” – I O TYM POWINNAŚ NAPISAĆ ARTYKUŁ!! Bo to jest rzeczywiste wyzwanie! I najlepiej we współpracy z ludźmi, którzy wiedzą jak to robić w agile (Krystianem, Tomkiem Wykowskim, itp.) Czekam z utęsknieniem na dobry, polski artykuł o tym jak może wyglądać analiza w agile, który nie będzie pielęgnował strachów dużej części analityków, który pokaże że może być KOMPLETNIE inna, co wcale nie oznacza, że będzie gorsza.

            Tylko nie z pozycji osoby, która poniża innych nazywając ich twardogłowymi. Tylko może właśnie z pozycji osoby, która rozumie co oznacza agile i pomaga innym wytłumaczyć jak w odpowiedzialny sposób można go skalować. Właśnie po to, by radzić sobie ze złożonymi projektami. Bo inaczej nikt z „obozu zwinnego” nie potraktuje Cię jako sojusznika. Wszystkim będzie się wydawało, że po prostu chcesz nasikać im do namiotu.

          • Michał, a czy Ty zajmowałeś się wymaganiami w złożonym projekcie?

            Non stop gadam z klientem. Na tym polegają moje codzienne zajęcia. Problemem nie jest brak komunikacji. A rozwiązaniem na złożoność nie jest wystarczająco długie i częste rozmawianie z klientem. Problem jest w tym, że ludzie mimo najszczerszych chęci i największej wiedzy w swojej dziedzinie napotykają duże wyzwania, żeby określić wymagania względem rozwiązania/softu. Dlatego, że mogą nie rozumieć ograniczeń jakie stwarza IT – funkcjonalnie i niefunkcjonalnie. Mogą mówić, co jest dobre z ich perspektywy, ale już np. nie podejmą decyzji co jest dobre z punktu widzenia ich działu + działu controllingu. I nie zawsze wystarczy zaprosić kolejną osobę do dyskusji albo odpowiednio dużą liczbę osób i zrobić burzę mózgów. Czasem wiedza jest rozproszona. Czasem trudno dostępna. Czasem ukryta! Nie mówię, że analityk super wszystko na raz rozwiąże. Mówię, że to trudne. I zastanawiam się jak to dobrze robić. Zastanawiam się nad tym od 6 lat. Głównie nad tym – w pracy i po pracy. Ty ile czasu na to poświęciłeś?

            Może mówimy o innych projektach? W mniejszej skali czy jakimś charakterze projektu pewnie to nie występuje.

            Od kiedy pracuję to pytam developerów. Z ludźmi, z którymi pracuję i mam przekazać konkretną informację. Przekazuję im w rozmowie, później podsyłam coś, do czego mogą wrócić. Rysuję na kartce, pokazuję na screenie. Siedzę w tym samym pokoju, chodzimy razem na herbatę i na obiad. Nie ma problemu, żeby się ktoś powiedział, że nie jest coś jasne, że jest bez sensu. Siedzimy i rozkminiamy albo poprawiam. Gadam z nimi na co dzień. Pytam, czy mają informacje potrzebne do pracy, czy jest jasne, czy OK. Do znudzenia. Czasem robię ankiety – z zespołami, z którymi pracuję. A ostatnio puściłam na blogu taką co odpowiedziało 110 osób, co im się nie podoba w analizie, analitykach i jej produktach: http://analizait.pl/2016/mysla-o-analitykach-testerzy-programisci-kierownicy/.

            Czy po stronie developerów jest taka refleksja? Albo po stronie Agila, co można by poprawić w Srumowaniu w firmie z punktu widzenia kogoś innego niż wnętrza zespołu? Znasz coś takiego? Ja się często spotykam z postawą, że jeśli analityk/kierownik/zarząd potrzebuje czegoś, co nie jest z definicji wpisane w agilowe podejście, np. podania terminów (jednak ktoś na to daje pieniądze), większej wymiany informacji niż przewidziane spotkania, to jest uśmiech pod nosem albo szydera, że ktoś nie kuma agila. Nie ma wyjścia na przeciw uzasadnionej potrzebie.

            „może oni nie chcą diagramu ani kawałka dokumentu?” Właśnie to piszę w przedostatnim rozdziale artykułu, żeby robić to, co jest potrzebne do udzielania odpowiedzi, a developerom dawać to, czego oni potrzebują.

            Ja oceniam, że diagram jest porządny z punktu widzenia mojego w kontekście takim, że na jego podstawie mogę udzielić ważnej dla zespołu informacji, której ktoś potrzebuje – wtedy jest porządny. A jeśli nie potrafię, to nie jest porządny. Właśnie piszę w poście, że robię diagramy dla siebie, żebym ja potrafiła udzielać odpowiedzi w złożonych problemach. Mogą nie potrzebować diagramu, ale potrzebują konkretnej odpowiedzi, jeśli napotykają problem.

            Myślę, że wiem wiele, czego developerzy potrzebują do pracy, bo sama byłam developerem, bo rozmawiam z nimi codziennie i bo widzę jakie mają później problemy, bo czegoś nie wiedzieli, a teraz mamy defekt, niedociągnięcie czy brak akceptu klienta.

            Brałam udział w wielu projektach, gdzie albo sama robiłam diagramy, albo ktoś inny je robił i też w takich, gdzie ich nikt nie robił. Widziałam jak to było mieć diagram i jak to było nie mieć diagramu i opierać się na słowno-muzycznym opisie, niespisanych ustaleniach albo intuicji. Widzę korzyści z posiadania diagramów w złożonych zagadnieniach. Nie jesteśmy indywidualnymi artystami tylko inżynierami tworzącymi skomplikowany system informatyczny, na którym działają duże firmy i od którego zależą ich działania. Właśnie tu mi chodzi o to, że niektórzy dla zasady jak widzą diagram to go odrzucają, bo nie potrzebowali go w małych projektach albo dlatego, że dostawali zawsze ustne, szczegółowe instrukcje. I niektórzy dla zasady nie dają mi tego robić po swojemu, żeby dostali to, czego potrzebują.

            Na pewno nie wiem lepiej od programistów czego oni potrzebują. I właśnie tego nie rozumiem dlaczego wiele osób mimo, że nie są odpowiedzialni za wymagania i nigdy się nimi w złożonym systemie nie zajmowali, wiedzą lepiej, co jest wystarczające do ogarnięcia problemu i dostarczenia odpowiedzi.

          • „Jeśli coś innego jest good enough to OK” – tylko czemu mam nieodparte wrażenie, że rozmawiam z Fordem, który mówi mi, że mogę sobie wybrać samochód w dowolnym kolorze, pod warunkiem, że będzie czarny, a analiza może być good enough pod warunkiem, że to JA JAKO ANALITYK powiem co oznacza good enough

            – ja mam dokładnie przeciwne wrażenie. Nie mówię jak ma wyglądać praca programistów, zespołów. Mówię o tym jak ma wyglądać rozkminianie rozwiązań pod kątem wymagań, bo tym się zajmuję. A mam wrażenie, że to z drugiej strony jest problem, że chcę sobie zrobić diagram i dokument (ze to jest „too much, too heavy”), bo uważam, że to mi bardziej pomoże. Jeśli Ty nie masz z tym problemu, to czemu to bierzesz do siebie? To nie jest wtedy artykuł do Ciebie. Ja mam takie sytuacje i się z tym spotykam i o tym pisze.

            „i nikt, żaden developer w krótkich spodenkach, który na oczy nie widział „profesjonalnego” procesu wytwórczego, nie będzie mi mówił co ta analiza ma zawierać. ”
            – to Ty mówisz :) developer w krótkich spodenkach jest mi bliższy niż ktokolwiek inny. Z takiego środowiska jestem, takich mam znajomych. I właśnie ich pytam czego oni potrzebują. A po swojej stronie się zastanawiam jak to dostarczać. Tak samo ja mogę chcieć rezultatu jak działa oprogramowanie, ale nie zaglądam w kod i nie mówię, że takie konstrukcje są niewłaściwe.

            Zaczynam się zastanawiać czy, a rebours, nie prezentujesz równie twardogłowego stanowiska, które tak bardzo krytykujesz u osób po drugiej stronie :-)
            – bo mówię – dam Wam czego potrzebujecie, a w zamian dajcie mi do tego dochodzić po swojemu?

            Napisałaś w artykule „Analizę robisz dla siebie. Żeby poskładać sobie wszystko w głowie.” I to jest święta prawda. I jak robisz ją dla siebie, możesz sobie wybrać dowolną formę, notację, metodę. Chcesz robić 100 diagramów? Rób.
            – no właśnie nie mogę w wielu przypadkach. Jeśli Ty tak nie uważasz, to artykuł nie jest do Ciebie.

          • „Zastanawiam się za to jak ogarnąć te potrzeby klienta w bardzo złożonym, wymagającym projekcie, jeśli się jest w takim środowisku” – I O TYM POWINNAŚ NAPISAĆ ARTYKUŁ!! Bo to jest rzeczywiste wyzwanie!
            – no właśnie o tym piszę, że to jest wyzwanie i niełatwa sprawa.

            I najlepiej we współpracy z ludźmi, którzy wiedzą jak to robić w agile (Krystianem, Tomkiem Wykowskim, itp.)
            – Nie wiem czy to wiedzą, bo mi Krystian nie odpowiedział na to w szczegółach. I nie widzę szczególnej otwartości na rozmowę. Wręcz przeciwnie.

            Czekam z utęsknieniem na dobry, polski artykuł o tym jak może wyglądać analiza w agile, który nie będzie pielęgnował strachów dużej części analityków, który pokaże że może być KOMPLETNIE inna, co wcale nie oznacza, że będzie gorsza.
            – ja to właśnie próbuję robić. Dochodzić do tego i publikować. Ale to też wymaga otwartości z drugiej strony.

            Tylko nie z pozycji osoby, która poniża innych nazywając ich twardogłowymi.
            – Gdzie kogoś poniżyłam? A przytoczyć Ci cytaty gdzie mnie tu ktoś obraża?
            – Jeśli jesteś otwarty na różne rozwiązania, to nie jest artykuł do Ciebie.

            Tylko może właśnie z pozycji osoby, która rozumie co oznacza agile i pomaga innym wytłumaczyć jak w odpowiedzialny sposób można go skalować. Właśnie po to, by radzić sobie ze złożonymi projektami.
            – Ja tego nie wiem. Tu jest pytanie. Ale jak słucham jak to robią inni, to widzę, że to ma bardzo wiele wspólnego i z innymi projektami i nie rozumiem, czemu inne są złe, choć robią to bardzo podobnie.

            Bo inaczej nikt z „obozu zwinnego” nie potraktuje Cię jako sojusznika. Wszystkim będzie się wydawało, że po prostu chcesz nasikać im do namiotu.
            – No właśnie o tym jest artykuł. Że warto chociaż otworzyć się na rozmowę, a nie odrzucać z automatu.

          • „a czy Ty zajmowałeś się wymaganiami w złożonym projekcie” – uznajmy że tak, CV nie będę wysyłał, bo w tak zacnym gronie to niekulturalne będzie ścigać się na długość członka ;-)

            „często spotykam z postawą, że jeśli analityk/kierownik/zarząd potrzebuje czegoś, co nie jest z definicji wpisane w agilowe podejście…” – a widzisz, zgadzamy się!! Przecież powtarzam od dłuższego czasu, że to kwestia postawy, a nie metody.

            Mogę odbić piłeczkę i napisać, że w waterfallu często spotykałem się z postawą, że kierownik/sponsor/zarząd źle reagował na jakiegokolwiek CR’a. Wina metody? No oczywiście że nie, bo przecież każdy powie, że zarządzanie zmianą w klasycznych podejściach wytwarzania i zarządzania projektem to coś naturalnego, a CR’y to nic złego. A mimo wszystko, reagowali źle i w większości przypadków kwitowali problem konstatacją, że IT coś źle zrobiło. Dlaczego ci wszyscy mądrzy ludzie tak się zachowywali? Czy byli twardogłowi? Mieli złą postawę? Może niekompetentni? A może wcale nie mądrzy?

            A może splot pewnych okoliczności, coś co Deming nazwałby „systemem” pchał ich myślenie w pewną stronę? A agile, jako że to inny „system” pcha ludzi w jeszcze inną stronę. I to normalne że wywołuje zgrzyty w innych miejscach niż waterfall.

            Od tego są dojrzali ludzi, mentorzy, coache, analitycy, by tłumaczyć ten system. By wiedzieli wcześniej gdzie coś zazgrzyta. A wyzwaniem pozostaje: co zrobić, aby ludzie byli otwarci na tę naukę? Aby zaczęli dostrzegać te problemy i chcieli mieć wew. motywację ich rozwiązywania. I to co jest bezcenne w podejściach LEAN-Agile to kultura, którą Sceptyk pewnie określi mianem bezwartościowych metafor, a która w praktyce sprzyja właśnie otwieraniu ludzi na takie zachowania. Największą słabością waterfalla są systemowe warunki skłaniające ludzi do zamiatania lub przerzucania problemów. To co jest największą zaletą podejść LEAN-Agile, to wyciąganie problemów na wierzch i zmuszanie ludzi do zajmowania się nimi. Dla wielu ludzi wychowanych w klasycznym świecie zderzenie się z tym, że o problemach mówi się otwarcie jest kulturowym szokiem. A to jest największa bariera we wdrażaniu takiej zmiany.

            Czekam oczywiście na jakiś przykład pojedynczej osoby, która gdzieś w jakiejś firmie zachowuje się jak gbur, idiota, palant, a którą teraz ktoś wyciągnie by udowodnić mi, że to co napisałem o kulturze LEAN-Agile to bullshit – i od razu komentarz z mojej strony: {wzruszenie_ramion} :-)

            We wtorek startuje w Warszawie 2-dniowa konferencja o transformacjach agile’owych dużych przedsiębiorstw, przyjedź, bo gwarantuję Ci, że to wszystko o czym piszesz się tam wyleje :-) Każda duża firma która wdraża agile przechodzi przez moment, gdzie wytwarzanie jest już zwinne, ale wyższy management, wszelkie procesy zarządcze i decyzyjne związane z implementacją strategii są jeszcze po staremu. Sam w takiej firmie pracuję. I zapewniam Cię, że JEST PRZEZABAWNIE :-) Straszno i śmieszno jednocześnie :-)

            p.s.
            I aby już zamknąć tę dyskusję… prowadzisz zajebistego bloga, ułatwiasz mi niesamowicie robotę, bo zamiast coś tłumaczyć juniorom samemu, mogę wysłać im linka do Twoich artykułów, wyników ankiet, itp. Niektórzy przechodzili przez kurs adeptów analizy i bardzo sobie chwalili. Jesteś świetna w tym co robisz. I rób to dalej :-)
            Musisz jeszcze tylko trafić na dobrego agile’a (a nie jakieś nędzne imitacje) i uwolnić się spod wpływu pana Jarosława Ż. ;-) A gwarantuję Ci, że pokochasz zwinność, bo po tym co przed chwilą napisałaś o tym jak ogromny wysiłek wkładasz w komunikację i naukę, pasujesz do tej układanki idealnie.

          • Dzięki :)
            Już mam plany na wtorek i środę, ale jak powiesz co to jest, to może się załapię na następną albo jakieś materiały z tej.
            Co do Jarka. Każdy ma swoje spojrzenie na różne sprawy. Moje może nieco inne na współpracę z dev, ale to też wynika z charakteru pracy. Ale w temacie analizy, to to, co ja piszę, to nie widzę jakiejś sprzeczności z J. A od niego wiem większość rzeczy, jakie wiem o analizie. I gdyby nie jego blog, to myślę, że analiza u nas byłaby kilka lat do tyłu – moja na pewno i ludzi, co czytają tego bloga i innych, co czytają J. Mało kto by to wszystko odkrył w tak krótkim czasie.

          • Waterfall tworzy przed decydentami ułudę, że wszystko jest zaplanowane, przewidziane, pod kontrolą, ba, nawet ryzyka znamy i potrafimy ocenić ich prawdopodobieństwo (nie piszę o teorii i o tym co jest w podręcznikach PMI tylko o tym jak w praktyce zachowują się ludzie używający tej metody).
            Agile odziera proces wytwórczy z tych wszystkich mitów. Wywala od razu na stół problemy, że czegoś nie wiemy, nie umiemy, nie potrafimy. I każe nam się nimi zajmować. Np. od razu wywala problem wartości dokumentów analitycznych i każe analitykom zastanawiać się co z tych wielu stron dokumentacji, które do tej pory przygotowywałem jest tak naprawdę ważne dla mojego klienta czyli developera. Tak samo jak PM’om każe się zastanawiać jaka jest wartość tych wszystkich planów, które robią. Samo myślenie, że developer jest klientem, a więc kimś ważniejszym od nich, już jest nieznośne dla wielu ;-)

            Dla wielu osób wychowanych w starym świecie praca w warunkach tak ogromnej niepewności jest nieznośna, bo są przyzwyczajeni do podejmowania decyzji gdy niby wszystko jest jasne.

            Dla ludzi wychowanych w nowym świeci tak samo nieznośne jest gdy ktoś oczekuje od nich odpowiedzi na wszystkie pytania.

    • Intryguje mnie, czy Pan Andy z Panem Krystianem zakładają również, że developerzy powinni sami budować infrastrukturę sieciową pod konstruowany przez siebie system (włącznie z konfiguracją firewall’i, itd.), stroić serwery baz danych, konfigurować w razie potrzeby HSM’y, podkręcać jądra systemów, itd.?

      A Panu Andy’iemu warto uświadomić, że rola = zbiór kompetencji – to jest po prostu synonim, więc przeciwstawianie roli zbiorowi kompetencji jest semantycznym nieporozumieniem. Przypomnę, że we wszystkich metodykach od zawsze pojawia się następujące wyjaśnienie: rola to nie osoba, dana osoba może pełnić w projekcie wiele ról.

  9. Ja przez lata mojego doświadczenia pracowałem w oparciu o metodyki „tradycyjne” a od ostatnich 2 lat „agilowe”.
    Uważam, że fundamentalna rożnica między tymi metodykami nie leży w szczegółach takich jak sposób zbierania wymagań, używane narzędzia, role w zespole itp. Zgadzam się w zupełności, że sprawny manager projektu/członek zespołu dobiera właściwe narzędzia w zależności od sytuacji i tym więcej ich zna tym lepiej.

    Dla mnie największą różnicą jest to, czy :
    1) przyjmujemy założenie, że na początku da się dokładnie zidentyfikować większość wymagań biznesowych, stworzyć na ich podstawie plan a następnie podążać według niego przez cały projekt

    2) czy też założeniem jest to, że biznes nie jest w stanie dokładnie stwierdzić, czego chce lub jego klienci dopóki nie wykona jakiegoś eksperymentu w oparciu o coś namacalnego (Minimum Valuable Product) i nie zweryfikuje empirycznie czy założenie działa czy też nie (testy A/B)

    W pierwszym przypadku, odstępstwa od planu, wyrzucenie do kosza kawałku kodu/produktu są błędem w sztuce.

    W drugim przypadku jest to norma. Chodzi aby jak najszybciej/najtaniej zrobić jakiś kawałek produktu, sprawdzić czy działą i stwierdzić czy rozwijamy go dalej bo jest ok, zmieniamy coś bo jednak nam się nie podoba, albo wyrzucamy kompletnie do kosza i zaczynamy od nowa. I nie jest to błędem, o ile z takiego działania płyną wnioski i lepsze zrozumienie biznesu/klienta.

    Oczywiście, nie wyobrażam sobie aby taką metodą prowadzić projekt w stylu stadion piłkarski na mistrzostwa euro. Tam musi być z góry określone jak stadion ma wyglądać, na kiedy ma powstać itp i kluczowe jest podążanie zgodnie z planem.

    Krótko mówiąc, obydwie metodyki mają racje bytu należy tylko je stosować w odpowiedniej sytuacji

  10. Widzę Michale, że z Ciebie cichy psychoanalityk. Niczym Freud przenikasz ludzkie umysły i dusze. Dostrzegasz lęki i urojenia (ułudy), których biedni waterfallowcy ze starego świata dojrzeć nie potrafią lub co gorsza nie chcą. Dobrze, że agileowa prawda wyzwala. Dzięki!

  11. trochę pomieszanie z poplątaniem w artykule, mam wrażenie że bez zrozumienia czym agile jest albo po prostu napisane na bazie fatalnych doświadczeń. ale zgadzam się, iż frameworki agilowe stał się po prostu modne, w tym w wielu korporacjach, choć tam niejednokrotnie istotnie mało tego agile w agile’u. mało przez m.in nieelastyczne procedury, projektowe budżety zamiast produktowych, zabijanie kreatywności poprzez oczekiwanie ciągłych sukcesów mierzonych krótko-okresowo, itd…

    btw. nikt nie mówi, że zwinne podejścia są tańsze niż waterfallowe; nikt nie mówi że te podejścia są proste; mam też wrażenie same podmioty typu PMI „pomagają” by zatracać istotę zwinności; bzdurą jest twierdzenie że ogólnie dokumentacji ma nie być w agilowych podejściach…

    to co wyżej piszę przez pryzmat paru lat pracy w środowiskach waterfallowych jako analityk bzinesowy + paru lat pracy we frameworkach określanych jako agilowe (jako PO badz czlonek zespolu dewelopeskiego).

  12. Dużo dużo za długich komentarzy. Zgadzam się z dwiema stronami, ale widzę, że wiekszość osób silnie niezgadzających się z tekstem nigdy nie stała po stronie klienta, gdzie często z przyczyn organizacyjnych nie da się pracować agilowo, albo grupy interesariuszy nie mają czasu zaangażować się w projekt (liczą na płynną transformacje i przejście z narzędzia A do B i maks mogą poświęcić pare dni na warsztaty i odbiór). Nie raz pracowałem z ‚super’ dostawcami agilowymi, którzy mieli być też analitykami i spędzałem pare godzin zamiast paru minut na tłumaczeniu podstawowych dla mnie rzeczy, bo nikt ich nie nauczył rachunkowości, nie znają się na międzynarodowych standardach dot. interfejsów magazynowych itd . Uważam, że analitycy po stronie klienta są niezbędni i przy naprawdę dużych organizacjach podejście waterfallowe jest niezbędne, gdyż inaczej nie da się zarządzić biznesem, urlopami, warsztatami itd. Projekty agilowe stale angażują wszystkie strony, a nie każdy projekt można tak zrealizować. Dostawca ..może być książkowo adżajlowy.
    A silosy – czasem są potrzebne, mają chronić organizacje przed poświęceniem zbyt dużych zasobów na projekt informatyczny (w końcu firma ma zarabiać a nie zajmować się projektami IT).

  13. Szanowni! Przeszedłem przez artykuł – przeszedłem przez komentarze; całość bardzo, bardzo wciągająca niczym „Stranger Things” :). Nie chce nurkować w dyskusję ale… 3 grosze z mojej strony jako refleksja osoby z doświadczeniem APM/TPM i pokrewnym.

    Grosik 1 – Nie mieszajcie Agile Product Management z Agile Project Management! To dwa światy!

    Grosik 2- Jeśli dana organizacja NIE POTRAFI robić biznesu/projektów/rozwijać produktów TRADYCYJNIE to tym bardziej nie będzie umiała AGILE/ZWINNIE!

    Grosik 3 – Agile/Scrum samo sobie robi krzywdę – poprzez pozornie mały/niski „buy in” tzn. jest wiele osób i organizacji przekonanych, że jednym szkoleniem, broszurką, książką zmienią same siebie na lepsze; zwłaszcza młodzi ludzie, adepci różnych ról IT – po co czytać/poznać setki stron P2/PMBOK/itp skoro można do poduszki przeczytać kilka stron Scrum Guide…

    Have a nice day!

  14. Cześć!

    Przebrnąłem przez całość i nie chcę mocno wchodzić w dyskusję, szczególnie, że wielu mądrzejszych ode mnie już się wypowiedziało. Chciałbym tylko zwrócić uwagę na następujące:
    – Agile nigdzie nie zakazuje rozbudowanych analiz, pięknych diagramów UML, kwadracików, kółeczek i innych. Niech istnieją, niech analiza będzie jak najlepsza – to tylko pomoże. Najważniejsze to by zespoły wytwarzające miały kontakt z analitykiem (pośredni lub bezpośredni) i by ten analityk wiedział jak z poziomu analizy biznesowej/systemowej miał wyglądać produkt zakładając horyzont czasowy 1-2 sprintów. Agile nie zakazuje istnienia analizy od A do Z. Ważnym natomiast jest by analiza była otwarta na feedback klienta i zespołów wytwarzających.
    – Tomku, co do 3 grosika. Nikt nie mówi, że Agile czy SCRUM jest prosty i ma niski buy in. Wręcz przeciwnie. Twórcy SCRUM zauważają, że ten framework to zbiór prostych zasad/ reguł, ale jego zastosowanie jest bardzo trudne. Tak samo pokazuje życie. Zwróccie z resztą uwagę na to jak ogromny jest SCRUM Community i jak ogromna ilość wiedzy jest codziennie przemielana.

    Hania, odnosze wrażenie, że ktoś strasznie wystraszył Cię SCRUMem czy Agile. Może organizacja, może nieodpowiedni ludzie. Wszystko jest dla nas i spróbuj przeszukać sieć właśnie pod kątem tematów, które Cię trapią. Należy tez pamiętać, że są oczywiście projekty, w których SCRUM nie jest najlepszym rozwiązaniem. Natomiast samo podejście Agile, czy do wywarzania oprogramowania, czy do innych dziedzin życia, nadaje się doskonale. Przecież nawet PRINCE2, w swojej podstawowej formie, realizuje zasady Agile. To po prostu ma sens i działa.

    Tyle z mojej strony :) Nie bać się! Próbować! :)

    • Cześć Karolu. Zgadzam się z Tobą. Właśnie to miałam na celu przekazać tutaj. Chodzi mi o postawę ortodoksyjną, że nie ma być analityka, nie ma być nic szczegółowo analizowane i modelowane, bo nie. Jak rozmawiam z ludźmi powiedzmy autorytetami w tym temacie, to (nie wiem dokładnie jak procentowo), ale zupełnie 2 różne są postawy. Jedna właśnie taka jak piszesz, a druga taka, że nie ma być analityka i analizy, przypadków użycia i UML, tylko rozmowa, a wszystko inne jest złe (czytaj nie-agilowe). Chociaż Alistair Cockburn (jeden z twórców manifestu agile) napisał ksiażkę „Jak pisać efektywne przypadki użycia” a Arie van Bennekum (drugi z twórców manifestu agile)nie widzi w dobrej analizie problemu, a mówi, że jest bardzo ważna, wiele naszych polskich ekspertów widzi w tym problem i uznaje za coś niewłaściwego – nie wpisanego w agile.

      • Dokładnie. Wytwarzanie oprogramowania musi po prostu być zdrowe. Jeżeli w danej organizacji zespołom produkcyjnym pomaga genialna fancy analiza, to powinni ją stosować. Jeżeli przeszkadza, to powinni zaprzestać. Każde środowisko jest inne. Ani SCRUM ani ogólnie Agile, na mój stan wiedzy, nigdzie nie zakazuje istnienia analityków w procesie. Moje doświadczenie mówi nawet, że oni są totalnie niezbędni, jednakże jeżeli korzystamy z któregoś ze zwinnych frameworków, to również analitycy powinni się do niego dostosować i go wspierać. Wtedy wszystko działa. Największym błędem w stosowaniu Agile jest radykalizowanie zasad ukrytych za manifestem i komplikowaniem całego procesu, który z założenia ma być jak najprostszy, szczególnie w dużych, wielozespołowych projektach. Powiedziałem co wiedziałem. Fajnie, że poruszyłaś ten temat i rozpętałaś trochę burzę w okół mody na zwinność :)

ZOSTAW ODPOWIEDŹ