Battle for Agility

Agilopolis po wakacjach serwuje 2 wydarzenia

Po wakacjach inicjatywa Agilopolis budzi się ponownie do życia z dwoma wydarzeniami. Już w poniedziałek 31.08 trzecie z kolei spotkanie ACD a tam prezentacja Marcina Kołtonowskiego na temat:

“Kanban in IT. How and if the idea of Kanban can be used in Agile or IT”

Poza tym w trakcie spotkania:

• kilka pytań i odpowiedzi jakie pojawiły na pierwszym Agilopolis Community Conference w czerwcu,
• prezentacja na temat motywacji, którą przeprowadzi Jurek Wachała,
• dyskusja na temat testowania w SCRUM

Spotkanie odbędzie się w Silver Forum, Strzegomska 2/4 od godziny 17:30 (sala jeszcze nie podana). Więcej informacji na temat spotkania znajdziecie pod adresem:

http://agilopolis.com/content/agilopolis-community-day-3

Agilopolis Community Conference

Drugie wydarzenie to kolejna edycja konferencji ACC, która tym razem rośnie do pełnych dwóch dni i odbędzie się 21-22 września 2009. Tym razem pojawią się goście z zagranicy min. Roman Pilcher, autor bardzo ciekawie zapowiadającej się książki “Agile Product Management with Scrum: Creating Products that Customers Love“, który wystąpi z dwoma tematami:

• Owner-related techiques
• Grooming the Product Backlog

Oprócz niego wystąpią też:

• Mattias Skarin z tematami “10 steps to Agile adoption” oraz “Agile myth or magic“,
• Paul Klipp z tematem “Agile Promoting Strategies“,
• David Friar z tematem “Agile in the ‘Real’ World - things they don’t teach you in Agile School“
• Habte Woldu jako moderator dyskusji panelowej “Introduction of agile in organization - pitfalls and obstacles“

Drugi dzień to dwa warsztaty w formie gier:

• Scrum Game
• Product Owner Game

Więcej szczegółów… i cennik znajdziecie na stronie:

http://www.agilopolis.com/content/agilopolis-community-conference-0

Add comment August 29th, 2009

Agile Eastern Europe 2009

W naszej części Europy mało jest konferencji o profilu czysto związanym z Agile/SCRUM, a jeszcze mniej takich na które zwykły śmiertelnik może sobie pozwolić finansowo. Tym bardziej cieszy fakt, że w dniach 18-19 września 2009 w Kijowie odbędzie się pierwsza edycja konferencji Agile Eeastern Europe 2009.

Szczerze zachęcam do udziału, bo prelegenci i ich tematy są bardzo ciekawi, a cena jeszcze do 15 lipca całkiem przystępna (210 USD za 2-dniowy udział z wyżywieniem).

• Mary Poppendieck
• Grigori Melnik
• Jutta Eckstein
• Boris Gloger
• Jurgen Appelo
• J.B.Rainsberger
• David Hussman

Nie zabraknie także (całkiem z resztą pokaźnej) reprezentacji z Polski:

• Paweł Kazienko
• Tomek Włodarek
• Paweł Lipiński
• Tomasz Wykowski
• Bartosz Bańkowski
• Szczepan Faber

Szczegółowy program konferencji znajdziecie pod adresem
http://agileee.com/schedule/program-details

Nadmienię jeszcze tylko, że Agilers/tinyPM są jednym ze sponsorów konferencji i na pewno podczas konferencji będzie można wygrać dodatkowe licencje :-)

Add comment June 25th, 2009

Pierwsze spotkanie Agilopolis za nami!

Wreszcie chwila na to, żeby wrócić na chwilę do ostatniego czwartku… a to właśnie wtedy odbyło się pierwsze spotkanie Agilopolis! Bardzo byłem ciekaw jak wyjdzie pierwsza poważna próba aktywizacji Wrocławskiego “półświatka” Agile :-) no i muszę powiedzieć, że jestem mile zaskoczony…

Ale od początku. Pierwsza informacja, to kto stoi za samą inicjatywą, bo nie wynika to jasno ze strony. Wrodzona skromność inicjatorów nie pozwoliła im wyjść z cienia przedwcześnie, więc pozwólmy im teraz odebrać pochwałę:

• Jurek Wachała
• Marcin Kołtonowski
• Tomek Łukasiewicz

