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

12

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?

— Thomas Owens
źródło

10

„dodanie siły roboczej do późnego projektu oprogramowania sprawia, że później” - Fred Brooks

— Oded

2

@Oded Dodawanie osób spóźnionych wcale nie jest wspomniane. Ponadto prawo Brooksa nie mówi nic o wadach, ale zwiększenie kanałów komunikacji w celu podejmowania decyzji i informowania ludzi. Podejrzewałbym, że jak sugeruje Karl Bielefeldt, trudności w komunikacji mogą prowadzić do wad.

— Thomas Owens

@ThomasOwens - Tak, cytat rzeczywiście dotyczy zwiększenia kanałów komunikacji (a co za tym idzie trudności), przy założeniu, że doprowadziłoby to do wad.

— Oded

Nadal powiedziałbym, że gdy wielu projektantów zostaje rzuconych na projekt, często wskazuje to na marsz śmierci.

— Morgan Herlocker

@ironcode Liczba programistów w projekcie powinna być podyktowana rozmiarem i zakresem projektu oraz sposobem jego organizacji. Posiadanie zbyt wielu programistów lub dodanie zbyt wielu programistów później są oznakami złego zarządzania, być może marszu śmierci.

— Thomas Owens

14

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 .

— Péter Török
źródło

Do rozwiązania tego przypisałem wykres Thrashing / Process / Productivity McConnella. Jeśli nie wprowadzisz nowych osób, przyzwyczaisz się do narzutów związanych z komunikacją zaangażowanych w projekt na początku, a utrzymanie odpowiedniej komunikacji staje się łatwiejsze i bardziej naturalne. Dzieje się tak zgodnie z prawem Brooksa, gdy dodajesz ludzi do projektu z opóźnieniem, co byłoby równoznaczne z wprowadzaniem opóźnionego procesu do projektu - wzrost kanałów komunikacji oznacza wzrost thrashingu i załamanie komunikacji, które prowadzi do wad. Jednak mogę być nieuzasadniony. Twoje uzasadnienie może być prawidłowe.

— Thomas Owens

Ale przy mniejszej liczbie osób jest mniej prawdopodobne, że pozwolą im trzymać się swoich mocnych stron. Czy łatwiej jest zatrudnić kilku dobrych programistów, którzy mogą być lepsi, jeśli mogą skupić się na obszarze zamiast jednego guru, który może zrobić wszystko?

— JeffO

@Jeff O, masz rację. OTOH, jeśli każdy programista koncentruje się tylko na swoim silnym obszarze, komunikacja między nimi może być jeszcze bardziej kłopotliwa.

— Péter Török

1

Czy komunikacja jest bardziej kłopotliwa, czy po prostu staje się wymagana?

— JeffO

@Jeff O, IMO im mniej rozumieją się nawzajem, tym bardziej wymagana jest komunikacja, a tym większe szanse na nieporozumienia i fałszywe założenia.

— Péter Török

5

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.

— Karl Bielefeldt
źródło

Jedynym problemem jest to, że nie wspomniano o zmianie (a konkretnie zwiększeniu) liczby personelu w czasie. Mówi tylko, że jeśli masz projekt z udziałem n osób, będziesz mieć m wad. Dodanie ludzi wprowadza narzut komunikacyjny i problemy, ale to (z tego co mogę powiedzieć) wykracza poza zakres prostej relacji między wadami ludzi. Zgadzam się, że efektem ubocznym dodawania ludzi z opóźnieniem jest nie tylko wzrost kanałów komunikacji i potrzeba szkolenia ludzi i przyspieszania ich (prawo Brooksa), ale także potencjalny wzrost wad. Ale to nie wchodzi w zakres.

— Thomas Owens

Późne dodawanie ludzi to tylko jeden czynnik, o którym wspomniałem. Zarząd nadal ma tendencję do przypisywania więcej ludzi z góry do projektów ich przewidywania są bardziej ryzykowne lub złożone.

— Karl Bielefeldt,

Celem SLIM (i innych narzędzi szacunkowych, jeśli są właściwie stosowane) jest pomoc w oszacowaniu potrzebnej liczby osób, kosztu projektu, wymaganego czasu i tak dalej. Wymaga to jednak właściwego zrozumienia i używania narzędzia.

— Thomas Owens

3

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.

— psr
źródło

2

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.

— Morgan Herlocker
źródło

Jeśli jedynym sposobem, aby zapobiec pracy 4 programistów nad tym samym plikiem, jest ograniczenie wielkości zespołu do 3, masz większe problemy.

— JeffO

2

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

— Daniel B.
źródło

Na przykład w przypadku systemu Windows jestem pewien, że system Windows ma również większe możliwości wystąpienia wad, ponieważ jest większy. Jeśli jeden programista napisał system, który miał 10 SLOC i system, który miał 10000 SLOC, system z 10000 SLOC miałby większe szanse na defekt (który obejmuje literówki uniemożliwiające kompilację, brakujące średniki, błędy logiczne itp.) . Zazwyczaj większe projekty miałyby więcej inżynierów, ale związek nie dotyczy liczby osób i wad, ale wielkości i wad.

— Thomas Owens

@ThomasOwens - tak, właśnie o to mi chodziło.

— Daniel B

Dlaczego nie można porównywać błędów w stosunku do wielkości i złożoności projektu?

— JeffO

@JeffO - Mierzenie go względnie jest całkowicie nietrywialne (jak dokładnie to robisz?). Być może oryginalne stwierdzenie jest wyjęte z kontekstu, ale autorzy rzadko odnoszą się do złożonych, obliczonych wyników po prostu jako „wady”. W takim przypadku oczekiwałbym innego słowa, takiego jak „jakość” (co oznacza, że dokonano pewnych obliczeń) lub dłuższego wyrażenia, takiego jak „wady przypadające na przydzielonego inżyniera”. Być może jestem tutaj trochę cyniczny wobec autorów :)

— Daniel B

@Jeff Byłyby. Ale porównałbyś wady do wielkości i złożoności, a nie do liczby osób. Wraz ze wzrostem wielkości i złożoności rosną wady i liczba osób. Tak więc, chociaż liczba ludzi rośnie, wzrost liczby ludzi nie zwiększa liczby wad.

— Thomas Owens

1

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.

— Michał
źródło

0

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ą?

— JeffO
źródło