Agile lekarstwem dla zarządzania wymaganiami?

Organizacja Standish Group co roku publikuje swój sławny raport zatytułowany Chaos Report. Raport ten zawiera wyniki badań dotyczących jakości projektów informatycznych. Od kilkunastu lat Standish Group zadaje organizacjom te same pytania dotyczące liczby projektów kończących się sukcesem. Porównanie tych liczb na przestrzeni lat jest ciekawe przede wszystkim dla kierowników projektów, ale nie tylko.

Niedawno przeczytałem nie sam raport, ale wnioski z raportu za 2011 rok zaprezentowane przez Johna Parkera na blogu w artykule Why so Many IT Projects are Challenged, Under Deliver Promised Value, or Outright Fail.

Autor zamieścił tam następującą tabelkę:

Jest to porównanie liczby projektów zakończonych sukcesem (które zmieściły się w budżecie i harmonogramie i dostarczyły zamawiającemu oczekiwaną wartość), liczby projektów, które się zakończyły, ale nie zmieściły się w zaplanowanym budżecie, bądź były opóźnione lub też miały ograniczony zakres w stosunku do pierwotnych założeń oraz liczby projektów, które zostały zakończone porażką.

Z przedstawionych liczb widać, że na przestrzeni kilkunastu lat nastąpiła nieznaczna poprawa, ale mimo wszystko liczba projektów zakończonych pełnym sukcesem jest bardzo mała.

Najbardziej rzuca się w oczy jednak porównanie liczby projektów zakończonych sukcesem realizowanych według standardowej metody Waterfall - 14%, do liczby projektów zakończonych sukcesem prowadzonych według metodyk zwinnych, Agile - 42%. Różnica jest na tyle diametralna, że w samym opracowaniu raportu zamieszczono komentarz:

“The Agile process is the universal remedy for software development project failure. Software applications developed through the Agile process have three times the success rate of the traditional Waterfall method, and a much lower percentage of time and cost overruns.”

Przyznam, że nie zdawałem sobie sprawy z takiej przewagi podejścia Agile nad standardowym cyklem wytwarzania oprogramowania. Ciekawy jestem, czy firmy realizujące projekty informatyczne w ślad za tym opracowaniem w przyszłości będą stawiały jeszcze bardziej na metodyki zwinne.
W każdym bądź razie Standish Group dostarczył znaczących argumentów za tym kierunkiem rozwoju.

A dlaczego Agile miałoby być lekarstwem dla zarządzania wymaganiami?

Otóż, wg Standish Group trzy najważniejsze powody, dla których projekty nie kończą się pełnym sukcesem to:

• Lack of user input
• Incomplete requirements and specifications
• Changing requirements and specifications.

Wszystkie te czynniki są rezultatem niedostatecznej analizy biznesowej. Można wysnuć wniosek, że standardowe podejście, w którym pierwszą fazą projektu jest analiza kończąca się zatwierdzeniem specyfikacji wymagań - jest błędne. 

Ja nie spotkałem się jeszcze z projektem, w którym czas przeznaczony na analizę byłby wystarczający lub wyniki fazy analizy byłyby kompletne i zawierałyby dokładnie opisane wszystkie wymagania. Niby zakłada się, że wymagania mogą podlegać zmianom w późniejszych fazach projektu, przy czym istnieje świadomość, że im późniejsza zmiana wymagań, tym koszt jest większy. Ale najczęściej mimo wysiłku całego zespołu projektowego liczba zmian przekracza punkt krytyczny, po którym okazuje się, że sukces projektu jest zagrożony.

Czy zatem stosowanie podejścia Agile do zarządzania wymaganiami i prowadzenia całego projektu może kluczem do sukcesu? Wiele na to wskazuje. Choć w moim odczuciu potrzeba jeszcze wiele czasu, żeby się o tym przekonać na własnej skórze. Sądzę, że potrzebujemy jeszcze więcej opracowań na temat metodyk zwinnych oraz przekonania do nich organizacji i ludzi, którzy od lat realizują projekty zgodnie ze starymi i sprawdzonymi metodami.

