Koniec pandemii? A jeśli tak, to co dalej?

Dawno nie miałem tak ciekawej rozmowy jak wczoraj. Do pewnego stopnia była to rozmowa przełomowa, gdyż może wskazywać, że powoli kończy się trwająca od lat pandemia. Oczywiście pojawiają się pytania, jak duże mamy straty i czy uda się odbudować świat po pandemii? A jeśli się uda, jak długo to będzie trwało. Ale, od początku…

Wczorajsze popołudnie rozpoczęło się od odebrania telefonu od nieznajomej osoby. W pierwszych słowach rozmówca przedstawił się jako lider zespołu wytwarzającego oprogramowanie dla bardzo wymagającego Klienta. Zespół jest dość spory – łącznie, kilkadziesiąt osób podzielonych na mniejsze grupy. System także jest spory. Rozwijany w dużych przyrostach, przez lata. Z jednej strony, ciągle dodawane są do niego nowe obszary funkcjonalne. Z drugiej – do istniejących funkcjonalności wprowadzane są zmiany.

Sytuacja, wydawałoby się, dość jasna i powszechna. W czym więc problem? Otóż, zespół doszedł do wniosku, że powoli przestaje panować nad całą złożonością, a dalszy rozwój oraz utrzymanie zaczynają być na tyle uciążliwe, że skutkuje to zauważalnym spadkiem efektywności i skuteczności prac, a co za tym idzie, rosnącą frustracją członków zespołu. Na tyle dużą, że część z nich postanowiła opuścić zespół z tego właśnie powodu. Ponieważ problem nie jest nowy, więc, jak mi powiedziano, był wielokrotnie dyskutowany. Efektem tych dyskusji było spostrzeżenie, iż aktualny sposób prowadzenia prac, oparty o historyjki i epiki, pomimo ‚dokręcania’ ich zgodnie z rekomendowanymi technikami, bardzo utrudnia prace analityczne. Jednym z objawów tych trudności jest poświęcanie coraz większej ilości czasu na przeszukiwanie narzędzia wykorzystywanego do zarządzania specyfikacją, w celu znalezienia opisu aktualnej funkcjonalności systemu oraz wprowadzanie zmian do niej. Spostrzeżeń, oczywiście było więcej, bo i problem jest niemały.

Szukając metod poprawy sytuacji, członkowie zespołu, uczestniczyli w wielu szkoleniach, spotkaniach branżowych oraz, jak mi powiedziano, przeczytali cały Internet dwa razy. I stwierdzili, że w zasadzie, niewiele nowego się dowiedzieli. Wprawdzie doczytali o nowych technikach, możliwych zmianach w sposobie zapisu, nowych narzędziach. Wiele z takich zaleceń wprowadzili do swojej pracy, ale jakościowej zmiany nie zaobserwowali.

Szczerze mówiąc, usłyszawszy to, mocno się zdziwiłem. Internet jest bowiem pełen opisów technik , które pozwalają na usprawnienie prac nad tego typu przedsięwzięciem, czym podzieliłem się z rozmówcą. I w tym momencie rozpoczął się kolejny interesujący wątek.

Wszystkie dotychczasowe poszukiwania metod mogących usprawnić prace były skoncentrowane na podejściu agile’owym. Na pytanie dlaczego, padła odpowiedź, że tylko takie znają. Cały zespół jest bowiem z pokolenia, które weszło na rynek, na którym niepodzielnie panuje agile. Odruch, by szukać tylko wśród technik agile’owych był tak naturalny, że nikt przez dłuższy czas nie myślał, by sięgnąć gdzie indziej. Bo czym jest gdzie indziej? Historią, jak stwierdził z uśmiechem rozmówca.

Rany, jaki ja jestem stary, pomyślałem.

W końcu, ktoś z zespołu otworzył pozycję historyczną. W Internecie, oczywiście. Usłyszałem, że to było o UMLu. Pozycję znam, więc bynajmniej nie dotyczy tylko UMLa. Kilka osób z zespołu stwierdziło wówczas, że miało jakieś zajęcia z UMLa na studiach, ale nikt jakoś poważnie tego nie traktował. Raczej na zasadzie, nauczyć się, by zaliczyć. Pomimo tego, zespół postanowił temat podrążyć. Stworzono nawet malutki projekt pilotażowy, którego celem było wypróbowanie nowopoznawanych technik do realizacji prac projektowych. Dwie osoby równolegle z resztą zespołu, po nowemu i na boku, opisywało analizę. Wniosków z tego ćwiczenia było wiele. Te ważniejsze, to:

  • początkowo, dwuosobowy zespół gros czasu poświęcał na opisanie tego, jak jest aktualnie, by w ogóle móc myśleć o opisaniu nowej funkcjonalności,
  • zespół eksperymentatorów stwierdził po jakimś czasie, że to nie jest takie proste, a potwierdzeniem tych słów była informacja o czasie, jaki był poświęcany na poprawę tego, co zrobili,
  • doczytywanie w Internecie o stosowanych technikach skutkowało wnioskami w stylu a tutaj robią to trochę inaczej, choć niby to to samo,
  • wykorzystywane narzędzie do modelowania sprawiało na początku wiele problemów wynikających z jego złożoności.

Interesujące było to, że swoimi doświadczeniami zespół postanowił podzielić się w trakcie jednego z branżowych spotkań. I okazało się, że nie są sami z problemem. Co więcej, ich wystąpienie spotkało się z bardzo pozytywnym odbiorem a kilka osób stwierdziło, że spróbuje u siebie porozmawiać o możliwości wdrożenia tego typu metod pracy. Ale, jak to stwierdził rozmówca, na sali, pomimo ponad sześćdziesięciu osób, nikt (sic!) nie miał praktycznego doświadczenia z metodami pracy opartymi o modelowanie.

Pod koniec rozmowy przeszliśmy do tematu praktycznego wdrożenia takiego podejścia w zespole. Poruszyliśmy temat metodyki – pojęcia które wywołało od razu reakcję ale nie takiej sztywnej! Więc zapytałem, skąd obawa, że będzie sztywna? Odpowiedź, bo stare metodyki były sztywne. To sobie chwilę i o tym porozmawialiśmy. A na koniec padło pytanie, o szacunkowy czas wdrożenia takiego podejścia w całym zespole (kilkadziesiąt osób, przypomnę).