Spotkanie odbyło się wokół prezentacji Marcina na temat adaptacji SCRUM w NSN. Prezentacja była o tyle ciekawa, że prawie dokładnie rok temu Marcin wraz z Markiem Majchrzakiem prezentowali ten temat podczas IT Days 2008. Wtedy był to początek przygody NSN ze SCRUMem, więc tym bardziej ciekawe było posłuchanie jak to wygląda po roku.

Tym razem nie mam zamiaru znęcać się nad prezentacją, bo mi się podobała. Zwłaszcza, że tym razem dotyczyła tylko i wyłącznie aspektu wdrożenia SCRUM w NSN i pomijała zupełnie wątki rekrutacyjno/produktowe, a o to właśnie chodziło. W trakcie prezentacji wieloktornie wywiązywała się dyskusja na temat różnych aspektów tego wdrożenia, takich jak:

• podział ról i organizacja pracy w nowej rzeczywistości,
• przeszkody we wdrożeniu takich metod pracy,
• kwestia opłacalności takiego przedsięwzięcia,
• równoległa praca wielu zespołów SCRUM,
• i inne…

Pokazuje to, że temat jest chłonny i z pewnością jest wstępem do jeszcze wielu bardziej szczegółowych dyskusji nad poszczególnymi kwestiami wdrażania agile w dużej organizacji, jakie mam nadzieję na forum Agilopolis zostaną poruszone.

Mnie oprócz powyższych kwestii interesuje ostatnio temat “Agile jako sposób na zespoły typowo utrzymaniowe”. Może uda się wydusić z uczestników jakieś doświadczenia :-) Acha! Panowie - czekamy na forum dotyczące spotkań, żebyśmy mogli podyskutować trochę o naszych planach i uwagach na temat Agilopolis Community Day.

Kolejne spotkanie wstępnie za cztery tygodnie (ze względu na odbywający się za trzy tygodnie GeeCON), ale potem możliwe, że spotkania przejdą w tryb trzytygodniowych odstępów.

Zachęcam tych, którzy nie dotarli na pierwsze spotkanie do odwiedzenia kolejnego, a inicjatorom gratuluję udanego startu!

Add comment April 20th, 2009

Agilopolis

Otrzymałem wczoraj od Marcina Kołtonowskiego informację na temat powstałej niedawno inicjatywy o nazwie Agilopolis. Projekt jest tym razem Wrocławski (co mnie niezmiernie cieszy, jako że zamieszkuję to miasto) i ma na celu doskonalenie praktyk agile i SCRUM w polskich firmach. Dla kompletności zmieszczę oryginalną informację jaką dostałem od Marcina. Jest co prawda po angielsku, ale chyba dacie sobie radę, prawda?

Agilopolis is an interdisciplinary collaboration of researchers and practitioners working on research activities that would be difficult to develop under traditional funding mechanisms. The lifespan of the Agilopolis can last anywhere between a few months and several years. Our goal is to make agile & scrum more clear to everybody. The Agilopolis assemble experts (and future experts) on a Agile topic together for intensive work. It is not an avenue for briefing novices about the subject matter. Occasionally, a group might admit a person with little experience and a lot of enthusiasm. However, such participants should be present as observers and in the minority. Agilopolis are also referred to as task groups or technical advisory groups.

Dodam tylko jeszcze, że po świętach, jeszcze w kwietniu, zaplanowane jest we Wrocławiu pierwsze spotkanie pod ochoczo brzmiącą nazwą “Agilopolis Community Day”, na które się wybieram i was też zachęcam do przyjścia.

1 comment April 3rd, 2009

Agile w Nokia Siemens Networks

23 kwietnia 2008 na Politechnice Wrocławskiej w ramach IT Days 2008 obył się wykład pt. “Agile techniques in big IT venture” poprowadzony przez Marcina Kołtonowskiego i Marka Majchrzaka z Nokia Siemens Networks (dalej NSN). Poniżej przedstawiam garść informacji o tym co na wykładzie można było usłyszeć i o tym czego niestety nie usłyszałem, a nie ukrywam, że chciałem :-)

Prezentacja podzielona była na 5 części:

1. Ogólne informacje na temat NSN oraz na temat platformy @dvantage, przy której pracują obaj autorzy.
2. Krótkie przypomnienie modelu kaskadowego (ang. waterfall) i jego wad.
3. Manifest agile i główne założenia iteracyjnego tworzenia oprogramowania.
4. Wprowadzenie do Scrum z omówieniem cyklu projektu i ról w projekcie.
5. Część praktyczna, czyli spojrzenie na implementację Scrum w NSN jako dużej globalnej korporacji.