Macierz CRUD w EA

Dla lepszego zrozumienia artykułu najpierw przypomnijmy sobie czym jest CRUD? Według Wikipedii są to cztery podstawowe funkcje w aplikacjach korzystających z pamięci trwałej, które umożliwiają zarządzanie nią. Skrót CRUD pochodzi od angielskich terminów: Create, Read, Update oraz Delete (Utwórz, Odczytaj, Aktualizuj oraz Usuń). Skrót ten może być stosowany w odniesieniu do interfejsu użytkownika większości aplikacji, które zazwyczaj pozwalają użytkownikowi na:

• utworzenie lub dodanie nowych informacji (create),
• odczytanie lub wyświetlenie istniejących informacji (read),
• modyfikowanie lub edycję istniejących informacji (udpate),
• usuwanie istniejących informacji (delete).

Praca grupowa w Enterprise Architect

Sparx Enterprise Architect posiada bogate możliwości w zakresie konfiguracji środowiska począwszy od łatwego umożliwienia pracy indywidualnej do złożonych konfiguracji pracy wielu organizacji w odniesieniu do modelowania jednocześnie wielu przedsięwzięć.

W najprostszej konfiguracji, gdy model tworzy jedna osoba wystarczy zainstalowanie programu Sparx Enterprise Architect na jednej stacji roboczej i aktualizacja modelu w pliku EAP. W takim przypadku możemy również mówić o pracy grupowej, gdyż zazwyczaj wyniki pracy prezentowane są zwykle interesariuszom przy użyciu jednej z poniższych metod:

• eksport diagramów w postaci pliku graficznego lub umieszczenie diagramów w niezależnie tworzonej dokumentacji,
• przesyłanie kopii pliku EAP lub umieszczenie go we współdzielonym repozytorium,
• generowanie dokumentacji w formacie RTF,
• generowanie raportu HTML,
• eksport modelu w formacie XMI.

Poniżej zostały opisane po krótce różne metody pracy grupowej wraz z ich zaletami i wadami.

Dołączanie grafiki do wymagań

Naturą wymagań jest ich forma tekstowa. Każde wymaganie jest formułowane w języku naturalnym. Składa się co najmniej z jednego zdania oznajmującego.

Dobrze, żeby wymaganie miało:

• swój unikalny identyfikator, do którego można referować w innych artefaktach analitycznych, 
• nazwę - która w skrótowej formie prezentuje jego charakter,
• treść - jedno lub kilka zdań; może się składać również z listy numerowanych lub wypunktowań.

A co, jeśli wymaganie dotyczy na przykład ekranu użytkownika lub kształtu raportu? 

Czy należy wówczas w formie tekstowej opisywać położenie przycisku na ekranie? 

Doświadczony analityk wie, że znacznie skuteczniej jest w wymaganiu umieścić prototyp ekranu pokazujący miejsce, gdzie taki przycisk zostanie umieszczony przez programistę.

Połączenie dwóch diagramów przez dwuklik

Niedawno otrzymałem od jednego z czytelników takie zapytanie:

Przeglądałem Pana stronę internetową na temat obsługi Enterprise Architecta, jednak nie znalazłem tam informacji na temat problemu, który próbuje rozwiązać od jakiegoś czasu, a mianowicie: czy istnieje możliwość połączenia dwóch diagramów, np. czynności poprzez dwuklik na jednym z elementów jednego, który kończąc jeden proces jest jednocześnie początkiem drugiego procesu. Byłbym bardzo wdzięczny za odpowiedz czy coś takiego jest możliwe a zarazem podpowiedz jak to zrobić.

Postanowiłem przygotować odpowiedź w postaci wpisu na blogu, gdyż może to być przydatna informacja również dla innych czytelników.

Jak uruchomić dwie wersje Enterprise Architect?

Jeśli instalujemy nowszą wersję programu Sparx Enterprise Architect jesteśmy informowani uprzejmie, że musimy odinstalować poprzednią wersję programu. Jeśli się zgodzimy, wówczas instalator wykona za nas automatycznie tę operację.

