Ilość rutynowej pracy przy tworzeniu oprogramowania i jej wpływ na szacowanie

Jestem przekonany, że ilość rutynowej pracy przy opracowywaniu oprogramowania jest - i powinna być - stosunkowo niewielka, jeśli nie pomijalna, i że jest to podstawowy problem oceny oprogramowania.

Pozwól mi opisać, w jaki sposób doszedłem do tego wniosku i powiedz, czy argumentacja ma jakieś poważne wady:

1. Wszystko, co można oszacować z dużą dokładnością, to rutynowa praca, co oznacza rzeczy, które zostały zrobione wcześniej. Nie da się oszacować wszystkich innych rodzajów pracy związanych z badaniami i kreatywnością, przynajmniej nie z dokładnością, powiedzmy, +/- 20 procent.

2. Rozwój oprogramowania polega na unikaniu powtarzalnych zadań. Jedną z jego podstawowych zasad jest OSUSZANIE (nie powtarzaj się). Ilekroć programista odkrywa, że ​​robi powtarzalne rzeczy, czas znaleźć abstrakcję, która unika tego powtarzania. Abstrakcje te mogą być prostymi rzeczami, takimi jak wyodrębnianie powtarzającego się kodu do funkcji lub umieszczanie go w pętli. Mogą być również bardziej złożone, np. Tworzenie języka specyficznego dla domeny. W każdym razie ich wdrożenie będzie wymagało badań (czy ktoś już to wcześniej robił?) Lub kreatywności.

Z tych dwóch punktów wyciągam powyższy wniosek.

Właściwie od dłuższego czasu zastanawiam się, dlaczego ta relacja nie jest wspomniana w każdej innej dyskusji, poście na blogu lub w artykule na temat oceny oprogramowania. Czy to jest zbyt teoretyczne? Czy moje założenia są błędne? A może jest to zbyt trywialne - ale dlaczego większość znanych mi deweloperów uważa, że ​​mogą dokonywać oszacowań z dokładnością wynoszącą +/- 20 procent lub więcej?

Może to być prawda w każdym danym projekcie. Jeśli jednak przez lata pracujesz nad wieloma podobnymi projektami dla różnych firm, może się okazać, że „rozwiązujesz” w zasadzie ten sam problem wiele razy z niewielkimi różnicami.

Na przykład pisałem warstwy dostępu do danych tak wiele razy, że wolę teraz robić to z „długich rąk” niż korzystać z popularnej ORM miesiąca. Szybsze i łatwiejsze jest mi radzenie sobie z „rutynowymi problemami” za pomocą znanych rozwiązań, niż znajdowanie i rozwiązywanie nowych dziwactw w komponentach innych firm.

Oczywiście mógłbym napisać własny ORM, aby uprościć powtarzający się kod bez dodawania nieznanych dziwactw w czyimś systemie, ale ten kod należałby do firmy, w której wtedy pracowałem, a inni programiści uznaliby go za równie dziwaczny jak wszelkie inne ORM stron trzecich.

Podobnie z mojego doświadczenia wynika, że ​​większość programów to automatyzacja procesów biznesowych i chociaż każda firma lubi myśleć, że ich procesy są dla nich unikalne; W rzeczywistości tak nie jest.

Nie mówiąc już, że oszacowanie jest łatwe! Jest to łatwiejsze, ale uważam, że w dzisiejszych czasach problem z oszacowaniem wynika raczej z nieodpowiednich wymagań niż z czasu poświęcanego na kodowanie.

Wymagania dzielą się na trzy kategorie:

1. Niejasne, szczegóły pozostawiono twórcy.

„Zrób mi stronę internetową, musi być fajna i sprzedawać moje widżety”

Zazwyczaj są one najłatwiejsze do oszacowania, ponieważ gdy pojawia się trudny nieoczekiwany problem, możesz po prostu zmienić wymagania na funkcjonalnie równoważne i uniknąć problemu.

2. Bardzo specyficzny

„Zmień kolor tła nagłówka # ff1100”

Bardzo szybki i znów łatwy do oszacowania. Ale! wymóg musi się zmienić. „Hmm nie, po zastanowieniu, spróbuj tego drugiego” lub „Czekaj! Miałem na myśli tylko na tej jednej stronie!” więc czas rzeczywisty „jak długo będę zadowolony z koloru nagłówka” nie ma nic wspólnego z szacunkami kodowania

3. Niejasne, szczegóły założone

„Zrób mi stronę internetową (podobnie jak Facebook)”

Tutaj mnogość niepotwierdzonych założeń: „oczywiście będziesz potrzebować innego logo”, „powinna mieć nieskończone przewijanie”, „musi być skalowalna dla 1 miliarda użytkowników!” skutecznie kontrolować wycenę. Albo deweloper myśli o wszystkim i przesuwa szacunek ponad oczekiwania „1 meeelion roboczogodzin”, albo myślą / zakładają, że wymagane są tylko podstawowe cechy i dają zbyt niskie oszacowanie. „och, tydzień czy dwa, zakładam, że chcesz po prostu umieścić facebooka w ramce iframe, prawda?”

Z doświadczeniem kodowanie jest bardzo szybkie, ale wymagania projektowe są (zwykle) twarde, a to jest coraz bardziej przenoszone z powrotem na niekodujących. Dzięki zwinnym metodologiom zwiększającym prędkość kodowania, przenosząc tę ​​odpowiedzialność na „biznes”, a nie na programistów.

dlaczego większość programistów, których znam, uważa, że ​​mogą dokonywać oszacowań z dokładnością wynoszącą +/- 20 procent lub więcej?

Ponieważ naszą cierpliwość oceniamy znacznie bardziej niż problem rzeczywisty.

Jeśli mam animować odbijanie się piłki, mógłbym spędzić na niej dzień, tydzień, miesiąc lub rok i nadal mieć animację odbijającej się piłki. Mam nadzieję, że tym lepiej będzie wyglądać, im więcej czasu na to spędzę, ale w pewnym momencie jestem niedorzeczny.

Ile wysiłku wkładam w odbicie piłki, jest funkcją czasu, który można na nią poświęcić. Jeśli mój poziom umiejętności nie obniży go, mogę skończyć z piłką, która tam siedzi. Ale kiedy nadejdzie ostateczny termin, czy powinienem pozwolić mu się poślizgnąć, czy przynajmniej dostać piłkę na ekranie? Wodospad nalegał na odbicie piłki, więc harmonogram się zmienił. Zwinny mówi, że po prostu weź piłkę. Przynajmniej dowiemy się, ile ludzi zależy na odbijaniu się. Jakość spadła.

Staram się mieć pewność, że moje kule odbijają się, ale kiedy nadejdzie termin, lepiej jest wytworzyć piłkę statyczną niż nic. Dlatego szacuję czas na podstawie rozsądnego czasu na problem, zanim zacznę mówić o alternatywach. Czasami piłka po prostu nie odbije się. Czasami to jest OK. Znikanie na miesiąc nie jest w porządku.