Radek Smilgin
Takie okresowe sprawdzanie stanu projektu często odbywa się w ramach jednej z faz procesu testowego, czyli nadzoru, monitorowania i kontroli. Jednak czynności te zarezerwowane są do kierowników testów albo dla pewnego forum jak np. daily standup w ramach Scrum. Inwentaryzacja w projektach informatycznych to dla mnie czynność, która nie jest zarezerwowana jedynie dla ról kierowniczych i jest zebraniem wszelkich informacji jakie posiadam(y).
Inwentaryzacja będzie więc zbiorem czynności formalnych lub nieformalnym, prowadzących do stworzenia spisu informacji oraz źródeł ich pochodzenia. Polega ona na ustaleniu faktycznego stanu wszystkich informacyjnych składników. W podejściu rachunkowym jest to też wyjaśnienie różnic pomiędzy stanem stwierdzonym podczas wykonania spisu faktycznego (stan rzeczywisty), a stanem wynikającym z księgowań. W informatyce będzie to raczej różnica między planem a aktualnym stanem projektowym.
Różnice wynikają z dwóch następujących powodów:
- zmian naturalnych cech informacji (brak aktualizacji, przeterminowanie, zmiana itp.),
- błędów i nadużyć popełnionych przez pracowników (celowe lub przypadkowe pomyłki liczbowe w dokumentacji testowej itd.).
Inwentaryzacja w szczególności sprowadza się to do:
- uzgodnienia planów ze stanem rzeczywistym,
- rozliczenia osób odpowiedzialnych za powierzone zadania,
- dokonania oceny przydatności składników objętych spisem,
- przeciwdziałania stwierdzonym w czasie spisu nieprawidłowościom w gospodarowaniu składnikami majątku (marnotrawstwo).
Powyższy opis bazuje na definicji z Wikipedii, która została znacząco zmieniona na potrzeby dostosowania do realiów IT.
Standardowa inwentaryzacja od tej projektowej różni się jednym znaczącym faktem. Nie ma ona na celu kontroli i sprawdzenia, czy nie doszło do kradzieży, ale chodzi o zrozumienie, co aktualnie posiadamy i czego nam brakuje.
Inwentaryzację projektową powinno stosować się regularnie, ale najczęściej w kluczowych kamieniach milowych.
Przykład inwentaryzacji w testowaniu - inwentaryzacja informacji o aplikacji na początku projektu.
Kiedy zaczynamy projekt warto pozbierać wszelkie dostępne o nim informacje. Służą do tego zarówno rozmowy z udziałowcami, jak Intranet i Internet. Mamy wiele pytań do zadania i wiele odpowiedzi do pozbierania:
a. Co to za produkt?
b. Kto jest jego odbiorcą?
c. Jak jest dostarczany?
d. Czy rynek już o nim słyszał? Czy są podobne produkty konkurencji?
e. Jakie są ryzyka związane z produktem?
f. Co wyróżnia go na rynku?
g. Jakie środowiska wspiera?
etc.
Do tego musimy zebrać linki lub dokumenty opisujące nasz produkt. Mogą to być formalne specyfikacje, ale mogą to być również opisy fragmentów funkcji wyciągnięte np. z repozytorium defektów.
O aplikacji musimy wiedzieć WSZYSTKO.
Jeśli jednak po przeprowadzeniu inwentaryzacji mamy przekonanie lub pewność, że czegoś nie wiemy, to w inwentaryzacji również warto to zawrzeć. Będzie to przypominacz, że warto szukać tej informacji w trakcie trwania projektu.
Aby zebrać w jednym miejscu wszelkie krytyczne informacje zbudowałem heurystykę, która pokazuje źródła informacji o aplikacji.
- Specyfikacje - wszelkie formalne dokumenty opisujące aplikację;
- Misja - pełne zrozumienie celu naszej aplikacji i co ma ona osiągnąć;
- Interesariusze biznesowi i projektowi - wszystkie osoby zaangażowane pośrednio i bezpośrednio w projekt, w tym działania konkurencji;
- Lista defektów - informacje z repozytorium defektów, w tym komentarze odnośnie naprawienia defektu;
- Groźby - zewnętrze i wewnętrzne zagrożenie dla aplikacji (również ryzyka);
- Internet / Intranet - informacje o aplikacji z sieci;
- Nauka - zdobywanie wiedzy o konstrukcji, architekturze i działaniu oprogramowania.
Zupełnie niespodziewanie powstała heurystyka inwentaryzacji informacji - SMILGIN :)
Jeśli kiedykolwiek przyjdzie Wam do głowy, że warto zebrać wszystkie posiadane informacje projektowe w jednym miejscu; kiedy dokonacie analizy tych informacji z uwzględnieniem co wiecie i czego jeszcze nie wiecie, pomyślcie, że właśnie robicie inwentaryzację.