Jak się pewnie domyślacie, idąc na ten wykład liczyłem głównie punkt 5 i głównie na nim się skupię. Na prezentację zaplanowano 90 minut. Pierwsze cztery części zabrały w sumie około 50 min. Szkoda, bo zupełnie niepotrzebnie dużo miejsca zajęły szczegóły na temat platformy @advantage i związanych z nią narzędzi oraz teoria na temat Scrum, przez co na to, co faktycznie najciekawsze zostało już tylko pół godziny plus 10 min na pytania z sali.

Ale do rzeczy… Wrocławski odział NSN podjął próbę wprowadzenia Scrum kilka miesięcy temu. Autorzy prezentacji opowiadali o pracy ok 20 osobowego zespołu, który został podzielony na 4 podzespoły (Scrumy). Trzy z nich zajmują się oprogramowaniem trzech różnych linii produkcyjnych wspomnianej platformy @dvantage, czwarty to typowy “firefighting team” zajmujący się naprawą krytycznych błędów na wszystkich trzech liniach działającego już produkcyjnie kodu.

W każdym zespole rolę Scrum Mastera pełni osoba z większym doświadczeniem wybrana z pośród dotychczasowych programistów. Zespoły praktykują codzienne 15 minutowe spotkania, planning meetings na początku sprintu oraz retrospectives po sprincie. Scrum Masterzy ze wspomnianych czterech zespołów tworzą wirtualny zespół Scrum of Scrums aby synchronizować podobne prace toczące się na poszczególnych liniach platformy. Nie wiem tylko ja wygląda komunikacja w obrębie tego zespołu, ale odniosłem wrażenie, że nie mają swoich codziennych spotkań.

Na razie wygląda normalnie… wręcz zbyt dobrze, a przecież to duża korporacja… no to przejdźmy do problemów jakie udało mi się wychwycić.

Po pierwsze NSN pozostaje jako korporacja organizacją polegającą na modelu kaskadowym. Różne warstwy organizacji mają do osiągnięcie pewne kamienie milowe i etapy ich osiągnięcia są góry ustalone. Sam dział programistyczny mapuje Scruma na poziomie poszczególnych faz modelu kaskadowego. I tak mamy opracowanie specyfikacji wymagań, analizę i projektowanie, implementację, wdrożenie i w końcu utrzymanie aplikacji. Jeśli da się dany etap wykonać iteracyjnie, to zespół podejmuje próbę zaprzęgnięcia do tego Scruma w skali pojedynczego etapu. Przy czym Scrum na etapie implementacji jest tutaj najbardziej eksponowany.

Autorzy zapytani przeze mnie o to, jak w takim razie radzą sobie ze zmianą wymagań pochodzących z fazy specyfikacji wymagań odpowiedzieli, że tamte wymagania są na tyle ogólne, że raczej nie zmieniają się potem podczas implementacji. Tak więc możliwa jest co najwyżej reakcja na zmiany drobniejszych wymagań, które identyfikowane są już podczas fazy implementacji a do faz, które już minęły nie wracamy. Nie rozumiem tylko na podstawie czego powstaje w takim przypadku backlog produktu i czy to oznacza, ze on nie może się już zmienić?

Drugi problem jaki dotyczy tak dużej organizacji, to kooperacja pomiędzy działami. W NSN funkcjonuje duży dział testów, który wykonuje między innymi testy funkcjonalne aplikacji tworzonych przez programistów NSN (w tym tych wchodzących w skład 4 Scrumów platformy @dvantage). Problem polega na tym, że praca działu testów nie jest uwzględniona w sprincie a odbywa się już po. W ramach sprintu programiści wykonują jedynie testy jednostkowe (przy czym TDD to raczej opcja niż norma, choć w przypadku tego typu systemów to mnie raczej nie dziwi).

