Rozważania o wymaganiach

Transkrypt

1 Rozważania o wymaganiach Stowarzyszenie Inżynierii Wymagań wymagania.org.pl Polish Association of Requirements Engineering (pare.wymagania.org.pl) Konferencja DOBRE WYMAGANIA Warszawa, 2-4 października 2013 konferencja.wymagania.org.pl (conference.wymagania.org.pl), konferencja@wymagania.org.pl 1

2 Spis treści Programowanie w świecie nowych technologii - 3 Wymagania: IT w pigułce - 8 Automatyczne zarządzanie projektami fantazja czy okazja? - 15 Quo vadis, analizo? - 19 Rola analizy biznesowej w ulepszaniu procesów IT - 24 Jak wygrać w Monte Carlo? - 29 Pięć tajemnic sukcesu, czyli znów o testowaniu 34 2

3 Programowanie w świecie nowych technologii Co to właściwie jest programowanie? Czy oznacza to tworzenie oprogramowania, a więc złożony proces, obejmujący całą drogę od analizy wymagań, poprzez projektowanie, pisanie kodu, integrację, testowanie, wdrożenie i utrzymanie? Czy też programowanie, to samo kodowanie: pisanie kodu źródłowego, kompilowanie, ewentualnie analiza statyczna i testy jednostkowe czyli to, co zwykle wykonują osoby zwane programistami? Jeśli programowanie, to pisanie kodu źródłowego na podstawie względnie dokładnej specyfikacji, wtedy zależność programisty od zmian technologii bywa mniejsza. Wiemy jednak, że w praktyce, na dobre i złe, programiści chcąc nie chcąc pełnią wiele funkcji: zbierają wymagania, testują, wdrażają, odpowiadają za utrzymanie. Tak dzieje się czasem z powodu niefrasobliwości kierownictwa, które nie rozumie potrzeby istnienia innych uczestników projektu poza skrzętnymi programistami. Czasem firma i projekt są po prostu bardzo małe. Niekiedy taki stan rzeczy bywa wynikiem świadomego wyboru metod zwinnych, agile. Wówczas programiści muszą dobrze rozumieć technologię, dla której tworzą kod jest to niewątpliwe wyzwanie! Co to właściwie jest technologia? Słysząc słowo technologia, zwykle wyobrażamy sobie coś twardego: nową elektronikę, nowe procesory, nowe światłowody, nowe sposoby produkcji tychże, i tak dalej. Jeśli nie elektronika, mechanika ani nie chemia, to ostatecznie nowe aplikacje: systemy operacyjne (np. zaroiło się nam w ostatnich latach od pseudo-nowości w formie plejady androidów, ios-ów, blackberries ów, symbianów!), nowe algorytmy, nowe języki programowania. Słowa technologia i technika są po polsku powszechnie stosowane zamiennie. Tymczasem angielskie słowo technology oznacza coś więcej: także procesy, procedury, sposoby organizacji. Przy takim rozumieniu technologii, wyzwaniem dla programisty byłyby również zmiany procesu tworzenia oprogramowania, takie jak, na przykład, przejście od modelu kaskadowego do przyrostowego, wdrożenie RUP, stosowanie formalnych metod modelowania wymagań. Tak, to często bywa dla programistów większym wyzwaniem, niż nowe techniki! Co znaczy nowe? W jakimś stopniu każde zadanie programisty jest nowe nie programuje się zwykle ponownie tego, co już działa, lecz realizuje funkcjonalność dotąd nie istniejącą. Po drugie, nowość to pojęcie względne: coś może być nowością dla danej osoby, na przykład język C# dla kogoś znającego Java, albo programowanie aplikacji MacOS dla kogoś, kto wcześniej pracował pod Windows. Technologia może być nowością w jednej firmie, czy branży, choć gdzie indziej istniała już wcześniej. 3

4 Wreszcie, istnieją też prawdziwe nowości: technologie, które wcześniej nie istniały w ogóle. Takie technologie są dla programistów największym wyzwaniem: czasem wymagają radykalnej zmiany dawnego podejścia, brak podręczników, brak narzędzi, jest większe ryzyko popełnienia błędów. Nowe technologie biznesu Większość zmian w oprogramowaniu bierze się z nowych potrzeb biznesowych. To biznes przychodzi do programistów i prosi zróbcie to a to, najlepiej na wczoraj. Stara funkcjonalność na nowych urządzeniach, na przykład mobilnych; nowa funkcjonalność ze starych elementów, na przykład możliwość zeskanowania kodu kreskowego towaru telefonem i sprawdzenie, czy produkt jest naprawdę markowy; wreszcie zupełnie nowa funkcjonalność na przykład nowe usługi bankowe albo ubezpieczeniowe, dostępne przez Internet. Tak, realizacja takich nowych technologii biznesowych to główny cel, podstawowe zadanie i największe wyzwanie dla programistów! Dziś oprogramowanie nie jest, jak 30 lat temu, dodatkiem do działania firmy czy instytucji, lecz jej motorem! Umiejętność IT, aby szybciej, skuteczniej i taniej niż konkurencja realizować w niezawodnym, łatwym do modyfikowania kodzie, zmieniające się jak w kalejdoskopie potrzeby biznesu, jest kluczem do sukcesu firmy, albo powodem jej klęski, jeśli IT zawiedzie. Nowe technologie platformy Pojawienie się nowego procesora, zmiany w systemie operacyjnym, nowe usługi internetowe (Web services), nowy protokół komunikacyjny, nowy algorytm szyfrowania danych, nowe, pojemniejsze dyski czy to wyzwania dla programistów, czy też sprawy dla nich obojętne? Bywa bardzo różnie! Nowe urządzenie jest wielkim wyzwaniem dla osoby, która pisze sterownik dla tego urządzenia, a sprawą często najzupełniej obojętną dla kogoś, kto tworzy kod wysokiego poziomu. Pod warunkiem pod warunkiem, że oprogramowanie ma dobrą strukturę, realizuje zasady hermetyzacji (encapsulation), modularyzacji, i ma właściwie zbudowaną hierarchię klas. Niezależnie od tego, jakiego rodzaju zmiany w technologiach miały, mają i będą miały miejsce, umiejętność radzenia sobie z nimi przez programistów zależy od umiejętności stosowania przez nich dobrego stylu programowania, wyboru właściwych języków i nieulegania pokusie stosowania brzydkich sztuczek (kludge) w pisaniu kodu. Programowanie jakiego poziomu? Różne zmiany technologiczne mają różny wpływ na pracę programistów, zależnie od tego, ja jakim poziomie ich programowanie się odbywa. Programista sterowników sprzętu musi rozumieć nową technologię i dostosowywać swój kod do jej zmian przy każdej technicznej nowości, natomiast jest zwykle obojętny na nowe wyzwania biznesowe. Programista aplikacji WWW być może nie dba (pod warunkiem, wspomnianej w poprzednim akapicie, poprawnie realizowanej hermetyzacji) o zmiany technologii układów scalonych, dysków i wyświetlaczy, ale za to musi stawić czoła modyfikacjom biznesu, który jego aplikacja realizuje! 4

5 Tak więc, podsumowując, rozwój różnych technologii jest lub nie trudnym wyzwaniem dla programistów, zależnie od tego, na jakim poziomie wirtualnej maszyny działają! Nowe języki programowania Programista szukający pracy ma czasem wrażenie, że znajomość właściwego języka programowania jest podstawowym warunkiem powodzenia! Jeśli wśród wymagań wobec stanowiska, o które programista się ubiega, napisano znajomość ADA95 APL Assembler AWK Bash Basic C C# C++ Ruby Smalltalk Xbase XHTML, to nie ma zmiłuj! Bez znajomości tego języka jest się bez szans. Cóż, wynika to z krótkowzroczności pracodawców, lub wręcz rozpaczliwej ignorancji działów zajmujących się rekrutacją, nie zdających sobie sprawy z tego, że nowego języka programowania można się doskonale nauczyć w ciągu kilku dni, natomiast opanowanie najlepszych praktyk i zasad inżynierii oprogramowania zajmuje o wiele dłużej! Kiepski programista znający właściwy język, będzie wydajniejszy od dobrego programisty, który tego właśnie języka nie zna przez pierwszy tydzień, a potem role się odwrócą! Czyli z punktu widzenia interesów własnej kariery, zalecałbym programistom sprostanie wyzwaniu uczenia się najnowszych, najmodniejszych języków, albo przeciwnie opanowaniu jakiegoś archaicznego dialektu, który jest i niemodny, i bardzo potrzebny jak COBOL w roku 1999! Natomiast z punktu widzenia faktycznych umiejętności zlecam raczej znajomość kilku języków, co wybitnie ułatwi w razie potrzeby szybkie uczenie się kolejnych. Nie zapominajmy, że języki programowania są dla ludzi, nie dla maszyn mikroprocesor i tak dostaje do wykonania sekwencję instrukcji napisanych w kodzie maszyny, a psychologiczne podstawy, na których opiera się gołosłowne twierdzenia o wyższości jednych języków nad innymi, są zwykle bardzo wątłe. Nie ma się czym ekscytować! Nowe paradygmaty programowania W przeciwieństwie do poszczególnych języków, ważna jest natomiast znajomość różnych paradygmatów, sposobów podejścia do programowania. O ile przejście między C++, C# i Java nie powinno nastręczać żadnych trudności, o tyle zmiana paradygmatu z asemblera na język strukturalny, z języka strukturalnego na obiektowy, a z każdego z nich na rekurencyjny, jak Lisp czy Prolog, to już większe wyzwanie. OK takim wyzwaniom programiści muszą sprostać, tak jak leśniczy nie powinien błądzić w lesie, i nic ponadto. Zresztą, nie wydaje się, aby należało się spodziewać czegoś nowego w tej dziedzinie w najbliższej przyszłości. Niekiedy, nowa technologia produktu programistycznego pociąga za sobą nowy paradygmat. Na przykład rozszerzająca się technologia tworzenia usług internetowych, wykorzystująca architekturę SOA, pociąga za sobą pewne nowe sposoby programowania, niezależnie od używanego języka. Czy nowe metody to też nowe technologie? To wprawdzie sprawa do teoretycznej dyskusji (patrz wcześniejszy akapit: Co to właściwie jest technologia?), ale nie ulega wątpliwości, że nowości czysto techniczne są dla programistów w praktyce o wiele mniejszymi wyzwaniami, niż stosowanie nowych metod wytwarzania 5

