Лучшие практики для доставки программного обеспечения вовремя

Ответ 1

• Сосредоточьтесь на функциях, не связанных с реализацией.
• Работайте в итерациях (например, еженедельно или раз в две недели).
• Отпустите рабочие функции в вашей промежуточной среде в порядке приоритета.
• Unit test ваш код, как вы идете, поэтому вы не замедлили ошибку, которая увеличивается геометрически по мере приближения даты выпуска.
• Будьте готовы сократить масштаб от менее важных функций. Материал всегда занимает больше времени, чем вы думаете.
• Убедитесь, что вы нарисуете пользовательский интерфейс заранее (если есть пользовательский интерфейс) и покажите его потенциальным пользователям.
• Тестировать, тестировать и тестировать еще несколько. Это кажется контр-интуитивным, но это экономит больше времени, чем требует.

Ответ 2

Это, вероятно, утопический сценарий;-). Но в любом случае, если нет ползучести функций, очень хорошая команда и четко определенные требования с абсолютно отсутствием коммуникационных проблем, то, вероятно, лучший способ доставить продукт вовремя будет

• Еженедельная встреча с командой для оценки текущего состояния (PM с командой, если есть PM)
• Руководитель команды может провести небольшую ежедневную встречу с членами команды, чтобы оценить их статус по вопросам/требованиям, делегированным им. Если есть проблемы, он должен предпринять необходимые шаги для решения проблемы.
• Отслеживание плана проекта и работающая делегация (руководителю группы необходимо знать индивидуальные сильные стороны каждого члена команды для надлежащего делегирования работы).
• Тестирование может быть автоматизировано до тех пор, пока технология не позволяет.
• Собственность на работу каждого члена команды.

Конец дня, это сводится к тому, как страстный человек относится к своей работе.

Только мои 2 пайса; -)

Ответ 3

Вопрос: Как большой программный проект может опоздать на один год? Ответ: Один день за раз!

Это не дает ответа на ваш вопрос, но я думаю, что это указывает на необходимость придерживаться вашего графика - если вы даже на один день отстаете, вам нужно как-то его поймать. (К сожалению, остальная часть The Mythical Man Month рассказывает о том, как в большинстве проектов нет "как-то"...)

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

Ответ 4

Есть одна небольшая точка, пропущенная предыдущими плакатами. Чтобы соответствовать сроку, прежде всего, должен быть определен реалистичный график. Проект должен быть разделен на небольшую задачу, зависящую от размера проекта, но в моем мире с проектами, занимающими около 3-4 месяцев, мы пытаемся разделить их на максимум 2-3 дня. Таким образом, оценка времени в основном реалистична, а риски вычисляются заранее и добавляются к предлагаемому графику.

Ответ 5

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

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

Ответ 6

Запрет необоснованных сроков продаж/маркетинга/управления, вы в значительной степени исключили все причины, по которым проекты не отправляются вовремя. История методологий разработки программного обеспечения представляет собой набор методов для работы, уменьшения воздействия и/или предотвращения:

• слабо определенная область
• функция ползучести
• недостаток знаний о домене
• крупные команды с проблемами связи
• немотивированные/некомпетентные разработчики

Ответ 7

Знайте, какие критически важные функции для клиента. Защитите прогресс на них. Часто очень верно, что 80% успеха приходится на 20% работы.

Ответ 8

Этап Периодический (ежемесячно? еженедельно?) пошаговые руководства по продуктам с использованием текущей принятой сборки в интересах группы продуктов. Начните их как можно раньше. Демонстрируйте каждую функцию, независимо от ее текущей юзабилити; не пропускайте те, которые отстают.

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

Ответ 9

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

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

http://shipcamp.com