Szkoda, że nie dowiedziałem się z prezentacji więcej na ten temat, bo właśnie tego byłem ciekaw najbardziej. NSN jako duża sformalizowana organizacja jest dotąd raczej oparta na pewnych warstwach zadaniowych i działach, które zajmują się pewnym wybranym aspektem działania firmy. Tymczasem wprowadzanie metod agile, w tym Scrum wiąże się ze zmianą organizacji pracy na bardziej projektową i wymaga utworzenia bardziej kompletnych i samowystarczalnych zespołów. Oczywiście wymagałoby to rewolucji i likwidacji pewnych działów, albo przynajmniej fizycznego przemieszczenia pracowników, tak aby np. pojedynczemu zespołowi developerów przydzielić również osoby z takiego działu testów, a pewnie znalazłoby się jeszcze kilka innych działów, z których należałoby wyciągnąć ludzi. Z tego co autorzy przekazali podczas wykładu wynika, że nie udało się tego dotąd zrobić w NSN i działy pomiędzy sobą nie dzielą nawet wspólnych sprintów.

Na koniec sprawy bardziej techniczne a nie organizacyjne. Sprint w tych zespołach trwa 4 tygodnie. Szacowanie zadań dla poszczególnych sprintów odbywa się w godzinach, przy czym odniosłem wrażenie, że oszacowania dokonują pojedynczy programiści a nie zespół (ale może to niedopowiedzenie). Autorzy prezentacji wspomnieli o śledzeniu wykresów burndown, ale nie wspomnieli nic na temat tego w jaki sposób śledzą velocity (co w przypadku estymowania w godzinach jest szczególnie pomocne) i jak wykorzystują to do planowania i poprawiania swoich oszacowań godzinowych.

No i jeszcze taka ciekawostka - continous integration. W przypadku omawianej na wykładzie platformy zbudowanie, integracja i wstępne przetestowanie automatyczne kodu trwa całą noc. Więc nad ranem następnego dnia zespoły wiedzą, czy coś im nie wyszło dnia poprzedniego. No… oflagowanie tego procesu mianem CI jest moim zdaniem lekkim nadużyciem i uważam, że dużo wiarygodniej brzmiałoby stwierdzenie, że w skali całego projektu nie da się tam wdrożyć pełnego CI. Chciałem zadać jeszcze pytanie czy w ogóle da się w takiej organizacji i przy tak skomplikowanych i złożonych systemach zachować zasadę, że w każdej iteracji otrzymujemy w pełni wdrażalny produkt, zwłaszcza że do tego potrzeba właśnie ścisłego współdziałania działów korporacji? Po prezentacji mam wątpliwości.

Chcę podkreślić, że nie chcę wytykać tutaj żadnych błędów. Moje spostrzeżenia traktuję bardziej jako konfrontację teorii ze staraniami zespołów ograniczonych z wielu stron przez sztywne ramy korporacji. Mam nadzieję, że uda się np. za rok usłyszeć podobne wystąpienie, w którym będzie mowa o tym, jakie z tych problemów udało się, bądź nie udało się rozwiązać. Na razie wygląda na to, że próby wdrożenia Scrum w NSN nie są wspierane na wszystkich poziomach organizacji i raczej wyglądają jako taka inicjatywa na średnim i niższych szczeblach. NSN dysponuje ponoć 500 Scrum Masterami (informacja z wykładu) - pytanie jaki jest stosunek ilości programistów do SMów? Być może na wyższych szczeblach funkcjonuje to bardziej na zasadzie “wszyscy są teraz agile, więc my też bądźmy, ale nie zmieniajmy przy tym za wiele”. Obym się mylił a rozpoczęty w NSN proces ulegał doskonaleniu w praktyce a nie tylko na prezentacjach.

I jeszcze takie fundamentalne pytanie jakie nasuwa mi się jeśli myślę o wdrażaniu agile w takiej organizacji. Czy w trakcie wdrażania procesów Scrum okazało się, że jakieś stanowiska są niepotrzebne? Czy każdy trybik takiej organizacji znajdzie dla siebie miejsce w ramach nowych procesów, czy może pewne stanowiska okażą się nie potrzebne?

Kij w mrowisko wsadzony :-) Czekam na komentarze tych najbardziej zainteresowanych, jeśli takowi czytają tego bloga :-)

6 comments April 28th, 2008

Jak zwinny jest Twój zespół?

Na polskiej grupie dotyczącej lekkich metodyk Piotr Gabryanczyk zaprosił do więcia udziału w ankiecie. Również zachęcam do jej wypełniania i czekamy na wyniki.

Add comment March 12th, 2008

Akcent Agile na JDD 07

