Raport Inżynierii Wymagań 2014
Transkrypt
Raport Inżynierii Wymagań 2014
WWW.COMPUTERWORLD.PL INŻYNIERIA WYMAGAŃ • Bez eksperymentowania str. 2 • Analiza biznesowa ulepsza procesy IT str. 4 • Przepis na sukces w projektach IT str. 6 • Projekty z automatu str. 8 • Procedury chronią przed skutkami błędów str. 10 • Projekt bez zbędnych opóźnień str. 12 • Dramatyczny wzrost wydajności dzięki IT str. 14 Z A R ZDOWIEDZ Ą D Z A N I E SIĘ I N ŻWIĘCEJ Y N I E R I A WEŹ W Y MUDZIAŁ AG A Ń W KONFERENCJI! Bez eksperymentowania Poświęcamy dużo czasu na wdrażanie nowych metod, narzędzi i sposobów zarządzania, ale robimy to na oślep. Należy sięgnąć po metody szacowania opłacalności i skuteczności działań. bzdury zawzięcie ujadają na prestiżowych konferencjach, można się tego obawiać. Nie twierdzę, że mając dobrze udowodnioną wiedzę o tym, co działa, co jest skuteczne, przekonamy innych. Nie, ludzkie zapotrzebowanie na wiarę w modne bzdury jest niewyczerpane. Ale to możemy dobrze wykorzystać w praktyce projektowej, w organizacjach, w działalności biznesowej. Czy łysi są mądrzejsi od kudłatych? BOGDAN BEREZA P rzed wojenną wyprawą, nad ogniskiem, w tipi wodza zebrało się ich trzech. Wódz 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 oczy patrzyły w przyszłość. Myślał nie tylko o tej wyprawie, ale i o następnych: co zrobić, aby decyzje o ich podjęciu 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 przydać. Skąd wiadomo, czy to prawda? W nauce o zarządzaniu, o zapewnieniu jakości, a nawet w pewnych obszarach inżynierii oprogramowania nietrudno spotkać tezy i teorie wątpliwe – modne bzdury. Nie zawsze to, co modne, jest bzdurą, a to, co niemodne – mądrością, ale brakuje metod pozwalających szybko i skutecznie odróżnić jedno od drugiego. 26 2 COMPUTERWORLD 5 marca 2013 O tym, że metoda staje się modna, decyduje wiele 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 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 Jak można odpowiedzieć na to pytanie? Kusi tzw. „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 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 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, grupy muszą być choć trochę równoważne. Ta zasada 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ę sukcesem”. Albo inne: „musimy stosować tę technologię, używają jej wszyscy”. Zamiast gołosłownych twierdzeń należy zrobić… co? 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 nierealne z powodów finansowych. Żeby sobie na to pozwolić, trzeba znaleźć ekscentrycznego miliardera-przedsiębiorcę, tak jak bohater książki Toma DeMarco „Zdążyć przed terminem”. Każdy język programowania, a nawet każdy arkusz kalkulacyjny zapewni wsparcie narzęNadzieja jest w matematyce dziowe metody Monte Carlo. Wyobraź sobie, Czytelniku, że Twój dział personiemal 30 lat i oto kilka tygodni temu byłem świadkiem równie zażartej dyskusji o wyższości Mac nad Windows i odwrotnie. Gdzie indziej jeszcze 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 trzeba było uznać, że prawda jest subiektywna i nie da się niczego rozstrzygnąć w żadnej kwestii, w tym w sprawie skuteczności metod produkcji oprogramowania? Nie jest tak źle, choć w chwilach pesymizmu, kiedy wygadani zwolennicy jakiejś modnej nalny 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, aby osiągnąć biznesowe korzyści! Mówi, że inwestycja w lepsze praktyki inżynierii wymagań zwróci się w krótkim czasie, ba – przyniesie znaczne zyski. Twój CIO stuka się w głowę, 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 SPECJALNE zarządzanIe I n Ż Y n I e rUSŁUGI I a WYDANIE W Y M aG a Ń temat CRM, CEM, BPML. Tego nowego to trzeba jak najszybciej zwolnić dyscyplinarnie… niestety, jeden z ważnych członków zarządu, znajdujący się na liście 100 najbogatszych Polaków, dał się zbajerować 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 wyglądać następująco: Na rysunku 1 (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ą. Poza tym stopa zysku zależy od KOSZTÓW UZYSKANIA oraz KOSZTÓW UTRZYMANIA produktu (np. produktu IT). 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 (zob. rys. 2). 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 jakość inżynierii wymagań wpływa na koszty utrzymania i wytworzenia? Czy to 5%, czy raczej 40%? 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. Przyjmując, że dane są prawdziwe, możemy dokonywać na papierze eksperymentów: jeśli usprawnimy inżynierię wymagań o 50%, to o ile zmaleją koszty produktu, o ile wzrośnie zysk? Ponieważ nie wiemy, na ile proponowane przez młodego pracownika zmiany zaowocują mniejszą liczbą błędów w wymaganiach ani jakie będą koszty ich wdrożenia, ani 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ć? rysunek 2: określenie siły oddziaływania poszczególnych czynników na końcowy efekt stopy zysku Sądząc z poziomu płac w Polsce, górny kwartyl wynagrodzenia dla kierowników marketingu to 11 tys. zł, a dla kierowników działu IT 12 tys. Odpowiednio, 25% dyrektorów działu IT zarabia ponad 23 tys. zł – tyle, ile 25% dyrektorów działu marketingu. Czyli rynek szacuje znaczenie tych działów jako podobne. Znaczny poziom niepewności pozostaje i wyliczenia algorytmiczne na podstawie niepewnych danych nie mają sensu. Z pomocą przychodzi metoda Monte Carlo. Jedna definicji brzmi: „metoda Monte Carlo jest stosowana do modelowania matematycznego procesów zbyt złożonych, aby można było przewidzieć ich wyniki za pomocą podejścia analitycznego. Istotną rolę odgrywa w niej losowanie wielkości charakteryzujących proces”. Procesy zbyt złożone – to dotyczy procesów wytwarzania oprogramowania. Nie da się wziąć pod uwagę wszystkich czynników wywierających wpływ na ich koszty i na ich skuteczność. Można zanalizować rozkład wyników dla danych generowanych losowo. Ręcznie byłoby to beznadziejne zadanie, ale od czego mamy komputery. Wrzuciwszy diagram sieci Bayesa do odpowiedniego narzędzia, możemy na nim rysunek 1: diagram sieci bayesowskiej pokazuje, od czego i w jakim stopniu zależy stopa zysku firmy wykonywać eksperymenty za pomocą wartości losowo wygenerowanych wokół oczekiwanej średniej. Wsparcie narzędziowe metody Monte Carlo da nam każdy język programowania, a nawet każdy arkusz kalkulacyjny. I co dalej? Co dalej i kogo w czasach kryzysu stać na takie eksperymenty? Przewidując to pytanie, z wielką obawą powołuję się na opracowanie z 2009 r., opublikowane przez SEI (Software Engineering Institute), dotyczące zastosowania tej metody w dziale badawczo-rozwojowym firmy Ericsson w Holandii: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1273&context=sei. To nie jest dobra rekomendacja dla prezesa kilkudziesięcioosobowej firmy informatycznej… Przypomnijmy sobie anegdotę o drwalu, co marnie rąbał drzewa, bo tak był zajęty, że nie miał czasu naostrzyć siekiery, czy o budowlańcu, co biegał z pustymi taczkami... Na co dzień poświęcamy dużo czasu na projektowanie i realizację zmian procedur i procesów, na wdrażanie nowych metod i narzędzi, nowych sposobów zarządzania, ale robimy to na oślep, kierując się intuicją i nie prowadząc późniejszych oszacowań opłacalności ani skuteczności tych eksperymentów. W ten sposób mnóstwo pieniędzy się marnuje, wręcz wyrzuca w błoto – choć część ich można przeznaczyć na zastosowanie opisanych w tym artykule metod, które są najzwyczajniej praktyczne, konkretne i opłacalne. A kryzys to najlepszy czas na takie sprawy! (http://gazeta. testerzy.org.pl/nr/2013-02-17/kryzys.html). Poza tym można spróbować przełamać stereotypy i uprzedzenia i poszukać współpracy z uczelniami. Przykłady, że taka współpraca jest obustronnie korzystna i pozwala nawet niewielkim firmom niskim kosztem osiągnąć udoskonalenia, będą omawiane na spotkaniu „Praktyczne doświadczenia współpracy między IT a wyższymi uczelniami w szwedzkim i polskim przemyśle IT”, 18 kwietnia br., podczas konferencji „Dobre wymagania” (http://breq2013.wymagania. org.pl/program/panel.html). Warto się przyjrzeć doświadczeniom z tej dziedziny. computerworld 5 marca 2013 27 3 z a r zDOWIEDZ ą d z a n i e SIĘ i n ŻWIĘCEJ Y n i e r i a WEŹ W Y MUDZIAŁ aG a Ń W KONFERENCJI! analiza biznesowa ulepsza procesy iT Usprawnianie pozyskiwania, konsolidacji, weryfikacji, zarządzania i realizacji wymagań IT jest równie ważne jak ulepszanie zarządzania finansami, marketingiem, sprzedażą i dostawami. 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ą. Moda na gotowce: BePL, UML, iTiL, PrinCe 2 Nie mam nic przeciwko tym językom (BEPL i UML) ani standardom (ITIL, PRINCE 2). To dobre narzędzia pracy. Niestety, nie zastąpią myślenia – a takie próby 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 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 weszła w świat PRINCE 2, trudno z niego zrezygnować w projektach, w których nie przynosi korzyści. 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ą. BOGdan Bereza W „Przewodniku po rynku szkoleń IT” (Computerworld, wrzesień 2012) możemy przeczytać, jakie wymagania pojawiają się najczęściej w ofertach pracy. Widzimy tam 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… Brakuje określeń: inżynieria oprogramowania, inżynieria wymagań, zapewnienie jakości, zarządzanie projektami informatycznymi, testowanie, projektowanie systemów, udoskonalanie procesów. Jak usprawniać procesy, i tworzyć choćby pojedyncze, ale dobre rozwiązania IT, skoro nie 14 4 computerworld 5 lutego 2013 zwraca się uwagi, jaki jest cel i sens biznesowy rozwiązania, ani jaka jest skuteczność i opłacalność metod IT, lecz koncentruje się na detalicznej, przemijającej znajomości technologii? Struktura rynku szkoleń IT jest odwzorowaniem tego stanu rzeczy. Teraz dobrze sprzedają się kursy dla użytkowników modnego narzędzia Cucumber (jedno z narzędzi do wykonywania tzw. testowania za pomocą słów-kluczy), kursy języka programowania Ruby (jeden z dziesiątków obiektowych języków programowania) oraz kursy Selenium – jednego z wielu narzędzi do testowania aplikacji webowych. Spróbujcie jednak sprzedać wiedzę pozwalającą 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, nie znając inżynierii oprogramowania, realizujemy projekty IT ad hoc, kierując się zawodnym instynktem lub opierając się 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, np. BEPL, jak i niskich, typu ogórek, selen czy rubin. Od samuraja do deminga i Jurana Po co 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 niepotrzebnych ambicji i potrzeb leśnych dziadków, czy o sprostanie wymogom modnej poprawności politycznej, a nie o budowanie aplikacji, o biznesowy sukces i zysk. Jest odwrotnie. To fiksacje technologiczno-narzędziowe z jednej strony, a z drugiej strony nawiedzony, niejasny język biznesu i marketingu służą głównie zaspokajaniu potrzeb rozmaitych „młodych wilczków” 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 60. XX wieku. Raczkujący, japoński przemysł motoryzacyjny rodzi śmiech i politowanie, podczas gdy amerykańskie krążowniki SPECJALNE zarządzanie i n Ż Y n i e rUSŁUGI i a WYDANIE W Y M aG a Ń szos zachwycają i budzą podziw. W tym czasie dwaj leśni dziadkowie, Deming i Juran (Juran żył 104 lata, jak na leśnego dziadka przystało) głoszą swoje teorie jakości. 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 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 braki albo odrzucano, albo naprawiano… wielokrotnie, gdyż wciąż powracały. Nowa kontrola jakości pojawiła się na każdym etapie produkcji, zaś wykrywane braki wykorzystywano, by wykryć ich przyczynę i trwale ją usunąć. Mówiąc językiem IT, zamiast obszernych i kosztownych testów systemowych i wdrożeniowych, zaczęto stosować znacznie skuteczniejsze testy wymagań, testy statyczne kodu źródłowego oraz testy jednostkowe, a wykryte defekty wykorzystywano do tego, aby usuwać ich technologiczne lub procesowe przyczyny. Kiedy IT dojrzeje do tego? Co zrobili Japończycy z amerykańskim przemysłem motoryzacyjnym, dobrze wiemy: „1980 – Japan surpassed the United States and became first in auto manufacturing” (http://en.wikipedia. org/wiki/Automotive_industry_in_Japan). 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 „wirtualizacji, oprogramowaniu klasy ERP Comarch, Java, .Net, HTML, C++, PHP, Delphi, Oracle, MySQL, Microsoft SQL Server, IBM DB2, Linux, Oracle, Unix itd. Żeby ulepszać, trzeba mierzyć Dobrze, 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, kierownicy stają się mistrzami młyna, wymagania – zaległościami, a kolejne etapy projektu – przebiegami. 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 których powodu CMM stało się CMMI? 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”. Więc może CMMI, może COBIT? Świat się biurokratyzuje, jest smutniej, a efekt biznesowy mizerny. Nawet po osiągnięciu kosztem znacznych nakładów magicznego poziomu CMMI-5. Nie wystarczy wdrożyć procedury, których domaga się zewnętrzny standard. Trzeba 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ł informatyczny dotąd świata nie podbił. Trzeba mierzyć prawdziwe koszty zbudowania systemu IT i jego poprawek, modyfikacji, utrzymania. Próbować oszacować efekty biznesowe wdrożenia systemu i porównać je z oszacowaniem biznesowych skutków zaniechania wdrożenia. Dział finansowy każdej, dobrze prowadzonej firmy ma dane i narzędzia, aby te porównania zrobić. Musi tylko otrzymać wytyczne od kierownictwa firmy, a dane – z działu IT. Pomiary wydajności i kosztów w IT nie cieszą się dobrą sławą. Począwszy od doświadczenia z „bystrymi inaczej” firmami doradczymi, 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 formularze, co w tym czasie się robiło. Nie! Tak rozumiane „pomiary wydajności” 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 można to robić? Polecam artykuły: • „Między biurokracją a chaosem” (http:// www.computerworld.pl/artykuly/321693_2/ Miedzy.biurokracja.a.chaosem.html) • „Dramatyczny wzrost wydajności dzięki IT” (http://www.computerworld.pl/artykuly/361381/Dramatyczny.wzrost.wydajnosci. dzieki.IT.html) • „Jakość warunkiem wydajności” (http://victo.eu/PL/Wiedza/jakosc_warunkiem.pdf). 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, np. wprowadziwszy nowe produkty / usługi; • albo utrzymawszy / zwiększywszy udział w już istniejącym segmencie rynku. Dla firm IT, które tworzą oprogramowanie na zamówienie, 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 z realizowane. Usprawnianie procesu pozyskiwania, konsolidacji, weryfikacji, zarządzania i realizacji wymagań, czyli całego procesu IT, jest dla firmy tak ważne jak ulepszanie procesów zarządzania finansami, marketingiem, sprzedażą, procesem dostaw. 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 stwierdzić, na ile skuteczne są próby 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ę trzy obszary, tradycyjnie taktowane jako odrębne: • inżynieria wymagań i wykonywane na podstawie wymagań oszacowania pracochłonności; • zarządzanie projektami IT; • metody udoskonalania i oceny jakości procesu IT. computerworld 5 lutego 2013 15 5 i n ŻWIĘCEJ Y n i e r i a WEŹ W Y MUDZIAŁ aG a Ń W KONFERENCJI! z a r zDOWIEDZ ą d z a n i e SIĘ Przepis na sukces w projektach iT Inżynieria wymagań porządkuje etapy pomiędzy potrzebą biznesową a wdrożeniem. Wprowadza procesy i procedury, bez których projekt IT nie może zakończyć się powodzeniem. Siedem żelaznych reguł udanego projektu Wiedzieć, co jest celem projektu. Narzędzia: współpraca z klientem, analiza biznesowa, inżynieria wymagań. W trakcie projektu umieć skutecznie modyfikować jego cel. Narzędzia: prototypowanie, zarządzanie wymaganiami, metodyki zwinne. Trafnie określić zadania do wykonania i oszacować pracochłonność projektu. Narzędzia: analiza wymagań. Skutecznie nadzorować przebieg projektu i stan produktu. Narzędzia: śledzenie realizacji wymagań, testowanie wymagań od samego początku. Automatyzować czynności administracyjne. Narzędzia: wersjonowanie, zarządzanie zmianami, testowanie podstawowe, śledzenie wymagań. Strategia: jakość osiąga się nie kosztem wydajności, przeciwnie: dążenie do jakości (unikanie błędów) zwiększa wydajność. Nacisk nie na znajdowanie błędów, lecz na zapobieganie błędom - w tym przez poprawnie określone wymagania. BoGdan Bereza I nżynieria wymagań to określenie, które odnosi się nie tylko do projektów IT. Choć samo pojęcie inżynierii wymagań jest stosunkowo nowe, to kłopoty, jakie powoduje lekkomyślne traktowanie wymagań, czyli niestosowanie zasad inżynierii wymagań, znane są od wieków. Toną statki i projekty 10 sierpnia 1628 r. przewrócił się i zatonął, kilkanaście minut po odbiciu od nadbrzeża, nowo zbudowany okręt flagowy marynarki szwedzkiej „Wasa”. Przyczyny? Okręt z powodu ambicji króla był potężniejszy niż inne ówczesne jednostki – dwupokładowy. Takie było życzenie króla, któremu nikt nie ośmielił się przeciwstawić. Tu od razu nasuwa się całkiem współczesna wątpliwość, czy na pewno klient ma zawsze rację? Dwupokładowy okręt miał 12 6 computerworld 15 stycznia 2013 znacznie wyżej środek ciężkości i okazał się przez to 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 m.in. zajmuje się takimi ich atrybutami, jak wykonalność (feasibility), oraz projektowanie: nie umiano wówczas precyzyjnie wyliczyć stabilności statku na podstawie informacji o jego wymiarach i rozkładzie ciężaru. Zastosowano metodę, którą można nazwać megaagile: po prostu pracowici cieśle-programiści dobudowali jeszcze jeden pokład, zgodnie z życzeniem zleceniodawcy-króla! Tak popełniono kardynalny błąd już w początkowej fazie projektu. Wynika on z powszechnego i wtedy, blisko 400 lat temu, i dzisiaj podejścia: „po co marnować czas na jakiś SRS, bierzmy się do roboty”. Kiedy projekt popada w kłopoty – albo wręcz, jak „Wasa”, kończy się spektakularną klęską – zwykle przyczyn szuka się wszędzie, tylko nie w braku inżynierii wymagań. Cichutko, bo wtedy jeszcze nie zniesiono kary śmierci, obwiniano króla-zleceniodawcę i jego idiotyczne pomysły. Ktoś powie: z takich pozornie idiotycznych pomysłów biorą się wielkie sukcesy biznesowe, zgodnie z zasadami strategii błękitnego oceanu. Owszem, tylko trzeba umieć sobie z nimi radzić. Na przykład stosując inżynierię wymagań. Obwiniano też głównego konstruktora, Henrika Hybertssona. Gdyby statek zatonął pół roku później, Hybertsson zbierałby pochwały. Ocena kierowników projektów zawsze jest przeraźliwie krótkowzroczna, oparta na pozornym sukcesie albo na równie pozornej, byle spektakularnej, klęsce. Obwiniano też procedury testowania. Ale testy przeprowadzono. Stabilność kadłuba sprawdzano w ten sposób, że gromada kilkuset robotników stoczni biegała po pokładzie z jednej strony na drugą, próbując rozkołysać kadłub. W przypadku „Wasy” testy przerwano, gdyż kadłub zaczął się kołysać zbyt niebezpiecznie, grożąc wywrotką. Króla zaś nie zawiadomiono, bo… obawiano się jego gniewu. No i oskarżano Polaków, bo to z nami głównie wojował król Gustaw II Adolf. Polski sabotaż był więc wyjaśnieniem. Król, nakazując śledztwo, wskazał jako przyczynę awarii „głupotę i niedbalstwo”. Bingo, proszę króla! Budując wielkie, skomplikowane rzeczy, ludzie z definicji są głupi, bo SPECJALNE i n Ż Y n i e rUSŁUGI i a WYDANIE W Y M aG a Ń zarządzanie rozum niewsparty narzędziami nie radzi sobie z nimi, a niedbalstwo jest 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 przodkowie nie uciekali, zajęci regułami i rytuałami. Wprowadzamy procesy i procedury, które tę staranność gwarantują. Albo ich nie wprowadzamy bądź nie przestrzegamy, wtedy tonie „Wasa” albo projekt IT kończy się klęską. Można powiedzieć, że pod pewnymi względami inżynieria wymagań jest bardzo stara. Programistyczny pięściak Pięściak albo inaczej tłuk pięściowy wykonywano z twardego krzemienia. To oznacza, że nasz jaskiniowy prapraprzodek w swoim interesie musiał 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 40. i 50. ubiegłego wieku nauczyliśmy się wytwarzać pięściaki z miękkiego krzemu zamiast krzemienia. Sam krzem, pierwiastek, nie jest specjalnie użyteczny, ale w układach scalonych i budowanych z nich komputerach – jak najbardziej. Komputery umożliwiają wykonywanie oprogramowania, które można modyfikować i przerabiać o wiele łatwiej i taniej niż krzemienne pięściaki czy budowane z drewna żaglowce. Oferowana przez oprogramowanie łatwość robienia nowych rzeczy i ich zmieniania jest podłożem olbrzymiego skoku cywilizacyjnego, jaki zanotowaliśmy właśnie od lat 50. zeszłego wieku. Ta łatwość okazywała się niebezpieczna. Względnie nieskomplikowane algorytmy programów w latach 40. i 50., tworzone od początku do końca przez ludzi wybitnych, nawet laureatów nagrody Nobla, 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 matematycznych algorytmów. Dlatego od podejścia charakteryzującego lata 50. i 60. – od pojmowania tworzenia programów jako rzemiosła artystycznego, IT przeszło do nowej fazy – inżynierii oprogramowania. Inżynieria wymagań jest jednym ze składników inżynierii oprogramowania. W inżynierii wymagań widać odmienność między światem akademickim a realiami przemysłu IT. W świecie akademickim określenie „inżynieria wymagań” jest powszechnie znane. Najpoważniejsze czasopismo w tej dziedzinie – „Requirements Engineering Journal” – wydawane jest od 1996 r., a więc już od 17 lat. Jeszcze starsza jest konferencja „IEEE International Requirements Engineering Conference”, która odbędzie się w tym roku już po raz dwudziesty pierwszy. Historia i materiały ze wszystkich wcześniejszych konferencji, począwszy od roku 1993, znajdują się na portalu requirements-engineering.org. Między analizą biznesową a oprogramowaniem Ciekawe porównanie – największa w Europie konferencja na temat testowania oprogramowania, EuroSTAR, też po raz pierwszy odbyła się w 1993 r. w Londynie. W tym czasie testowanie stało się i modą, i biznesem. A przecież kluczowe znaczenie inżynierii wymagań dla biznesu i dla IT wydaje się nie budzić najmniejszych wątpliwości. Przeszkoliwszy wiele tysięcy osób w zakresie testowania, w tym na niezmiernie popularny certyfikat ISTQB, autor 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ń. Zatem wiedza na ten temat istnieje w przemyśle IT, ale nie przekłada się na żadne działania. Czemu? Wyjaśnienie ma charakter bardziej antropologiczny i socjologiczny niż informatyczny. 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; Koszty Korzyść usunięcia błędu w różnych fazach projektu analiza budowa wdrożenie utrzymanie z inwestycji w jakość w różnych fazach projektu analiza budowa wdrożenie utrzymanie Początki inżynierii wymagań W drugiej połowie lat 60. coraz trudniej było znaleźć wystarczającą liczbę wysoko kwalifikowanych programistów, a projekty informatyczne przekraczały i budżet, i harmonogram. Zaczęto mówić o kryzysie oprogramowania i poszukiwać środków zaradczych – początkowo głównie w sferach języków programowania oraz jego architektury. Wyrazem tych tendencji była Konferencja Inżynierii Oprogramowania NATO, która odbyła się w 1968 r. To wtedy, wedle źródeł, po raz pierwszy oficjalnie użyto określenia „inżynieria oprogramowania”. W druku ten termin po raz pierwszy pojawił się prawdopodobnie w 1979 r., w tzw. „Raporcie TRW”. Nie było jednak szerzej znane ani stosowane aż do lat 90., kiedy ukazało się klasyczne opracowanie IEEE CS pt. „System and Software Requirements Engineering”. słusznie zresztą, bo trudno oczekiwać, że analizą biznesową będą się zajmować osoby z niewielkim doświadczeniem, bez całościowej wizji działania firmy. Znów posłużę się ryzykowną nazwą, dolne rejony inżynierii wymagań zadomowiły się w świecie 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ą kierownicy projektów, dbający, żeby produkt końcowy jakoś dał się wcisnąć odbiorcom; inżynierami wymagań są też członkowie zespołów agile, zwłaszcza „mistrzowie młyna”. Co dalej, czyli świt inżynierii Szkolenia przygotowujące do certyfikacji IREB CPRE (Certified Professional in Requirements Engineering) będą za dwa, trzy lata szły jak świeże bułeczki. Na wyższych piętrach spopularyzują się certyfikaty IIBA oraz QAMP. W tej sytuacji wzrośnie rola polskiego oddziału IREB (www.ireb.org.pl). W Polsce okrzepnie Stowarzyszenie Inżynierii Wymagań (www.wymagania.org.pl). Przyczynić się do tego może konferencja „Dobre Wymagania 2013” (breq2013.wymagania.org.pl), która odbędzie się 18–19 kwietnia. Opisywane w „Computerworld” wielokrotnie ADP (Automated Defect Prevention). jako metoda zarządzania projektami IT, stanie się czymś powszechnie stosowanym, 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 metodyka za pięć czy dziesięć lat może stać się powszechna i usunąć 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ń. computerworld 15 stycznia 2013 13 7 i n ŻWIĘCEJ Y n i e r i a WEŹ W Y MUDZIAŁ aG a Ń W KONFERENCJI! z a r zDOWIEDZ ą d z a n i e SIĘ BoGdan Bereza W świetnej książce Toma DeMarco „Zdążyć przed terminem” akcję otwiera scena, gdy 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, czego będzie dotyczyć szkolenie. Jak dobierać uczestników projektu? A może jak ich motywować? Jak się porozumiewać, rozwiązywać konflikty? Nic podobnego! Prowadzący wyjaśnia, że szkolenie ma nauczyć procedur, będzie zawierać omówienie dokumentacji i procesów. 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”. istnieje szereg 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. Projekty z automatu Wystarczy jasno sformułować wymagania, by zarządzanie projektami stało się prostsze. Zawiłe scenariusze różnych metodyk można wtedy zastąpić zautomatyzowanymi działaniami. 20 8 computerworld 7 grudnia 2012 Jest w tym wiele prawdy, ale, moim zdaniem, tylko pod warunkiem, że te drobne szczegóły administracyjne są pod kontrolą. W przeciwnym razie nawet najbardziej 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’a Jobsa – wystarczy sprawny organizator. Ja, robot: zalety automatycznego nadzoru Zalety automatyzacji rutynowych czynności administracyjnych, żmudnych i obarczonych ryzykiem pomyłki wynikającej z ludzkiego zmęczenia, 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, bystrych inaczej, którzy boją się, że automatyzacja rutynowych czynności pozbawi ich pracy. SPECJALNE i n Ż Y n i e rUSŁUGI i a WYDANIE W Y M aG a Ń zarządzanie Wystarczy wielka tablica świetlna Jak więc konkretnie, w praktyce, można zrealizować automatyczne zarządzanie projektem IT? Wystarczy wielka tablica świetlna, na której każda żarówka odpowiada jednemu wymaganiu, które tworzony system ma realizować. Na początku projektu żaróweczki świecą się głównie na czerwono – nic nie jest jeszcze gotowe. Rzut oka na taką tablicę zastępuje kunsztowne wyliczenia dumnych posiadaczy MBA, listy kontrolne rycerzy zakonu PRINCE2 czy intuicję liderów. Praca każdej osoby w projekcie jest połączona niewidzialnym drucikiem z tą tablicą. Deweloperowi udaje się zrealizować, dokonać analizy statycznej i skompilować kawałek kodu – jedna żarówka zmienia swoją barwę z czerwonej na nieco bardziej żółtą. Udaje się zintegrować, połączyć ze sobą i nawet uruchomić razem wiele takich kawałków? Cała grupa żaróweczek zaczyna się palić miłym żółtym blaskiem. 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 się na zielono. Wreszcie, w ostatnim rzędzie, odpowiadającym ostatecznemu terminowi zakończenia projektu, można spodziewać się wszystkich czy niemal wszystkich żarówek świecących na zielono. Ale nie wszystkie żarówki są tej samej wielkości. Są przecież wymagania kluczowe, które warunkują biznesowy sens całego przedsięwzięcia (wielkie żarówy), i wymagania mniej ważne (małe żaróweczki). Jakie to proste! Wystarczy dobrze znać wymagania, ich wagę, powiązania ze Zarządzanie projektem to zarządzanie ryzykiem 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. 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. Aby porządne zarządzanie ryzykiem nie odbywało się metodą stosowania niedoskonałej, emocjonalnej intuicji kierownika projektu lub jego podwładnych, konieczne jest systematyczne przypisywanie ryzyka poszczególnym wymaganiom i śledzenie jego zmian. Taka praktyka, zastosowana w kilku projektach, pozwoli nie tylko na półautomatyczne szacowanie ryzyka w kolejnych projektach, ale także na udoskonalenie całego procesu IT. sobą oraz z zaprojektowanymi modułami kodu i testami, a te z kolei powiązać z osobami, które dane zadania wykonują! To się nazywa śledzeniem powiązań wymagań (ang. requirements traceability). Na rynku jest wiele narzędzi, tak By zrealizować automatyczne zarządzanie projektem iT, wystarczy wielka tablica świetlna, na której każda żarówka odpowiada jednemu wymaganiu, które tworzony system ma realizować. na początku projektu żaróweczki świecą się głównie na czerwono, w miarę postępu prac jest coraz więcej żółtych i, wreszcie, zielonych. komercyjnych, jak i darmowych, które to wspierają. Oczywiście, takie rozwiązania dostępne są też w chmurze. Polecam jedno z wielu, znakomite, proste i niedrogie narzędzie ReQtest. Szwedzkie narzędzie, dodam, bo to – sądząc z reklam blachy dachowej i rynien – dobry argument marketingowy. Bez wróżenia z fusów Czy 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, przydzielaniem zadań różnym uczestnikom projektu? Jak mierzyć stan realizacji projektu? Gdzie umieszczać plany, raporty, wyniki audytów? Po kolei. Do oszacowania pracochłonności potrzeba 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 krytycznych. I patrzcie: wystarczyła analiza wymagań, nie trzeba było doktoratu z zarządzania! Harmonogram, kamienie milowe... Tak, przyznaję, to są rzeczy, których narzędzia do zarządzania wymaganiami nie wspierają wprost. Dlatego zbudowano narzędzia łączące świat PM oraz świat wymagań. Moim zdaniem znakomitym przykładem takiego narzędzia jest Concerto. Łączy ze sobą tradycyjnie osobne światy: śledzenie powiązań wymagań, zarządzanie zadaniami, automatyczne zapobieganie błędom, zarządzanie projektem i integrację. Jeśli nawet udało mi się jakoś okiełznać zastrzeżenia tradycjonalistów, to już słyszę nadciągającą falę zastrzeżeń ze świata Agile, sprowadzających się do narzekań – „jest zupełnie inaczej, niż myślisz” oraz „ty mnie nie rozumiesz”. 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ę. Jednak nasza tablica świetlna doskonale wpisuje się w agile’owe pojęcie rejestru zadań przebiegu (sprint backlog). Jeśli to takie proste, to dlaczego się tego nie robi Zetknąłem się ostatnio z nieznanym mi wcześniej zagadnieniem: audytem zarządzania budynkiem użyteczności publicznej. Zakres takiej kontroli jest olbrzymi, ale prawdziwy jej smak wynika dopiero z faktu, że nikt – poza kontrolerami – nie wie dokładnie, jakie są wymagania! Okazuje się na przykład, że obowiązkowa kontrola techniczna powinna obejmować coroczne sprawdzanie instalacji odgromowej. Nawet jeśli administrator budynku wie, co i kiedy powinno być zrobione, musi sam zadbać, aby o tym pamiętać. Nie istnieje żaden automatyczny system, który o tym przypomni. Aż się prosi o taką automatyczną listę kontrolną – zadanie do realizacji dla studenta drugiego roku informatyki. Wtedy administrowanie budynkiem przestałoby być nieustannym stresem i nieustannym pilnowaniem tysięcy drobnych szczegółów administracyjnych. To wszystko robiłoby się automatycznie! Ale pewnie nigdy tak nie będzie. 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. computerworld 7 grudnia 2012 21 9 WIĘCEJ PrO J e K T Y i TWEŹ UDZIAŁ W KONFERENCJI! z a r zDOWIEDZ ą d z a n i e SIĘ Procedury chronią przed skutkami błędów inżynieria wymagań – splot słoneczny iT Inżynieria wymagań obejmuje kluczowe dla projektów IT obszary: analizę biznesową, techniki sprzedaży, metodyki agile, zarządzanie, technologie programowania, testowanie i prawo IT. BOgdan Bereza 22 10 W 73. sekundzie lotu promu kosmicznego Challenger 28 stycznia 1986 r. nastąpiła eksplozja – cała załoga zginęła. Członkiem komisji badającej przyczyny katastrofy był laureat Nagrody Nobla Richard Feynman. To on wykrył przyczyny awarii: uszczelki w silnikach pomocniczych nie działały poprawnie w niskich temperaturach. Wiedzieli o tym szeregowi pracownicy projektu, ale to nie dotarło do kadry zarządzającej lub zostało przez nią zignorowane. 1996 rok: w wyniku błędu oprogramowania misja 501 rakiety Ariane 5 kończy się zaraz po starcie efektowną eksplozją. 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 wpisany na listę zabytków, co dramatycznie obniża wartość nieruchomości. Konserwator zabytków tłumaczy się, że „nie przyszło mu do głowy” zawiadomić właściciela, zaś rzecznik computerworld 20 listopada 2012 Ministerstwa Kultury mówi: „nie było złej woli, zabrakło procedur”. Przyczyny pomyłek, błędów i awarii Co wspólnego mają te historie? Temu zagadnieniu poświęcona jest książka Dietricha Dörnera „The Logic of Failure”. Jest to książka o tym, jak ludzie się mylą, podejmują złe i głupie decyzje. Co nam, ludziom IT, z tej gorzkiej prawdy? 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. Niezbędne są procedury! Nie biurokracja i papierologia, ale elastyczne, sprawne i automatyczne procedury, zabezpieczające nas przed skutkami naszych pomyłek. Procedury to nie luksus, to oszczędność. Dzięki nim wykryjemy błędy, kiedy ich usunięcie jest jeszcze tanie, projekty będą przebiegały sprawniej, a programiści, testerzy i klienci będą szczęśliwsi. Procedury to drogi prowadzące do celu. W IT cel to wymagania wobec systemu IT. To nie jest popularna nazwa: częściej mówi się o warunkach, założeniach, projektach, właściwościach. Zaś nazwa dziedziny wiedzy uczącej, jak znajdować, określać i skutecznie realizować cele, czyli inżynieria wymagań, to rzadkość. Inżynieria wymagań obejmuje kluczowe dla powodzenia przedsięwzięć IT obszary, których nazwy atakują nas ze wszystkich stron: analizę biznesową, techniki sprzedaży, metodyki agile, metody zarządzania, technologie programowania, sposoby testowania i nawet prawo IT. Niepowodzenia projektów wynikają z deficytów inżynierii wymagań. analiza biznesowa to inżynieria wymagań Obecnie wszelkie zmiany procesów biznesowych oznaczają zmiany systemów IT lub wdrażanie nowych rozwiązań IT. Analiza biznesowa to dyscyplina na wskroś informatyczna. To pierwszy etap inżynierii wymagań albo proces ją poprzedzający, źródło wiedzy dla tzw. procesu pozyskiwania wymagań. Często spotyka się opisy, w których inżynieria wymagań nie występuje. Następnym krokiem po analizie biznesowej jest projektowanie systemów. Wskutek takiego podejścia, informatycy słabo się orientują, co właściwie mają skonstruować... Sprzedaż to 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! Innymi słowy, sprzedaż to forma inżynierii wymagań, a psychologiczne zagrywki potrzebne do złapania klienta omawia się na kursach analizy biznesowej oraz inżynierii wymagań pod skromną nazwą technik pozyskiwania wymagań. Metodyki agile to inżynieria wymagań Wymagania kojarzą się z opasłymi tomami dokumentacji. Natomiast metodyki zwinne WYDANIE USŁUGI PrO J e K T Y i TSPECJALNE zarządzanie – agile, extreme programming, TDD – same nazwy brzmią radośnie, luzacko, nowocześnie. Porządna inżynieria wymagań nie musi być nudziarstwem, zaś metody agile nie tylko nie obywają się bez inżynierii wymagań, lecz są jej częścią! Co wykryli i ogłosili światu sygnatariusze Manifestu Agile? (www.agilemanifesto. org) Odkryli proste i dobrze znane zasady inżynierii wymagań i zarządzania projektami: • wymagania są zwykle zmienne; 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ń; skuteczną metodą pomocy jest prototypowanie: tworzenie małych fragmentów funkcjonalności, które ułatwiają klientom odkrycie, czego tak naprawdę chcą; • próby kurczowego trzymania się kaskadowego modelu cyklu wytwarzania oprogramowania i szczegółowego opisania wymagań, zanim przystąpi się do tworzenia kodu, są nieskuteczne i szkodliwe. Oto koncepcja agile w pigułce. Metodyki zwinne przyniosły IT odkrycie, że wymagania można i warto odkrywać za pomocą prototypowania i bardzo częstych kontaktów z klientem. Tylko niech nikt nie twierdzi, że podejście agile eliminuje inżynierię wymagań. Jest przeciwnie – metody zwinne wprowadzają inżynierię wymagań w procesy projektowania i programowania w znacznie większym stopniu niż w metodach tradycyjnych! Pokusa pisania kodu na łapu-capu jest wielka. Program, w przeciwieństwie do mostu, można poprawiać wielokrotnie, nawet po widowiskowym zawaleniu się. za uleganie tej pokusie przychodzi nam nieraz drogo płacić. zarządzanie projektami to inżynieria wymagań 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 Prawnicy to zamaskowani inżynierowie wymagań Zrozumienie podstaw inżynierii wymagań jest potrzebne zarówno wśród prawników, jak i podpisujących kontrakty menedżerów. Mimo dużych różnic w zakresie terminologii, są liczne podobieństwa w sposobie podejścia prawników, inżynierów wymagań oraz testerów projektujących testy akceptacyjne. Kontrakt na „wdrożenie systemu” 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 została przez prawnika strony zamawiającej propozycją, że w tej sytuacji zamawiający „w zasadzie zapłaci za aplikację”... 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 inżynieria wymagań w 100%; 2. Oszacowanie pracochłonności to zestaw metod, pozwalających szacować pracochłonność ich realizacji; 3A. Identyfikacja zadań to podział wymagań głównych na mniejsze, cząstkowe; 3B. Przydzielenie zadań i harmonogramowanie nie należą do inżynierii wymagań, ale ich wyniki przekładają się na atrybuty wymagań; 4. Nadzorowanie to określanie statusu realizacji poszczególnych wymagań. Celem wywodu nie jest udowadnianie tezy, że inżynieria wymagań oraz zarządzanie projektami to jedno i to samo, bo tak nie jest. Należy zrozumieć, że te dwa procesy są ze sobą powiązane; nie ma dobrego kierowania projektem bez zaangażowania się w inżynierię wymagań. Programowanie to inżynieria wymagań Jeśli programowanie to inżynieria wymagań, to czy wbijanie gwoździ lub układanie cegieł to architektura czy biznesplan dla nowego wieżowca? W dobrze zorganizowanym projekcie każde uderzenie młotka powinno wynikać z dokumentacji. 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 daje się to zrobić, tyle że gorzej i drożej. Kompetencje planisty, architekta, operatora dźwigu i murarza to zupełnie różne światy, ale między inżynierem wymagań, projektantem i programistą nie ma tak dużych różnic. Skąd bierze się wiele chronicznych problemów IT? Pokusa pisania kodu na łapu-capu jest wielka. Program można poprawiać wielokrotnie, nawet po widowiskowym zawaleniu się. Za uleganie jej przychodzi nam nieraz drogo płacić. Testowanie to inżynieria wymagań Testowanie polega na kontrolowaniu, czy to, jak jest, zgadza się z tym, jak ma być. Skąd wiadomo, jak ma być? To jest zapisane w wymaganiach! To jakim cudem odbywa się testowanie w tysiącach projektów, gdzie wymagania są niepełne, błędne, niespójne, nigdzie niezapisane? Cóż, wtedy albo testowanie jest bezcelowym marnowaniem czasu, albo brakujące wymagania zdobywa się podczas testowania. Testerzy domyślają się, jaki ma być wynik oczekiwany. Jest nawet szkoła „testowania eksploracyjnego”, która Nauka i certyfikacja inżynierii wymagań Zasad inżynierii wymagań i analizy biznesowej można się nauczyć. Istnieje wiele kursów uczących metod modelowania procesów biznesowych i wymagań (m.in. popularne UML). Poniżej prezentujemy listę kilku znanych na świecie certyfikacji ogólnych, wykraczających poza jedną technikę. IREB – Intenational Requirements Engineering Board Certyfikaty inżynierii wymagań oferuje międzynarodowa organizacja IREB (www.ireb.org). Polska grupa działaczy IREB (www.ireb.org.pl) zajmuje się promocją wiedzy na temat inżynierii wymagań w Polsce i udostępnieniem sylabusów oraz egzaminów na certyfikaty IREB po polsku. Na świecie certyfikaty IREB oferowane są w sześciu językach, w wielu krajach Europy, Ameryki i Azji. Certyfikat podstawowy – CPRE Foundation Level – ma 10 tys. 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: www.ireb.org (zakładka „Training”), zaś firmy szkoleniowe w Polsce na: www.ireb.org.pl/szkolenia. QAI – Quality Assurance Institute QAI Software Certifications (www.softwarecertifications.org) oferuje dwa certyfikaty: • CABA – Certified Associate Business Analyst • CSBA – Certified Software Business Analyst IIBA – International Institute of Business Analysis IIBA (www.iiba.org) 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 (www.warsaw. iiba.org) – polska organizacja IIBA. 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. W Polsce powstaje Stowarzyszenie Inżynierii Oprogramowania (zebranie założycielskie planowane jest na 10 stycznia 2013). Na kwiecień planowana jest konferencja „Dobre wymagania 2013”. Osoby zainteresowane przystąpieniem do stowarzyszenia i udziałem w konferencji mogą uzyskać więcej informacji na stronie: www.wymagania.org.pl computerworld 20 listopada 2012 23 11 DOWIEDZ SIĘ WIĘCEJ WEŹ UDZIAŁ W KONFERENCJI! Projekt bez zbędnych opóźnień Z TOMEM GILBEM, konsultantem zarządzania i inżynierii oprogramowania, rozmawiamy o ewolucyjnych metodach zarządzania projektami. dzi jest zdania, że skoro co tydzień dostarczają nowy kod, to pracują ewolucyjnie. Ale jeśli nie tworzą co tydzień nowej wartości dla rzeczywistych użytkowników oraz innych interesariuszy, to nie jest to metoda ewolucyjna. Zaletą podejścia ewolucyjnego jest to, że na jego wyniki nie trzeba czekać długo. Już po tygodniu widać, czy robimy coś dobrze, czy nie. A programowanie ekstremalne czy metody zwinne, w których bezpośrednio współpracuje się z klientem? Programowanie ekstremalne nie zakłada tworzenia całościowych wymagań, więc trudno określić, na ile kolejne, bardzo często budowane wersje programu tworzą kolejny poziom wartości dla klienta. Z kolei najbardziej popularna metodyka zwinna, Agile Scrum, nie określa jasno relacji między nadrzędnymi wymaganiami a zadaniami dla poszczególnych przebiegów. Nie mówię, że to są złe metodyki, ale nie wystarczy pracować zgodnie z nimi, aby móc mówić o metodzie ewolucyjnej. O co właściwie chodzi z metodami ewolucyjnymi? Czy to nie jest kolejna ładna nazwa na te same sposoby pracy, jakie stosowano zawsze? Szesnaście lat temu, w 1994 roku, konserwatywny przecież Departament Obrony USA zmienił swoje standardy inżynierii oprogramowania. Zaczęto wtedy stosować tak zwany Standard 498, który jest ewolucyjny. Departament Stanu oficjalnie wyrzekł się stosowania metod kaskadowych w projektach. To jest przykładem, jak w końcu, po wielu latach doświadczeń, przekonano się, że metody ewolucyjne sprawdzają się tam, gdzie metody kaskadowe zawodzą. Co charakteryzuje metody ewolucyjne? Metody ewolucyjne polegają na tym, że każdy projekt dzieli się na mniejsze projekty. Może ich być wiele, nawet pięćdziesiąt! Chodzi o to, aby każdy kolejny cykl dostarczał interesariuszom projektu jakąś nową wartość. Dzięki temu można także już w trakcie projektu, a nie dopiero tuż przed jego zakończeniem, zorientować się, czy zastosowane technologie sprawdzają się, czy 12 dobrze rozumiemy potrzeby użytkowników. Dzięki podejściu ewolucyjnemu kierownictwo projektu, jego sponsorzy otrzymują na bieżąco informację, czy wszystko dobrze idzie. Czym różnią się metody ewolucyjne od metod zwinnych? Pojęcie „metody ewolucyjne” jest szersze. Zawierają się w nich metody zwinne, ale nie tylko. Metody ewolucyjne pojawiły się dużo wcześniej, pod innymi nazwami, takimi jak: cleanroom software engineering, codzienne budowanie, metody przyrostowe, prototypowanie. Każda z nich jest w jakimś stopniu metodą ewolucyjną. Na ile metody ewolucyjne – niezależnie od nazwy – są dziś rozpowszechnione? Widziałem wyniki badań, według których około 30% organizacji posługuje się metodami ewolucyjnymi. To mnie dziwi. Dlaczego? Jak, Pana zdaniem, wygląda to naprawdę? W rzeczywistości odsetek firm stosujących metody ewolucyjne wynosi 1–5%. Wielu lu- Czy są sytuacje, kiedy metody ewolucyjne nie są odpowiednie? Moim zdaniem, nie – a wiele się nad tym zastanawiałem. Metodami ewolucyjnymi posługuję się od 1960 roku. Wielokrotnie natrafiałem na opór, spotykałem się z osobami mówiącymi, że ich projektu nie da się zrealizować w sposób ewolucyjny, bowiem nie da się go podzielić na tak małe kawałki. W rzeczywistości trudność polega na tym, że nie umie się tego zrobić. W tej dziedzinie wielu ludziom brakuje odpowiedniego wykształcenia. Co doradziłby Pan organizacjom, które chciałyby spróbować podejścia ewolucyjnego? Zaletą podejścia ewolucyjnego jest to, że na jego wyniki nie trzeba czekać długo. Już po tygodniu widać, czy robimy coś dobrze, czy nie. Podstawowa trudność dotyczy oceny wartości dla udziałowców. Jeśli na przykład nadrzędnym celem projektu jest obniżenie kosztów określonego działania klienta, to nie jest dostarczaniem wartości produkowanie kodu realizującego kolejne punkty funkcyjne lub kolejne przypadki użycia, o ile ich dostarczenie nie powoduje rzeczywistego obniżenia kosztów. Pod tym kątem w pierwszym rzędzie trzeba oceniać wartość poszczególnych funkcji oprogramowania. Czy mógłby Pan podać przykłady sukcesu metod ewolucyjnych? Doświadczenie nauczyło mnie, że w ciągu godziny potrafię znaleźć sposób, jak podzielić dowolnej wielkości projekt na fragmenty nie większe niż 2% całości. Udało mi się to osiągnąć w ogromnym projekcie amerykań- WYDANIE SPECJALNE USŁUGI skiego Departamentu Obrony, tworzącym oprogramowanie do zarządzania personelem tej zatrudniającej ponad 2 mln osób organizacji. W Hewlett-Packard ta metoda pracy stosowana jest od 20 lat, nikomu nawet do głowy nie przychodzi, by podważać zasadę cotygodniowych dostaw nowych wersji. Dzięki metodom ewolucyjnym działania organizacji stają się bardziej elastyczne, pracownicy zadowoleni, a klienci usatysfakcjonowani. Microsoft jest także wielkim użytkownikiem tej metody, choć nigdy nie nazywał jej ewolucyjną, posługując się własnymi nazwami. Zostało to opisane m.in. w książce dr. Michaela Cusumano z MIT pt. „Microsoft Secrets”. W tym czasie Microsoft był moim klientem. Kiedy współpracowałem z ich dyrektorem testów, powiedział kiedyś: „Tom, ewolucyjne dostawy to nasz sposób życia tutaj, w Microsoft”, choć, jak już wspomniałem, stosowano tam zupełnie inne nazwy. Microsoft wykorzystuje podejście ewolucyjne na trzech poziomach. Mają swoje codzienne budowanie, swoje kamienie milowe co 6 tygodni i wreszcie swoje uwolnienia, sterowane kryteriami marketingowymi. Tak naprawdę Microsoft jest jednym z wielkich użytkowników metod ewolucyjnych. Inny przykład to trwający ponad 4 lata projekt zrealizowany przez IBM Federal Systems Division (Wydział Projektów Federalnych IBM), kierowany przez prof. Harlana Millsa. Co miesiąc – to prawie dokładnie 2% z 4 lat – robiono kolejną przetestowaną dostawę. Ten i inne projekty prowadzone przez dział Millsa zrealizowano w terminie i bez przekroczenia budżetu. Wśród nich znalazło się oprogramowanie – jego naziemna część – do promu kosmicznego NASA, którego pracochłonność wyniosła 10 000 osobolat! Jeszcze w latach 80. ubiegłego stulecia Harlan Mills udowodnił, że podejście ewolucyjne działa w projektach Marynarki Wojennej USA, Departamentu Obrony i w NASA. Przy okazji odkryliśmy wtedy, że w podobny sposób NASA tworzyło tę część oprogramowania promu, która wraz z nim leciała w przestrzeń (na pokładzie promu kosmicznego znajdują się cztery komputery, niezależnie wykonujące to samo oprogramowanie, oraz piąty, rezerwowy, wykonujący tylko procedury wejścia na orbitę i lądowania). Co nas jeszcze bardziej zaskoczyło, to fakt, że naukowcy zajmujący się techniką rakietową i lotów kosmicznych pracowali w sposób ewolucyjny już od końca II wojny światowej, podczas gdy znaczna część ludzkości aż do dzisiaj tkwi w przestarzałym modelu kaskadowym! Projekt dąży do celu tak samo jak samonaprowadzająca się rakieta – dokonując, gdy trzeba, nieznacznych poprawek kursu. W granicach 2% zawsze można zmienić kierunek; umożliwia to adaptację do zmian wymagań w trakcie projektu, co dziś jest koniecznością biznesową. Tę zasadę znano i stosowano już o wiele lat wcześniej, niż powstał Manifest Agile. Jest Pan współautorem książki „Software Inspection”. Jaka jest Pana zdaniem obecna i przyszła rola testowania i kontroli jakości? Pana pytanie dotyczy w istocie dwóch zagadnień: kontroli jakości oraz zapewnienia jakości. Inspekcje same w sobie nie są żadnym magicznym rozwiązaniem. To dobra, systematyczna metoda pozwalająca skutecznie sprawdzać jakość dokumentacji, kodu, produktów informatycznych, lecz niewłaściwie stosowana, nie uratuje źle prowadzonego projektu. Od około 15 lat coraz więcej uwagi poświęca się testowaniu. Jest to wprawdzie postęp w porównaniu z czasem, kiedy testowanie utożsamiano z debugowaniem, ale nadal jest to metoda przestarzała i nieskuteczna w porównaniu z zapobieganiem błędom. Pod tym względem przemysł informatyczny nadal pozostaje daleko w tyle za – na przykład – przemysłem motoryzacyjnym. Zapobieganie błędom nazywam „lekkim zapewnieniem jakości” (Lean Quality Assurance). Na czym polega nowatorstwo tej metody? W istocie, jest ona sposobem na to, jak w praktyce realizować zasady, doskonale podsumowane tytułem znanej książki Philipa Crosby’ego „Quality is Free” („Jakość jest za darmo”). Oczywiście, jakość nie jest dosłownie za darmo, ale jest o wiele tańsza niż jej brak. Testowanie – także automatyczne, metodami TDD czy zwinnymi – jest kosztowne, a najbardziej kosztowne jest naprawianie znalezionych przez testy błędów. O wiele taniej jest im zapobiegać, zarówno w każdym projekcie, jak i poprzez takie kształtowanie procesów, aby sprzyjały zapobieganiu błędom. Na czym polega takie zapobieganie błędom? W jego skład wchodzi szereg szczegółowych technik. Zaczyna się od starannej analizy wymagań interesariuszy – wszystkich, nie tylko użytkowników i zleceniodawcy! Potem konieczne jest dokładne zaprojektowanie jakości – nie da się jej wtestować w prawie już gotowy system. Dobrze zaprojektowana architektura jest podstawą jakości systemów, czego nie biorą pod uwagę modne dziś metody zwinne. Rozmawiał Bogdan Bereza-Jarociński ŻYCIE POD PRĄD Tom Gilb należy do znanych na całym świecie guru zarządzania i inżynierii oprogramowania. Jest autorem kilku wielokrotnie wznawianych książek, oryginalnym myślicielem i aktywnym praktykiem, którego metody z powodzeniem stosuje wiele międzynarodowych korporacji. Urodził się w 1940 roku w Pasadenie, w pobliżu Los Angeles. Prowadzi intensywne życie – pod prąd. Większość ludzi stara się przenieść do Kalifornii, Tom płynął w przeciwnym kierunku. Wyemigrował do Londynu, mając 16 lat, do Norwegii – dwa lata później. Obecnie mieszka niedaleko Oslo. Napisał m.in. książki „Principles Software Engineering Management” („Zasady zarządzania inżynierią oprogramowania”), „Software Inspection” („Inspekcje oprogramowania”) razem z Dorothy Graham oraz „Competitive Engineering” („Konkurencyjna inżynieria”). Jest twórcą języka Planguage do opisu wymagań oraz metodyki Evo – Evolutionary Project Management („Ewolucyjne zarządzanie projektami”), o której książkę napisał współpracujący z nim jego syn, Kai Gilb. Tom angażował się początkowo głównie w projekty IT, ale od ponad 25 lat zajmuje się intensywnie zagadnieniami zarządzania korporacyjnego oraz inżynierią wielkich systemów w przemyśle lotniczym, telekomunikacyjnym i elektronicznym. Metody Toma Gilba są oficjalnymi standardami w IBM, Nokii, Ericssonie, HP, Intelu, Citigroup, Symbian i w Philips Medical. Tom był dotąd w Polsce dwukrotnie: w kwietniu 2008 roku na konferencji QAFATMS w Krakowie oraz w październiku 2008 na konferencji RE-AQCtion w Gdańsku. W maju tego roku będzie prowadził warsztaty w Szczecinie i Warszawie. Testowanie jest kosztowne, a najbardziej kosztowne jest naprawianie znalezionych przez testy błędów. O wiele taniej jest im zapobiegać, zarówno w każdym projekcie, jak i poprzez takie kształtowanie procesów, aby sprzyjały zapobieganiu błędom. 13 Z ADOWIEDZ R Z Ą D Z A NSIĘ I E WIĘCEJ I T I BI ZWEŹ N E S UDZIAŁ W KONFERENCJI! Dramatyczny wzrost wydajności dzięki IT Aby firmy mogły sprawnie reagować na potrzeby rynku, potrzebne jest tworzenie „oprogramowania jednorazowego”, tak jak jednorazowych maszynek do golenia. „Parasoftu” służą przede wszystkim programistom, umożliwiając wczesne testowanie oprogramowania (analiza statyczna, automatyczne testy jednostkowe), testerom (automatyczne testy funkcjonalne) oraz kierownikom projektów. Przy okazji Adam odkrył, że oprogramowanie można tworzyć zupełnie inaczej – dramatycznie sprawniej i skuteczniej – niż pozwalają na to sposoby dominujące dziś w przemyśle informatycznym. Ta nowa, rewolucyjna metoda, została opisana w książce Automated Defect Prevention (wydana w USA w 2007 roku, nie tłumaczona na język polski). Wszędzie, tylko nie w IT B lisko trzy lata temu, na łamach BOGDAN „Computerworld” opublikowa- BEREZAJAROCIŃSKI ny został artykuł pt. „Między biurokracją a chaosem” (CW 30/2007). Traktował on o metodyce automatycznego zapobiegania błędom (ADP – Automated Defect Prevention), stworzonej i opisanej w książce Adama Kolawy, założyciela i właściciela rmy „Parasoft” oraz Doroty Huizinga, wiceprzewodniczącej California State University – Fullerton. Adam, mający doktorat z zyki teoretycznej na California Institute of Technology, potrzebował kiedyś stworzyć oprogramowanie na użytek swoich badań. Zrobił to i odkrył, że informatyka pociąga go bardziej niż zyka. Wtedy (w 1987 r.) założył rmę „Parasoft”, specjalizującą się w produkcji narzędzi wspomagających produkcję oprogramowania. Narzędzia 26 14 COMPUTERWORLD 31 sierpnia 2010 Około 80 lat temu, dwóch amerykańskich specjalistów, Joseph Juran i Wiliam Deming opracowało metodyki zarządzania jakością, których podstawą jest teza, że zapobieganie błędom (a więc i defektom) jest o wiele tańsze i skuteczniejsze niż wykrywanie defektów i ich mozolne usuwanie. Tezy tej nie bardzo chciał słuchać w latach 40., po zakończeniu II wojny światowej, amerykański przemysł motoryzacyjny. Zarządzanie jakością polegało tam przede wszystkim na kontroli jakości: na wykrywaniu braków i ich mozolnym usuwaniu. Natomiast idee Jurana i Deminga wzięli sobie do serca japońscy producenci samochodów i dlatego – jeszcze dziś – na polskich (i nie tylko!) drogach widzi się o wiele więcej aut produkcji japońskiej niż amerykańskiej. Obecnie podejście Jurana/Deminga jest czymś naturalnym w większości branż produkcyjnych. Zamiast tylko naprawiać lub odrzucać wadliwe produkty, zarządzanie jakością koncentruje się na identykacji i usuwaniu wad procesu produkcyjnego. Proces zarządzania jakością jest ciągły i każdy z pracowników jest w niego zaangażowany. Jako TQM (Total Quality Management, kompleksowe zarządzanie jakością) lub pokrewna metoda SixSigma, koncepcja ta znana i stosowana jest od dawna. Ale nie w przemyśle informatycznym! Tutaj, niestety, wciąż dominuje podejście typu: „jakość to będzie”. Głównym sposobem zarządzania jakością jest kontrola jakości – zamiast usprawniać procesy i procedury, koncentrujemy się na testowaniu i „debugowaniu”, czyli szukaniu i usuwaniu defektów gotowych produktów. Takie podejście ma wysoce niekorzystne skutki biznesowe. Biznes to IT OK, powie Czytelnik, produkcję oprogramowania można usprawnić. Równie dobrze można usprawnić dostawy elektryczności, wywóz śmieci albo znaleźć tańsze lokale dla rmy. Czy jednak ma to większe, nie mówiąc już o „dramatycznym”, znaczenie dla skuteczności rmy, dla jej rezultatów biznesowych? Temu właśnie tematowi poświęcona jest najnowsza książka Adama Kolawy „Skokowy wzrost wydajności” (The Next Leap in Productivity, która w najbliższych miesiącach pojawi się w polskim tłumaczeniu nakładem Wydawnictwa CeDeWu. Otóż, współczesny biznes nie tylko – jak 20 lub 30 lat temu – wykorzystuje IT, jako funkcję o marginalnej wartości, w porównaniu np. z marketingiem i sprzedażą, lecz – niezależnie od tego, czy chodzi o handel butami, produkcję oprogramowania lub sprzedaż usług, np. wycieczek zagranicznych – współczesny biznes to jest IT! Jaki jest typowy problem z oprogramowaniem? Kierownicy działów IT śmiertelnie boją się wszelkich zmian i modykacji: „co nie jest popsute, tego nie należy naprawiać”. Zmiany budzą obawy i zajmują wiele czasu, a oprogramowanie jest notorycznie zawodne. Z tego powodu zmiany systemów IT chronicznie nie na- Dotąd mówiło się głównie, że kluczowe jest, aby dyrektor IT rozumiał dobrze biznes. Teraz już wiemy, że równie ważne jest, aby dyrektor zarządzający rozumiał dobrze możliwości, które stwarza IT. dążają za zmianami rynkowymi: nowymi potrzebami lub upodobaniami klientów. Jakakolwiek modykacja istniejących aplikacji połączona jest ze znacznym ryzykiem, czego wyraźnym objawem są m.in. rozbudowane systemy zarządzania błędami („defektami” wg termino- SPECJALNE I T IUSŁUGI B I WYDANIE ZNES Z ARZĄDZANIE logi ISTQB), ponieważ błędy znajduje się zwykle pod koniec projektu, a ich naprawa – podobnie jak każda modykacja istniejącej funkcjonalności – zawsze budzi obawy, że zepsuje się to, co dotąd działało poprawnie. Taki stan rzeczy powoduje, że rmy nie nadążają szybko i elastycznie reagować na zmienne potrzeby rynku, na potrzeby tworzenia nowych wersji oprogramowania, na zróżnicowanie rynków w epoce globalizacji. Dlatego potrzebna jest metoda, która pozwoliłaby tworzyć – wg określenia Adama Kolawy – „oprogramowanie jednorazowe”, tak jak istnieją obecnie jednorazowe maszynki do golenia, pieluchy, talerze i sztućce. Takie oprogramowanie można by tworzyć i modykować szybko i niezawodnie, bez długotrwałego procesu produkcji, testowania, debugowania i wdrażania. Kierownicy działów IT śmiertelnie boją się wszelkich zmian i modyfikacji. Z tego powodu zmiany systemów IT chronicznie nie nadążają za zmianami rynkowymi: nowymi potrzebami lub upodobaniami klientów. Jak osiągnąć ten cudowny – zdawałoby się – wynik? Według Kolawy, rozwiązanie jest proste: poprzez zastosowanie ADB (Automated Defect Prevention) do wytwarzania aplikacji. Czy to możliwe? Tak. Zastosowanie ADB, czyli w pełni zautomatyzowanych testów statycznych, jednostkowych i funkcjonalnych, w połączeniu z narzędziami do zarządzania projektem, śledzenia związków wymagań z komponentami oprogramowania i testami, pozwala kilkakrotnie, a nawet kilkunastokrotnie zwiększyć wydajność w tworzeniu oprogramowania, co odpowiednio i umiejętnie wykorzystane, może doprowadzić do wielokrotnego wzrostu wydajności przedsiębiorstwa – dramatycznego, skokowego wzrostu wydajności rmy. Klucz do sukcesu Dotąd mówiło się głównie, że kluczowe jest, aby dyrektor IT rozumiał dobrze biznes. Teraz już wiemy, że równie ważne jest, aby dyrektor zarządzający rozumiał dobrze możliwości, które stwarza IT. Adam Kolawa pisze: „Bez IT nie bylibyśmy w stanie wykorzystywać okazji i unikać szybko pojawiających się zagrożeń. Aby móc szybko i sprawnie reagować na zmiany na rynkach, potrzebne są duże pieniądze i elastyczne zasoby IT. Mówiąc szczerze, IT musi umieć zmieniać się równie szybko jak rynki. Statyczne IT nie pomoże organizacji konkurującej w globalnym biznesie. Aby szybko dostosowywać się do zmian, IT potrzebuje dającego się dostosować oprogramowania, co jest wprawdzie kłopotliwe, ale stwarza też nowe okazje. Organizacje umiejące szybko i sprawnie przekształcić wiedzę oraz informację w kod oprogramowania, uzyskają przewagę konkurencyjną nad rywalami, mającymi wolniejsze, mniej sprawne procesy wytwarzania oprogramowania. W kolejnej rundzie światowej konkurencji nie wystarczy mieć najlepszych ludzi. Co będzie potrzebne? Najszybsi i najbardziej kreatywni programiści, umiejący przetwarzać pomysły biznesowe w kod oprogramowania? Wcale nie. To przestarzały i niebezpieczny sposób myślenia. Zakłada się, że IT jest tylko kosztem ponoszonym, aby móc utrzymać przedsiębiorstwo. W rzeczywistości IT jest olbrzymią wartością – bezcennym motorem wzrostu i ekspansji”. Elastyczne i szybkie tworzenie niezawodnego oprogramowania pozwala przedsiębiorstwu szybko, sprawnie i elastycznie dostosować się do zmian na rynkach, wyprzedzać konkurencję, dostarczać klientom to, czego chcą. Dyrektor IT każdej rmy – zarówno wytwarzającej oprogramowanie na własne potrzeby, jak i na sprzedaż – powinien z grubsza znać metodykę ADP, umożliwiającą taki tryb pracy. Analitycy systemów (nazwa amerykańska – w Europie bardziej przyjęta jest nazwa „inżynierowie wymagań”), projektanci oraz programiści powinni stopniowo uczyć się pracować zgodnie z tą metodyką, aby móc ją stosować w praktyce i wytwarzać aplikacje – lub modykować istniejące – tak aby szybko i niezawodnie przekładać pomysły biznesowe na poprawnie działające oprogramowanie! Żeby ulepszyć, trzeba zrozumieć Po co dyrektor zarządzający, właściciel lub prezes rmy ma rozumieć podstawowe zasady IT, tak jak opisuje je Adam Kolawa? Oczywiście nikt nie wymaga – byłoby to absurdem – by prezes uczył się programowania. Nie w tym rzecz. Natomiast zadaniem jego jest zatrudnienie właściwego dyrektora IT i narzucenie mu właściwego kierunku. Aby umieć to zrobić, musi rozumieć z grubsza tezy Adama. Uwaga: choć narzędzia rmy „Parasoft” oferują funkcjonalność, która potrzebna jest do realizacji „dramatycznego wzrostu wydajności”, ani książka Kolawy, ani ten artykuł nie służą ich promocji. Te same wyniki można osiągnąć przy pomocy narzędzi innych rm lub narzędzi wolnodo- JAK TO OSIĄGNĄĆ W PRAKTYCE? Szczegóły na temat ADP (Automated Defect Prevention) znajdują się albo we wspomnianym na początku tekstu artykule „Między biurokracją a chaosem”, albo w książce Adama Kolawy. ADP pozwala osiągnąć „dramatyczny wzrost wydajności” działu IT. Pozwolę sobie tylko przypomnieć podstawowych sześć zasad ADP: • Stworzenie infrastruktury jednoczącej ludzi i technologię; • Określenie i zastosowanie dobrych praktyk; • Dostosowanie dobrych praktyk do specyfiki firmy, technologii, produktu i projektu; • Pomiary i monitorowanie statusu projektu; • Automatyzacja; • Przyrostowe wdrożenie praktyk ADP. Oczywiście, same nazwy niewiele mówią. Dlaczego ADP, a nie – szerzej przecież znane – ISO 9000 – ISO 9001, Six Sigma, CMMI, COBIT, ITIL, TickIT, ISO/IEC 12207, Bootstrap, SPICE, ISO/IEC 15504, TMM, MMAST, TAP, TCMM, TIM, TOM, TSM, TPI? Dlatego, że są to metody normatywne: wymagają spełnienia szeregu zasad, a jakość ocenia się na podstawie zgodności ze standardem, nie z produktywnością. No i wprowadzają masę biurokracji… mało mają wspólnego z regułami TQM (Total Quality Management)! stępnych (freeware). Naromiast metodyka Kolawy – darmowa – jest niezastąpiona. Wystarczy zakupić książkę, liczącą dużo mniej niż 200 stron; można ją przeczytać w jeden wieczór. Wiele praktycznych doświadczeń potwierdza (przykłady znajdziemy w książce), że wzrost wydajności IT i rmy naprawdę może nastąpić skokowo – zaskakująco, dramatycznie. Nic nie stoi na przeszkodzie – oprócz kurczowego trzymania się przyjętych, tradycyjnych metod – aby dać swojej rmie dramatyczną, rynkową przewagę nad konkurencją. Aby, stosując zasady ADP, osiągnąć umiejętność szybkiego, niezawodnego tworzenia nowego oprogramowania lub modykacji już istniejących aplikacji. Dzięki temu, produkcja oprogramowania przestanie być hamulcem zmian, a stanie się – ich nośnikiem. Bogdan Bereza-Jarociński jest konsultantem w rmie NewQuality, m.in. specjalistą w zakresie zarządzania projektami, zarządzania ryzykiem i zarządzania jakością, trenerem biznesu, psychologiem organizacji, informatykiem. COMPUTERWORLD 31 sierpnia 2010 27 15