Jeśli jednak chcielibyśmy z jakichś powodów skorzystać z poprzedniej wersji programu, czy musimy każdorazowo odinstalowywać i instalować ponownie program?

Okazuje się, że na jednym komputerze mogą współistnieć dwie lub więcej wersji EA.

Mapowanie przypadku użycia

Opracowanie modelu użycia ma na celu udokumentowanie w fazie analizy szczegółowych wymagań dotyczących funkcjonalności budowanego rozwiązania. W tym celu definiowani są aktorzy, którzy wchodzą w interakcję z systemem oraz przypadki użycia, które opisują wykorzystywaną przez nich funkcjonalność.

Jednakże analiza systemów informatycznych oprócz modelu funkcjonalnego obejmuje również inne obszary, takie jak:

• zarządzanie wymaganiami,
• modelowanie procesów biznesowych,
• modelowanie danych (logiczny model danych / model domeny),
• modelowanie interfejsu użytkownika. 

Ponadto analiza nie może istnieć w oderwaniu od innych zadań projektowych, takich jak:

• zarządzanie zakresem projektu,
• zarządzanie ryzykiem,
• zarządzanie problemami,
• zarządzanie zmianą,
• projektowanie,
• implementacja,
• testy.

Częstą praktyką jest chociażby opracowywanie scenariuszy i przypadków testowych przez analityków, które są wykorzystywane przez testerów. Dzieje się tak, gdyż przypadki testowe bazują w głównej mierze na przypadkach użycia, a analityk zna je najlepiej.

Zatem, wskazane jest stworzenie i utrzymywanie określonych powiązań elementów modelu użycia z elementami innych obszarów.

Jak przenieść scenariusz do innego przypadku użycia?

W trakcie pracy nad modelem użycia często dochodzi do sytuacji, w której analityk dochodzi do wniosku, że określony scenariusz należy przenieść z jednego przypadku użycia do innego. Może tak się zdarzyć, gdy okazuje się, że scenariusz alternatywny powinien rozwidlać się jeszcze bardziej, czyli mieć jeszcze dodatkowe alternatywy.
Czasem istnieje również potrzeba stworzenia nowego przypadku użycia podobnego do już istniejącego, na przykład, gdy tworzymy kolejną specjalizację przypadku generalizującego.
Gdyby scenariusze pisane były w zwykłym dokumencie MS Word, wówczas przeniesienie czy skopiowanie kroków scenariusza byłoby banalne. Jednak jeśli zdecydowaliśmy się na zastosowanie ustrukturalizowanych scenariuszy (Structured scenario), wówczas staje się to problematyczne.
Na szczęście istnieje rozwiązanie...

Raport dla przypadków użycia

Z modelem przypadków użycia tworzonym przez analityków w programie Enterprise Architect powinno się zapoznać wielu interesariuszy projektu. Spośród nich można wymienić projektantów, programistów, ale przede wszystkim przedstawicieli klienta, takich jak kluczowi użytkownicy, eksperci dziedzinowi i inni. W związku z tym, jeśli decydujemy się na opisywanie scenariuszy przypadków użycia w formie Structured Scenario w EA - powinniśmy również zadbać o ich stronę dokumentacyjną.
Profesjonalnie przygotowany raport poprawia czytelność i odbiór wyników pracy fazy analizy.

Scenariusze przypadków użycia w EA

W Sparx Enterprise Architect od wersji 8.0 wprowadzono możliwość opisywania scenariuszy przypadków użycia w formie ustrukturalizowanej (Structured Scenario). Wcześniej scenariusz można było tworzyć tylko w postaci sformatowanego tekstu zawierającego ewentualnie listy numerowane. Od dawna możliwe było również opracowanie scenariusza w formie Linked Document dołączonego do elementu typu Use Case.
W tym artykule chciałbym przybliżyć możliwości wykorzystania mechanizmu Structured Scenario. Ten sposób posiada wiele zalet i warto się z nimi zapoznać.