Piątek spędziłem na Java Developers Day 2007. Dlaczego piszę tutaj o konferencji Java? W zeszłym roku agile było praktycznie w każdym wystąpieniu. Wszystkie produkty, praktyki, frameworki były agile. W tym roku coś się zmieniło… terminem agile nie wiało już z każdej prezentacji, co w sumie jest nawet lepsze, bo przywykliśmy do zbytnich nadużyć w kwestii stosowania agile wszędzie gdzie się tylko da.

Ale nie myślcie, że agile zniknęło z JDD. Także i tegoroczna edycja miała swój akcent w postaci wystąpienia Jakuba Dziwisza na temat “Test Driven Development w Java”. Wykład powinien być niedługo dostępny w wersji wideo na stronach organizatora konferencji, a na blogu Jakuba powinien się pojawić artykuł uzupełniający samą prezentację. Zaczęło się nieźle… Jakub przekonywał o zaletach TDD w tworzeniu oprogramowania, z czym generalnie się zgadzam. Były założenia TDD, trochę o trybie red - green - refactor, później prosty test, który nie przechodził ale wyznaczył funkcjonalność, implementacja (test przeszedł - byliśmy w green), wreszcie przyszedł czas na “refactor”.

Niestety etap refaktoryzacji zaprezentowany podczas wykładu był dla mnie nieco kontrowersyjny. Mianowicie za jednym zamachem uległa zmianie implementacja testowanej klasy i bez uruchomienia testów od razu uległa zmianie także implementacja samego testu. Być może nie było to zamierzone a jedynie podyktowane ograniczeniami czasowymi samej prezentacji, ale chciałbym podkreślić, że w TDD właśnie po to najpierw piszemy test, żeby później w trakcie refaktoryzacji móc na nim polegać zmieniając kod. Jeśli programista zacznie jednocześnie zmieniać kod testowany i kod testujący to jaką ma pewność czy zielony pasek nadal wskazuje, że kod działa, a nie że właśnie dostosował test do tego, żeby przechodził z nowym kodem? A co jeśli po takich jednoczesnych zmianach test nie przejdzie? Czy to oznacza że źle zrefaktoryzowaliśmy kod, czy może nie wyszła nam modyfikacja testu? Test ma łapać błędy powstałe podczas refaktoryzacji. Dopiero później przychodzi czas na ew. refaktoryzację samego kodu testów. Z reszta Jakub wspomniał o tym, że dobrze napisane testy nie powinny tak często wymagać zmiany, kiedy tylko refaktoryzujemy kod aplikacji.

Chciałbym się także odnieść do pytania, które padło z sali. Mianowicie “Do czego TDD się nie nadaje?”. Odpowiedzią było, że “nie nadaje się do utrzymania oprogramowania”. Z drugiej strony Jakub stwierdził, że nie wyobraża sobie napisania linijki kodu produkcyjnego bez wcześniejszego napisania testów. Ani jedna, ani druga odpowiedź nie do końca mnie satysfakcjonuje.

To jest generalnie dobre pytanie jeśli chodzi o agile, bo będąc entuzjastą jakiejś konkretnej praktyki lub wszystkiego co agile, dość łatwo mówi się o tym jakie to wszystko jest piękne, ale pamiętamy formułę “there is no silver bullet” prawda?

Akurat według mnie TDD doskonale nadaje się do utrzymania oprogramowania. Nie mówię tu bynajmniej o rozpoczynaniu krucjaty w pisaniu testów do wielkiego istniejącego systemu, który takich testów nie posiada. Byłoby to niewiarygodnie męczące i praktycznie nieuzasadnione jeśli chodzi o koszty. Ale jestem zdania, że w takim wypadku doraźne aplikowanie TDD do napotkanych błędów w tego typu kodzie jest bardzo dobrą praktyką.

Załóżmy, że zostaje zgłoszony błąd w utrzymywanym przez nas oprogramowaniu. Co należy zrobić?

1. Najpierw piszemy test, który reprezentuje oczekiwane przez nas prawidłowe działanie aplikacji (jesteśmy w fazie RED, test nie przejdzie, bo przecież mamy błąd w aplikacji).
2. Naprawiamy błąd. A skąd wiemy, że go naprawiliśmy? Bo przeszedł test, które wcześniej napisaliśmy. Jesteśmy w GREEN.
3. Skoro mamy poprawkę i test, który przechodzi, to czas na ew. REFACTOR. Wiemy, że mamy test, który odpowie czy nie zepsuliśmy poprawki.