Tiaaaa, i dotknęliśmy trudnego tematu. Oczekiwania były takie, by zaspół zaczął pracować opierając się o modelowanie po miesiącu, maksymalnie dwóch. Ja stwierdziłem, że to niemożliwe, gdyż z tego co słyszę, wdrożenie ma dotyczyć zarówno opisywania procesów jak i całej analizy systemowe. Zespół bowiem doszedł do wniosku, że albo zrobią wszystko, albo nie zaczynają, bo to nie ma sensu. Chwilę o tym porozmawialiśmy i na koniec pojawił się jednak pomysł, jak do tematu podejść przyrostowo. Rozmówca zrozumiał wówczas, dlaczego myślenie w perspektywie miesiąca nie jest zbyt użyteczne. Że to bardziej temat na lata, by w pełni wypracować i wdrożyć metodykę ( w tym, narzędzia do pracy zespołowej). Natomiast podzielenie tego procesu na przyrosty, opracowywane w sposób uwzględniający stan docelowy, zostało uznane za słuszne.

A jak zabezpieczyć się przed ryzykiem pójścia w maliny, padło pytanie na koniec. Odrzekłem, że trzeba mieć w zespole doświadczoną osobę, która będzie mistrzem dla czeladników. A skąd ją wziąć, padło kolejne.

Hmmmm, dobre pytanie, pomyślałem. Pandemia agile’owa spowodowała, że wytworzyła nam się luka pokoleniowa. Osoby, które mają takie doświadczenie, to moim zdaniem ludzie w wieku 45+ (oczywiście z wyjątkami). Sam znam kilkadziesiąt takich osób. Z szeroką wiedzą, dużym doświadczeniem w konsekwentnym stosowaniu procesów wytwórczych opartych o modelowanie w różnego typu przedsięwzięciach. Część z nich…jest już na emeryturze. Ci, którzy nie są, pracują w firmach i raczej nie wspomogą innych firm. I taka mnie tkła myśl, że jeśli rzeczywiście pandemia ma się ku początkowi końca i firmy zdecydują się na to, by usprawniać swoją pracę posiłkując się zdroworozsądkowo technikami, które lata temu zostały uznane za niewłaściwe, to pojawi się problem kompetencyjny. Bo zabraknie mistrzów, którzy mogliby przez dłuższy okres zabezpieczać pracę wdrażających się zespołów. A bez nich, firmy staną przed dylematem, wymyślać koło od nowa, czy nie? A jeśli nie, to co? Bo same książki (jakie by nie były dobre) i szkolenia (jakie by nie były dobre) to za mało.

To była ta mało optymistyczna część naszej rozmowy.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Grafika: House photo created by master1305 – www.freepik.com

Od historyjek do epików wstępująco (ang. bottom-up)

Moda na Edżajl trwa i na razie nic nie zwiastuje rychłego zakończenia trendu. Jednym z tego efektów jest konieczność wpisania elementów procesów wytwórczych opartych o bardziej zaawansowane narzędzia w proste elementy skramomopochodne. Oczywiście, przed takimi wyzwaniami (ponieważ rzecz dzieje się w korporacji, więc o problemach nie ma mowy) i mi przychodzi stawać. I stąd niniejszy wpis.

W stosowanym od lat podejściu, usprawnienie określonego obszaru biznesowego zwykle skutkuje powstaniem obrazu docelowego procesu biznesowego. W zależności od sytuacji, może to być zarówno duża reorganizacja procesów, jak i drobna ich modyfikacja. Efekt, z analitycznego punktu widzenia, jest we wszystkich przypadkach taki sami – powstaje komplet – procesy biznesowe oraz stojący za nimi aparat pojęciowy (model pojęć).

Jeżeli w ślad za zmianami w procesach podążać mają zmiany w rozwiązaniach IT, model jest uzupełniany o kolejny wymiar – oczekiwania wobec funkcjonalności IT zdefiniowane w kontekście poszczególnych kroków procesu. Dlaczego tak? Uzasadnieniem dla takiego podejścia jest chęć uniknięcia wymagań precyzowanych w bliżej nieokreślonym kontekście (często na wyrost). Bazując na krokach, rozważamy konkretny, nieduży zakres procesu i tym samym, co pozwoli na łatwiejsze uzasadnienie istnienia wymagania i korzyści z niego wynikających. Technicznie, technika skutkuje powstaniem diagramu wymagań, na którym z krokiem skojarzone są wymagania. W przypadku języka SysML, diagram taki mógłby wyglądać, jak poniżej.

Diagram wymagań ilustrujący koncepcję łączenia kroków w procesie i wymagań

Jak widać, definicja wymagań może nawiązywać do proponowanej stylistyki historyjkowej, nie tracąc nic na swojej mocy. Wprawdzie fragment JAKO nazwa roli jest redundantny i jest powieleniem relacji krok procesu – tor reprezentujący rolę, na której się znajduje, ale przy dostatecznej stabilności przebiegu procesu, redundancja nie powinna sprawiać problemu.

Zwykle, po wykonaniu tych działań, kolejnym elementem procesu wytwórczego jest powiązanie wymagań z opisem funkcjonalności systemów, które będą uczestniczyły w ich realizacji (np. przypadki użycia, usługi, itp.). W przypadku podejścia edżajlowego, wymagane jest jednakże zgrupowanie wymagań w kategorie, nazywane epikami. Z punktu widzenia procesu wytwórczego opartego o modele jest to krok zbędny, ale oczekiwania procesu edżajlowego są w tym momencie bezwzględne – historyjka musi być elementem epiku.

Epik to element grupujący. Kryteria grupowania są subiektywne. Pojawia się więc pytanie – jak zgrupować wymagania w zbiory? Ponieważ takie podejście, jakie proponuję jest jakby wbrew zstępującemu procesowi edżajlowemu (najpierw epiki, potem historyjki), więc wskazówek w edżajlowych bazach wiedzy nie znalazłem. Ale, z pomocą przychodzi znana od dziesiątek lat technika diagramu podobieństw (ang. affinity diagram). Wykorzystajmy ją wprost. Bez jakichkolwiek modyfikacji. Uzyskamy pożądane epiki. Jeśli ktoś nie zna techniki – załączam odnośnik do krótkiego wykładu na Jutjub.

Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

