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

11

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?

Frank Puffer
źródło
7
99% całego rozwoju oprogramowania poza obszarami takimi jak jądra zostało zrobione tysiące razy wcześniej. Zdecydowanie zbyt wielu programistów chce robić wszystko w nowy, wymyślny sposób, ciągle wymyślając na nowo te same stare problemy.
Wygięty
@ Bent: Czyli mówisz, że tworzenie oprogramowania polega głównie na kopiowaniu i wklejaniu? Wiem, że wielu programistów działa w ten sposób i często odkrywa, że ​​prowadzi to do niemożliwego do utrzymania kodu. Ale to inna historia. Nawet jeśli ktoś tak działa, musi dowiedzieć się, co skopiować i skąd. To również uważam za pracę badawczą.
Frank Puffer
1
@rwong: Oczywiście sensowne jest używanie bibliotek. Ale znalezienie właściwej funkcji w bibliotece i odpowiedniego sposobu jej użycia to albo praca badawcza (jeśli lib jest skargą i / lub nie znasz go dobrze), albo trywialna (jeśli nie znasz tej funkcji). To, co nazywacie „kodem kleju”, jest według mnie często skomplikowane. Wdrożenie go nie jest konieczne rutynową pracą.
Frank Puffer
1
@ JohnR.Strohm: Nie czytałem tych konkretnych książek, ale znam podstawy COCOMO - jednak nigdy nie korzystałem z nich w praktyce. Przeczytałem także dwie lub trzy inne książki DeMarco. Czy mógłbyś podpowiedzieć, jaka konkretna treść jest związana z moim pytaniem?
Frank Puffer
2
@FrankPuffer, „Software Engineering Economics” firmy Boehm jest wymagany do oszacowania oprogramowania. Książka Demarco nie jest daleko w tyle. KRÓTKA odpowiedź brzmi: jeśli jesteś wystarczająco zaznajomiony z tym, co oprogramowanie musi zrobić, aby CAŁKOWICIE oszacować, jesteś na tyle zaznajomiony, aby uznać to za rutynowe.
John R. Strohm,

Odpowiedzi:

11

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.

  1. 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

  1. 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.

Ewan
źródło
Absolutnie zgadzam się z tym, co napisałeś o nieodpowiednich wymaganiach, ale to inna historia. W pierwszej części odpowiedzi mówisz, że często używasz dobrze znanych technik, aby większa część pracy stała się rutyną. Celowo robisz to bez dodatkowych abstrakcji. Prawdopodobnie działa to dobrze przez krótki czas, może 2-5 lat, w zależności od używanych technologii. Ale wtedy możesz zauważyć, że nie poprawiłeś swojego procesu tak bardzo, jak niektórzy konkurenci. Również inni programiści, którzy utrzymają Twój kod później, mogą mieć problem.
Frank Puffer,
Oczywiście to nie tak, że nigdy nie używam rzeczy innych firm. Chodzi o to, że jeśli wiesz, jak zrobić coś już za pomocą narzędzia X, oszacowanie jest łatwe
Ewan
W tym przypadku nie tylko oszacowanie, ale także wdrożenie staje się łatwe. Jeśli cały twój projekt jest taki, masz szczęście. Ale w moim eksperymencie dzieje się tak tylko w małych projektach. Wszystkie większe (> 10 dni) projekty, w które byłem zaangażowany, wymagały nowych koncepcji lub technologii i to właśnie spowodowało większość pracy, czyniąc wysiłek w zakresie standardowych rzeczy pomijalnymi.
Frank Puffer
Nie wdawajmy się w wojnę z płomieniem „kto jest najlepszym programistą”. Im więcej mówię, tym więcej rzeczy zrobiłeś przed mniejszą ilością nowych rzeczy. Jeśli wszystkie twoje projekty wymagają użycia nowych technologii do większości funkcji ... Wydaje się to dziwne
Ewan
@Ewan „koncepcje lub technologie”. Dla mnie ten pierwszy odnosi się do reguł biznesowych i / lub tego, czego chce projektant. Nie chodzi tylko o nowe technologie.
Izkata,
6

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.

candied_orange
źródło
Dobra uwaga, więc zasadniczo mówisz, że oszacowanie powinno opierać się na wartości, jaką dana funkcja ma dla klienta (lub właściciela produktu). Osobiście podoba mi się to podejście, ale z mojego doświadczenia nie wynika, że ​​estymacja oprogramowania jest ogólnie rozumiana, nawet przy zwinnym ustawieniu. Wadą jest to, że często nie masz informacji o wartości funkcji przez klienta. Kolejną wadą jest to, że nie obsługuje pakietów roboczych, które nie skutkują bezpośrednio funkcją widoczną dla klienta.
Frank Puffer
@FrankPuffer Nie zgadzam się, że zwinne metody tego nie wyjaśniają. W szczególności SCRUM nawet nie prosi deweloperów o oszacowanie, dopóki wartość funkcji nie będzie tak wysoka, że ​​faktycznie planuje się ją wykonać, to znaczy w samą porę. Do tego szczególnie nadają się metody zwinne: najpierw zidentyfikuj funkcje o najwyższej wartości biznesowej, następnie oszacuj je, a następnie ZRÓB ICH i sprawdź, ile czasu to faktycznie zajęło. Powtórz płukanie. Po kilku cyklach będziesz miał bardzo dobre wyobrażenie o szacunkowym i faktycznym czasie tworzenia.
RibaldEddie