Как планировать огромные программные проекты?

Ответ 1

Это помогло мне начать:

[1] Начните с документа требований. Напишите с точки зрения клиентов. Напишите все, что должно делать программное обеспечение. Избегайте предоставления решений. Будьте ясны. Если функциональность получит вход, укажите, что именно он может ожидать, сколько он должен ожидать и как он должен действовать в ситуациях с ошибками.

Не забудьте указать ограничения. Все имеет предел. Если ваше решение будет управлять учетными записями, сколько из них должно обрабатываться? 20 или 10 миллионов?

Ваш документ требований должен включать функциональные требования, а не функциональные требования. Нефункциональные требования: производительность, стабильность, использование ресурсов, безопасность и т.д.

[2] Когда вы закончите задание, требования придают каждому требованию значение оценки: должно быть, важно, необязательно.

[3] Теперь напишите документ, в котором вы укажете, как будут выполняться все требования. Будьте осторожны с деталями. Не идите вглубь. Пойдите для правила 20/80. Укажите 20% функциональности в глубину, которая повлияет на 80% решения.

Вы, вероятно, заметите, что не можете описать, как будут выполняться все требования. Хорошо писать "Я не знаю, как это реализовать". Но важно, чтобы вы это записывали! Количество "не знает" скажет вам, насколько рискован ваш проект.

[4] Следующий шаг - создать список задач. Вам нужно будет знать, что на самом деле вам нужно делать. Для каждого требования у вас будет несколько задач для выполнения.

Одна из этих задач - выяснить, как реализовать требования "не знать". Не пытайтесь прояснить каждый "не знаю". Пойдите для обязательных и важных. Уточнение некоторых из "не знает" может быть даже мини-проектом.

[5] Когда у вас есть ваши задачи, оцените время, необходимое для их завершения. Не стесняйтесь оценивать. Невозможно точно оценить, когда вы находитесь в начале проекта. По мере продвижения проекта вы будете переоценивать задачи, и ваши оценки будут более точными.

Мне было очень полезно сделать так называемые три точечные оценки. Оцените время, которое вам понадобится, если все будет хорошо. Это вы оптимистичное время. Затем оцените, сколько времени потребуется, если у вас возникнут проблемы. Это ваше пессимистичное время. Затем оценим реалистичное время. Пробел между оптимистичным и пессимистичным временем покажет вам, насколько вы не уверены в реализации.

[6] Теперь вам придется выполнять задачи в том порядке, в котором они будут реализованы. Некоторые из задач будут иметь зависимости, которые ваш заказ должен будет отразить. Существует очень хороший инструмент, который поможет вам визуализировать этот заказ: стену вашего офиса. Напиши свои задания на столбе и поместите их на стену. Шутки в сторону. Это сработало для меня очень хорошо.

[7] Теперь вы уже находитесь в середине своего проекта. Сумма ваших оценок даст вам две даты выпуска (оптимистичные и пессимистические). Вы можете установить мильные камни. Периодически обновляйте оценки ваших задач. Изменение расчетной даты выпуска сообщит вам, как вы выполняете.

Ответ 2

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

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

Ответ 3

Выполняйте свою работу в итерациях. Сосредоточьтесь на том, что необходимо для одной конкретной итерации. если вы будете фокусироваться на всех деталях одновременно, вы потерпите неудачу.

Во-первых, определите, какие общие функции вы хотели бы иметь и разработали для этого.

На следующих шагах вы будете добавлять все больше и больше расширенных функций.

Когда у вас есть каркас архитектуры, который является стабильным, вы можете разделить проект на модули и распределить их нескольким командам. Команды также будут работать в итерациях.

С самого начала никто не может проектировать огромный программный проект. Огромный проект растет медленно, со всеми обычными проблемами детства.

Ответ 4

Один укус за раз.

Если вы еще этого не сделали, любая из методологий Agile работает лучше всего. Scrum отлично, XP - это хорошо. Они используют итерации, которые получают как можно быстрее небольшие фрагменты функционала.

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

Ответ 5

Начните с 1 peice, развить его, совершенствовать и учиться на нем. Как только вы это сделаете, перейдите к следующей части. Когда вы делаете каждый фрагмент, добавьте в свою библиотеку повторно используемый код. По мере того, как вы идете, процесс должен быть более совершенным, а время разработки должно уменьшаться. Самое худшее, что вы можете сделать, это развить все это в подходе, основанном на водопаде. Получите что-то работающее и совершенное, это не только позволит вам показать рабочие части боссов, но также позволит вам найти свой естественный баланс между планированием и кодированием.

Если вы хотите формальный способ планирования, я бы рекомендовал гибкое развитие. Это даст вам хорошее руководство для планирования ваших задач и их выполнения. Но я все еще думаю, что команда разработчиков попадет в ритм, который лучше всего подходит, и поэтапный подход позволит это.

Ответ 6

Все это должно исходить из документа требований проекта, это позволит вам узнать, какие функции на самом деле являются требованиями, а какие функции добавлены в область ползучести. Убедитесь, что вы реализуете то, что они хотят.

Мой совет всегда разговаривает с человеком, которому нужно доставить проект, придумайте график, когда у вас будет важная функция x, завершенная. Выяснение того, что должно быть сделано, - это запуск через документ требований и для больших приоритетов проекта (и малых), заданных для выполнения первой задачи.

Обсуждение разговоров - лучший способ убедиться, что все знают, что происходит в любое время.

Ответ 7

Очевидно, что вы хотите разбить его на более мелкие куски, помните, когда вы делаете WBS (Structure Workdown Structure), чтобы не только разбить его на более мелкие части, но также:

• определите, какие части будут обработаны в первую очередь (приоритет наиболее важных для бизнеса)
• план доставки, многие проекты доставляют код, но затем имеют трудное время для продвижения, планируют, как будет поставляться каждый выпуск, и потенциальное воздействие на пользователей.
• сделайте что-то рано или быстро - ничто не создает уверенность, как ранняя победа
• разработать свой план коммуникации - кому нужно знать, что и когда - Ex: для каждого итеративного выпуска, которому необходимо получить уведомление об изменении/воздействии.
• определить, будете ли вы повторно оценивать обратную связь во время выпуска, чтобы определить, изменился ли порядок доставки или функциональность.
• понимают, что чем скорее вы выйдете на производство, тем скорее вам нужно будет его поддерживать, а также продолжить разработку.

Ответ 8

Успешные проекты по разработке программного обеспечения на заказ - это тот, который обеспечивает решение поставленных задач, вовремя и в рамках бюджета. Это требует хорошего планирования с самого начала проекта и разумного управления проектом на протяжении всей жизни проекта. Работайте с вашим разработчиком нестандартного программного обеспечения и оставайтесь сосредоточенными на ваших ключевых задачах. Это гарантирует, что вы получите специальное программное решение, отвечающее потребностям вашего бизнеса и обеспечивающее хороший возврат ваших инвестиций.