OCeeL, teoretyczna teoria, czy praktyczna praktyka?

Zupełnie niespodziewanie przeprowadziłem dzisiaj ponad godzinną rozmowę ze studentem podejmującym decyzję o temacie pracy magisterskiej. Pytanie, z jakim zadzwonił, można streścić jednym zdaniem Czy OCL to już odległa historia, czy coś, czym warto się jeszcze zająć? Ponieważ dziś sobota, więc nie spodziewałem się telefonu w takiej sprawie, ale doszedłszy do siebie, już chciałem odpowiedzieć, że jak to historia? , ale powstrzymałem się i zapytałem a skąd pytanie? Odpowiedź była do przewidzenia – wszyscy mówią, że to czysta teoria i tak nikt nie pracuje.

To jak się pracuje?

Takim pytaniem postanowiłem podrążyć temat. I usłyszałem, że po pierwsze, OCL to już programowanie, po drugie, bez sensu jest dokumentować każdą linijkę kodu, i po trzecie, dlaczego analityk ma narzucać programiście, co ma robić.

OCL to już programowanie

Tak może powiedzieć tylko ktoś, kto nie ma pojęcia, czym jest OCL. Wytłumaczywszy studentowi, że OCL ma się tak do programowania, jak wzór w Wordzie do zapisów w silniku reguł biznesowych, usłyszałem – o dziwo – odpowiedź tak mi się wydawało.

Dokumentowanie a analiza

Na temat tego typu sformułowań można byłoby książkę napisać. Analiza to nie dokumentowanie! Analiza to proces tworzenia koncepcji rozwiązania. To co pozostaje po wykonanej analizie, można nazwać dokumentacją, ale jest to poniekąd efekt uboczny a nie cel. Tutaj student poprosił o wyjaśnienia, ale na koniec stwierdził, że rozumie (a dokładniej, zakminił).

Wpływ na programistę

Dlaczego analityk ma narzucać programiście, co ma robić? Hmmm…dlatego, że taka jego rola. Odpowiedzialnością analityka jest doprowadzenie do powstania koncepcji rozwiązania. W tym celu musi komunikować się z szeroko pojętym zestawem interesariuszy. W ich skład wchodzi zarówno tak zwana strona biznesowa jak i technologiczna, z programistami włącznie. Nie zmienia to faktu, że to analityk jest odpowiedzialny za stworzenie koncepcji. Ta koncepcja jest następnie przekazywana do zaprogramowania. Bez narzucania metod, ale z narzuceniem celu.

Ale przecież programista może stwierdzić, że można to zrobić lepiej! Oczywiście, że może. Ale to analityk powinien finalnie potwierdzić koncepcję. Zdanie programisty, to zdanie jednego z interesariuszy. Analityk musi uwzględnić zdanie wszystkich, którzy mają wpływ. I dokonywać korekt każdoroazowo, gdy taka konieczność nastąpi. Czyli do samego końca procesu produkcyjnego.

Ten temat zajął nam najwięcej czasu. Mam jednakże wrażenie, że rozmówca ostatecznie zrozumiał znaczenie OCL w całym procesie wytwórczym. Zresztą, nie tylko OCL. 

Ale dlaczego warto pisać o takiej rozmowie?

Kto poddał w wątpliwość?

To jest powód powstania niniejszego wpisu. Wątpliwość bowiem podniósł opiekun przyszłej pracy. Pracownik naukowy. Osoba, która powinna rozumieć. Poszerzać horyzonty studentów. Inspirować. Nie poddawać się modom. 

To był jakiś dzban (tak się chyba teraz mówi o osobach, które nie w pełni rozumieją, co mówią), pomyślałem. Zaproponowałem, aby student jeszcze raz porozmawiał z opiekunem i wyjaśnił powody dla których chciałby się zająć OCeeLem.

Niesmak pozostał. A wraz z nim pytanie dokąd zmierza świat naukowy?


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Edżajl 2018 (level Corpo, level hard)

agile2018mediumDługo nosiłem się z zamiarem powrotu do pisania. W końcu to nastąpiło, ale po raz kolejny sprawdziła się zasada, że rzecz raz odłożona dalej odkłada się już sama. Ostatecznie, zaniosłem się i idąc za ciosem postanowiłem kontynuować wątek zwinności. Dlaczego? Bo chyba nie da się go nie kontynuować, obserwując wszechobecne uzwinnianie się zespołów, metod pracy i całych organizacji. I ten ostatni poziom wydaje się być groźny. I o tym, w skali korporacyjnej, poniżej.

Co to jest ten Edżajl?

No właśnie. Na początku mojej przygody z tym trendem, było to nic innego jak sposób organizacji pracy w zespole projektowym. Kilka prostych zasad, proste narzędzie (stosowaliśmy ScrumDesk) i można było się w to pobawić. Fundamentalnych usprawnień nie odnotowaliśmy, ale miałem wrażenie, że w jakimś stopniu wzrosło poczucie świadomości stanu prac w zespole. Od strony inżynierskiej Scrum nie wpłynął na stosowane metody pracy. Tak było wiele lat temu.

Tymczasem mamy rok 2018. Mamy Edżajl. I tego Edżajla już nie rozumiem. Co oznacza, że nie rozumiem większości otaczającego mnie świata zawodowego.

Poziom IT

Co o nim wiem. Wiem, że Edżajl to klimat pracy. Ma być korzystny. O klimat troszczą się Edżajlkołczowie. Piękni dwudziestoletni, którzy są w stanie powiedzieć jakie metody pracy stosować, a jakie nie, bo się nie sprawdzają. Sprawdzają się metody proste albo nowe. Nie sprawdzają się metody kojarzone z Łoterfolem – siedliskiem zła, który kreatywnych ludzi wciskał w tryby biurokratycznej machiny i pozbawiał wpływu na cokolwiek.

Skąd to wiedzą? Wiedzą stąd, że spotykają się w swoim gronie pięknych dwudziestoletnich i dyskutują. Na tych spotkaniach panuje dobry klimat, skutkujący szczerą, otwartą rozmową, z której to powstają nowe pomysły. W sposób otwarty Edżajlkołczowie komunikują swoje przemyślenia zespołom edżajlowym. Ponieważ pracujemy w duchu akceptowania zmian i poprawek, nie przejmujemy się tym, że nowe pomysły często przeczą starym pomysłom. Refaktor idei, czyli pozytyw.

