Які найбільші вузькі місця при розробці великих проектів? [зачинено]

Скажімо, моя компанія мала розробити репліку MS Word (лише як приклад). Що було б вузьким місцем у процесі розробки, якщо припустити, що у нього є нескінченна кількість грошових коштів та така організація, як Microsoft? Іншими словами, які найпоширеніші перешкоди для швидкого розвитку такого програмного забезпечення? Припустимо, що всі специфікації є на місці і організація працює на відмінно, тому ми просто зосередимось на розробці програмного забезпечення, поки продукт не буде готовий до поставки. Можливі такі варіанти: - Написання коду - Написання тестів - Тестування кінцевого продукту вручну - Передусім перепис коду через поганий дизайн - Розробка коду - Огляд коду, виконаний досвідченими розробниками - Проектування графічного інтерфейсу - Редагування графічного інтерфейсу на основі альфа / бета-відгуки користувачів - обробка зворотного зв’язку від користувачів - чекання відгуків альфа / бета-користувачів

Будь ласка, використовуйте посилання у своїй відповіді або повідомте про свій досвід з цього питання.

На мій досвід, головним «вузьким місцем» є процес навчання . Коли ваша гіпотетична компанія налаштована на розробку наступного Microsoft Word, існує величезна прогалина між тим, що вам потрібно знати, і тим, що ви насправді знаєте. Розмір розриву залежить від багатьох факторів, це може бути в технології або області. Ви торкнулися деяких із цих питань у вашому запитанні, наприклад, дизайну, відгуків користувачів тощо. Microsoft Word розробляється вже понад 30 років, тому між історією, кодом, інструментами та людьми існує багато знань.

Тож якби я спробував це зробити, я б спробував найняти найкращих людей із досвідом роботи в галузі, як технічної, так і управлінської. Спробуйте і прочитайте будь-яку доступну літературу в цій галузі. Я також спробую якнайшвидше отримати зворотній зв'язок з клієнтами. Найбільша проблема - це найважливіші речі, про які ви не знаєте, і про них можна дізнатися дуже пізно у вашому процесі.

Це, до речі, не властиве лише програмним проектам. Це стосується кожного масштабного проекту, де ви намагаєтесь зробити щось нове. Наприклад, подивіться на сонник Boeing. Про це написано багато книг. Міфічний місяць людини - це один.

Припустимо, що всі специфікації встановлені на місці, і організація працює бездоганно.

Ви припустили, що двох найбільших «вузьких місць» у процесах розробки програмного забезпечення не існує (з мого особистого досвіду).

Навіть у вашому гіпотетичному, досконалому світі я можу побачити деякі проблеми:

Напевно, найголовніше, з моєї власної точки зору, - це стосунки з клієнтами. На мій власний досвід, бізнес має справу з клієнтами, які часто намагаються змінити проект під час його розвитку. У деяких випадках вони намагаються перекрити запит на зміну як виправлення помилки, щоб уникнути необхідності платити гроші. Це може призвести до великої бюрократії, яка може затримати проект або призвести до швидких злому коду, що перетворюється на технічну заборгованість далі вниз. Я читав і чув про команди, які вирішують ці проблеми так само просто, як дихати, і впевнено хочу, щоб я був в одній з них :)

Друге питання - відсутність належної доменної моделі. Ерік Еванс добре висвітлює це у своїй книзі: Дизайн, керований доменом . Відсутність хорошої доменної моделі призводить до деяких проблем, виділених у відповіді Гленна, наприклад, намагання знайти помилку. Без чистої моделі домену може зайняти багато часу, щоб пройти / налагодити код, щоб виділити та виправити проблему. Я б заперечував, що хороша модель домену значно полегшує життя та налагодження, тим більше при підтримці та розширенні програми далі вниз.

Проблеми, про які я згадав вище, не створюють негайних проблем, але якщо вам потрібно буде підтримувати цей продукт протягом тривалого періоду часу, вони можуть повернутися до переслідування вас та вашої команди.

Я не впевнений, що ви маєте на увазі під «організацією, яка працює ідеально», але навіть у фантастичній організації найбільшим вузьким місцем у будь-якому значному проекті є спілкування. Mythical Man Month вказує на те, як у міру зростання команди проекту комбінації комунікацій вибухають, майже гарантуючи помилки та пропущену інформацію.

З того, що я бачив поки що на роботі, велике джерело вузьких місць походить просто від помилок та людської помилки, яка їх створила. Подумайте лише про час, який потрібен для налагодження коду, знайдіть виправлення проблеми та перевірте нове рішення. А тепер уявіть, чи спричинило це виправлення ще однієї тонкої помилки. Це може бути основним потоком болю і, таким чином, уповільнює розвиток в цілому.

Я думаю, що Брендон Морец має найкращу відповідь. Але хочу додати, що вивести першу версію з великого проекту не все так складно. Я особисто ніколи цього не робив.

Що я не зміг зробити, це створити першу версію таким чином, щоб другу, третю версію тощо та / або виправлення помилок і / або незначні покращення функцій також можна було доставити своєчасно.

Так, я погоджуся з вищезазначеними речами, і він повинен дотримуватися програмних моделей. Наскільки мені відомо, основні речі:

1. Тимчасовий менеджмент 2. Ефективність роботи та управління командою 3. Координація роботи в команді та покращення взаємодії з Клієнтом

Якщо у нас є вищевказані чотири, то ми можемо перейти до нового світу з успіхом і багато вдосконалення в плані особистості та програмного забезпечення. Це призводить до хороших стосунків з клієнтом, і клієнт буде віддавати замовлення, не думаючи про нас.

Латентні дефекти, вимоги, дизайн, реалізація, розгортання .... Як і в матеріалах, які зламані, але ви їх ще повинні знайти. Уявіть, що розробка програмного забезпечення була у випадку, коли кожна нова помилка була викликана останніми змінами.