Oczywiście w przypadku systemów, które nie posiadały wcześniej testów, faza 2 i 3 są trudniejsze, bo nie wiemy czy poprawka i refaktoryzacja nie wpłynęły negatywnie na inne części systemu na które nie mamy testów, ale cóż. Jeśli znajdziemy inny błąd to wracamy do kroku 1. W ten sposób doraźnie reagując budujemy powoli bazę testów dla systemu, który mogliśmy dostać w spadku. Przy okazji pisania testów uczymy się także samego systemu, a napisane w tym momencie testy zabezpieczą nas przed powrotem tego samego błędu w kolejnym wydaniu oprogramowania.

Czy w takim razie rozpoczynając nowy projekt można zastosować TDD wszędzie i nie powstanie ani linijka kodu bez testów, które najpierw nie przechodziły? Niestety nie zawsze jest to możliwe. Wg. mnie nie warto pisać testów jednostkowych dla klas GUI w aplikacjach typu desktop. Ciężkie jest także testowanie w ten sposób kodu widoków w aplikacjach webowych. Oczywiście to nie znaczy, że nie należy automatyzować testów tego typu elementów. Chodzi tylko o to, że są to elementy, które raczej nadają się do testów funkcjonalnych, najlepiej “nagranych” przy pomocy specjalnego oprogramowania przez testerów, a nie przez samych developerów i przynajmniej w moim przypadku nie bardzo sprawdzało się tutaj TDD w swojej czystej formie.

TDD to jednak jedna z bardziej interesujących praktyk agile, więc na pewno jeszcze do tego tematu wrócę.

Add comment October 28th, 2007

Agile na JDD 2006

Wczoraj (tj. 21 października) w Krakowie odbyła się konferencja Java Developers Day 2006, na której swoje 5 minut miało także agile. Pan Marcin Kucieba z Sabre Poland miał wystąpić z tematem “Zastosowanie praktyk Agile w tworzeniu aplikacji i systemów z wykorzystaniem Javy”. Piszę “miał”, bo ostatecznie zaprezentował temat “Agile developement”, który z samą Javą miał niewiele wspólnego. Podczas tej prezentacji zostały przedstawione najczęściej stosowane praktyki agile takie jak:

• iteracyjne tworzenie oprogramowania
• idea user stories i ich estymowania
• backlog i wypalanie się projektu
• test driven development i wartość testów
• continous integration

Zacząłem ten wpis dość krytycznie, bo jednak po temacie z agendy konferencji spodziewałem się bardziej szczegółowego odniesienia do narzędzi i metod związanych ze środowiskiem programistów Java, do których sam się zaliczam. Niemniej ,mimo wstępnego rozczarowania, sama prezentacja była całkiem wartościowa. Zwłaszcza jej końcowa część, gdzie Pan Kucieba podjął temat “Dlaczego Agile?” i pokazał między innymi zależności oczekiwań klientów w stosunku do otrzymanych wyników na tle podejścia waterfall (prosty aczkolwiek wymowny wykres). To samo dotyczy również poziomu i szybkości zwrotu kosztów z inwestycji w przypadku wcześniejszych releasów z działającą funkcjonalnością jakie można zrobić stosująć agile zamiast czekać do ostatecznej akceptacji całej listy wymagań. Nie mogę sam zamieścić tej prezentacji, ale mam nadzieję, że pokaże się ona na stronie Polskiej Grupy Agile.
Dobrze, że takie wystąpienie się pojawiło chociaż nadawałoby się bardziej na rozpoczęcie konferencji “Agile Day” jakiego mam nadzieje doczekamy się w roku 2007 :-). Co ciekawe “agile” pojawiło się na JDD2006 praktycznie w każdym z wystąpień począwszy od testowania kodu przy pomocy TestNG (w tym kontekście to zrozumiałe) aż po ideę SOA (prezentacje BEA i DRQ), na której temat prelegenci zgodnie twierdzili, że jest ona bardzo “agile” :-).

Samą konferencję uważam za całkiem udaną. Natomiast w sferze agile mam następujące spostrzeżenie. Z jednej strony to dobrze, że wszyscy dostrzegają w agile dobrą drogę, ale jednak jestem w tym względzie mocno sceptyczny. Doczekaliśmy się momentu, kiedy wszyscy chętnie przyklejają swoim produktom i praktykom metkę agile podczas gdy nie ma to z agile dużego związku.

To chyba tyle mojej subiektywnej oceny JDD2006 z agile w tle.

Add comment October 22nd, 2006