Edżajlkołczowie pracują ze swoimi zespołami. Zespoły mają ograniczoną liczebność, gdyż zespoły zbyt duże są nieefektywne. Przy większych przedsięwzięciach, powstaje wiele zespołów mających realizować wspólny cel. Ale zespoły są autonomiczne i nikt, ale to Nikt Spoza Zespołu, nie może czegokolwiek wrzucić do Baklogu. Tak więc zespoły muszą się ze sobą dogadywać. Customer collaboration over contract negotiation. Tako rzecze Manifest. Jak się uda, to się dogadają. Jak się nie uda, to zespół, który liczył ale się przeliczył, w swojej autonomiczności musi czekać na autonomię innego zespołu. Ale tym się nie martwimy, bo ważne, że klimat rozmów był korzystny. Kiedyś się dowiezie. Na razie zaślepimy, wdrożymy, i jakoś to będzie. Responding to change over following a plan. No przecież.

W dużych organizacjach systemów jest dużo. Najczęściej zmiana pociąga za sobą zmianę w więcej niż jednym systemie. Autonomiczny zespół musi więc posiadać u siebie specjalistów, którzy będą w stanie dokonać zmian w każdym z systemów. Ale nie zawsze się da. Bo jeśli zmiana dotyka kilkunastu systemów, to posiadanie choćby jednego specjalisty u siebie spowodowałoby przekroczenie maksymalnej liczby osób w zespole. Co więcej, może się także nie udać z racji tego, że system jest z gatunku centralnych i z założenia ma być dobrem wspólnym. A jeśli dobro wspólne, to nie prywatne. I na przykład sposób specyfikowania wymagań dla takiego dobra wspólnego może się różnić od tego, który wypracował zespół autonomiczny. Co więcej, zespół systemu centralnego może mieć całkiem rozbieżne z zespołem edżajlowym priorytety. I znowu trzeba czekać. I zaślepiać.

Manifest rzecze także  Working software over comprehensive documentation. Każdy przedszkolak, nie mówiąc o Edżajlkołczach, wie, że do produkcji softu potrzeba epików, storysów i tasków. Można też kanwasy, łajefrejmy i inne persony. Komunikacja, komunikacja, lekkość, zwinność. Tego nam potrzeba. Życie takiego bytu jest tak burzliwe, jak krótkie. Dyskusja, spory, poprawki, dyskusja, poprawki, zaimplementowane, DOD spełnione, poszło! A po roku jakiś inny, Obcy zespół musi sięgnąć do koncepcji rozwiązania. I męczy, i dręczy, i nawet próbuje się wbić do Baklogu autonomicznego systemu, ale ten ma przecież swoje, autonomiczne priorytety. Się uda, się wbije. Się nie uda, to powstanie kopia, łata, cokolwiek, co pozwoli Obcemu zrealizować swoje, autonomiczne plany. Że to niepotrzebne? Że to nadmiarowe? Kozioł ofiarny, by móc pracować w dobrym klimacie.

W bardzo dużych organizacjach, systemów i zespołów potrafi być bardzo dużo. Wprawdzie każdy jest zmotywowany, skoncentrowany na celu, ale jakaś kontrola – pardon, liderszip – być musi. Ktoś komuś jakiś raport na biurko czasami musi wrzucić. Najlepiej jakby z terminami, kosztami. Oczywiście wszystko edżajlowo, ale tak gdzieś pod spodem, jakby jakiegoś Ganta? Tylko, żeby nikt nie widział.

Poziom organizacji

No ale jak to zrobić? Ha! Proste! Tu do akcji wkraczają piękni trzydziestoletni – mistrzowie fechtunku słowem i pałerpojntem. Ci, którzy karierę pięknych dwudziestoletnich mają za sobą i doradzają. Oni mają wiedzę Świata, gdyż w takich organizacjach pracują, co to taką wiedzą dysponują. I oni wiedzą, że taka jedna firma, to kiedyś, podzieliła się na Trajby, Składy, Czaptery. I oni wiedzą, że tak trzeba postąpić, aby duch edżajla spłynął na całą organizację, a nie tylko na ajti. Wprawdzie piękni dwudziestoletni nie ogarnęli jeszcze zagadnienia współpracy w skali mikro, ale nie przeszkadza to we wdrażaniu zmiany w skali makro.

BPRRolnictwo w Polsce ma długą historię. I co, jak co, ale orki nikt nie musi nas uczyć. Zaorajmy więc dotychczasowe struktury i wdrażajmy podejścia autonomiczne na poziomie biznesu. Piękni trzydziestoletni nie pamiętają jednak, że tego typu radykalne zmiany historia zarządzania zna i ma za sobą. Jedną z najbardziej zbliżonych do Rewolucji Edżajl jest teoria Business Process Reingeenering, opisana przez Hammera i Champy’ego w latach dziewięćdziesiątych w książce Reengineering the Corporation: A Manifesto for Business Revolution. Doświadczenia z  wdrażania tej metody dały w efekcie łagodniejsze podejścia typu Business Process Improvement. Ale to było dawno, a teraz jest Edżajl. Będzie Pan zadowolony.

Tak więc, mamy nowe struktury organizacji edżajlowej. Wywiedzione wprost z koncepcji budowy oprogramowania, metody edżajl zaczynają rządzić biznesem. Edżajl to prostota, wobec czego wraz z nowymi strukturami dekretowane są redukcje (czytaj, uproszczenia) ról i stanowisk. Wprawdzie pracę trzeba wykonać, ale będzie jakoś prościej, bo stanowisk i ról mniej. Poza tym, edżajl to wymienność, więc zawsze można komuś obok coś wrzucić – niech czuje, że ma Edżajla. Czyli prościej i w dobrym klimacie. Nowe struktury są autonomiczne. Nie troszczą się szczególnie o inne, wszystko hermetyzują u siebie i dla siebie. Oczywiście za wyjątkiem tych obszarów, których ukryć się nie da. Ale tutaj jakoś trzeba się dogadać.