6 oprogramowania. Dlatego pominięcie tego tematu oznaczałoby zamykanie oczu na to, co najistotniejsze! Temu wyzwaniu programiści stawiają czoła, ze zmiennym powodzeniem, od ponad 60 lat. Kiedyś programowanie było zajęciem dla samotnych geniuszy, często lauretaów Nobla z fizyki 1. Potem stało się zadaniem zespołowym, trochę z pogranicza sztuki, trochę rzemiosła, stopniowo manufaktury. Rosnąca złożoność przedsięwzięć informatycznych oraz ich efektowne niekiedy niepowodzenia spowodowały, że usiłowano je uporządkować, zbiurokratyzować, uczynić bardziej przewidywalnymi. Z pra-oceanu pra-programowania wyłoniły się nowe, nieznane wcześniej dyscypliny: analiza biznesowa, inżynieria oprogramowania, zarządzanie konfiguracją, zapewnienie jakości, testowanie, utrzymanie. Potem nadeszła kontr-rewolucja agile, próba powrotu do pre-biurokratycznych korzeni. Każda z tych zmian wywierała ogromny wpływ na treść i kształt pracy programistów, każdorazowo wyzwaniem było poradzenie sobie w nowej rzeczywistości. Jak radzić sobie ze zmiennością Rozwój technologii oznacza zmiany. Jakim wyzwaniem są dla programistów zmiany? Na pierwszy rzut oka, zmiany, także te wynikające z rozwoju technologii, nie są dla programistów ani większym, ani mniejszym wyzwaniem, niż dla każdego innego. Zmiany powodują obawy, poczucie zagrożenia, uaktywniają syndromy tak robiliśmy zawsze oraz lepiej nie próbować naprawić tego, co nie jest zepsute. Jednak, zmiany w IT mają też swoją specyfikę, która odróżnia je od zmian w, dajmy na to, hutnictwie, a upodabnia do zmian mody są niezwykle szybkie i nagłe. Zmiany oprogramowania, wynikające ze zmiany technologii, łatwo mogą doprowadzić do chaosu, którego bezwinnymi (czasem, współwinnymi ) ofiarami często stają się programiści i testerzy. Jeśli nie ma dobrze działającego procesu zarządzania zmianami wymagań, programiści o zmianach dowiadują się często chaotycznie i na ostatnią chwilę. Jeśli nie ma dobrego projektu, zmiany wdrażane przez programistów mogą być niespójne. Jeśli nie dokonuje się analizy wpływu (impact analysis), to zdarza się, że realizacja żądanej zmiany wymaga znacznie więcej czasu, niż przewidywano. Tę litanię można by ciągnąć jeszcze długo. Łatwość modyfikacji Rozwój technologii IT zwykle nie odbywa się skokowo, kwantowym skokiem, lecz drogą stopniowych, niewielkich zmian. Tak więc wyzwanie dla programistów nie oznacza zwykle, że wyrzuca się komplet starego oprogramowania i wszystko pisze zupełnie od nowa, lecz że dokonuje się modyfikacji już istniejących aplikacji i systemów. Dlatego łatwość, na ile oprogramowanie poddaje się zmianom, tak zwana łatwość utrzymania (maintainability) decyduje, na ile rozwojowi technologii towarzyszy nieustanna trauma, a na ile może się on odbywać bezboleśnie, płynnie. Niestety, przy projektowaniu systemów i podczas ich realizacji w projektach, ta właściwość pada zbyt często ofiarą krótkowzroczności, chęci osiągnięcia pozornego sukcesu w bieżącym projekcie kosztem przyszłych pokoleń, jak deficyt budżetowy państwa! W końcu szybciej jest zacytuję 1 Artykuł na ten temat: Przyszłość IT tworzą geniusze na 6

7 Adama Kolawę 2, polskiego programistę-miliardera przyspawać zapasowe koło do osi, niż mozolnie przykręcać pięć śrub! Zaś kierownik projektu zostanie pochwalony za zakończenie projektu w terminie - nikt nie widzi, że osiągnięce kosztem jakości i łatwości utrzymania. I tak oszczędność wynikająca ze zwykłego niechlujstwa, wynosząca, dajmy na to, 100 K, powoduje wzrost kosztów testowania, wdrożenia i napraw w ostatniej chwili o 1000 K, zaś rozłożone na lata koszty utrzymania mogłyby być może i o K mniejsze. Nie magiczne języki programowania, nie mistyczne zwinne, ekstremalne metodyki, nie betonowe normy typu PRINCE-2, ITIL czy COBIT, lecz wyłącznie dobry proces inżynierii oprogramowania, dobre praktyki zapewniają, że programiści będą sobie radzic z wyzwaniami płynącymi z rozwoju technologii bez potrzeby wylewania hektolitrów potu i łez. 2 Adam Kolawa Skokowy wzrost wydajności, CeDeWu 2010, oraz 7

8 Wymagania: IT w pigułce 28 stycznia 1986 roku: w 73 sekundzie lotu promu kosmicznego Challenger nastąpiła eksplozja cała załoga zginęła. W komisji, badającej przyczyny katastrofy, uczestniczył między innymi laureat Nagrody Nobla, słynny fizyk Richard Feynman. To jego przede wszystkim zasługą było wykrycie przyczyny śmiertelnej awarii: uszczelki w silnikach pomocniczych nie działały poprawnie w niskich temperaturach, o czym wprawdzie dobrze wiedzieli szeregowi pracownicy projektu, ale ta wiedza jakoś nie dotarła to kadry zarządzającej, lub została przez nią zignorowana. 1996: w wyniku błędu oprogramowania, misja 501 rakiety Ariane 5 kończy się zaraz po starcie efektowną eksplozją na szczęście nikt nie zginął, ale z dymem poszło kilkaset milionów dolarów. Rok 2012: pawilon Emilia w centrum Warszawy, kupiony od miasta przez spółkę deweloperską, zostaje bez wiedzy kupujących wpisany na listę zabytków, co dramatycznie obniża wartość tej nieruchomości. Konserwator zabytków tłumaczy się, że nie przyszło mu do głowy zawiadomić właściciela, zaś rzecznik Ministerstwa Kultury mówi: nie było złej woli, zabrakło procedur. Przyczyny pomyłek, błędów i awarii Co mają ze sobą wspólnego te trzy, opisane powyżej, tak na pozór różne, historie? Temu zagadnieniu poświęcona jest znakomita książka Dietricha Dörnera The Logic of Failure. Jest to książka psychologiczna o tym, jak ludzie systematycznie i spektakularnie mylą się, podejmują złe i głupie decyzje, tak samo w IT, jak w administracji, w przemyśle, w rolnictwie. Pewnie to prawda tylko co nam, ludziom IT, z tej gorzkiej wiedzy? Cóż, dzięki niej mamy szansę przestać się łudzić, że dobre wyniki projektów IT osiągnie się za pomocą natchnienia, uduchowienia, intuicji albo najnowszego języka programowania o dziwacznej nazwie. Sorry, folks, niezbędne są procedury nie biurokracja i papierologia, ale elastyczne, sprawne i w miarę możliwości automatyczne procedury, zabezpieczające nas przed skutkami naszych w 100% ludzkich pomyłek. Procedury, to nie kosztowny luksus, lecz wręcz przeciwnie oszczędność. Dzięki nim wykryjemy skutki ludzkich pomyłek błędy jak najwcześniej, kiedy ich usunięcie jest jeszcze względnie tanie. Dzięki procedurom projekty będą przebiegały sprawniej, a programiści, testerzy i co najważniejsze Klienci będą szczęśliwsi. Jak piękny jest świat, kiedy nie musimy marnować czasu i nerwów na borykanie się ze skutkami cudzych pomyłek, ani na maskowanie własnych! Inżynieria wymagań splot słoneczny IT Procedury, to jakby drogi, prowadzące nas jak najlepiej do celu. Pojemne określenie jak najlepiej czasem oznacza autostradę, czasem wąską ścieżkę, czasem kolejkę linową, a czasem nawet przedzieranie się z kompasem przez bezdroża zależnie och celu. Uwaga: w dwóch powyższych zdaniach dwukrotnie użyłem słowa cel. Cel trzeba znać, aby wiedzieć, dokąd idziemy, ale również, aby wybrać jak najlepszą drogę, która tam do celu prowadzi. Polecam małe ćwiczenie: wpisać w Google wyrażenie definicja celu i pooglądać wyniki wyszukiwania. Cel, to wiedza o tym, co chce się zrobić, dokąd dojść, co zrealizować. 8

9 Cel, czyli wymagania wobec systemu IT. To nie jest popularna nazwa: częściej mówi się o warunkach, o celach, założeniach, projektach, właściwościach. Zaś nazwa dziedziny wiedzy, uczącej, jak znajdować, określać i skutecznie realizować cele inżynieria wymagań to już niestety! zupełna rzadkość. Szukając na portalach pośrednictw pracy, znajdujemy oferty dla analityków, sprzedawców, projektantów, programistów, nawet testerów! ale ze świecą szukać firmy, ogłaszającej potrzebę zatrudnienia inżyniera wymagań. Trochę lepiej wygląda to na uczelniach, gdzie zdarzają się studia podyplomowe dla inżynierów wymagań. Tymczasem inżynieria wymagań, to w istocie rzeczy dziedzina, obejmująca wszystkie kluczowe dla powodzenia przedsięwzięć IT obszary, których nazwy atakują nas dziś ze wszystkich stron: analizę biznesową, techniki sprzedaży, metodyki agile, metody zarządzania, technologie programowania, sposoby testowania, i nawet prawo IT. Niepowodzenia projektów, zarówno IT, jak innych, nieodmiennie wynikają z deficytów inżynierii wymagań, choć łatwiej nam mówić o pomyłkach prezesa Lato, bezmyślnych urzędnikach czy niestarannych programistach. Nie było złej woli zabrakło procedur, a procedury to wszakże drogi, prowadzące do celu, czyli zabrakło umiejętności określenia celu i sposobów jego realizacji: zabrakło inżynierii wymagań. Analiza biznesowa, to właśnie inżynieria wymagań Niby to samo, a jednak nie to samo: zależy, jak zdefiniuje się zakres obu pojęć. W praktyce, analityk (analityk biznesowy), to osoba, która bada i opisuje (modeluje) procesy biznesowe, te istniejące obecnie, jak i te, które chce się mieć w przyszłości. Na razie jakby niewiele ma to wspólnego z informatyką? - tyle że w dzisiejszych czasach wszelkie zmiany procesów biznesowych oznaczają albo zmiany istniejących systemów IT, albo wdrażanie nowych rozwiązań IT, czyli analiza biznesowa to dyscyplina na wskroś informatyczna. Z punktu widzenia inżynierii wymagań (pojęcie stosowane wyłącznie w IT, podczas gdy analiza biznesowa jest określeniem używanym w wielu branżach), analiza biznesowa to albo pierwszy etap inżynierii wymagań, albo proces ją poprzedzający, źródło wiedzy dla tak zwanego procesu pozyskiwania wymagań. Często spotyka się opisy, gdzie nazwa inżynieria wymagań w ogóle nie występuje: następnym krokiem po analizie biznesowej jest projektowanie systemów (czasem między nimi pojawia się jeszcze analiza systemowa). Nieważne są nazwy problem w tym, że jakże często chaos w nazewnictwie sprzyja chaosowi w projektach: Analiza biznesowa A miracle happens Projektowanie systemu 9

10 Jak przemysł IT często widzi proces oprogramowania Ponieważ jednak cuda zdarzają się nieczęsto, skutkiem takiego podejścia informatycy projektanci, architekci, programiści słabo orientują się, co właściwie mają skonstruować. Przykłady w obfitości każdy znajdzie we własnym doświadczeniu, a ponadto w komiksach Dilberta Oto, jak naprawdę wyglądają relacje między analizą biznesową, inżynierią wymagań i projektowaniem: Analiza biznesowa Inne wymagania biznesowe Wymagania techniczne Pozyskiwanie wymagań Inżynieria wymagań (proces wymagań) Projektowanie systemu A tak jest naprawdę nawet jeśli te procesy inaczej się nazywają Sprzedaż, to o dziwo! - inżynieria wymagań Aż w głowie się kręci, tyle jest rozmaitych teorii sprzedaży, metod sprzedaży, technik sprzedaży i szkoleń dla sprzedawców! Z lewej strony naciera marketing i zagadnienia tworzenia marki, z prawej techniki sprzedaży, z dołu reklama, a z góry zarządzanie doświadczeniem klienta 3. I wszędzie powtarzane jest jak mantra: poznać potrzeby klienta, odkryć potrzeby klienta, stworzyć nowe potrzeby klienta, ukierunkować potrzeby klienta na swój produkt, zidentyfikować ukryte autentyczne długofalowe potrzeby klienta Czy chodzi o proszek do prania, samochód, film, biuro podróży czy system komputerowy 4, sedno sprawy to wykryć, zrozumieć, opisać i przełożyć na język operacyjny wykonanie produktu czy usługi, które będziemy realizować i z zyskiem sprzedawać. Czyli innymi słowy, sprzedaż to w gruncie rzeczy forma inżynierii wymagań, a psychologiczne zagrywki, potrzebne do złapania klienta, wykładane na szkoleniach sprzedawców jako wiedza tajemna, omawia się na kursach analizy biznesowej oraz inżynierii wymagań pod skromną nazwą technik pozyskiwania wymagań. Inna rzecz, że tradycyjna inżynieria wymagań też mogłaby się niejednego nauczyć od marketingu oraz reklamy: a dlaczego niby nie robić spotkań JRP przy muzyce i występach dobrze zbudowanych tancerzy płaci obojga!? Niech jednak lepiej zostanie, tak jak jest bo bez tej otoczki czarnej magii, NLP, freudyzmu i guślarstwa, dostawcy szkoleń dla sprzedawców poszliby wkrótce z torbami! Ale czytelnicy tego artykułu niech wiedzą, jak jest naprawdę. 3 Customer Experience Management (CEM). 4 W gruncie rzeczy chodzi o to samo, bowiem produkcja i dystrybucja proszku do prania, funkcjonalność samochodu, produkcja i dystrybucja filmu oraz logistyka biura podróży realizowane są w 90% przy pomocy systemów IT. 10

