Nareszcie ciekawy sylabus!

Sylabusy, certyfikacje i standardy w świecie IT są jak chodzenie do dentysty: konieczne, ale trudno powiedzieć, że nas uskrzydlają.

Oczywiście, że są zwykle archiwum starej, zakurzonej wiedzy – ale akurat przeciwko temu nic nie mam, bo wiedza, choć zakurzona dla niektórych, nadal jest ważna, potrzebna i zupełnie nie znana większości, warto ją rekomendować i rozpowszechniać. Prawdziwy kłopot z sylabusami polega na tym, że napisane są prawie zawsze wyjątkowo drętwym językiem, że najprostsze nawet sprawy, o bardziej złożonych nie wspominając, nagminnie wyjaśniają w sposób fantastycznie zawiły i że pełne są bezużytecznych dziwactw, terminologicznych i merytorycznych.

Tymczasem rok temu pojawił się sylabus zupełnie inny – prezentujący nowe, świeże idee, napisany żywym, zrozumiałym i zwięzłym (!) językiem. W tych okolicznościach aż wierzyć się nie chce, że na dodatek nie prezentuje żadnych niszowych ciekawostek, ważnych tylko dla smakoszy i dziwaków, lecz trafia w samo sedno zagadnień ogromnie ważnych w praktyce.

Sylabus nazywa się [email protected]. 😊

Nie, wcale nie jest to kolejna lista słodkich opiwueści o tym, jak śliczne są „user stories” i co oznacza DoD – piszę „kolejna”, bo od takich list, wyrażonych zwykle podniosłym i mało konkretnym językiem, aż kipi literatura „agile’owa” i jedna więcej nikomu do niczego nie jest potrzebna; tym bardziej, że w czasie, kiedy piszę te słowa, pewnie w agile’owym Internecie pojawiło się kilka nowych, nawiedzonych pomysłów w tej dziedzinie.
Ten sylabus jest realizuje propozycję, głoszoną przez mądrych ludzi od dawna, ale zagłuszaną skutecznie przez jej przeciwników, jak połączyć najlepsze elementy nie-agile’owej inżynierii wymagań z najlepszymi pomysłami i metodami ze świata zwinnego.

Dotąd tego nie było. Ze świata zwinnego słyszało się i słyszy tak piramidalne nieprawdy, jak np. to, że „w lean startup inżynieria wymagań jest archaiczna” (np. http://blog.testowka.pl/2014/02/26/komentarz-do-blad-arystotelesa-w-it/), zaś świat nie-agile’owej inżynierii wymagań chwilami przypominał i przypomina sabat, zrzędliwie i wbrew oczywistości głoszący, że wszystkie wymagania trzeba koniecznie opisywać bardzo dokładnie i długo, długo przed rozpoczęciem jakiegokolwiek kodowania i wdrażania.

Arystoteles popełnia błąd Arystotelesa w poszukiwaniu srebrnej kuli („silver bullet”)

zob. https://www.computerworld.pl/news/Blad-Arystotelesa-w-IT,394951.html

Zarówno agile, jak i „klasyczna” inżynieria wymagań są skarbnicami świetnych metodyk i doskonałych technik, których łączenie jest od lat skutecznie utrudniane przez ideologiczne zacietrzewienie.

[email protected] jest – jak samo trafnie określa – próbą zbudowania grobli między tymi dotąd oddzielonymi obszarami, propozycją otworzenia mostu powietrznego, zaopatrującego ich wygłodzonych mieszkańców.

Egzamin i certyfikat? Jak pisze sylabus, rekomendowany czas trwania kursu, przygotowującego do egzaminu, wynosi albo jeden dzień, albo dwa dni, zależnie od doświadczenia i wiedzy uczestników. Najwięcej i najłatwiej skorzystają na nim – i kursie, i egzaminie – ci, którzy mają już jakie-takie doświadczenie zarówno w klasycznej inżynierii wymagań, jak w praktykach agile’owych. Nie przesadzajmy jednak, może być ogromnie przydatny także dla nowicjuszy, bo wszak nie trzeba najpierw pójść dwiema błędnymi drogami, żeby móc od początku skorzystać z trzeciej, lepszej. Gorąco polecam go także już osiwiałym weteranom jednej i drugiej – klasycznej i agile’owej – drogi, jeśli w głębi serca przypuszczają, że warto spróbować pogodzić od lat zwaśnione rody Kapuletów i Montekich i gotowią są wdać się w niebezpieczny romans z przedstawicielem / przedstawicielką dotąd niby-wrogiej opcji.

Wszystkie praktyczne informacje na temat tego certyfikatu znajdziecie na stronie http://ireb.requirements.org.pl/[email protected].

Tutaj będziemy zaś co tydzień publikować kolejny odcinek wiadomości o [email protected] – aż nawet nie zauważycie, kiedy staniecie się ekspertami!

Pozdrawiam, Bogdan Bereza