Co sprawia, że ​​projekt jest duży? [Zamknięte]

Z ciekawości, jaka jest różnica między małym, średnim i dużym projektem? Czy mierzy się to liniami kodu lub złożonością?

Buduję system barterowy i do tej pory mam około 1000 linii kodu do logowania / rejestracji. Mimo że jest dużo LOC, nie uważałbym go za duży projekt, ponieważ nie jest tak skomplikowany, choć jest to mój pierwszy projekt, więc nie jestem pewien. Jak to jest mierzone?

Złożoność.

Im większa złożoność, tym trudniej jest nauczyć się wszystkiego w projekcie.

Z grubsza, jak bym zgodził się - pamiętaj, że jest to mniej więcej arbitralne. „Rozmiar” projektu składa się z innych czynników, takich jak złożoność, wiersze kodu źródłowego, liczba funkcji / wartość biznesowa itp. Bardzo mały produkt może zapewnić dużą wartość itp. Mówiąc to:

• 2m + sloc to duży do dużego projekt. Są one na ogół tak skomplikowane, że niewielu, jeśli w ogóle, ludzie są „biegli” w całym systemie; raczej odpowiedzialność jest zmodularyzowana wzdłuż struktury kodu. Projekty te często zapewniają ogromną wartość biznesową i mogą mieć kluczowe znaczenie dla misji. Czasem są też pod dużym obciążeniem technicznym i mają inne obawy.

• Sloc 100k - 2m to projekt średniej wielkości. To jest moja podstawa: projekt jest na tyle skomplikowany, że wymaga pewnej wiedzy eksperckiej i prawdopodobnie narodził się do pewnego stopnia techniczny dług; prawdopodobnie zapewnia również pewną wartość biznesową.

• 10–100 tys. To niewielki projekt, ale niezbyt mały, aby mieć wystarczającą złożoność, którą będziesz potrzebować od eksperta; jeśli jesteś open source, zastanów się, czy nie zaufać zaufanym osobom w celu sprawdzenia swoich zobowiązań.

• Wszystko mniej niż 10 tys. Sloców jest naprawdę małe. To nie znaczy, że w ogóle nie może dostarczyć żadnej wartości, a wiele bardzo interesujących projektów ma bardzo mały ślad (np. Camping, którego źródłem jest ~ 2 kb (!)). Osoby niebędące ekspertami mogą generalnie wzbudzać obawy dotyczące wartości - naprawiać błędy i dodawać funkcje - bez konieczności posiadania zbyt dużej wiedzy na temat domeny.

Wielkość projektu mierzy się stopniem niemożności utrzymania.

Złożoność, którą można oszacować na kilka sposobów:

1. Budżet. Projekt z budżetem w wysokości 10 000 000 USD prawdopodobnie różni się znacznie od projektu na przykład poniżej 10 000 USD. Może to obejmować robociznę, oprogramowanie, sprzęt i inne koszty poniesione przy realizacji projektu.
2. Godziny pracy osoby na ukończenie projektu. Czy zajmie to milion godzin czy coś jeszcze? Można to również postrzegać jako czynnik osi czasu, w którym niektóre projekty mogą potrwać lata, które, jak powiedziałbym, były duże w porównaniu do innych, które mogą potrwać krócej niż tydzień. Zauważ, że godziny pracy osoby mogą być mylące, jak ktoś może pomyśleć, podwajając personel, dzięki czemu nad projektem pracuje dwa razy więcej, a następnie harmonogram można skrócić o połowę, co rzadko by mi się wydawało.
3. Ilość sprzętu, innych systemów i osób korzystających z tego, co buduje projekt. Jeśli coś wiąże się ze 101 systemami, może być bardziej skomplikowane, że jeśli jest samodzielne i nie wiąże się z niczym innym.

Chociaż wymagania mogą brzmieć jak dobry sposób na zmierzenie tego, często jest więcej wymagań, które zostaną znalezione, gdy projekt zostanie zrealizowany przy założeniu, że metodologia inna niż Waterfall.

Rozmiar projektu prawdopodobnie najlepiej mierzy się liczbą wymagań systemu, w przypadku których wymagań nie można dalej zmniejszać.

Oczywiście, więcej wymagań w większości oznacza większą złożoność, ale nie zawsze tak jest.

Zmierzyłbym rozmiar projektu na podstawie tego, jak trudno jest postrzegać cały projekt jako pojedynczy duży obraz. Na przykład mam bazę kodu do eksploracji / prototypowania dotyczącą problemu uczenia maszynowego, nad którym pracuję. To tylko 5 000 wierszy kodu, ale wydaje się, że to ogromny projekt. Istnieje mnóstwo opcji konfiguracji, które działają w nieprzewidywalny sposób. Gdzieś w bazie kodu można znaleźć prawie każdy wzorzec projektowy znany człowiekowi, aby zarządzać całą tą złożonością. Projekt jest często nieoptymalny, ponieważ ewolucja bardzo wzrosła i nie jest refaktoryzowana tak często, jak powinna. Jestem jedynym, który działa na tej bazie kodu, ale często jestem zaskoczony tym, jak rzeczy się oddziałują.

