Как планировать огромные программные проекты?
мы начали огромный проект. Мы знаем, как он должен выглядеть, но не знаем, как его реализовать. Мы начали с написания прототипов для тестирования различных реализаций. Чего нам не хватает, так это обзора общего прогресса в области развития. Мы не знаем, тратим ли мы слишком много времени на детали или эти детали достаточно важны, чтобы тратить время.
Я начал с создания списка задач, которые мы должны сделать, таких как "реализовать функцию X", "проверить, как реализовать Y". Сейчас У меня есть огромная карта памяти С 500 задачами. Следующий шаг, который я мог бы сделать, - определить зависимости между задачами. Таким образом, я бы знал, что реализовать в первую очередь, и задачи, от которых больше всего зависит, являются наиболее важными. Но я не могу сделать такой порядок с помощью инструмента "карта разума". Это очень расстраивает.
Как вы планируете огромные проекты программного обеспечения?
7 ответов
есть много хороших статей и книг на эту тему. Но вкратце, сократите зависимости, держите вещи простыми, но гибкими и начните с написания быстро кодируемых компонентов-это дает вам гораздо лучшее "ощущение" того, как вам нужно будет делать вещи. Подготовьтесь к тому, чтобы ваши проекты развивались и готовились переписать довольно много кода.
Не пытайтесь написать идеальную систему с нуля. Set out написать упрощенную систему и вы, возможно, случайно, в итоге пишет идеальный системы.
работайте итерациями. Сконцентрируйтесь на том, что необходимо для одной конкретной итерации. если вы будете фокусироваться на всех деталях одновременно, вы потерпите неудачу.
во-первых, решить, какие общие функции вы хотели бы иметь и дизайн для этого.
на следующих шагах вы будете добавлять все больше и больше дополнительных функций.
когда у вас есть стабильный каркас архитектуры, вы можете разделить проект на модули и распределить их нескольким командам. Команды также будут работать в итерациях.
никто не может создать огромный программный проект с самого начала. Огромный проект растет медленно, со всеми привычными детскими проблемами.
один укус за раз.
серьезно, глядя на все это хорошо, пока вы не полностью сосредоточены. Мы должны разбить его на все более мелкие проекты, пока не сможем обхватить его руками.
Если вы еще не пошли этим путем, любая из гибких методологий работает лучше всего. Scrum отлично, XP - это хорошо. Они используют итерации, которые получают маленькие биты functionalitiy как можно быстрее.
пытаться обхватить руками все это очень, очень сложно, и я нахожу это чрезвычайно демотивирующим. Но с гибкой техникой пользователи сразу видят прогресс, и наша команда возбуждается, потому что их код используется в реальной жизни.
начните с 1 peice, развивайте его, совершенствуйте его и учитесь у него. Как только вы это сделаете, переходите к следующей части. По мере выполнения каждой части добавьте в свою библиотеку повторно используемый код. По мере того как вы идете, процесс должен получить более уточненным, и время развития должно уменьшить. Худшее, что вы можете сделать, это разработать все это в водопадном подходе. Получите что-то работающее и улучшите его, это не только позволит вам показать боссам рабочие части, но и позволит вам найти естественный баланс между планированием и программированием.
Если вы хотите формальный способ планирования, я бы рекомендовал гибкую разработку. Это даст вам хорошее руководство о том, как планировать свои задачи и выполнять их. Но я все равно думаю, что команда разработчиков попадет в ритм, который лучше всего подходит, и инкрементный подход позволит это.
Это то, что помогло мне начать:
[1] Начните с документа требований. Пишите с точки зрения клиентов. Записывать все, что программное обеспечение должно быть в состоянии сделать. Избегайте давать решения. Будьте откровенны. Если функциональность получит входные данные, укажите, чего именно она может ожидать, сколько она должна ожидать и как она должна действовать в ситуациях ошибок.
Не забудьте указать ограничения. Всему есть предел. Если ваше решение собираетесь управлять учетными записями, сколько он должен быть в состоянии обрабатывать? 20 или 10 миллионов?
ваш документ требований должен включать функциональные требования, а не функциональные требования. Не функциональные требования: производительность, стабильность, использование ресурсов, безопасность и так далее.
[2] Когда вы закончите указывать требования, дайте каждому требованию оценку важности: должно быть, важно, необязательно.
[3] Сейчас напишу документ, в котором вы указываете how требование будет реализовано. Будьте осторожны с деталями. Не углубляйся. Придерживайтесь правила 20/80. Укажите 20% функциональности, которая будет влиять на 80% решения.
вы, вероятно, заметите, что вы не можете описать, как каждое требование будет реализовано. Можно написать:"Я понятия не имею, как это реализовать". Но важно, чтобы вы это записали! Количество "не знаю" скажет вы как рискованный проект.
[4] Следующий шаг - Составить список задач. Вы должны знать, что на самом деле нужно делать. Для каждого требования у вас будет несколько задач для выполнения.
одна из этих задач-выяснить, как реализовать "не знаю" требования. Не пытайтесь прояснить каждое "не знаю". Идите на обязательные и важные. Уточнение некоторых из "не знает" может быть даже мини-суб проект.
[5] После того, как у вас есть ваши задачи оценить время, необходимое для их выполнения. Не стесняйтесь оценивать. Невозможно точно оценить, когда вы находитесь в начале проекта. По мере продвижения проекта вы будете переоценивать задачи, и ваши оценки станут более точными.
Мне было очень полезно сделать так называемые трехточечные оценки. Прикиньте время, которое вам понадобится, если все пойдет хорошо. Это ваше оптимистическое время. Затем оценить, сколько времени это займет, если у вас возникнут проблемы. Это ваше пессимистическое время. Затем оцените реалистичное время. Промежуток между оптимистическим и пессимистическим временем покажет вам, насколько вы неуверенны в реализации.
[6] Теперь вам придется привести задачи в порядок, в котором они будут реализованы. Некоторые из задач будут иметь зависимости, которые должен отражать ваш заказ. Существует очень хороший инструмент, который поможет вам визуализировать этот заказ: ваш офис стена. Напишите ваши задачи на post-its и положите их на стену. Серьезно. Это сработало для меня очень хорошо.
[7] Теперь ты уже в середине своего проекта. Сумма Ваших оценок даст вам две даты выхода (оптимистическую и пессимистическую). Вы можете установить контрольные точки. Периодически обновляйте оценки для своих задач. Изменение расчетной даты выпуска покажет вам, как вы работаете.
все это должно исходить из документа требований проекта, это позволит вам узнать, какие функции на самом деле являются требованиями и какие функции добавлены в область ползучести. Убедитесь, что вы реализуете то, что они хотят.
мой совет Всегда разговаривайте с человеком, которому вам нужно доставить проект, придумайте график, когда у вас будет важная функция x завершена. Выяснить, что нужно сделать, - это начать с документа требований и для большого проекта (и малого) приоритеты, по которым задача должна быть поставлена в первую очередь.
Talk talk talk-лучший способ убедиться, что все знают, что происходит в любое время.
очевидно, вы хотите разбить его на более мелкие кусочки, помните, что при выполнении WBS (структура разбивки работы) не только разбить его на более мелкие кусочки, но и:
- определите, какие части будут работать в первую очередь (приоритет наиболее важных для бизнеса)
- план по доставке, многие проекты доставляют код, но затем имеют трудное время в продвижении, планируют, как каждый выпуск будет доставлен и потенциальные последствия для пользователей
- вам что - то сделано рано/быстро-ничто не укрепляет уверенность, как ранняя победа
- разработайте свой план общения-кто должен знать, что и когда-например: для каждого итеративного выпуска, кто должен получить уведомление об изменении / воздействии
- определите, будете ли вы повторно оценивать обратную связь во время выпусков, чтобы определить, изменен ли заказ доставки или функциональность
- поймите, что чем раньше вы выпускаете в производство, тем раньше вам нужно поддерживать его, а также продолжать развитие