Jarek Żeliński:
Moim zdaniem problematyczne są ogólne wskaźniki z uwagi na mityczną wydajność człowieka. Nie wyobrażam sobie jakiejkolwiek wyceny bez wiedzy o wydajności człowieka (dobrej znajomości wykonawców) i bez wiedzy o przedmiocie do wykonania. Wymaga to dwóch rzeczy: dobrego projektu oraz własnego zespołu lub kontraktowania na dzieło (pytamy za ile na kiedy "ktoś" coś dla nas wykona). Dlatego wycena projektu w wielu przetargach (gdzie nie ma szczegółowego projektu i nie znani są jeszcze wykonawcy) zawsze mnie zadziwia.
W FP liczone są realne funkcje - akcje, które wykonuje program i które składają się na pożądany skutek biznesowy. Inaczej mówiąc liczy się to co program robi i co jest intencją użytkownika. Nie liczy się tego co program robi dodatkowo i co nie było intencją użytkownika.
Na przykład: wyświetlenie profilu użytkownika może się składać z pokazania wyszukiwarki, kliknięcia "szukaja" i kliknięcia w wybraną osobę. Pokazanie tej osoby jest intencją użytkownika i to jest ta funkcja. Funkcją tą nie jest pokazanie wyszukiwarki czy szukanie samo w sobie, lista wyszukanych osób nie ma żadnego biznesowego znaczenia.
Z tym jest duży problem - architekci, analitycy i biznes musi umieć liczyć te punkty, mieć w tym doświadczenie oparte na wynikach z przeszłości - ciągłe udoskonalania.
Z uwagi na wiek metody liczone są staromodne funkcje i operacje na rekordach danych itp. Równie dobrze zamiast funkcji użytkownika można liczyć use case-y, do tego chyba nawet powstał wariant metodyki oparty właśnie o UCki.
osobiście spotykałem się z dwiema skutecznymi metodami:
- wycena na bazie "standardowego use case" z dobrą wiedzą o własnym zespole (liczba use case razy ryczałtowy koszt)
- wycena ba bazie modelu klas (klasy dostawały wagi na bazie wielkości interfejsu, to co potrafi framework wchodziło ryczałtem).
FP można szacować na kilku etapach: od planowania biznesowego po szczegółowe planowanie technikaliów. Metoda zakłada pewien procentowy rozstrzał i przeszacowanie. Na najwyższym poziomie jest to bodajże 50% - to wystarczy, żeby zaklepać kasę i wstępnie oszacować harmonogram.
w obu przypadkach do wyceny wymagany jest dobry projekt i to jest przeszkoda tam, gdzie "projektów nie robimy" (agile coś tam i extreme coś tam, wybaczcie sarkazm.... ale mam podstawy).
Dobry projekt tak - z tego się powinno liczyć punkty, ale można też szacować je wcześniej. I co więcej - mając wielu dostawców możesz się z nimi rozliczać z punktów funkcyjnych. Ty sobie szacujesz najpierw od najwyższego poziomu po poziom projektu technicznego. Dostawca realizuje i przedstawia własną wycenę w FP. Jeśli odbiega od Twoich szacunków zbyt mocno to zlecasz audyt firmie zewnętrznej.
Z takim dostawcą można w umowie uzgodnić stawkę za jeden FP. Taki punkt trzeba odpowiednio dostroić w zależności od technologii, obszaru i może kilku innych czynników. Do tego są VAFy (Value Adjustment Factor) i z tym jest właśnie związany drugi największy problem, bo o ile do samych punktów funkcyjnych są jakieś konkretne wytyczne to VAFy trzeba sobie dostosować samodzielnie, najlepiej udoskonalać je w cyklicznym procesie.
Jeśli wyjdzie taka sytuacja, że dostawca niedoszacował FP to może (jeśli ma coś do gadania) próbować dochodzić swego wskazując ostateczne wyliczenie na bazie gotowego kodu. Jest to ścieżka bardziej formalna niż ściemy i tłumaczenia się na bazie tradycyjnego harmonogramu. Takie ewentualności można uregulować w umowie.
Jeszcze o jednym. W VAFach zaszyta siedzi ta mityczna wydajność ludzka, o której pisałeś na początku. Zostawia się ją w domyśle, żeby nie mówić o niej w ogóle. Krótko mówiąc pracochłonność jednego punktu funkcyjnego musi zależeć od zdefiniowanych VAF-ów (dla technologii, obszaru itp), a nie od ludzkiego widzimisię - programista sprowadzony do średniej, jego wydajność zależy od tego czym się zajmuje. Przykład: zaprogramowanie jednego FP w Javie (technologia) dla systemu CRM (obszar) być może wyjdzie efektywniej niż programowanie tego CRM-a w PHP.
Moim zdaniem wiec wycena na bazie np. FP wymaga kaskadowego procesu, który wcale nie jest zły...
Jedno i drugie jest dobre, złoty środek będzie najlepszy. Można stosować kaskadowe podejście w procesie iteracyjnym. Robienie na pałę bez ogarnięcia wymagań to zbrodnia (chociaż w małej skali może być zupełnie nieszkodliwa).
Na koniec moje summary o punktach funkcyjnych:
+ precyzyjniejsza od mandaysów
+ uniemożliwia ukrywanie dodatkowych kosztów
+ umożliwia porównywanie własnej efektywności względem innych firm z całego świata (porównuje się w skrócie stawkę za jednego FP, stąd widać czy nie przepłacamy)
- koszt wdrożenia jest duży, wymaga zmiany podejścia, wdrożenie może być bolesne
- pełne wdrożenie i doszlifowanie wszystkiego trwa długo - metoda musi być przetestowana i doprecyzowana przynajmniej w kilku podejściach
- nowość na naszym podwórku, mimo że w USA stosowane od 20? lat, brakuje dobrych firm konsultingowych, audytowych, szkoleniowych, brakuje specjalistów, architektów, analityków
- moim zdaniem trudno wdrożyć metodę bez zewnętrznego konsultingu i szkoleń
.. to się rozpisałem.
Kontynuacja, kilka luźno sformułowanych dodatkowych ficzerów:
1. Mając wyliczone FP można pilnować jakości -> czy ilość błędów w testach na punkt funkcyjny jest w normie czy nie?
2. Moc zespołu analityków, projektantów, architektów, programistów i nawet zewnętrznych dostawców można wyrazić w punktach funkcyjnych na rok lub miesiąc, jak kto woli.
3. Można sprawdzać czy dany dostawca nie próbuje wziąć roboty ponad swoje siły.
4. Gromadzone dane historyczne mogą służyć jako baza do optymalizacji -> jedna technologia jest tańsza od innej w danym obszarze, jedna firma jest efektywniejsza i ma lepszą jakość od innej, itp
Koniec.
Przemek Wiśniewski edytował(a) ten post dnia 09.08.10 o godzinie 15:56
пропозиції роботи