Z drugiej strony, jeden z moich projektów hobby ma około 3-4 razy więcej kodu, a jednak wydaje się o wiele mniejszy, ponieważ jest to w zasadzie biblioteka funkcji matematycznych, które są do siebie w większości ortogonalne. Rzeczy nie wchodzą w interakcje w skomplikowany sposób i całkiem łatwo jest zrozumieć każdą funkcję osobno. Łatwo jest zobaczyć duży obraz w takim stopniu, w jakim jest jeden, ponieważ nie ma zbyt wiele jednego do zobaczenia.

Arbitralna odpowiedź: jak duży jest projekt, jak bardzo chciałbyś, abyś zrobił go od samego początku z pozyskiwaniem zdarzeń i SOA. Albo że autorzy systemu przeczytali książkę Evana „DDD: Tackling Complexity in the Heart of Software”;)

Współdziałanie i zakres

Uważam, że złożoność i zakres decydują o tym, jak duży jest projekt. Istnieje jednak kilka wartości niematerialnych, które mogą również wpływać na wielkość projektu.

Wymagania

Największym problemem, z jakim się spotkałem, był brak wymagań. W mojej szczególnej sytuacji kierownik sprzedaży ustalał wymagania. Skupił się na sprzedaży ... muszę dostać sprzedaż. Jego zdaniem to, o co prosił klient, nie wydawało się aż tak skomplikowane, ponieważ zbudowaliśmy coś podobnego. Niejasne wymagania prowadzą do niedocenianych miejsc pracy i przekraczają oczekiwania.

Brak CCMU

CCMU nazywam „ Coo Ca Moo ” (Clear Complete Mutual Understanding). Musisz mieć CCMU ze swoim klientem.

Jeśli masz mały projekt ze słabym CCMU, możesz zakończyć projekt 2,3,4 lub więcej razy. Zatem prosta 20-godzinna praca zamienia się w 60-godzinny projekt ze zestresowanym personelem i bardzo niezadowolonym klientem.

Zakres pełzania

Zdarza się to częściej niż myślisz. Klient decyduje, że skoro już robisz A, B i C, dodanie D lub nawet F. nie powinno być trudne. Jeśli to zachowanie nie zostanie sprawdzone, może również przekształcić mały projekt w projekt średniej wielkości. W zależności od sposobu, w jaki kierownik sprzedaży sprzedał zlecenie, te oczekiwania dotyczące zakresu mogą wydawać się „BEZPŁATNE” dla klienta.

Dziwne, czytając wiele z tych odpowiedzi, widzę, że wielkość projektu widzę zupełnie inaczej. Być może to moja praca w dużej korporacji, ale tendencję do postrzegania wielkości projektu jako raczej skali jego widoczności / pożądania dla klientów (w zależności od obszaru pracy mogą to być współpracownicy lub faktycznie płacący klienci).

Złożoność jest właściwą odpowiedzią, ale jak ją oszacować?

Czynniki to:

1. Punkty rozszerzenia liczą się
2. Liczba warstw modułów (funkcje, klasy, systemy klas, biblioteki, biblioteki współdzielone, aplikacje, aplikacje sieciowe itp.)
3. Liczba zależności (w tym platformy)
4. Funkcje liczenia współzależności.
5. Niezbędne zasoby inne niż kod (w tym grafika / grafika, skrypty sterujące - takie jak skrypty projektowania poziomów - i inne zasoby wymagane do ukończenia wersji aplikacji).

Im więcej ich masz, tym bardziej złożony jest projekt.

LOC jest notorycznie niedokładny w przypadku wielu pomiarów, ale myślę, że próbujesz zmierzyć coś, czego tak naprawdę nie ma dokładnego sposobu pomiaru. Być może alternatywą może być cykliczność .

Ostatecznie jednak uważam, że „bezczelność” projektu jest trudna do oszacowania. To prawie jak pytanie, jak ustalić, czy pies jest duży, czy nie. Nie tylko istnieje wiele sposobów jej pomiaru (masa, objętość itp.), Ale osobiście nie uważam tego za bardzo przydatne. Rzeczywistość jest taka, że ​​moje kryteria będą prawdopodobnie takie jak: „Jak prawdopodobne jest, że ucieknę od tego psa, jeśli zobaczę go w ciemnej uliczce?”

Dla przypomnienia, generalnie nie uważam, że 1k linii kodu to za dużo. Byłby to spory fragment kodu, ale w wielkim schemacie rzeczy nie byłoby tak wiele. Oczywiście przypuszczam, że to zależy od języka. Na przykład 1k wierszy kodu to znacznie mniej kodu w języku takim jak C niż w języku takim jak Pyhon.