11 Metodyki agile, to - wbrew mitom - inżynieria wymagań Wymagania kojarzą się wielu osobom z opasłymi, zakurzonymi - fizycznym lub wirtualnym kurzem - tomami dokumentacji, której nikt nie czyta, która zawsze jest nieaktualna, niepotrzebna i nieczytelna, oraz z paraliżującą biurokracją. Natomiast metodyki zwinne agile, extreme programming, TDD same już nazwy brzmią radośnie, luzacko, nowocześnie! Lecz to tylko przesądy. Podobnie jak nie każdy homoseksualista jest wesoły (gay), a nie każdy heteroseksualista jest ponurym katoendekiem, tak samo porządna inżynieria wymagań nie musi być przygnębiającym nudziarstwem, zaś metody agile nie tylko nie obywają się bez inżynierii wymagań one są wręcz częścią inżynierii wymagań! Co wykryli i ogłosili światu sygnatariusze Manifestu Agile ( Otóż odkryli proste i w gruncie rzeczy dobrze znane, choć powszechnie ignorowane zasady inżynierii wymagań i zarządzania projektami, a mianowicie: Wymagania są zwykle zmienne (często ogromnie zmienne!) i potrzebny jest sprawny, elastyczny proces zarządzania tymi zmianami; Klienci użytkownicy często nie są w stanie od początku zdefiniować i jednoznacznie określić swoich potrzeb oraz wymagań, a skuteczną metodą, jak im pomóc, jest prototypowanie: tworzenie dla nich małych fragmentów funkcjonalności, które ułatwiają klientom odkrycie, czego tak naprawdę chcą; W takiej sytuacji, próby kurczowego trzymania się modelu kaskadowego cyklu wytwarzania oprogramowania, oraz próby szczegółowego opisania wymagań zanim przystąpi się do tworzenia kodu, są nieskuteczne i szkodliwe. Oto cała koncepcja agile w pigułce, a reszta humanistyczna frazeologia ( ludzie są ważniejsi niż dokumentacja ), rozmaite rytuały (np. programowanie parami) oraz ostentacyjnie dziwaczna terminologia (np. młyn i przebieg w terminologii agile scrum) to tylko szczegóły. Podsumowując metodyki zwinne przyniosły IT cenne odkrycie, że wymagania można i niekiedy ogromnie warto odkrywać (pozyskiwać) przy pomocy prototypowania i bardzo częstych kontaktów z klientem; że dobrą definicją wymagania może być czasem zaakceptowany przez klienta kawałek kodu, a nie pracochłonny opis, który rozmija się z rzeczywistymi potrzebami użytkowników. Znakomicie! tylko niech nikt nie twierdzi, że podejście agile eliminuje inżynierię wymagań, skoro jest przeciwnie metody zwinne wprowadzają inżynierię wymagań w procesy projektowania i programowania w znacznie większym stopniu, niż odważały się metody tradycyjne! Zarządzanie projektami, to nic innego, jak inżynieria wymagań PRINCE-2, PMI, zarządzanie projektami, przez cele, procesowe, humanistyczne, zasobami ludzkimi wow! Wielki świat, pełen wypasionych metodyk, monopoli, guru, mistrzów, szkół, certyfikatów, trzyczęściowych garniturów, NLP, BMW i nawiedzonych przywódców! A jednak spróbujmy przyjrzeć się dokładnie: a nuż król jest nagi? 11

12 Zarządzanie projektami to: 1. Określenie, co jest celem projektu; 2. Oszacowanie pracochłonności projektu; 3. Identyfikacja zadań do wykonania, przydzielenie ich ludziom i budowa harmonogramu; 4. Nadzorowanie przebiegu projektu, jego statusu, zgodności z harmonogramem i podejmowanie działań zaradczych, kiedy projekt zaczyna się walić. Teraz spójrzmy na te zadania z perspektywy inżynierii wymagań. 1 określenie celu to jest inżynieria wymagań w 100%; 2 oszacowanie pracochłonności to zestaw metod, pozwalających na podstawie wymagań szacować pracochłonność ich realizacji; klasycznym przykładem jest np. analiza punktów funkcyjnych; 3A identyfikacja zadań, to podział wymagań głównych (nadrzędnych) na mniejsze, cząstkowe; 3B przydzielenie zadań i harmonogramowanie nie należą przyznaję - do inżynierii wymagań, ale ich wyniki przekładają się na atrybuty wymagań (np. czas wykonania, osoba odpowiedzialna za realizację wymagania); 4 nadzorowanie, to określanie statusu (stopnia) realizacji poszczególnych wymagań. Celem powyższego wywodu nie jest udowadnianie naciąganej tezy, że inżynieria wymagań oraz zarządzanie projektami to w 100% jedno i to samo bo tak nie jest. Należy jednak koniecznie zrozumieć, że te dwa procesy są ze sobą ogromnie powiązane, w związku z czym nie ma cokolwiek twierdzą modne teorie i VIP-certyfikaty dla kierowników projektów nie ma dobrego kierowania projektem bez zaangażowania się w inżynierię wymagań! Każdy zaś kierownik projektu, który bawi się w wielkiego lidera, nie dbając o wymagania ( Umiecie przecież sami napisać program! Czy trzeba was prowadzić za rączkę? Klient nie ma czasu określić swoich wymagań! ), tylko pozoruje kierowniczą pracę i przynosi więcej szkody niż pożytku. Programowanie, to też inżynieria wymagań Jeśli programowania, to inżynieria wymagań, czy wobec tego wbijanie gwoździ lub układanie cegieł, to architektura czy wręcz biznesplan dla nowego wieżowca? I tak, i nie. Oczywiście, czynności wykonywane przez osobę trzymającą młotek lub kielnię, są dramatycznie odmienne od czynności, wykonywanych przez osoby pracujące w z modelowaniem biznesowym w MS Excel, lub przy pomocy CAD architekta. Niemniej, w dobrze zorganizowanym projekcie każde uderzenie młotka i położenie każdej cegły powinny wynikać precyzyjnie z wcześniejszej dokumentacji, z projektu architektury, z wymagań w przeciwnym razie zagrożenia projektu są ogromne. Sytuacja w IT jest o tyle szczególna, że podczas gdy w budownictwie nie ma szans na zbudowanie gmachu przy pomocy samych murarzy, bez planistów i architektów, o tyle w IT w jakimś sensie daje się to zrobić tyle że znacznie gorzej i znacznie drożej. Co więcej, kompetencje planisty, architekta, operatora dźwigu i murarza to zupełnie różne światy, natomiast między inżynierem wymagań, projektantem i programistą nie ma aż tak dużych różnic. 12

13 Stąd bierze się wiele chronicznych problemów IT. Pokusa pisania kodu na łapu-capu jest wielka program, w przeciwieństwie do mostu, można poprawiać wielokrotnie, nawet po widowiskowym zawaleniu się i za uleganie tej pokusie przychodzi nam nieraz drogo płacić. Testowanie, to po prostu inżynieria wymagań Testowanie, to kontrola, czy to, jak jest, zgadza się z tym, jak ma być. Na przykład, czy aplikacja poprawnie dodaje albo steruje urządzeniem, czy dokument zgodny jest ze swoim celami z dokumentami źródłowymi, czy funkcja pomocy w programie wyświetla właściwe informacje. Skąd jednak wiadomo, jak ma być? To jest właśnie zapisane w wymaganiach! Doprawdy? zaoponuje ktoś.to jakim cudem odbywa się testowanie w tysiącach projektów, gdzie wymagania są niepełne, błędne, niespójne, nigdzie nie zapisane? Cóż, wtedy albo testowanie jest najzupełniej bezcelowym marnowaniem czasu (skoro każdy wynik testu daje się na siłę wyinterpretować jako w zasadzie poprawny ), albo brakujące wymagania de facto zdobywa się podczas testowania. Testerzy domyślają się, jaki ma być zgodny z niezapisanymi wymaganiami wynik oczekiwany. Czasem domyślają się dobrze, czasem źle, często inaczej niż programiści, czasem inaczej niż użytkownicy. Jest nawet cała, modna szkoła testowania eksploracyjnego, która uczy, jak kreatywnie domyślać się, mimo braku wymagań, co jest OK, a co nie jest, lub niestandardowo zdobywać wymagania ze starych manuali, z rozmów przy piwie, w saunie Pięknie, ale czasochłonnie, drogo i nie zawsze skutecznie. Prawnicy, to zamaskowani inżynierowie wymagań 7 marca 2008 roku zorganizowaliśmy 1-dniową konferencję SoftLex prawne aspekty inżynierii oprogramowania. Okazało się wtedy, jak liczne są podobieństwa mimo wielkich różnic terminologii podejścia prawników, inżynierów wymagań oraz testerów projektujących testy akceptacyjne. Kontrakt na wdrożenie systemu (tak w języku prawniczym nazywa się budowa systemu na zlecenie) określa warunki, które muszą być spełnione, aby zadanie dostawcy uznać za wykonane. Propozycja jednego z dostawców, opisania warunków odbioru systemu zdaniem oprogramowanie w zasadzie będzie działać, skontrowana przez prawnika strony zamawiającej propozycją, że w tej sytuacji zamawiający w zasadzie zapłaci za aplikację, okazało się niedostatecznie precyzyjne Jednym słowem, zrozumienie podstaw inżynierii wymagań przez prawników i podpisujących kontrakty menedżerów jest potrzebne. Nauka i certyfikacja inżynierii wymagań Zasad inżynierii wymagań oraz analizy biznesowej można się nauczyć. Istnieje szereg kursów uczących konkretnych metod modelowania tak procesów biznesowych, jak i wymagań (m.in. popularne UML), ale tutaj podamy kilka znanych na świecie certyfikacji ogólnych, wykraczających poza jedną technikę. IREB International Requirements Engineering Board Certyfikaty inżynierii wymagań oferuje międzynarodowa organizacja IREB ( Polska grupa działaczy IREB ( zajmuje się promocją wiedzy na temat inżynierii wymagań w Polsce i udostępnieniem sylabusów oraz egzaminów na certyfikaty IREB po polsku. W tej chwili na 13

14 świecie certyfikaty IREB oferowane są w sześciu językach, w wielu krajach Europy, Ameryki oraz Azji. Certyfikat podstawowy CPRE Foundation Level ma dziś na świecie osób. IREB oferuje także certyfikaty zaawansowane (Advanced Level). Listę firm prowadzących szkolenia przygotowujące do egzaminów na certyfikaty IREB można znaleźć na (zakładka Training ), zaś firmy szkoleniowe w Polsce na QAI Quality Assurance Institute QAI Software Certifications ( oferuje dwa ciekawe certyfikaty: CABA Certified Associate Business Analyst CSBA Certified Software Business Analyst IIBA International Institute of Business Analysis IIBA ( także ma dwa poziomy certyfikacji: CCBA Certification of Competency in Business Analysis CBAP Certified Business Analysis Professional Opisy tych certyfikacji ma na swojej stronie po polsku IIBA Warsaw Chapter ( polska organizacja IIBA. Zapraszamy do tańca! Konferencja poświęcona inżynierii wymagań i analizie biznesowej Dobre Wymagania (konferencja.wymagania.org.pl) odbędzie się 2-4 października 2013 w Warszawie. Jak to było z testowaniem? W roku 2000 mało kto w Polsce słyszał o testowaniu to znaczy, testowano oczywiście, ale testowanie nie było postrzegane jako odrębna specjalność, nie istniały szkolenia dla testerów. Tematyka testowania pojawiła się po raz pierwszy na konferencji KKIO w 2000 roku, potem na konferencjach zorganizowanych przez autora artykułu we współpracy z IIR w 2002 i 2003 roku. Ruszyły pierwsze w Polsce szkolenia na tzw. certyfikaty ISEB (dziś ISTQB), w 2003 roku założono stowarzyszenie testerów SJSI. Dziś testowanie w Polsce staje się big business. Tak samo będzie z mniej więcej 10-letnim opóźnieniem z inżynierią wymagań. Za 10 lat, w 2022 roku, trudno będzie sobie wyobrazić, że kiedyś inżynier wymagań był niemal nieznanym zawodem. Dlatego serdecznie zapraszamy wszystkich zainteresowanych na zebranie założycielskie PARE Stowarzyszenia Inżynierii Wymagań (wymagania.org.pl), które odbędzie się podczas konferencji Dobre Wymagania, w październiku 2013 roku w Warszawie (enter.wymagania.org.pl). 14

15 Automatyczne zarządzanie projektami fantazja czy okazja? W godnej polecenia książce Toma DeMarco Zdążyć przed terminem, akcję otwiera scena, gdzie bohater książki, nieprawomyślny kierownik projektów IT w dużej firmie, stawia się na obowiązkowym kursie zarządzania projektami. Bohater pyta prowadzącego, o czym będzie to szkolenie? Czy o tym, jak dobierać uczestników projektu? A może o tym, jak ich motywować? Jak się porozumiewać, jak rozwiązywać konflikty? Nic z tego jednak - prowadzący wyjaśnia, że szkolenie nauczy procedur, omówi dokumentację i procesy. Tak, to ważne sprawy - zgadza się bohater - tylko nazwa szkolenia jest wobec tego nieodpowiednia! Powinno się ono nazywać nie zarządzanie projektami, lecz drobne szczegóły administracyjne! Jest w tym wiele prawdy - ale, moim zdaniem, tylko pod warunkiem, że te drobne szczegóły administracyjne są pod kontrolą. W przeciwnym razie najbardziej nawet charyzmatyczny przywódca zainspiruje uczestników do... entuzjastycznego i pracowitego udziału w marnotrawiącym zasoby chaosie. Natomiast projekt, w którym te drobne szczegóły administracyjne nie są problemem, nie potrzebuje ani Aleksandra Wielkiego, ani Steve Jobsa - wystarcza im sprawny organizator. Ja, robot: zalety automatycznego nadzoru Zalety automatyzacji rutynowych, typowych, powtarzalnych i względnie prostych czynności administracyjnych; czynności koniecznych, żmudnych, narażonych na pomyłki wynikające z ludzkiego zmęczenia, nudy, emocji - te zalety są oczywiste! Bez komputerowej automatyzacji nie mielibyśmy dziś kart płatniczych ani przelewów przez Internet, telefonów komórkowych, hamulców ABS... szkoda czasu i miejsca na dalsze wyliczanie! Ta oczywista prawda ma, niestety, wielu przeciwników. Wszelkiej maści konserwatystów, bo po o usprawniać to, co działa? Bystrych inaczej, którzy boją się, że automatyzacja rutynowych czynności pozbawi ich pracy. Ekologów, zielonych i wyznawców buddyzmu zen, którzy twierdzą, że i tak zbyt wiele mamy w życiu stresu i pośpiechu (racja), zapominając, że automatyzacja pozwala go zmniejszać; oraz tych wszystkich, co uważają, że cierpienie uszlachetnia, więc grzesznym jest ułatwiać sobie życie. Wielka tablica świetlna Jak więc konkretnie można by zrealizować automatyczne zarządzanie projektem IT - w praktyce? Wystarczy wielka tablica świetlna, na której każda żarówka odpowiadałaby jednemu wymaganiu, które tworzony system ma realizować. Na początku projektu żaróweczki świeciłyby się głównie na czerwono - nic nie jest jeszcze zrobione, i rzut oka na taką tablicę zastępowałby kunsztowne wyliczenia dumnych posiadaczy MBA, listy kontrolne rycerzy feudalnego zakonu PRINCE2, czy natchnione intuicje przywódców, liderów oraz innych organizacyjnych nieszczęść. Praca każdej osoby w projekcie byłaby połączona niewidzialnym drucikiem z tą tablicą. Deweloper zrealizował, dokonał analizy statycznej i skompilował kawałek kodu - jedna żarówka zmienia swoją 15

16 barwę z czerwonej na nieco żółciejszą! Udało się zintegrować, połączyć ze sobą i nawet uruchomić razem wiele takich kawałków - i cała grupa żaróweczek zaczyna się palić miłym, żółtym blaskiem! Ups - test jednostkowy modułu wykrył błąd, więc jedna żarówka, już tak obiecująco żółta, na powrót czerwienieje. Kiedy testy systemowe i akceptacyjne idą do przodu, coraz więcej żarówek zielenieje. Jeśli cały projekt posuwa się sprawnie do przodu, to w kolejnych rzędach coraz więcej żarówek świeci zielono, coraz mniej - czerwono, tak, by w ostatnim rzędzie - odpowiadającym terminowi ostatecznemu - móc spodziewać się, zgodnie z przyjętym kryterium, wszystkich, czy niemal wszystkich, żarówek świecących zielono. Nie wszystkie żarówki są tej samej wielkości! Są wszakże wymagania kluczowe, które warunkują biznesowy sens całego przedsięwzięcia (wielkie żarówy), i wymagania mniej ważne - małe żaróweczki 5. Jakie to proste! Wystarczy dobrze znać wymagania, ich wagę, ich powiązania ze sobą oraz z zaprojektowanymi modułami kodu i testami, a te z kolei - z osobami, które te zadania wykonują! To się nazywa śledzeniem powiązań wymagań (ang. requirements traceability) i rynek narzędzi tak komercyjnych, jak i wolnych, oferuje ich bardzo wiele (zalecam wstukać w wyszukiwarkę frazę requirements traceability tools, albo wziąć może udział w szkoleniu Certified Professional in Requirements Engineering - IREB CPRE 6 ). Oczywiście, takie rozwiązania dostępne są też w chmurze (czego dziś nie ma w chmurze?). Polecam jedno z wielu - wymienione tutaj zgodnie z moimi subiektywnymi preferencjami - znakomite, proste i niedrogie narzędzie ReQtest (reqtest.com) 7. Szwedzkie narzędzie, dodam, bo to, zdaje się - sądząc z reklam blachy dachowej i rynien - dobry argument marketingowy. Jak to - więc narzędzie do zarządzania wymaganiami może wystarczyć do zarządzania projektem? A co z oszacowaniem pracochłonności, co ze ścieżkami krytycznymi, co z kamieniami milowymi, z harmonogramowaniem, co z przydzielaniem zadań różnym uczestnikom projektu? Jak mierzyć stan realizacji projektu? Gdzie umieszczać plany, raporty, wyniki audytów i inne PM-owe czary-mary? Po kolei. Oszacowanie pracochłonności wymaga przede wszystkim i niemal wyłącznie - dobrych wymagań. Tak jak pracochłonność wykopania dołu jest względnie prostą funkcją jego objętości oraz twardości podłoża, tak pracochłonność projektu IT jest względnie zawiłą funkcją sumy jego założeń - systemowego odpowiednika objętości dołu. Istnieje szereg naprawdę dobrych metod szacowania pracochłonności projektów na podstawie wymagań, na przykład na podstawie punktów funkcyjnych, albo punktów UML - czyli z modeli wymagań. Inne metody, to wróżenie z fusów. Ścieżki krytyczne są funkcją hierarchii wymagań. Jeśli realizacja ważnych wymagań X, Y i Z wymaga realizacji wymagania A, to owo A grzecznie nam się układa na trzech ścieżkach ścieżkach krytycznych. I patrzcie - wystarczyła analiza wymagań, nie trzeba było doktoratu z zarządzania! 5 Więcej na ten temat - w artykule Tester's High Noon, victo.eu/eng/papers/high_noon.pdf 6 Lista dostawców: 7 Zwłaszcza polecam łopatologiczny film: 16

17 Harmonogram, kamienie milowe: tak, przyznaję - tego narzędzia do wymagań nie wspierają wprost. Dlatego pobudowano narzędzia łączące świat PM oraz świat wymagań. Moim, nadzwyczaj subiektywnym, zdaniem, znakomitym przykładem takiego narzędzia jest Concerto 8. Concerto łączy ze sobą tradycyjnie osobne światy: śledzenie powiązań wymagań, zarządzanie zadaniami, automatyczne zapobieganie błędom 9, zarządzanie projektem, integrację. Pełny opis wymagałby odrębnego artykułu. Jeśli nawet udało mi się jakoś okiełznać (można pomarzyć...) zastrzeżenia tradycjonalistów, to już słyszę nadciągającą, groźną falę zastrzeżeń ze świata agile, sprowadzających się, niezależnie od szczegółów, niczym w małżeństwie, do narzekań typu to jest zupełnie inaczej, niż myślisz oraz ty mnie nie rozumiesz. Cóż, rzeczywiście: proponowana przeze mnie tablica świetlna odebrałaby nieco chaotycznego romantyzmu młynom (scrum w agile-owym dialekcie, czyli - mówiąc po ludzku - codzienne spotkania zespołu), bo przestałyby one służyć tak mocno wzajemnemu informowaniu się. Patrząc szerzej, jak już pisałem we wcześniejszych artykułach, agile nie jest anty-wymaganiowy, przeciwnie: on jest ultra-wymaganiowy! Nasza tablica świetlna doskonale wpisuje się w agile-owe pojęcie rejestru zadań przebiegu (sprint backlog)... Tak, wiem, jakie niedopuszczalne zdanie napisałem kilka akapitów wyżej: wystarczy dobrze znać wymagania, ich wagę, ich powiązania [...]. No cóż, to naprawdę wystarczy, ale mało kto tę oczywistą prawdę stosuje, bo wymagania są niemodne 10. Tak samo z odchudzaniem: wystarczy magiczna dieta ŻM ( żreć mniej ) i odchudzanie działa... a mimo tego kolorowe pisma pełne są szalbierczych diet równie skomplikowanych, co nieskutecznych. Zarządzanie ryzykiem: to po prostu nie wypada! Zarządzanie projektami, jeśli pojmować je nowocześnie, a nie w postaci ITIL-owej, COBIT-owej czy PRINCE2-owej rąbanki, to przede wszystkim zarządzanie ryzykiem 11. Jak to znakomicie opisują w swojej książce Walzing with Bears Tom DeMarco i Tim Lister, oszacowanie terminu realizacji projektu jest w istocie ćwiczeniem z oceny prawdopodobieństwa: im późniejszą datę się podaje, tym mniejsze jest ryzyko, że projekt przed jej upływem nie zostanie ukończony. Czyli popularne wśród młodych ambitnych twierdzenie - połączone z głośnym waleniem się w klatę będziemy na pewno gotowi przed <wstawić datę>, ma walor jedynie propagandowy, ale nie zawiera żadnej informacji. Porządne zarządzanie ryzykiem, aby nie odbywało się, jak wygląda powszechna praktyka, metodą stosowania niedoskonałej, emocjonalnej intuicji kierownika projektu, lub jego podwładnych, wymaga systematycznego przypisywania ryzyka poszczególnym wymaganiom, i śledzenia jego zmian. Zastosowana w kilku projektach, taka praktyka pozwoli nie tylko na pół-automatyczne szacowanie ryzyka w kolejnych projektach, ale także na udoskonalenie całego procesu IT Artykuł Między biurokracją a chaosem, Computerworld, 21 sierpnia 2007, 10 Tak bardzo niemodne, że nawet elegencką nazwę inżynieria wymagań wyparło niemal całkowicie chronicznie nieprecyzyjne określenie analiza! 11 Testowanie na podstawie ryzyka jako sposób zarządzania zagrożeniami w projekcie informatycznym, victo.eu/pl/wiedza/test_na_podst_ryzyka.pdf 17

18 Jeśli to takie proste, czemu tego się nie robi? Zetknąłem się ostatnio z nieznanym mi wcześniej zagadnieniem: audytem zarządzania budynkiem użyteczności publicznej. Spadochroniarze sprawdzają, czy są dokonywane okresowe kontrole techniczne? Czy jest instrukcja przeciwpożarowa? Czy właściwie - zgodnie z czymś tam o zamówieniach publicznych - wykonywane są przetargi na rozmaite prace, w tym konserwację? Zakres takiej kontroli jest olbrzymi, ale prawdziwy smak życia wynika dopiero z faktu, że nikt - poza kontrolerami - nie wie dokładnie, jakie są wymagania! Obowiązkowa kontrola techniczna powinna, okazuje się na przykład, obejmować coroczne sprawdzanie instalacji odgromniczej, więc ja, naiwny, spytałem, skąd wiadomo, że nie, na przykład, instalacji zabezpieczającej przed ewentualnym wybuchem wulkanu? Gdzieś tam jest to ponoć zapisane, w jakichś tajemnych przepisach, ale znają je tylko wtajemniczeni, co przeszli kosztowne i czasochłonne kursy zarządców nieruchomości. Nawet tam, gdzie administrator - zarządzający ma wiedzę, co i kiedy ma być zrobione, musi zadbać samemu, aby o tym pamiętać. Nie istnieje, okazuje się, żaden automatyczny system, który o tym przypomni. Aż się prosi o taką automatyczną listę kontrolną - zadanie do realizacji dla studenta 2 roku informatyki. Wtedy administrowanie budynkiem przestałoby być nieustannym stresem i nieustannym pilnowaniem tysięcy drobnych szczegółów administracyjnych - to robiłoby się automatycznie! Ale nigdy tak nie będzie... zbyt wielu znakomicie okopanych, poważnych udziałowców poniosłoby straty! Zbyt wielu ma z tego chaosu wymierne korzyści! Autorzy obowiązujących zasad - bo o ileż łatwiej, przyjemniej i bezpieczniej posługiwać się ezopowym językiem prawno-administracyjnym, niż formułować swoje wymagania w jakże banalnej formie reguł, realizowanych przez jakieś - ohyda! - informatyczne narzędzie. Kontrolerzy - oczywiście. Po automatyzacji, już ich wizyta nie budziłaby pobożnej trwogi, utraciliby tę odrobinę nimbu groźnej władzy, jaki otacza ich działania. Dostawcy kosztownych i czasochłonnych kursów zarządców nieruchomości - to jasne. Narzędzie, aplikacja zarządzająca uczyniłoby ich kursy najzupełniej zbędnymi. Doświadczeni administratorzy - zarządzający, którzy utraciliby przywileje wynikające z posiadania wiedzy tajemnej, i byliby rozliczani ze swoich faktycznych umiejętności. Wszyscy - nie byłoby już na co móc tak fajnie ponarzekać! Pogadać przez telefon o 7-ej wieczorem! Pobałaganić, pochachmęcić - gdzie bez tego byłby słodko-kwaśny smak życia? Pomyślałem jaka straszna jest ta branża, administrowanie budynkami publicznymi! Prawda? Bo u nas, w świecie IT, jest przecież zupełnie... tak samo :-( 18

19 Quo vadis, analizo? Historia, teraźniejszość i przyszłość analizy b iznesowej oraz inżynierii wymagań Co robili starożytni? Wprawdzie nasi przodkowie nie budowali systemów IT, bowiem nie mieli jeszcze komputerów, ale budowali wiele innych rzeczy, co do których też warto było wiedzieć, co właściwie ma powstać, zanim wbiło się pierwsze gwoździe, postawiło pierwsze kroki w jakąś stronę, albo kupowało przedmiot od sąsiada. W przeciwnym razie, konsekwencje mogły być niemiłe: Wraz z pojawieniem się pierwszych wspólnot osiadłych, rozpoczął się handel wymienny: obie strony transakcji znały się wzajemnie. Gdy wyroby psuły się, to wszyscy w osadzie o tym wiedzieli i przynosiło to hańbę wytwórcy. [ ] Pojawienie się handlu między osadami spowodowało [ ] handel na ryzyko kupującego Kupujący musiał ocenić produkt pod względem jego użyteczności w chwili zakupu, potem kupcy wyjeżdżali i gdy wyroby nie działały lub psuły się, nie wiadomo było do kogo mieć pretensje. 12 Przeskoczmy teraz kilka tysięcy lat i popatrzmy na wymowny przykład o wiele późniejszy: jakie kłopoty spowodowało lekkomyślne traktowanie wymagań, czyli niestosowanie zasad inżynierii wymagań, w roku Wtedy to, 10 sierpnia, przewrócił się i zatonął, kilkanaście minut po odbiciu od nadbrzeża, nowo zbudowany okręt flagowy marynarki szwedzkiej Wasa 13. Przyczyny? Okręt z powodu ambicji króla był potężniejszy niż inne ówczesne okręty dwupokładowy. Takie było życzenie króla, któremu nikt nie ośmielił się przeciwstawić nasuwa się tutaj myśl, czy więc na pewno klient ma zawsze rację? Bowiem dwupokładowy okręt miał znacznie wyżej środek ciężkości i okazał się w związku z tym niezwykle wywrotny. Analiza biznesowa wskazała wprawdzie, że potrzebne są dwa pokłady z działami, ale zbyt szybko przeskoczono od potrzeby biznesowej do jej implementacji budowy kadłuba. Zaniedbano etapy pośrednie: inżynierię wymagań, która między innymi zajmuje się takimi atrybutami wymagań, jak ich wykonywalność (feasibility) 14, oraz projektowanie: nie umiano jeszcze wówczas precyzyjnie wyliczyć stabilności statku na podstawie danych o jego wymiarach i rozkładzie ciężaru. Zastosowano metodę, którą można by nazwać megaagile: po prostu pracowici cieśle-programiści dobudowali jeszcze jeden pokład, zgodnie z życzeniem zleceniodawcy-króla! Tak więc popełniono kardynalny błąd jakże typowy we współczesnych projektach IT już w początkowej fazie projektu, wynikający z powszechnego i wtedy, blisko 400 lat temu, i dzisiaj podejścia po co marnować czas na jakiś SRS, bierzmy się do roboty. 12 Inżynieria oprogramowania jak zapewnić jakość aplikacjom, Bogdan Bereza i Bolesław Szomański, 2009, Wydawnictwo Helion. 13 Wydobyty w 1961, okręt można dziś oglądać w Muzeum Wasa ( 14 IEEE Recommended Practice for Software Requirements Specification (IEEE ). 19

20 Warto jeszcze rzucić okiem na konsekwencje tego błędu, bardzo charakterystyczne. Kiedy projekt popada w kłopoty albo wręcz, jak Wasa, kończy się spektakularną klęską zwykle winnych szuka się wszędzie, tylko nie w braku inżynierii wymagań. Otóż, oczywiście, choć cichutko wtedy jeszcze nie zniesiono kary śmierci obwiniano królazleceniodawcę i jego idiotyczne pomysły. Hm, tylko że z takich to pozornie idiotycznych pomysłów biorą się wielkie sukcesy biznesowe, zgodnie z zasadami strategii błękitnego oceanu, tylko trzeba umieć sobie z nimi radzić na przykład stosując inżynierię wymagań. Obwiniano głównego konstruktora, Henrika Hybertssona: no, jasne. Gdyby statek zatonął ledwo pół roku później, tenże Hybertsson zbierałby pochwały. Ocena kierowników projektów zawsze jest przeraźliwie krótkowzroczna, oparta albo na pozornym sukcesie, albo na równie pozornej, byle spektakularnej, klęsce. Jak zwykle, obwiniano też testowanie: czemu nie ostrzegli? Otóż, testowanie wykonano. Stabilność kadłuba sprawdzano wówczas w ten sposób, że gromada kilkuset robotników stoczni biegała po pokładzie z jednej strony na drugą, rozkołysując kadłub. W przypadku Wasy testy przerwano, gdyż kadłub zaczął się kołysać zbyt niebezpiecznie, grożąc wywrotką. Króla zaś nie zawiadomiono, bowiem obawiano się jego gniewu. No i jeszcze oskarżano Polaków, bo to z nami głównie wojował król Gustaw II Adolf. Polski sabotaż był więc ponętnym wyjaśnieniem. Sam król, nakazując śledztwo, określił przyczynę awarii jako głupotę i niedbalstwo. Bingo, proszę króla! Budując wielkie, skomplikowane rzeczy, ludzie z definicji są głupi, bo rozum nie wsparty narzędziami - nie radzi sobie z nimi, zaś niedbalstwo jest naszą cechą przyrodzoną geny pieczołowitości i staranności wyginęły dawno temu, stając się pokarmem tygrysów szablastozębnych, przed którymi nasi pieczołowici i staranni przodkowie nie uciekali, zajęci regułami i rytuałami. Wiedząc o tym, wprowadzamy procesy i procedury, które tę staranność gwarantują albo ich nie wprowadzamy, i nie przestrzegamy, wtedy tonie Wasa lub projekt IT kończy się klęską. Czyli, pod pewnymi względami, inżynieria wymagań jej wielka potrzeba i jeszcze większy brak jest bardzo, bardzo stara. Programistyczny pięściak Pięściak, albo tłuk pięściowy, wykonywano z twardego krzemienia, więc nasz jaskiniowy pra-praprzodek w swoim własnym interesie realizował trochę inżynierii wymagań, żeby jego wielodniowe wysiłki nie poszły na marne. Źle wykonany pięściak trudno było przerobić na coś innego. W latach czterdziestych i pięćdziesiątych ubiegłego wieku nauczyliśmy się wytwarzać pięściaki z miękkiego krzemu zamiast krzemienia. No, może sam krzem pierwiastek nie jest specjalnie użyteczny, ale w układach scalonych i budowanych z nich komputerach jak najbardziej. Komputery bowiem umożliwiają wykonywanie oprogramowania, które można modyfikować i przerabiać o wiele łatwiej i taniej niż krzemienne pięściaki, albo budowane z drewna żaglowce. Ta łatwość zarówno robienia nowych rzeczy, którą daje oprogramowanie, jak i łatwość ich zmieniania, jest podłożem całego olbrzymiego skoku cywilizacyjnego bez precedensu, jaki zanotowaliśmy od lat 50-ych zeszłego wieku do dziś. 20

21 Z drugiej strony, ta łatwość okazała się też niebezpieczna. Względnie nieskomplikowane algorytmy programów w latach 40-ych i 50-ych, w dodatku tworzone od początku do końca przez ludzi wybitnych, nawet laureatów nagrody Nobla 15, nie wymagały stosowania ani analizy biznesowej, ani inżynierii wymagań. Od tego czasu sytuacja zmieniła się diametralnie: wielomilionowej rzeszy twórców oprogramowania nie daje się już obsadzić geniuszami, a dla większości aplikacji oraz systemów IT o wiele ważniejsza jest ich zgodność z potrzebami biznesowymi, niż stosowanie trudnych, matematycznych algorytmów. Dlatego od podejścia charakteryzującego lata 50-e i 60-e od pojmowania tworzenia programów jako radosnego rzemiosła artystycznego, IT przeszło do nowej fazy inżynierii oprogramowania. Ta faza trwa do dziś i niesie nas w przyszłość. Inżynieria wymagań jest jednym ze składników inżynierii oprogramowania. Kalendarium inżynierii wymagań Konferencja Inżynierii Oprogramowania NATO, 1968 Tak zwany wówczas kryzys oprogramowania coraz trudniej było znaleźć wystarczającą liczbę wysoko kwalifikowanych programistów, coraz częściej projekty informatyczne przekraczały i budżet, i harmonogram 16, spowodował, że zaczęto poszukiwać środków zaradczych początkowo głównie z sferach języków programowania oraz jego architektury. Wyrazem tych tendencji była właśnie rzeczona konferencja, kiedy, wedle legendy, po raz pierwszy oficjalnie użyto określenie inżynieria oprogramowania. Inżynieria wymagań Ten termin prawdopodobnie po raz pierwszy pojawił się w druku w 1979 roku, w tak zwanym raporcie TRW 17, ale nie było szerzej znane ani stosowane aż do lat 90-ych, kiedy pojawiło się klasyczne opracowanie IEEE CS pod tytułem System and Software Requirements Engineering. Jak w wielu obszarach, także w dziedzinie inżynierii wymagań widać odmienność między światem akademickim, a realiami przemysłu IT. W świecie akademickim określenie inżynieria wymagań (jako gałąź szeroko rozumianej inżynierii systemów oraz inżynierii oprogramowania) jest powszechnie znane i przyjęte. Najpoważniejsze czasopismo w tej dziedzinie Requirements Engineering Journal 18 wydawane jest regularnie od 1996 roku, a więc już od szesnastu lat. Jeszcze starsza jest konferencja: IEEE International Requirements Engineering Conference odbędzie się w tym roku już po raz dwudziesty pierwszy 19. Historia i materiały ze wszystkich wcześniejszych konferencji znajdują się na portalu requirementsengineering.org, począwszy od roku Przyszłość IT tworzą geniusze ( 16 Doświadczenia z tego okresu opisuje m.in. książka Freda Brooksa Mityczny osobomiesiąc. Eseje o inżynierii oprogramowania z 1975 roku, wielokrotnie usupełniana i wznawiana. 17 Software Requirements Engineering Methodology, TRW Defense and Space Systems Group Oryginalna nazwa lokalizacji: 19 W czerwcu 2013, w Rio de Janeiro ( 21

22 Ciekawe porównanie największa w Europie konferencja na temat testowania oprogramowania, EuroSTAR, też po raz pierwszy odbyła się w 1993 roku, w Londynie. W międzyczasie testowanie stało się big business i modne: przykładowo, quasi-monopolistyczna organizacja ISTQB 20, działająca od 2003 roku, chwali się dziś armią osób mających tak zwany certyfikat podstawowy testowania oprogramowania, podczas gdy analogiczna organizacja inżynierii wymagań, IREB 21, dopiero niedawno przekroczyła liczbę osób z certyfikatem podstawowym inżynierii wymagań. O co chodzi? Przecież kluczowe znaczenie inżynierii wymagań zarówno dla biznesu, jak i dla IT wydaje się nie budzić najmniejszych wątpliwości. Przeszkoliwszy wiele tysięcy osób w zakresie testowania, w tym na ów niezmiernie popularny certyfikat ISTQB, autor tego artykułu wielokrotnie zetknął się z opiniami osób zajmujących się testowaniem, że źródłem wszelkich kłopotów, które skrupiają się na testerach i testowaniu, są niedostatki inżynierii wymagań właśnie, czyli wiedza na ten temat istnieje w przemyśle IT, ale nie przekłada się na żadne działania. Czemu? Wyjaśnienie, moim zdaniem, ma charakter bardziej antropologiczny i socjologiczny, niż informatyczny. Otóż nazwijmy je tak górne obszary inżynierii wymagań zadomowiły się pod nazwą analizy biznesowej względnie wysoko w świecie organizacyjnych i korporacyjnych hierarchii; całkiem słusznie zresztą, bo trudno oczekiwać, że analizą biznesową będą się zajmować osoby z niewielkim doświadczeniem, nie mające całościowej wizji działania firmy. Z drugiej strony znów posłużę się ryzykowną nazwą dolne rejony inżynierii wymagań zadomowiły się w świcie projektowania, architektury systemów, w niełatwych technicznie zagadnieniach modelowania, UML, DDD To co pośrodku taka czysta inżynieria wymagań jakoś nie może dobić się uznania. Oczywiście, istnieje w rzeczywistości, bo magiczny, cudowny skok od wyników analizy biznesowej do diagramów UML, ani tym bardziej do gotowego, działającego kodu, nie istnieje. Czyli zadania inżynierii wymagań wykonują lepiej lub gorzej kierownicy projektów, dbający, żeby produkt końcowy jakoś tam dał się wcisnąć odbiorcom; inżynierami wymagań są też członkowie zespołów agile, zwłaszcza mistrzowie młyna 22 (kocham terminologię agile!). I co dalej, czyli obiecane quo vadis Jak słusznie ktoś zauważył, osobiście mam skłonność do trafnego przewidywania zdarzeń IT, tyle że przedwcześnie. Na przykład, przywlokłem do Szwecji w 1999 roku nowość certyfikację ISEB (to taka dawna forma ISTQB), do Polski w 2001 i 2002 roku konferencje i szkolenia testowe oraz inspirację do założenia organizacji testerów oprogramowania. W 2005 roku opublikowałem artykuł pt. Drogowskaz do przyszłości - mądrość będzie na serwerach, czyli ASP 23 i hey presto oto mamy od paru lat arcy-modne pojęcie chmury obliczeniowej! Wszystkie przeze mnie przewidywane kierunki zrealizowały się w 110% i stały wielkim biznesem, ale ja sam już w tym zrywaniu owoców moich proroctw jakoś nie uczestniczę. Dlatego zachęcam do 20 ISTQB International Software Testing Qualifications Board istqb.org, zrzesza ponad 40 krajów członkowskich, w tym Polskę. 21 IREB International Requirements Engineering Board ireb.org powstało w 2006 roku. 22 Czyli Scrum Masters

23 uważnej lektury poniższego akapitu to, co tam piszę, sprawdzi się na pewno, natomiast wciąż nieobsadzone są stanowiska prezesów organizacji, wciąż do wzięcia jest rynek szkoleń. Zacytujmy więc poetę: RE is like candy on a shelf / You want to taste and help yourself / The sweetest things are there for you / Help yourself, take a few / That's what I want you to do. Szok szkoleniowo-certyfikacyjny Szkolenia przygotowujące do certyfikacji IREB CPRE (Certified Professional in Requirements Engineering) będą za 2-3 lata szły jak świeże bułeczki. Na wyższych piętrach, spopularyzują się certyfikaty IIBA 24, oraz QAMP 25. W tej sytuacji wzrośnie rola polskiego oddziału IREB ( Organizacje Tak jak pół roku temu w Szwecji powstało SARE (Swedish Association for Requirements Engineering, tak w Polsce okrzepnie Stowarzyszenie Inżynierii Wymagań ( stanowisko prezesa nie obsadzone!). Konferencja Dobre Wymagania 2013 (breq2013.wymagania.org.pl) wprawdzie odbędzie się, jak zaplanowano, kwietnia 2013, ale prawdziwym sukcesem komercyjnym okaże się dopiero w 2014 roku, kiedy pod zmienioną nazwą wezmą się za nią mistrzowie marketingu i PR-u. Pisma: pojawi się nowe, międzynarodowe, wielojęzyczne pismo na temat inżynierii wymagań, którego główna wersja będzie anglojęzyczna JAKAŚDOMENA.com, ale będzie też miało swoje wersje w innych językach, np. polska.jakaśdomena.com. Praktyka i narzędzia Opisywane w Computerworld już wielokrotnie ADP (Automated Defect Prevention) jako metoda zarządzania projektami IT, stanie się czymś powszechnie stosowanym i oczywistym, oczywiście pod lepszą marketingowo nazwą skoro chmura jest już zajęta, to może inne, duże zjawisko naturalne, np. wulkan albo śnieżyca? Ta powszechna za 5-10 lat metodyka usunie z zarządzania projektami zarówno magię i szarlatanerię, jak i biurokrację, zamiast nich wprowadzając automatyzację czynności powtarzalnych i prostych, oraz śledzenie statusu projektu na podstawie wymagań jak już pisaliśmy przed Świętami w numerze 35/2012 ( Projekty z automatu 26 ). Potwierdzam tak będzie. 24 IIBA International Institute of Business Analysis (iiba.org). 25 QAMP Quality Assurance Management Professional (

24 Rola analizy biznesowej w ulepszaniu procesów IT Selenium, Cucumber oraz Ruby W Przewodniku po rynku szkoleń IT (Computerworld, wrzesień 2012) możemy przeczytać, jakie wymagania pojawiają się najczęściej w ofertach pracy. Widzimy tam następujące nazwy: systemy klasy ERP firmy SAP, systemy klasy ERP firmy Oracle, systemy wspierające zarządzanie relacjami z klientami CRM, projektowanie aplikacji internetowych [ ] wirtualizacja, oprogramowanie klasy ERP Comarch, Java,.Net, HTML, C++, PHP, Delphi, Oracle, MySQL, Microsoft SQL Server, IBM DB2, Linux, Oracle, Unix, Microsoft, HP, Cisco, IBM, Vmware, Novell Zupełnie brakuje na tej liście określeń takich jak: inżynieria oprogramowania, inżynieria wymagań, zapewnienie jakości, zarządzanie projektami informatycznymi, testowanie, projektowanie systemów, udoskonalanie procesów. Gdyby analogiczna sytuacja była na przykład w budownictwie, to firmy szukałyby nie murarzy, zbrojarzy, hydraulików, inżynierów budowlanych czy architektów, tylko specjalistów w zakresie określonych marek klejów, cegieł i rur oraz rodzajów domów, np. specjalistów budowania domów jednorodzinnych w terenie podmokłym dla czteroosobowych rodzin, mających dwa samochody, psa i kota. Jak w tej sytuacji usprawniać procesy, a nawet tworzyć choćby pojedyncze, ale dobre rozwiązania IT, skoro nie zwraca się uwagi na to, jaki jest cel i sens biznesowy danego rozwiązania, ani jaka skuteczność i opłacalność metod IT, lecz koncentruje się na detalicznej, przemijającej znajomości technologii? Struktura rynku szkoleń IT jest znakomitym odwzorowaniem tego stanu rzeczy. Teraz podobno dobrze się sprzedają kursy dla użytkowników modnego narzędzia Cucumber (jedno z setek, akurat dzisiaj cool, narzędzi do wykonywania tzw. testowania przy pomocy słów-kluczy), kursy języka programowania Ruby (jeden z dziesiątków obiektowych języków programowania, sympatyczny, ani gorszy, ani lepszy od innych) oraz Selenium jednego z wielu narzędzi do testowania aplikacji webowych. Spróbujcie jednak sprzedać wiedzę pozwalającą naprawdę zrozumieć te zagadnienia ponad technologicznymi szczegółami nie uda się, zbyt mały jest popyt. Mało kto chce rozumieć, wszyscy chcą tylko umieć, szukają gotowych przepisów na jedną sytuację. Podsumowując: zafascynowani selenem, ogórkiem oraz rubinem (dlaczego IT wymyśla takie odjechane, nic nie mówiące nazwy?), nie znając inżynierii oprogramowania, realizujemy projekty IT ad hoc, kierując się zawodnym instynktem, lub opierając na ratujących sumienie menedżerów gotowcach (następny akapit). Dopóki to się nie zmieni, dopóki analiza biznesowa oraz inżynieria wymagań nie znajdą się na szczycie listy w przewodniku po rynku szkoleń -dopóty udoskonalanie procesów będzie w dużym stopniu grą pozorów i fikcją. 24

25 Moda na gotowce: BEPL, UML, ITIL, PRINCE 2 Nie mam nic przeciwko ani tym znakomitym językom (BEPL i UML), ani tym niezłym standardom (ITIL, PRINCE 2). To dobre narzędzia pracy. Niestety, nie zastąpią myślenia a takie próby niekiedy są podejmowane. Tak samo jak niestosowne jest sięganie po młotek, zanim się wie, co do czego trzeba przybić i czy w ogóle przybijać, tak mija się z celem modelowanie w języku UML wymagań, które są niepoprawnie pozyskiwane, czy wręcz można się ich tylko domyślać. Moda na gotowce utrudnia udoskonalanie procesów: skoro już zainwestowało się spore sumy we wdrożenie UML, to niełatwo znaleźć czas na zastanowienie się, czy ten sposób modelowania jest zawsze stosowny; jeśli firma często pod naciskiem zewnętrznym weszła w świat PRINCE 2 trudno jej z niego zrezygnować w tych projektach, gdzie nie przynosi on korzyści. Słowem, aby móc naprawdę oceniać jakość procesów i usprawniać je, punktem wyjścia muszą być rzeczywiste cele biznesowe i realne wymagania, a nie narzędzia, które mogą (choć nie muszą) usprawnić realizację tych wymagań dotyczy to zarówno narzędzi wysokich, jak BEPL, jak i niskich, typu ogórek, selen czy rubin. Od samuraja do Deminga i Jurana Po co w ogóle bawić się w ulepszanie procesów? W porównaniu z ogórkiem, rubinem i selenem brzmi to mało konkretnie, budzi podejrzenia, że chodzi o zaspokojenie potrzeb jakichś leśnych dziadków (i leśnych babć, oczywiście, także), czy wręcz o modną poprawność polityczną a nie o budowanie wypasionych aplikacji, ani nie o biznesowy sukces i zysk. Jest jednak dokładnie odwrotnie to fiksacje technologiczno-narzędziowe z jednej strony, a z drugiej nawiedzony, niejasny język biznesu i marketingu, służą głównie zaspokajaniu potrzeb rozmaitych młodych wilczków (pojęcia młode wilki i leśni dziadkowie niekoniecznie odnoszą się do daty urodzenia raczej do sposobu pracy i systemu wartości), a mało biznesowym, finansowym korzyściom. Zapoznajmy się z klasycznym przykładem. Lata sześćdziesiąte ubiegłego wieku raczkujący japoński przemysł motoryzacyjny budzi śmiech i politowanie, podczas gdy amerykańskie krążowniki szos zachwycają i budzą podziw. W tym czasie dwaj słynni dzisiaj leśni dziadkowie, Deming i Juran (Juran rzeczywiście żył 104 lata, jak na leśnego dziadka przystało: ) głoszą swoje teorie jakości. Napakowane, pewne siebie amerykańskie firmy motoryzacyjne nie chcą ich słuchać, bo po co, skoro dysponują najnowszymi, motoryzacyjnymi odpowiednikami ogórka, selenu i rubinu? Procedury to dobre dla mięczaków! Deming i Juran pojechali więc do Japonii, gdzie gospodarze uważnie ich słuchali i posłuchali. W japońskich fabrykach zaczęto odchodzić od starego paradygmatu produkcji taśmowej, gdzie kontrola jakości skupiała się na końcu taśmy, a wykrywane na taśmie braki albo odrzucano, albo naprawiano wielokrotnie, gdyż wciąż powracały. Zamiast tego nowa kontrola jakości pojawiła się na każdym etapie produkcji, zaś wykrywane braki wykorzystywano przede wszystkim do tego, by wykryć ich przyczynę i trwale ją usunąć. Mówiąc językiem IT, zamiast obszernych i bardzo kosztownych testów systemowych i wdrożeniowych, zaczęto stosować mało sexy, ale znacznie skuteczniejsze testy wymagań, testy statyczne kodu źródłowego oraz testy jednostkowe, a wykryte defekty wykorzystywano przede wszystkim do tego, aby usuwać ich technologiczne lub procesowe przyczyny, a nie do nerwowego debugowania! Kiedyż, ach kiedyż IT dojrzeje do tego samego? 25

26 Co zrobili Japończycy z amerykańskim przemysłem motoryzacyjnym, dobrze wiemy: Japan surpassed the United States and became first in auto manufacturing ( To samo zrobią z innymi za najwyżej 10 lat firmy, których działy IT skoncentrują się na ulepszaniu procesów, zamiast na rubinach, ogórkach, selenie, oraz na wymienionych wcześniej wirtualizacji, oprogramowaniu klasy ERP Comarch, Java,.Net, HTML, C++, PHP, Delphi, Oracle, MySQL, Microsoft SQL Server, IBM DB2, Linux, Oracle, Unix, Microsoft, HP, Cisco, IBM, Vmware, Novell. Żeby ulepszać, trzeba mierzyć OK, więc ulepszajmy, skoro tyle na tym wygrali Japończycy. Agile! krzyczą jedni. Programowanie ekstremalne! krzyczą drudzy. TDD! SPICE! COBIT! CMMI! PMBOK! Jeśli wygrało Agile, nagle wszystko staje na głowie i zamiast robić oprogramowanie, wszyscy chodzą na treningi współpracy w grupie (firmy oferujące naukę miękkich umiejętności biznesowych zacierają ręce), kierownicy stają się nagle mistrzami młyna, wymagania zaległościami (backlog), a kolejne etapy projektu przebiegami. Wow, tylko co to zmienia? Nawet przyjąwszy, że agile jest cudowną bronią (Wunderwaffe, silver bullet), to co z procedurami czynności innych, niż samo pisanie oprogramowania tymi, z powodu których CMM stało się CMMI? Więc może CMMI, może COBIT? Świat się biurokratyzuje, jest smutniej, a efekt biznesowy jest mizerny nawet po osiągnięciu kosztem znacznych nakładów magicznego poziomu CMMI-5. Nie wystarczy wdrożyć procedury, których domaga się w zasadzie słusznie jakiś zewnętrzny standard. Trzeba koniecznie mierzyć, ile ich wdrożenie i przestrzeganie kosztuje, jakie przynosi efekty jeśli chodzi o jakość i o wydajność, i jaki jest ich ostateczny skutek biznesowy, mierzony obrotami, zyskiem, udziałem w rynku. Bez tego cała robota na nic: najwięcej na świecie firm IT mających poziom dojrzałości procesów CMMI-5 jest w Indiach, ale jakoś indyjski przemysł IT dotąd świata nie podbił. Trzeba więc mierzyć prawdziwe koszty zarówno zbudowania systemu IT, jak i jego poprawek, modyfikacji, kosztów utrzymania. Próbować choć oszacować efekty biznesowe wdrożenia systemu, i porównać z oszacowaniem biznesowych skutków zaniechania takiego wdrożenia. Działo finansowy każdej w miarę dobrze prowadzonej firmy ma dane i narzędzia, aby takie porównania zrobić, tylko musi otrzymać odpowiednie wytyczne od kierownictwa firmy, a dane z działu IT. Pomiary wydajności oraz kosztów w IT nie cieszą się dobrą sławą. Począwszy od doświadczenia z bystrymi inaczej firmami doradczymmi, usiłującymi mierzyć wydajność IT liczbą przyciśnięć przez pracowników klawiszy klawiatury na godzinę, a skończywszy na obawach przed rozbudowaną papierologią: pół dnia się pracuje, a drugie pół wpisuje w odpowiednie formularze, co w tym czasie się robiło. Nie! Tak rozumiane pomiary wydajności oczywiście nie działają. Trzeba to robić inaczej automatycznie. Wtedy dopiero, bez żmudnych, nudnych, dodatkowych nakładów, będzie można bez trudu dowiedzieć się, co ile czasu zajmuje w projektach IT, i ocenić efekty ulepszeń. Jak, w szczegółach, można to robić? Polecam artykuły: Między biurokracją a chaosem ( 26

27 Dramatyczny wzrost wydajności dzięki IT ( Jakość warunkiem wydajności ( Sukces w biznesie a udoskonalanie procesów Po co udoskonalać procesy IT? Po to, żeby docelowo zwiększyć, lub co najmniej utrzymać, zysk firmy. Docelowo, czyli: albo zwiększywszy stopę zysku przy tych samych co wcześniej obrotach; albo zwiększywszy obroty, na przykład wprowadziwszy nowe produkty / usługi; albo utrzymawszy / zwiększywszy udział w już istniejącym segmencie rynku. Zarówno dla firm IT, które tworzą oprogramowanie na zamówienie, jak i działów IT w firmach zajmujących się innym biznesem, kluczem do sukcesu są wymagania: żeby miały biznesowy sens, żeby były dobrze zdefiniowane i opisane, i wreszcie sprawnie możliwie szybko i niedrogo zrealizowane. Usprawnianie procesu pozyskiwania, konsolidacji, weryfikacji, zarządzania i realizacji wymagań, czyli po prostu całego procesu informatycznego (procesu tworzenia oprogramowania) jest dla firmy równie ważne (jeśli nie ważniejsze) jak lepiej znane, rozumiane i doceniane ulepszanie procesów zarządzania finansami, marketingiem, sprzedażą, procesem dostaw. Peopleware Proces biznesowy Proces IT: Pozyskiwanie wymagań, analiza biznesowa Analiza, zarządzanie, realizacja wymagań Marketing Sprzedaż Zarządzanie firmą Produkcja Dostawy Finanse udoskonalanie procesu IT Specyfikacja wymagań, projektowanie, programowanie, integracja, testowanie, wdrożenie, modyfikacje i utrzymanie, konfiguracja, kierowanie projektem Proces produkcji oprogramowania nie jest w przeciwieństwie do procesów produkcyjnych w tradycyjnym przemyśle wytwarzaniem wielu kopii tego samego produktu. Każdy projekt IT jest inny, realizuje odmienne wymagania. Dlatego, aby móc stwierdzić, na ile skuteczne są próby 27

28 udoskonalenia procesu IT, trzeba znaleźć miary, pozwalające porównywać ze sobą projekty i produkty IT. Taką miarą są wymagania, ich trudność i złożoność. W tym miejscu łączą się ze sobą trzy obszary, tradycyjnie taktowane jako odrębne: inżynieria wymagań i wykonywane na podstawie wymagań oszacowania pracochłonności; zarządzanie projektami informatycznymi; metody udoskonalania i oceny jakości (głównie wydajności) procesu informatycznego. To temat dobry do kolejnego artykułu, dość sformalizowanego: jak zastosować sieci bayesowskie oraz metodę Monte Carlo do projektowania oraz weryfikacji skuteczności ulepszeń procesu IT? 28

29 Jak wygrać w Monte Carlo? Narada w namiocie wodza Przed wojenną wyprawą, nad ogniskiem, w tipi wodza, zebrało się ich trzech. Wódz, najmłodszy ze wszystkich, zamierzał przedsięwziąć wyprawę przeciwko sąsiedniemu plemieniu, ale tak ważnej decyzji nie chciał, nie mógł podjąć sam. Może wyprawa się nie powiedzie? Może wystąpią nieoczekiwane przeszkody? Jakie mogą być ich skutki? Z tymi pytaniami zwrócił się do młodszego z szamanów. Starszy szaman milczał, jego wyblakłe, jasnoszare oczy patrzyły w przyszłość. Myśli nie tylko o tej wyprawie, ale o wielu następnych, przez dziesiątki lat: co zrobić, aby decyzje o ich podjęciu, lub zaniechaniu, on i jego następcy podejmowali coraz lepiej, coraz bardziej bezbłędnie? Takiej narady Indian sprzed dwustu-trzystu lat raczej nie zobaczymy dzisiaj. Wódz kierownik projektu rzadko rozmawia ze specjalistą od zarządzania ryzykiem (młodszy szaman), a prawie nigdy ze specjalistą od udoskonalania procesów i procedur (starszy szaman). A szkoda, bo mogliby się sobie nawzajem ogromnie przydać. Skąd wiadomo, czy to prawda? W nauce o zarządzaniu, o zapewnieniu jakości, a nawet o pewnych obszarach inżynierii oprogramowania, nietrudno spotkać tezy i teorie wątpliwe, kiepsko uzasadnione modne bzdury. Nie zawsze wprawdzie to, co modne, jest bzdurą, a to, a co niemodne mądrością, ale brakuje metod, pozwalających szybko i skutecznie odróżnić jedne od drugich. O tym, że jaka metoda, przez jakiś czas przynajmniej, staje się modna i panuje o niej przekonanie, że naprawdę sprawdza się ona w praktyce, decyduje szereg czynników, nie mających nic wspólnego z jej rzeczywistą wartością. Pomińmy mechanizmy, których opis należy do psychologii, dynamiki grupowej, socjologii, antropologii czy mechanizmów międzyludzkiej komunikacji. Jeśli chcemy a warto zmniejszyć ich wpływ, trzeba dać inne, lepsze metody w zamian. I z tym mamy kłopot. Kiedyś, w czasie młodzieńczego wakacyjnego wyjazdu, moja namiotowa partnerka wdała się przy kolacji w spór z moim kolegą na temat wyższości języków strukturalnych nad COBOL-em. Po dwóch godzinach strasznej pyskówki wspólny wyjazd stanął pod znakiem zapytania. Minęło niemal trzydzieści lat i oto kilka tygodni temu byłem świadkiem równie zażartej dyskusji o wyższości Mac a nad Windows i odwrotnie. Gdzie indziej, toczą się zajadłe i bezproduktywne dyskusje o wyższości agile nad metodami tradycyjnymi, PRINCE-2 nad PMI, IREB nad REQB, UML nad XML. Czyżby więc trzeba było uznać, jak miłośnicy post-modernizmu, że prawda jest wyłącznie subiektywna, i nie da się niczego rozstrzygnąć w żadnej kwestii, w tym w sprawie skutecznych i nieskutecznych metod produkcji oprogramowania? Nie jest tak źle, choć w chwilach pesymizmu, kiedy wygadani zwolennicy jakiejś modnej bzdury zawzięcie ujadają na prestiżowych konferencjach (NLP! Mapowanie umysłu! Cucumber! Agile scrum! Usługi w chmurze! Metoda delficka!), można się tego obawiać. Nie twierdzę wprawdzie, że mając dobrze udowodnioną wiedzę, co działa, a co nie działa; co jest skuteczne, a co nieskuteczne, przekonamy innych: nie, ludzkie zapotrzebowanie na wiarę w modne i hałaśliwe bzdury jest 29

30 niewyczerpane. Ale i tak tę wiedzę możemy dobrze wykorzystać w praktyce projektowej, w organizacjach, w działalności biznesowej. Czy łysi są mądrzejsi od kudłatych? Jak można odpowiedzieć na to pytanie? Kusi tak zwana logiczna (czytaj: nielogiczna) dyskusja, odwoływanie się do anegdotycznych przykładów i fałszywych analogii zainteresowanym, polecam lekturę Krótkiego kursu samoobrony intelektualnej Normanda Baillargeona. Mając choć odrobinę intelektualnej uczciwości, należy jednak przeprowadzić badanie, spełniające wymogi naukowe. Wybiera się połowę osób łysych, połowę kudłatych, mierzy im iloraz inteligencji oraz poziom wiedzy i proszę bardzo teza o wielkiej przewadze łysych udowodniona. Jakim cudem? Drobne fałszerstwo: łysych wybieraliśmy spomiędzy pracowników wyższej uczelni, a kudłatych spośród bezrobotnych w PGR na odludziu. Nie, nie, nie: żeby wynik badania był miarodajny, badane grupy muszą być choć trochę równoważne (więcej na ten temat w artykule Inżynieria jakości nauka czy szarlataneria?, adres Ta prosta, oczywista zasada nigdy, ale to NIGDY nie jest przestrzegana, kiedy porównuje się ze sobą różne metody, języki programowania, technologie, narzędzia, sposoby modelowania, podejścia do zarządzania, struktury organizacyjne, procedury. Czy razi kogoś uzasadnienie typu ta metoda jest lepsza, przecież projekt zakończył się pełnym sukcesem? Albo inne: musimy stosować tę technologię, używają ją wszyscy i nie możemy zostać z tyłu. Albo X jest znanym na świecie specjalistą i twierdzi, że najlepszym sposobem na realizację zachwycających projektów jest Y. Wreszcie, najczęściej, antagonistów próbuje się powalić erystyką, czyli sztuką prowadzenia sporów: Każdy rozumie, że przecież bla bla ludzka kreatywność bla bla projektowanie obiektowe bla bla TQM proaktywnie BDD bla bla. Tymczasem, zamiast takich zupełnie gołosłownych twierdzeń, przy których nawet populistyczne łgarstwa niektórych polityków wydają się względnie dobrze uzasadnione, należy zrobić co? No, co? Oczywiście, porównać ze sobą dwa, a najlepiej więcej, projektów, równoważnych pod każdym względem, różniących się tylko metodą, której skuteczność chce się zbadać. Tylko to jest najzupełniej nierealne, z powodów finansowych oczywiście: żeby odkryć, która metoda jest lepsza, trzeba początkowo co najmniej podwoić koszty. Żeby sobie móc na to pozwolić, trzeba by znaleźć ekscentrycznego miliardera-przedsiębiorcę, tak jak bohater książki Toma DeMarco Zdążyć przed terminem. Czyli już cała nadzieja na nic? Nadzieja jest w matematyce Wyobraź sobie, Czytelniku, że Twój dział personalny zawiódł haniebnie i zatrudnił człowieka, który, zamiast dostosować się do kultury Twojej organizacji i zaangażować z całego serca w walkę o wpływy, robienie dobrego wrażenia i podgryzanie rywali, jest autentycznie zainteresowany usprawnieniem procesów po to, aby osiągnąć biznesowe korzyści! Mówi, że inwestycja w, dajmy na to, lepsze praktyki inżynierii wymagań, zwróci się w krótkim czasie, ba przyniesie znaczne zyski. Twój CIO stuka się w głowę ( jaka inżynieria wymagań? Człowieku, ważna jest zapora ogniowa, przepustowość sieci oraz architektura baz danych! ), Twój CFO mówi, że nie da się uzyskać potrzebnych danych finansowych, a Twój CMO trzyma się za serce i jęczy coś na temat CRM, CEM oraz BPML. Tego nowego to trzeba jak najszybciej zwolnić dyscyplinarnie niestety, jeden z ważnych członków 30

31 zarządu, znajdujący się na liście 100 najbogatszych Polaków, dał się zbajerować tym biznesowym korzyściom i mówi, żeby dać młodemu spróbować. Młody wziął się do pracy. Najpierw zbudował sieć bayesowską, pokazującą, od czego i w jakim stopniu zależy stopa zysku firmy. Taka sieć mogła, przykładowo, wyglądać następująco: Na rysunku (tak, to jest graf - diagram sieci bayesowskiej) interesujący wynik STOPA ZYSKU przedstawiony jest jako zależny (strzałki pokazują tę zależność) od szeregu czynników. Czynniki przedstawione na niebiesko marketing, logistyka itd. te nas nie interesują (co nie znaczy, że są nieważne, tylko w tym momencie nie ich udoskonalaniem się zajmujemy). Poza tym, stopa zysku zależy od KOSZTÓW UZYSKANIA oraz KOSZTÓW UTRZYMANIA produktu (na przykład, produktu informatycznego). Te zaś zależą od CZYNNIKÓW JAKOŚCI to zielone pola na rysunku, wśród nich zarządzanie, inżynieria wymagań, i inne. Strzałki zależności, mają swój atrybut, swego rodzaju siłę zależności, mówiącą, jak mocno dany czynnik wpływa na końcowy efekt. Suma wszystkich zależności powinna wynosić 100%, w przeciwnym razie oznacza to, że jakiś ważny czynnik został pominięty. Skąd możemy wiedzieć, jaka jest siła tych zależności? Jak bardzo, powiedzmy, jakość inżynierii wymagań wpływa, w porównaniu z innymi czynnikami, na koszty utrzymania i wytworzenia? Czy to 5%, czy raczej 40%? 31

32 To można próbować oszacować, na pewnym poziomie pewności, na podstawie: (1) opinii eksperckich, (2) danych historycznych z kolejnych projektów oraz najlepsze oszacowanie na podstawie (3) danych z całej branży o ile są dostępne: Przyjmując, że nasze dane są prawdziwe na początku, to jest ryzykowne założenie! możemy teraz dokonywać na papierze (ściślej, na modelu sieci bayesowskiej) eksperymentów: jeśli usprawnimy na przykład inżynierię wymagań o 50% (co to znaczy? możliwe są różne miary, na przykład liczba błędnych lub zapomnianych wymagań, jaką inżynieria wymagań wypuszcza), to o ile zmaleją koszty produktu, o ile wzrośnie zysk? Ponieważ jednak nie wiemy, ani tego, na ile proponowane przez młodego pracownika zmiany rzeczywiście zaowocują mniejszą liczbą błędów w wymaganiach, ani tego, jakie będą koszty ich wdrożenia, ani tego, jak silna jest zależność między jakością inżynierii wymagań, a kosztami produktu, ani nawet tego, na ile koszty produktu wpływają na zyski to co mamy robić? Sądząc z poziomu płac w Polsce, górny kwartyl wynagrodzenia dla kierowników marketingu to złotych, a dla kierowników działu IT złotych. Odpowiednio, 25% dyrektorów działu IT zarabia ponad złotych dokładnie tyle samo, ile 25% dyrektorów działu marketingu. Czyli rynek szacuje poprzez pensje znaczenie tych działów jako podobne. Niemniej, znaczny poziom niepewności pozostaje, i wszelkie wyliczenia algorytmiczne na podstawie niepewnych danych nie mają sensu. Z pomocą przychodzi metoda Monte Carlo. Jedna z jej definicja brzmi: metoda Monte Carlo jest stosowana do modelowania matematycznego procesów zbyt złożonych, aby można było przewidzieć 32