Spisu treści:
oszacowanie projektu oprogramowania
Pixabay
Wprowadzenie
Oszacowanie jest po prostu trudne. Niestety jest to również bardzo potrzebne. Firmy wykorzystują szacunki do planowania harmonogramów wydań, podejmowania zobowiązań wobec swoich klientów, decydowania o tym, czy proponowana funkcja jest warta wdrożenia, śledzenia szybkości pracy zespołów i skutecznego ustalania priorytetów pracy. Kierownictwo często chce wiedzieć, kiedy funkcja lub element dostawy będzie gotowy do produkcji. W końcu tworzenie oprogramowania nie jest trywialną inwestycją. Bez szacunków, jak kierownik projektu dokonałby oceny? Gdyby ludzie potrafili dokładnie przewidzieć przyszłość, w 2% przypadków ludzie nie wygrywaliby w wyścigach konnych. Szacowanie to wielka zagadka. Firmy muszą prosić swoich ludzi o zrobienie niemożliwego: przewidywanie przyszłości.
Najpierw przejrzyjmy kilka popularnych metod szacowania (na wypadek, gdybyś przegapił niektóre emocje). Następnie możemy przyjrzeć się, co to oznacza dla nas i naszych projektów.
Model wróżbity
Ten model nie wymaga prawie żadnego wysiłku do oszacowania. Estymatorzy zastanawiają się przez chwilę, co należy zrobić, aby zaimplementować i przetestować funkcję, a następnie wyrzucają liczbę. Brzmi trochę jak „… (długa pauza)… Ummmmm… 6 tygodni”. Następnie wszyscy przytakują i idziemy dalej. Mogliby spędzić sporo czasu na przednim końcu, omawiając to, co wiedzą o wymaganiach (co prawdopodobnie nie jest pełnym obrazem). Ta dokładna analiza sprawia, że ich szacunki są bardziej wiarygodne. Pod koniec projektu zawsze istnieje przyjęte uzasadnienie, dlaczego oszacowanie było tak dalekie od rzeczywistości. Zawsze istnieją nieprzewidziane okoliczności, które mogą służyć jako kozioł ofiarny. Często nikomu nie przychodzi do głowy, że model jest poważnie uszkodzony.
Jak więc możemy ulepszyć ten proces? Wiem! Możemy użyć techniki dekompozycji (tj. Dziel i zwyciężaj). To podejście zakłada, że znasz pełny zakres funkcji lub projektu w interfejsie. Każda funkcja jest podzielona na małe fragmenty. Każdy fragment jest szacowany (styl wróżki), a następnie dodajemy je, aby uzyskać ogólną ocenę funkcji / projektu. Jest to z pewnością bardziej skomplikowane podejście, ale wydaje się lepsze z dwóch powodów:
- Mniejsze fragmenty pracy są zwykle łatwiejsze do rzetelnego oszacowania.
- Chociaż nadal istnieje możliwość popełnienia błędu (+/- pewna kwota), istnieje założenie, że błędy będą się wzajemnie eliminować, gdy zsumujesz je, a otrzymasz bardziej wiarygodne oszacowanie ogólne.
Podstawową wadą tego podejścia jest to, że indywidualni współpracownicy (ludzie, którzy faktycznie wykonują pracę) powszechnie nie doceniają. Nadal są znacznie lepsi niż te nad nimi i wokół nich, ale to nie jest wysoka poprzeczka. Nie wydaje się, aby tak było, ponieważ wszyscy widzieliśmy przypadki, w których programiści zaskoczyli się, wykonując coś przed terminem. Ale to jest pojedynczy punkt danych, a nie trend. Ludzie czasami wygrywają w kasynie; wydawaj pieniądze w kasynie codziennie przez rok, a będziesz mieć mniej pieniędzy niż na początku. Jeśli śledzisz szacunki względem wartości rzeczywistych przez rok lub dwa, odkryjesz, że szacunki nie odpowiadają rzeczywistości. Podczas gdy wielu biznesmenów jest absolutnie przekonanych, że programiści leniwie uzupełniają swoje szacunki i wykorzystują dodatkowy czas na „pozłacanie” lub sprawdzanie swoich zapasów,dane pokazują inaczej. Strategia „anulowania” nie działa.
I co teraz? Porzućmy model wróżki i przejdźmy do podejścia opartego na rozmiarze. Okazuje się, że chociaż ludzie są okropni w szacowaniu czasu ukończenia, w rzeczywistości jesteśmy całkiem dobrzy w określaniu, jak duże jest coś. Jesteśmy szczególnie dobrzy w określaniu wielkości porównawczej („jest większy, ale mniejszy niż tamto”). Jeśli myślimy raczej w kategoriach rozmiaru lub złożoności niż czasu, nasz mózg przetwarza to bardziej niezawodnie. Następnie możemy wziąć wartości rozmiaru i obliczyć rzeczywistą liczbę godzin projektu na podstawie sprytnej magicznej formuły! I wtedy na scenę wkracza popularny model punktów funkcyjnych (scena po lewej).
Analiza punktów funkcyjnych (FPA)
Do analizy punktów funkcyjnych musimy zidentyfikować pięć typów rzeczy w naszej aplikacji: zewnętrzne dane wejściowe, zewnętrzne wyjścia, zewnętrzne zapytania, zewnętrzne pliki interfejsów i wewnętrzne pliki logiczne (nie martw się zbytnio o definicje; możesz je zbadać później). Każdy ich przykład (funkcja) ma związaną z nim złożoność (niski, średni lub wysoki). Korzystamy z poniższej tabeli, aby obliczyć, ile punktów przypisuje się każdej funkcji.
Teraz, jeśli zsumujemy punkty dla wszystkich naszych funkcji, możemy otrzymać liczbę taką jak 457 punktów funkcyjnych dla naszego projektu. Następnie potrzebujemy tylko wzoru, aby obliczyć liczbę godzin… Opierając się na naszym ostatnim projekcie, nasz „wskaźnik dostaw” wyniósł 15 punktów funkcyjnych na osobę miesięcznie. To mniej więcej 30 osobomiesięczna praca, co powinno zająć trochę ponad dwa i pół miesiąca dla mojego 12-osobowego zespołu. Ta-da!
Jest to z pewnością bardziej złożone niż nasz poprzedni model. W rzeczywistości istnieją cztery kluczowe obszary złożoności do rozpoznania.
- Pięć typów komponentów niekoniecznie jest intuicyjnych i łatwo zapomnieć o umieszczeniu czegoś na liście lub przypisaniu tego do niewłaściwego segmentu.
- Tabela używana do generowania punktów funkcyjnych zawiera magiczne liczby, których walidacja wymagałaby dużo wysiłku. Czy te liczby są odpowiednio skalibrowane, aby generować wiarygodne szacunki dla moich zespołów?
- Wskaźnik dostaw (kluczowy element układanki) jest obliczany na podstawie produktywności Twojego zespołu. Jak często musimy obliczyć nową liczbę? W rzeczywistości jest bardzo niewiele wskazówek na ten temat.
- Co składa się na niską, średnią lub dużą złożoność? Jak to definiujemy, aby wszyscy to rozumieli? Czy właściwe wykonanie tego zadania nie jest krytyczne dla dokładności naszych obliczeń?
W tym bardzo prostym przykładzie jest kilka ruchomych części, a nie omówiliśmy nawet bardziej skomplikowanych modeli złożoności i innych danych, które mogą wejść w grę (np. Współczynnik kosztów, wskaźnik wsparcia, gęstość defektów itp.). Więcej ruchomych części oznacza więcej możliwości wystąpienia błędów. Czy teraz czynimy oszacowanie zbyt skomplikowane? Nie płacimy programistom za poświęcanie dużej ilości czasu na szacowanie. Nie mogę sprzedać wyceny moim klientom. Potrzebuję działającego oprogramowania. Czy jest coś jeszcze?
Going Agile
Przyjrzyjmy się teraz pokrótce zwinnemu scrumowi (wystarczy, aby zrobić porównanie). Jak wspomniano wcześniej, ludzie źle oceniają czas i całkiem nieźle radzą sobie z porównywaniem rozmiarów. Oto kilka terminów do zrozumienia:
- Sprint - przedział czasowy (zwykle dwa tygodnie).
- Historia użytkownika - dyskretna praca, najlepiej na tyle mała, aby mogła ją wykonać jedna osoba w sprincie. To jest to, co szacujemy.
Najpopularniejszą strategią jest wykorzystanie do oszacowań sekwencji Fibonacciego (0, 1, 2, 3, 5, 8, 13). Nie jest liniowa - wraz ze wzrostem skali wielkość luk rośnie. Kluczowe jest to, że luki powinny być na tyle duże, aby nie było powodu, aby spierać się o nieistotne różnice. Gdy osiągniesz powyżej 3, różnica między 4 a 5 lub 7 i 8 jest tak znikoma, że nie ma sensu tracić czasu na szukanie, który to jest. Działałaby również sekwencja o podstawie 2 (0, 1, 2, 4, 8, 16 itd.).
„Ale czekaj, to tylko liczba. Co to znaczy? Ile godzin to punkt? ” Punkty nie mają bezpośrednio korelować z godzinami, ponieważ gdyby tak było, zespoły kusiłyby, aby wrócić do szacowania godzin, a następnie w jakiś sposób zamienić to na punkty. Jak wspomniano wcześniej, dokładność naszych szacunków wynika z oceny porównawczej i nie szacowania liczby godzin, które coś zajmie. Jeśli dajesz zespołowi możliwość myślenia w kategoriach godzin, narażasz swoją zdolność do dokładnego szacowania.
Powiedzmy, że zacząłeś od ćwiczenia kalibracji. Wciągnij swój zespół do pokoju i przeprowadź go przez listę 10-12 historyjek użytkowników. Wybierz taki, który jest mały, ale nie najmniejszy i zrób to jako pierwszy. Przejrzyj ją i ogłoś, że ta historia to „3”. Nie pytasz. Mówisz. Następnie przejdź do następnej historii. „Jeśli to była trójka, co to jest?” Teraz zespół ocenia historie względem innych historii. W końcu będą mieli całkiem niezłe pojęcie, co stanowi „1”, „2” itd. Nie szacują. Czas nie ma znaczenia. Porównują historie do innych, które mają już numer. Następnie możesz umieścić przykładowe historie dla każdej liczby w sekwencji w dokumencie zwanym linijką. Mogą użyć tego jako odniesienia, jeśli nie są pewni, czym jest „5”.
Oto klucz. Magicznym sosem, który sprawia, że to działa, jest „prędkość” (liczba punktów, które drużyna może zdobyć w sprincie, uśredniona z 3-4 sprintów). Powiedzmy, że Twój sprint trwa dwa tygodnie, a Twój 8-osobowy zespół ma średnią prędkość 35 punktów. Otrzymujesz 35 punktów za 640 godzin pracy (8 x 80 godzin). Jeśli ustalimy, że rozpoczęcie pracy zajmie około 100 punktów pracy, to wiem, że to około 6 tygodni pracy i ~ 1900 godzin. Zespół jest bardzo dobry w konsekwentnym określaniu rozmiarów historii, a Ty wykorzystujesz to do planowania projektu. To obliczenie działa, ponieważ czas trwania jest spójny od sprintu do sprintu.
Aby przeprowadzić długoterminowe planowanie na wysokim poziomie, możesz poprosić potencjalnych klientów, aby podzielili funkcje wysokiego poziomu na tymczasowe, jednowierszowe historie i przypisali im wartości punktowe. Nastąpi utrata pewnej dokładności, ale wykorzystujesz model, który już rozumieją. Bardziej dokładną ścieżką byłaby względna wielkość na poziomie elementu. „Ta funkcja jest większa niż ta 40-punktowa, mniejsza niż 120-punktowa cecha i nieco większa niż 65-punktowa funkcja, którą właśnie zrobiliśmy”. Historie są pogrupowane w „epiki”. Jeśli każda funkcja jest epicka, na końcu będziesz wiedzieć, ile punktów zajęło jej ukończenie. Zachowaj historię tego i możesz jej użyć do planowania wydania.
Wniosek
Obecnie w użyciu jest wiele metodologii. Każdy ma wady i zalety. Musimy w jakiś sposób dowiedzieć się, jak zmaksymalizować dokładność naszych szacunków, abyśmy mogli podejmować dobre decyzje. Nie oznacza to, że nasze szacunki muszą być dokładne. Muszą być tylko na tyle dokładne, aby były przydatne. Jeśli nie rozumiesz szacowania, możesz założyć, że szacunki nie były dokładne, ponieważ zespół nie wykonał dobrej pracy. Nie oszacowali poprawnie lub nie wykonali poprawnie projektu. Bicie będzie trwało do czasu poprawy szacunków. Ale szacunków nigdy nie należy używać jako zobowiązania. To najlepsze przypuszczenie na podstawie ograniczonych informacji, które mamy dzisiaj. Kiedy pojawiają się nowe informacje, musimy pozwolić na ponowne sprawdzenie szacunków. Wszystko inne oczekuje niemożliwego, czyli problemu z przywództwem (a nie zespołem).
Podejście Scruma jest znacznie prostsze niż to, co widzimy w analizie punktów funkcyjnych. I powiedziałbym, że jest o wiele bardziej godny zaufania niż magiczne stoły z magicznymi liczbami. Zapewnia największy zwrot za grosze (minimalny wysiłek przy dość wysokim stopniu dokładności). Z punktu widzenia wysiłku nie tworzy to ciężkiego procesu do zrozumienia i wykorzystania przez zespoły. Oszacowanie zwinności może faktycznie nastąpić bardzo szybko, gdy wszyscy zrozumieją szczegóły szacowanej pracy. Z pewnością jest to lepsze niż wyciąganie liczb z powietrza. Wykorzystanie prędkości ma bardzo ważne znaczenie: wprowadza dane historyczne do obliczeń. Przy każdym sprincie przeliczasz swoją prędkość. Jest to krytyczne, ponieważ z biegiem czasu zmienia się przepustowość. Zespoły, które używają FPA, mogą uzyskać wskaźnik realizacji na podstawie poprzedniego projektu,co w niektórych przypadkach miało miejsce kilka miesięcy temu. Od tamtego czasu prawdopodobnie wiele się zmieniło. Sugeruję, abyś odkrył Agile i naprawdę włożył wysiłek w zrozumienie punktów fabularnych i szybkości. Nie polegaj na szacowaniu w godzinach tylko dlatego, że to właśnie rozumiesz. Wierzę, że podziękujesz sobie później.