Czy naprawdę istnieje związek między liczbą osób przypisanych do projektu a liczbą wad?

Oto cytat z podręcznika szkoleniowego w pracy dotyczący SLIM i szacowania oprogramowania:

Zauważ też, że istnieje korelacja między Wysiłkiem a Defektami. Oznacza to, że im więcej osób zostanie przypisanych do projektu o danym rozmiarze, tym więcej będzie Defektów.

Wysiłek to osobiście (osobo-lata, osobo-miesiące) dla projektu. Defekty to liczba defektów wykrytych w dowolnym momencie cyklu życia. Rozmiar jest definiowany jako przypadki użycia, punkty funkcyjne lub SLOC, które składają się na projekt.

Wydaje się to sprzeczne z intuicją, zakładając dobry proces i zdolnych inżynierów. Na przykład posiadanie większej liczby osób oznacza więcej oczu na wszystkie artefakty (specyfikacje wymagań, projekty, kod, testy). Poza tym, że mam więcej oczu, moja intuicja sugeruje, że istnieje niewielki związek między wysiłkiem a wadami w projekcie wykorzystującym odpowiednie techniki jakości.

Nie byłem w stanie znaleźć żadnych dokumentów poza tymi o modelu Putnam (używanym przez SLIM), które sugerowałyby jakikolwiek znany związek między defektami a wysiłkiem lub defektami i liczbą ludzi w projekcie. Czy jest to znany związek i czy twierdzenie, że „więcej osób = więcej wad” jest słuszne?

Moja intuicja wygląda następująco:

Im więcej osób jest przypisanych do projektu o danym rozmiarze, tym większy jest narzut komunikacji
=> większe szanse na nieporozumienia i wszelkiego rodzaju problemy komunikacyjne
=> większa liczba powstałych defektów.

I

Dobrzy programiści są rzadsi, dlatego trudniej je znaleźć i zatrudnić, niż przeciętni / źli
=> im więcej osób jest przypisanych do projektu o danym rozmiarze, tym niższy ich średni poziom kompetencji
=> im wyższa liczba powstałych wad.

Ale to może być tylko moje rozumowanie, nie mam żadnych dowodów potwierdzających.

Na marginesie: podkreślone poniżej założenia są dość mocne, biorąc pod uwagę stan naszego zawodu:

Wydaje się to sprzeczne z intuicją, zakładając dobry proces i zdolnych inżynierów . [...] moja intuicja sugeruje, że istnieje niewielki związek między wysiłkiem a wadami w projekcie wykorzystującym odpowiednie techniki jakości .

To może być tylko korelacja. Kierownictwo ma tendencję do przydzielania większej liczby osób do pomocy w projektach, które ich zdaniem będą bardziej złożone, lub w projektach, które pozostają w tyle z powodu wielu nieprzejednanych błędów lub projektach, które wymagają wielu powiązań między różnymi komponentami. Jeśli mógłbyś podjąć decyzje zarządcze z mieszanki, podejrzewam, że korelacja przynajmniej by się zmniejszyła, jeśli nie odwróci.

Biorąc pod uwagę ostatnio zaktualizowane definicje wielkości i wysiłku, sugerowałbym, że być może wyniki wynikają z faktu, że Wysiłek (całkowity roboczogodzin) jest w rzeczywistości lepszym oszacowaniem rzeczywistej wielkości projektu niż miary stosowane przez źródło (Wysiłek byłby idealna miara, jeśli wszystkie zespoły i zasoby drużyny były równoważne).

Dlatego tak naprawdę dzieje się tak, że większe projekty mają więcej wad, co wcale nie jest zaskakujące.

Wydaje się to sprzeczne z intuicją, zakładając dobry proces i zdolnych inżynierów.

Nie sądzę, aby można było założyć jedno z nich w prawdziwym świecie. Im więcej osób w projekcie, tym większe prawdopodobieństwo, że będziesz mieć złe jabłka, które nie nadążą i spowolnią najlepszych programistów. Nawet jeśli przyjmiesz założenia, istnieje kilka innych rzeczy, które spowalniają projekty i powodują więcej defektów w miarę zwiększania liczby osób:

• koszty ogólne komunikacji
• ogólne czytanie kodu (przez to rozumiem, że nawet najlepsi deweloperzy poświęcają więcej czasu na czytanie i konsumowanie kodu innych ludzi niż własnego)
• testowanie musi być dokładniejsze (wszyscy strzelamy do 100% pokrycia testowego, ale rzadko zdarza się to w prawdziwym świecie. Im więcej osób angażuje się w projekt, tym bardziej przerażające jest refaktoryzowanie bez wyjątkowo dokładnych automatycznych testów, ponieważ tylko ma się nadzieję, że zmiany nie będzie mieć skutków ubocznych. Nie wszystkie testy można nawet zautomatyzować w rozsądny sposób, co zajmuje jeszcze więcej czasu.

Z mojego doświadczenia wynika, że ​​negatywne skutki projektów załadowanych programistami spadają, gdy projekt jest bardzo modułowy i masz tylko 1 lub 2 osoby na poziom. Nie dbam o to, jakiego systemu kontroli wersji używasz, ponieważ 4 programistów, którzy automatycznie łączą się do tego samego pliku, prawdopodobnie będzie złym pomysłem.

Istnieje różnica między korelacją a przyczyną; cytat wydaje się mówić, że całkowita liczba wad jest zwykle wyższa w przypadku projektów, w których przydzielono większą liczbę inżynierów. Ma to dla mnie idealny sens, jestem pewien, że MS Windows ma więcej wad niż aplikacje, które tworzę, ale to nie znaczy, że moje aplikacje są najwyższej jakości.

Podając inny, bardziej abstrakcyjny przykład - jeśli weźmiemy całkowitą liczbę zgonów na kraj i skorelujemy to z całkowitą liczbą lekarzy w tym kraju, jestem pewien, że możemy powiedzieć „kraje z większą liczbą lekarzy poniosły więcej zgonów”. Nie byłoby tak dlatego, że lekarze spowodowali śmierć, ale raczej, że duża liczba lekarzy wskazuje na dużą populację.

Odłóżmy na chwilę twierdzenie o liczbie osób.

Przyjęcie liczby wstrzykniętych defektów jako funkcji wysiłku może mieć sens, o ile zakładasz, że zwiększony wysiłek koniecznie wymaga zwiększenia rozmiaru, ponieważ istnieje silna korelacja między liczbą defektów a rozmiarem oprogramowania.

Jeśli więc założymy, że im więcej wysiłku włożymy w projekt, tym więcej wierszy kodu zostanie zapisanych, prawdopodobnie można użyć wysiłku jako proxy dla rozmiaru, aby przewidzieć liczbę defektów. Korelacja między wielkością (np. LOC) a liczbą defektów była wielokrotnie pokazywana w pracy Watts Humphrey, Capers Jones i innych.

Nie rozumiem, jak wiele osób pasuje, poza tym, że więcej ludzi oznacza większy wysiłek.

Na marginesie, nie myl korelacji z przyczynowością. Podczas gdy istnieje korelacja między wielkością a liczbą wstrzykniętych wad, rozmiar nie jest przyczyną. Przyczyna zwykle pochodzi, jak zauważyłeś, z ludzi i problemów procesowych. To powiedziawszy, defekty jako funkcja wielkości są świetną miarą do zrozumienia, czy istnieje problem i do oceny skuteczności zmiany.

Zakładam, że ogranicza się to do członków głównego zespołu programistycznego, a nie do sytuacji, w której są specjaliści: UI, UX, DBA itp.

Myślę, że trzeba to dobrze zarządzać, ale to nie jest łatwe. Małe zespoły złożone z wysokiej jakości programistów mogą same zarządzać. Bardziej prawdopodobne jest unikanie dużych fragmentów kodu tworzonych przez osoby o mniejszych talentach.

Posiadanie większej liczby członków zespołu może ułatwić podział obowiązków. Umieść lepszych lub bardziej doświadczonych devloperów na trudnych obszarach. Odrzuć część przyziemnych lub nieprogramowych zadań od swoich lepszych programistów i pozwól młodszym deweloperom poradzić sobie z przerwami. To zajmie więcej planowania i przemyślenia, ale daje szansę na wykorzystanie twojego talentu.

Istnieje opinia, że ​​lepiej mieć świetnego programistę, który musi podnieść nową umiejętność, niż twórca poniżej średniej, który już ją zna. To świetnie, jeśli masz czas. Prawdopodobnie powodem, dla którego więcej projektantów jest przypisywanych do projektu, jest ilość pracy wymaganej i ograniczenia czasowe. Możesz mieć kogoś, kto może skupić się na określonym obszarze i stać się bardziej wykwalifikowanym. Wspaniale jest mieć tę wszechstronną wiedzę, ale czasami z małym ukierunkowaniem mniejszy twórca może przyjąć instrukcje i biegać z nią.

W rzeczywistości nie ma wielu ludzi, którzy kiedykolwiek zarządzali dużym zespołem przy udanym projekcie. Nawet jeśli wszyscy są utalentowani, duże zespoły mają trudności z samodzielnym zarządzaniem. Czy ego przeszkadzają?