Jakie są największe wąskie gardła przy opracowywaniu dużych projektów? [Zamknięte]

Powiedzmy, że moja firma miała opracować replikę MS Word (tylko jako przykład). Jakie byłoby wąskie gardło w procesie rozwoju, zakładając, że ktoś ma nieskończoną ilość gotówki i organizację taką jak Microsoft? Innymi słowy, jakie są najczęstsze przeszkody w szybkim tworzeniu takiego oprogramowania? Załóżmy, że wszystkie specyfikacje są na miejscu, a organizacja działa idealnie, dlatego skupiamy się na rozwoju oprogramowania, dopóki produkt nie będzie gotowy do wysyłki. Niektórymi alternatywami mogą być: - Pisanie kodu - Pisanie testów - Ręczne testowanie produktu końcowego - Przepisywanie kodu ze względu na zły projekt w pierwszej kolejności - Projektowanie kodu - Przegląd kodu wykonywany przez doświadczonych programistów - Projektowanie GUI - Ponowne projektowanie GUI w oparciu o alpha / opinia użytkowników beta - przetwarzanie opinii użytkowników - oczekiwanie na opinie użytkowników wersji alfa / beta

Proszę skorzystać z referencji w odpowiedzi lub podać swoje doświadczenie na ten temat.

Z mojego doświadczenia wynika, że ​​głównym „wąskim gardłem” jest proces uczenia się . Kiedy Twoja hipotetyczna firma postanawia opracować następny program Microsoft Word, istnieje ogromna przepaść między tym, co musisz wiedzieć, a tym, co faktycznie wiesz. Wielkość luki zależy od wielu czynników, może dotyczyć technologii lub dziedziny. W swoim pytaniu poruszyłeś niektóre z tych kwestii, np. Projekt, opinie użytkowników itp. Microsoft Word jest rozwijany od ponad 30 lat, więc między historią, kodem, narzędziami i ludźmi kryje się za tym duża wiedza.

Więc gdybym spróbował to zrobić, spróbowałbym zatrudnić najlepszych ludzi z doświadczeniem w dziedzinie, zarówno technicznych, jak i zarządzania. Spróbuj przeczytać dowolną dostępną literaturę w tej dziedzinie. Spróbuję również uzyskać opinie klientów tak szybko, jak to możliwe. Największym problemem są najważniejsze rzeczy, o których nie wiesz i możesz dowiedzieć się o nich bardzo późno.

Nawiasem mówiąc, nie dotyczy to wyłącznie projektów oprogramowania. Dotyczy to każdego projektu na dużą skalę, w którym próbujesz zrobić coś nowego. Np. Spójrz na Boeing Dreamliner. Na ten temat napisano wiele książek. Miesiąc mitycznego człowieka to jeden.

Załóżmy, że wszystkie specyfikacje są na miejscu, a organizacja działa idealnie.

Zakładasz, że dwa największe „wąskie gardła” w procesach tworzenia oprogramowania nie istnieją (z moich osobistych doświadczeń).

Nawet w twoim hipotetycznym, idealnym świecie widzę pewne problemy:

Prawdopodobnie najważniejsza, z mojego punktu widzenia, jest kontakt z klientami. Z własnego doświadczenia wynika, że ​​firma ma do czynienia z klientami, którzy często próbują zmienić projekt podczas jego opracowywania. W niektórych przypadkach próbowali wysłać prośbę o zmianę jako poprawkę błędu, aby uniknąć konieczności płacenia jakichkolwiek pieniędzy. Może to prowadzić do dużej biurokracji, która może opóźnić projekt lub doprowadzić do szybkich włamań do kodu, które stają się technicznym długiem w dalszej linii. Czytałem i słyszałem o zespołach, które radzą sobie z tymi problemami tak łatwo, jak to jest oddychać, i na pewno żałuję, że nie byłem w jednym z nich :)

Drugi problem to brak odpowiedniego modelu domeny. Eric Evans zapewnia dobrą relację na ten temat w swojej książce: Domain Driven Design . Brak dobrego modelu domeny prowadzi do niektórych problemów wskazanych w odpowiedzi Glenna, takich jak próba zlokalizowania błędu. Bez czystego modelu domeny przejście do / debugowanie kodu w celu wyizolowania i rozwiązania problemu może zająć dużo czasu. Twierdziłbym, że dobry model domeny znacznie ułatwia życie i debugowanie, tym bardziej w przypadku utrzymywania i rozszerzania aplikacji na późniejszym etapie.

Problemy, o których wspomniałem powyżej, nie przysparzają natychmiastowych problemów, ale jeśli musisz utrzymywać ten produkt przez długi czas, mogą wrócić, by prześladować Ciebie i Twój zespół.

Nie jestem pewien, co rozumiesz przez „organizacja działa idealnie”, ale nawet w fantastycznej organizacji największym wąskim gardłem w każdym znaczącym projekcie jest komunikacja. Mityczny Miesiąc Człowieka wskazuje, jak wraz z rozwojem zespołu projektowego wybuchają kombinacje komunikacji, co prawie gwarantuje błędy i pominięte informacje.

Z tego, co do tej pory widziałem w pracy, duże źródło wąskiego gardła wynika po prostu z błędów i błędu ludzkiego, który je spowodował. Pomyśl tylko o czasie potrzebnym na debugowanie kodu, znajdź rozwiązanie problemu, a następnie ponownie przetestuj nowe rozwiązanie. Teraz wyobraź sobie, czy ta poprawka spowodowała kolejny subtelny błąd. Może to być poważny strumień bólu, a tym samym spowalnia ogólny rozwój.

Myślę, że Brandon Moretz ma najlepszą odpowiedź. Ale chcę dodać, że uzyskanie pierwszej wersji dużego projektu nie jest wcale takie trudne. Ja osobiście nigdy tego nie zaniedbałem.

Nie udało mi się stworzyć pierwszej wersji w taki sposób, że druga, trzecia itd. Wersja i / lub poprawki błędów lub drobne ulepszenia funkcji mogą być dostarczone w odpowiednim czasie.

Tak, zgadzam się z powyższymi rzeczami i muszę przestrzegać modeli oprogramowania. Zgodnie z moją wiedzą najważniejsze są:

1. Zarządzanie czasem 2. Efektywność zespołu i zarządzanie zespołem 3. Koordynacja w zespole i 4. Lepsze zrozumienie z klientem

Jeśli mamy powyższe cztery, możemy przenieść się do nowego świata z sukcesem i wieloma ulepszeniami pod względem osobowości i oprogramowania, co prowadzi do dobrych relacji z klientem, a klient będzie wydawał zamówienia bez myślenia o nas.

Utajone wady w wymaganiach, projekcie, implementacji, wdrożeniu ... Jak w przypadku rzeczy zepsutych, ale jeszcze ich nie znalazłeś. Wyobraź sobie rozwój oprogramowania, w którym każdy nowy błąd był spowodowany najnowszymi zmianami.