Każda zmiana ma jakieś skutki uboczne. To oczywiste. Wśród lekko zdezorientowanych skutków ubocznych stoją ramię w ramię osoby zajmujące się procesami biznesowymi, architekci biznesowi, architekci IT. Pojawia się bowiem zasadnicze pytanie – co ma być optymalizowane – praca Trajbów, czy praca całej organizacji? Co, jeśli te cele nie są zbieżne? Idąc dalej, jak tworzyć architekturę biznesową (choćby pojęcia) – dla Trajbu czy organizacji? Mamy architektury IT dla Trajbów czy dla organizacji? Jak wdrażać jednolite standardy w konstelacji autonomicznych jednostek? Senioredżajlkołczowie to wiedzą. Proponują jednostki wskrośtrajbowe. Ale to oznacza, że Trajb nie jest już tak autonomiczny, jak to obiecywali. Ale kto jest ważniejszy – ten od Wskroś, czy ten w Pionie? Pozostaje się dogadać.

I różne takie

Mylnym byłby wniosek, że tak fundamentalne problemy dotyczą jedynie poziomu organizacji. Na poziomach zespołów także mamy dylematy z gatunku dawno rozwiązanych ale w Edżajl fundamentalnych. Czy analiza powinna być elementem sprintów, czy też wyciągnąć ja poza sprinty, gdyż jest trudna do oszacowania. Wyciągnięcie jej poza sprint skutkuje rozpoczynaniem prac ze stabilnymi wymaganiami. Ale w takim razie w ramach czego powinna być prowadzona analiza? Jeśli zaś jest prowadzona w sprincie, opóźnienia stają się nagminne. Czy user story to wymaganie, czy coś innego? Jak się mają te wymagania do innych metod ich specyfikowania. Jak połączyć repozytorium user story z repozytoriami na przykład narzędzi do opisu wymagań technikami inżynierskimi (UML, BPMN, SysML). Czy elementem zmiany jest też poziom organizacji? Jeśli tak, jaki zespół powinien to robić? Ciężko sobie wyobrazić nieduży zespół posiadający w swoim składzie architektów, analityków biznesowych, analityków systemowych, specjalistów od usprawniania procesów, kontroli procesów, itd. Różne zespoły? To jaki produkt jest prezentowany Prodaktołnerom? Diagram? Jakby wbrew fundamentalnym obietnicom Edżajl.

To co to jest ten Edżajl?

No właśnie. Minął rok i dalej nie wiem. Intuicja podpowiada mi, że to prosta droga ku porażce. Że to już było. Że obietnice aż kłują populizmem w oczy. To, że ja nie rozumiem, co to Edżajl, to jeszcze nie problem. Problemem jest to, że wdrażający Edżajl, mam wrażenie, także nie wiedzą, co to tak do końca jest.

Ale kilkudziesięcioletnie doświadczenie mówi też, poczekajmy. Zobaczymy co z tego wyjdzie.  Idąc tym tokiem myślenia, mam wrażenie, że  Edżaj  zakończy swój dynamiczny żywot tak jak inne koncepcje, które miały zrewolucjonizować świat, a ostatecznie stały się małą częścią czegoś większego, dużo bardziej skomplikowanego. Pytanie oczywiście o koszty tej nauki. Ale to już inna bajka.

Ilustracja: https://pl.freepik.com/darmowe-wektory/ręcznie-rysowane-eleganckie-baleriny_849800.htm Designed by Freepik

 


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

The Business Agility Manifesto – jest nadzieja

Open flying old books

Agile (czytaj, ażil) w korporacji, jak na razie, kojarzy mi się z wielkim bałaganem, jeszcze większym nieporozumieniem i niekończącym się poganianiem jednego wzniosłego hasła, innym wzniosłym hasłem uzupełnianym metaforami coach’ów z zupełnie niepasującej bajki. Może trochę przesadzam, ale jeśli przesadzam, to tylko trochę.

Dwa tygodnie temu w ręce moje wpadł Manifest (https://busagilitymanifesto.org/) opracowany przez osoby, które bardziej kojarzą się z tymi niedobrymi czasami twardej inżynierii niźli ze zwinnością. Roger Burlton, Ronald Ross oraz John Zachman po raz kolejny połączyli siły i na bazie swoich doświadczeń wypracowali zestaw zasad dla zwinnego biznesu. I po raz kolejny, trafili w moje potrzeby. Najważniejszą z nich była potrzeba odnalezienia się w tym szaleństwie, które obserwuję i choćby drobnego odniesienia się do fundamentalnych wątpliwości odnośnie prób skalowania sofware’owego agile’a do potrzeb agile’owej korporacji. I postawienia przeciwwagi dla narracji w stylu „ostatecznie liczy się działający soft”. Bo moim zdaniem tak nie jest. Działający soft jest środkiem do celu, ale nie tylko on decyduje o zwinności organizacji. I od oprogramowania chciałbym zacząć analizę zaleceń manifestu, świadom tego, że zaczynam niejako od środka.

Developing software faster is not sufficient, in and of itself, for survival and growth because once operational, such software is likely to prove difficult to continuously and rapidly change without unintended consequences.

Samoorganizujące się zespoły, dobierające techniki głównie pod potrzeby szybkiego dostarczenia oprogramowania, nie zwracające szczególnej uwagi na szeroki kontekst organizacyjny tworzenia i utrzymania oprogramowania miesiąc po miesiącu dozbrajają tykającą od wdrożenia pierwszego przyrostu bombę. Ograniczanie wiedzy o biznesowym kontekście przedsięwzięcia do form akceptowanych w słownomuzycznym backlogu, odżegnywanie się od technik badających spójność biznesową rozwiązania oraz zgodność z otoczeniem, w którym przyjdzie je zastosować oraz stawianie na piedestale potrzeb deweloperów skutkuje zaciąganiem biznesowego i technologicznego długu, którego termin spłaty może nadejść gwałtownie, bez wcześniejszego uprzedzenia.

W moim przekonaniu, aby oprogramowanie mogło wspierać zwinne zarządzanie organizacją, musi być oparte o solidne fundamenty, w szczególności:

  • uwzględniać biznesową interpretację rzeczywistości organizacyjnej (być w zgodzie z modelem pojęć (koncepcji) ),
  • stanowić naturalne rozwinięcie wynikającego ze strategii organizacji łańcucha tworzenia wartości (być w zgodzie z modelem procesowym bądź innym, holistycznym spojrzeniem na opis realizowanych w organizacji działań dostarczających produkt Klientowi),
  • opierać się o solidny fundament analizy systemowej, zapewniający wewnętrzną spójność oprogramowania.

Część z tych tematów znajduje swoje rozwinięcie w materiałach uzupełniających manifest.

True business agility is measured not just by speed of response to requests, changes, or disruption, but also by the coherence of the response.

Spójność, której dotyczy postulat, powinna być traktowana wielowymiarowo – w poziomie, jako wewnętrzna synergia komponentów rozwiązania informatycznego, jak i w pionie – jako zgodność z rozwiązaniem biznesowym. Aby można było to stwierdzić, wymagane jest stworzenie jednoznacznego opisu wymiarów rozwiązania w formie umożliwiającej ich szczegółową analizę w efektywny sposób. Do tego potrzebny jest aparat narzędziowy bogatszy niż szkice i historyjki.

A critical skill for analysts is the ability to engage in dialogs to assess business knowledge for gaps, conflicts, ambiguity, and completeness.

Aparat ten daje szansę na nawiązanie efektywnego i skutecznego dialogu ze wszystkimi stronami wpływającymi na rozwiązanie, nie tylko tymi, którzy są w stanie zrozumieć potrzebę wytwórcy oprogramowania.

Instantaneous change is not the goal. The goal is well-considered change that achieves the desired business effect and avoids unintended side effects.

Frictionless change is not the goal. The goal is change that is dependably shaped according to business strategy, policies, and business obligations and commitments obligations.

Dobrze zaprojektowane rozwiązanie, uwzględniające wymagania wielu stron, pozwoli na jego płynniejsze wdrożenie oraz dłuższe wykorzystywanie, bez konieczności poprawiania go zaraz po wdrożeniu.

Skimping on the quality of business software – creating a tech debt – has no place in businesses striving for change in existing lines of business.

Dobrze zaprojektowanie rozwiązanie nie będzie automatycznie obciążone żadnym długiem, wręcz przeciwnie, będzie kolejnym małym krokiem w kierunku realizacji strategii.

Failing expensively or repeatedly, even if fast, is nonetheless waste to be eliminated.

The value of failing fast in order to learn fast must be balanced against other factors including: impact on business customers, cost of rework, and exposure to risk.

A jeśli już przyjdzie nam od razu poprawiać świeżo opracowany produkt, oznaczać to będzie, iż najprawdopodobniej po prostu źle wykonaliśmy swoją pracę. Strategia Fail fast ma swoje określone miejsce i nie powinna tłumaczyć każdej porażki.

Self-organizing teams and other agile organization schemes alone do not lead to business agility.

Self-organizing teams are a means, not an end. They do not reduce, but rather increase, the need for business strategy, value chain coherence, reuse of business knowledge, and effective portfolio governance.

A i jeszcze te zespoły. Samostanowiące o sobie. Samoorganizujące się. Szlachcic na zagrodzie… Pracujemy w dużej firmie. Musimy dbać o synergię. Musi być ktoś, kto ustanawia reguły, a zespoły samostanowiąc o sobie, muszą się w wyznaczonych ramach mieścić. Musi być ktoś, kto rozlicza ze stosowania się do reguł. Musi być lider. Konsekwentny.

Tyle na pierwszy raz.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Analiza biznesowa jest ą, ę

Notebook and coffee with copy space on a wooden background. selective focus

Słuchałem jakiś czas wywiadu z prof. Bralczykiem na temat języka polskiego. Z wywiadu tego, utkwił mi w głowie fragment dotyczący ewolucji języka, która między innymi skutkuje znacznym zubożeniem słownictwa będącego w powszechnym użyciu. Mnogość określeń bazujących na subtelnościach i niuansach jest zastępowana zwrotami typu wporzo, mega, czy zapożyczeniami w stylu ołmajgod. Tak, wiem, makaronizmy od wieków uzupełniały nasz język, aczkolwiek, jak mi się wydaje, nie w takim stopniu.

Nałożyłem tę sytuację na inne języki – języki wyrazu myśli analitycznej. Od dziesiątek lat rozwijane z myślą o radzeniu sobie w sytuacjach, w których język naturalny jest niewystarczający, gdy zwykły zapis myśli w formie zdań utrudnia pracę, a czasami czyni ją niewykonalną w zadanym czasie i w oczekiwanej jakości. W obszarze tym także widać było pewną ewolucję – strukturalne metodyki wytwarzania oprogramowania zostały płynnie zastąpione paradygmatem obiektowym, poszerzający się zakres technologiczny odnajdywał wsparcie w nowych środkach wyrazu – nowych językach. Kolejne obszary analizy biznesowej, architektury biznesowej, architektury korporacyjnej zostały objęte dedykowanymi językami. Środki wyrazu, jakimi aktualnie dysponuje (a precyzyjniej, powinien dysponować) kompetentny analityk są ogromne. Nic tylko uczyć się, uczyć, uczyć, nabierać doświadczenia i świadomie, płynnie i adekwatnie do sytuacji stosować.

I nagle okazało się, że to wszystko jest niepotrzebne. Że JAKO analityk CHCĘ stosować bardzo proste techniki ABY szybko wdrażać rozwiązania. I niewiele więcej jest potrzebne. I skomplikowane stało się proste. Jak budowa cepa.

OMG! Ja jednak wolę ą, ę. Rili.

 


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

SCRUM responsibly

W którą stronę bym się nie obrócił, przed oczami widzę zwinność. Nie, żebym miał wizje – tak mnie uszczęśliwia szara rzeczywistość. W zasadzie nie miałbym nic przeciwko temu, gdyby nie fakt, iż w większości przypadków zwinność ta przybiera karykaturalną formę pogoni za nieosiągalnym – a im bardziej nieosiągalne staje się nieosiągalne, tym szybszy i mniej kontrolowany staje się pościg.

Patrząc na ten fenomen z punktu widzenia analityka biznesowego, nie mogę pojąć sposobu, w jaki zwinność, promowana przez praktyki SCRUM, miałaby pomóc realizować przedsięwzięcia prowadzone w nietrywialnym środowisku. Trudność z pojmowaniem rozpoczyna się już na poziomie roli o nazwie Product Owner. Tłumacząc literalnie na język polski, mamy do czynienia z właścicielem produktu. Ale jakiego produktu? Czy produktem jest cała zmiana, która została zainicjowana (na przykład w formie projektu)? Jeżeli tak, to właściciel produktu powinien być nazywany właścicielem zmiany. Jeżeli jednak powinien być jawnie wskazany produkt, to jaki? Załóżmy, że zmiana dotyczy usprawnienia jakiegoś obszaru organizacji – czy w takim razie ten obszar jest produktem? Jeżeli tak, to czy w przypadku szerokiej zmiany, dotykającej na przykład wielu procesów biznesowych, nie wystąpi konflikt choćby pomiędzy właścicielem produktu a właścicielami procesów biznesowych?

Bez względu na to, co jest produktem, zgodnie z zaleceniami SCRUM, właściciel tegoż jest odpowiedzialny za zawartość product backlogu, a zespół deweloperski, za jego przetworzenie w finalny, wartościowy produkt każdego sprintu. Załóżmy, że rozpoczynamy prace w przedsięwzięciu o charakterze opisanym wcześniej. Efektem prac sprintu mogą być wskazane w procesach punkty nieciągłości, wykazana niezgodność pomiędzy celami procesów a modelem biznesowym, oraz wskazane do zrewidowania polityki, reguły biznesowe oraz definicje niektórych pojęć. Pytanie, czy to ma wartość biznesową w kontekście SCRUM (boć nie jest to przecież działający fragment systemu).? Kim są deweloperzy (boć miejsca dla projektantów, programistów i testerów tam nie ma)? Analiza biznesowa na tym poziomie ma to do siebie, iż nie jest zbyt przewidywalna. Mnogość międzyludzkich interakcji, często powiązanych z emocjami wynikającymi z zaburzenia komfortu na najniższych poziomach piramidy potrzeb, powoduje, iż zwroty analitycznych akcji są częste, a z dnia na dzień odkrywane mogą być obszary wymagające osobnego potraktowania. W praktyce, sprinty zaczynają określać częstotliwość raportowania, pozostawiając prace swojemu własnemu rytmowi. Innymi słowy, zaczynamy praktykować sztukę dla sztuki. Po co?

W trakcie kilkunastu rozmów na temat praktyk SCRUM w kontekście analizy, docierał do mnie przekaz, iż SCRUM jest techniką deweloperską, w której deweloper to członek zespołu pracujący nad rozwiązaniem IT. Gdyby przyjąć taki punkt widzenia, to cała praca związana z projektowaniem docelowego kształtu organizacji w ramach szeroko pojętej zmiany odbywać się powinna poza SCRUM. Jeżeli tak, to za właścicielem produktu powinien stać sztab analityków biznesowych i architektów biznesowych, wspierających go w podejmowaniu decyzji dotyczących product backlogu. Ale zaraz – czy nie sankcjonujemy przypadkiem podejścia waterfall (które, dla przypomnienia, jest ZŁEM)? Najpierw analiza a potem „kodowanie”?

Kontynuując podróż w dół procesu wytwórczego, docieramy w końcu do zespołu deweloperskiego, którego zadaniem jest wytwarzanie, w odstępach wyrażanych długością sprintów, upragnionego oprogramowania. Podtrzymując założenie, iż pracujemy na problemach o złożoności nietrywialnej (np. dowolna korporacja), zmiana na poziomie IT będzie wymagała zmian w wielu systemach jednocześnie, które rozwijane są w różnych technologiach, jednostkach organizacyjnych i podmiotach (spółki zależne, dostawcy w pełni zewnętrzni). Zakładając zdroworozsądkowo, iż planowanie logiki rozwiązania (poziom PIM według MDA) dokonywane jest według zasad wspierających systemowe podejście do problemu, analiza poszczególnych funkcjonalności może trwać zauważalnie długo z punktu widzenia długości sprintu. W praktyce może się to przełożyć na funkcjonowanie podzespołów scrumowych dwóch prędkości – zespół analityków, ux-owców, architektów IT pracujących nad przyrostem n, i deweloperów, zajmujących się przyrostem n-1. Oczywiście, nic nie stoi na przeszkodzie aby deweloperzy w jakimś zakresie pracowali nad przyrostem n, aczkolwiek małe jest prawdopodobieństwo, aby ukończyli go w sprincie, w którym ukończą go analitycy. To tez prowadzi do wniosku, iż do pewnego stopnia mamy jawnie do czynienia z podejściem (iteracyjnym i przyrostowym) waterfall.

Poszczególne wątki można rozwijać dalej, aczkolwiek z punktu widzenia celu niniejszego wpisu nie jest to zasadne. Wątpliwości, które opisałem mam od dawna. Dane mi było przeprowadzić wiele rozmów, z wieloma osobami, z wielu organizacji i żadna z tych rozmów wątpliwości nie rozwiała, a większość tylko je potwierdziła. Z drugiej strony, ze środowisk promujących zwinne, oparte o SCRUM podejście, uzyskuję zapewnienia, iż da się to wszystko ogarnąć, tylko trzeba zmienić styl myślenia, podejście, zaufać, i takie tam. Cierpliwie czekam, bom ciekaw. Aczkolwiek coraz bardziej utwierdzam się w przekonaniu, że jedyną rzeczą, jaka nas może uchronić od porażki są wysokie kompetencje osób pełniących poszczególne role w projekcie (architektów korporacyjnych, architektów biznesowych, analityków biznesowych, analityków systemowych, architektów IT, projektantów, programistów, testerów, specjalistów dziedzinowych, scrum masterów, kierowników projektów, i innych), dobrze określony proces wytwórczy (metodyka dostosowana do charakteru przedsięwzięcia), dobrze określony proces zarządczy (dostosowany do specyfiki przedsięwzięcia), postawa skierowana na rozwiązywanie problemów oraz zdrowy rozsądek, nakazujący czerpanie z różnych źródeł (waterfall, agile, TQM, facylitacja, BPM, design thinking, itd.).

Howgh!

 

Grafika: http://www.freepik.com/free-photo/silhouettes-of-a-tree-and-a-man-on-a-book_969890.htm” Designed by Freepik


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Edżajl. 2017.

omtTo „hasło”jest w moim przekonaniu jednym z najczęściej aktualnie odmienianych przez przypadki wyrazów w środowisku IT. Jesteśmy edżajl, będziemy edżajl, organizacje edżajl, zespoły edżajl, to jest edżajl, to nie jest edżajl. Drugim, co do popularności „hasłem”, jest już chyba pośmiertnie wyróżniony łoterfol. To jest jak w łoterfol, tak nie robimy, bo to będzie łoterfol, przechodzimy z łoterfol na edżajl. Dobre i złe.

Początek lat 90-tych, studiuję informatykę na Uniwersytecie Wrocławskim, rok czwarty studiów…wpada mi w ręce jakiś artykuł o obiektowości. Jeszcze niewiele o tym wiem, ale czuję, że jest w tym moc. Rok czwarty, kilka miesięcy później. Koledzy z roku jadą do Holandii sprzedawać jakieś druciane cudeńka…proszę ich o przywiezienie mi dwóch książek o obiektowości. Przywożą. Object-oriented Modeling and Design. James Rumbaugh. Object-oriented Analysis and Design. James Martin, James Odell. Czytam od deski, do deski. Kilkukrotnie. Nie mogę uwierzyć – metody strukturalne są takie złożone, a w metodach obiektowych wszystko jest takie proste. I obiecują, że to wystarczy.

Piszę pracę magisterską. Sytuacja komfortowa, gdyż na całym Uniwerku, oprócz mnie i kolegi z roku, nikt się na tym nie zna. Łącznie z opiekunem. Po studiach kolega pisze bazę obiektową w Turbo Pascalu, ja drążę analizę obiektową. Piszemy pierwszy system. Modelujemy na kartkach, potem w ABC FlowCharter. Prosto, łatwo i przyjemnie. We dwóch daliśmy radę. Kurcze, to jednak nie były czcze obietnice z tą obiektowością. Analiza (mój konik) – trzy diagramy! Rok 1993…wpada mi w ręce Object-oriented Software Engineering: A Use Case Driven Approach. Ivar Jacobson. Pojawiają się przypadki użycia. Proste. Dodajemy do zestawu naszych technik. Końcówka lat 90-tych, pojawia się praca Dougha Rosenberga i Robustness Analysis. Fajne. Przerabiamy tę technikę na odpowiednik w UML. Bo powstał UML. Guru obiektowości połączyli siły i powstał standard. Teraz już będzie marsz ku sukcesowi.

Rok 2017. Obiektowość jest dalej obecna. Mamy UML 2.5. Kilkanaście typów diagramów. Do tego SysML, BPMN, ArchiMate i wiele innych języków. Zewsząd słychać, że UML jest zbyt skomplikowany. Ba! Jest bardziej skomplikowany niże metodyki strukturalne (sic!). Za nami także obietnice silwerbuletów: component – based development (CBD), SOA, BPMS. Każda z tych technik znalazła swoje miejsce i w odpowiednich sytuacjach jest stosowana.

Rok 2017. Edżajl. Wszędzie. Edżajl jest dobry, łoterfol jest zły. O łoterfolu mówią trzydziestolatkowie, którzy sami często przyznają, że nigdy nie zrealizowali dużego projektu w takim podejściu. [Hmmm…to ile projektów w podejściu strukturalnym zrealizowałem w 1992 roku?] To nie zmienia jednak faktu, że łoterfol jest zły. Jedynie dobry jest edżajl.

Zespoły mają być interdyscyplinarne, pracujemy razem na ołpenspejsie, dużo rozmawiamy, spotykamy się, warsztatujemy, piszemy historyjki, mamy łajtoardy, flipczarty, kanbamy, diołdi, diołar, dżiry. Mamy czas, przyzwolenie, nie mamy eMeSProdżekta, mamy za to dejli, retro, pibiary. Jesteśmy zmotywowani, samoorganizujący się, mniej lub bardziej dojrzali, mamy edżajl kołczów, a nawet łordy i eksele.

Mamy też złożone systemy. Projekty, które wymagają modyfikacji wielu systemów jednocześnie. Systemy rozwijane w różnych technologiach, w różnych departamentach, w różnych lokalizacjach, przez dostawców zewnętrznych jak i siły wewnętrzne. Mamy SLA, goniące terminy. Nie jesteśmy w stanie zmontować jednego interdyscyplinarnego zespołu, bo byłby za duży. I ludzie nie przyjadą na 100% z tylu lokalizacji. To zmontujmy wiele. Może analityczny i deweloperski? Ale to byłby łoterfol!! Nie, trzeba jakoś inaczej. Ważne, by deweloper, ramię w ramię, siedział z biznesem, analitykiem testerem…wówczas będzie dobrze.

Produkujemy jeszcze więcej historyjek, tasków, kontyngentów, akceptujemy nawroty (bo to edżajl), świętujemy oddania na sprincie, nie przejmujemy się kolejną przeróbką (bo to edżajl). Terminy gonią, zatrudniamy dodatkowe osoby, mamy więcej statusów międzyzespołowych, rozmawiamy, motywujemy się. Akceptujemy pomyłki.

I jest dobrze? Bo nie w łoterfolu? Bo nie w UMLu? Bo po nowemu?

Nie?

To może jednak jakiś enterprajs skram? SEJF, czy jakoś tak? Bo jednak nie da się ze wszystkim tak radośnie? No ale co…enterprajs skram, to enterprajs juzerstory? Hmmm…to może jednak coś zapisać nie w historyjce? To może jednak analiza biznesowa? Może jakaś analiza systemowa?

No dobrze, byleby prosto. Bez zbędnego ciężaru. Na tablicy. Edżajl modeling. Ma ktoś zdjęcie tablicy sprzed tygodnia? Nie? A ktoś pamięta?

To może czasami jakiś friłerUML? Darmowy. Zawsze to lepiej niż na tablicy. Każdy tyle, ile uważa za słuszne. Zespół zdecyduje ile. Każdy decyduje, jak chce. Oferta u Ciebie, to Offer mnie. Ale Twój Customer znaczy co innego, niż u mnie. To trzeba uspójnić. Zgłosimy to na dejli albo na retro.

Łotefol jakiego już nikt nie pamięta versus radosna twórczość. Mam wrażenie, że taki ostro spolaryzowany świat występuje w dyskusjach o Agile. Pośrodku są jednakowoż metody iteracyjne i przyrostowe, metody adaptacyjne (znane od lat), którymi przesiąkły rozsądne podejścia waterfall (które z tym mitycznym waterfall mają niewiele wspólnego).

To kiedy zaczniemy czerpać z doświadczeń?

Rok 2018…zobaczymy…

                     

Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.