Представьте, что у вас нет проблемы с ползучести функций, у вас есть мотивированная и стабильная команда, четкие определенные проблемы для решения. И вы знаете домен/язык/инструменты, связанные с вашим проектом.
Как вы придерживаетесь графика и выполняете этот рубеж 1.0?
Каков ваш подход к итеративной доставке?
Я бы рекомендовал рекомендации для небольшой команды, где проблем с коммуникацией немного или почти нет.
Это, вероятно, утопический сценарий;-). Но в любом случае, если нет ползучести функций, очень хорошая команда и четко определенные требования с абсолютно отсутствием коммуникационных проблем, то, вероятно, лучший способ доставить продукт вовремя будет
Конец дня, это сводится к тому, как страстный человек относится к своей работе.
Только мои 2 пайса; -)
Вопрос: Как большой программный проект может опоздать на один год? Ответ: Один день за раз!
Это не дает ответа на ваш вопрос, но я думаю, что это указывает на необходимость придерживаться вашего графика - если вы даже на один день отстаете, вам нужно как-то его поймать. (К сожалению, остальная часть The Mythical Man Month рассказывает о том, как в большинстве проектов нет "как-то"...)
Кроме того, посмотрите на планирование на основе фактических данных в таких продуктах, как FogBugz. Это даст вам самую последнюю оценку того, когда продукт, скорее всего, отправит - на самом деле, он дает ряд дат, с вероятностями для каждой даты. Если вы видите, что вероятная дата релиза проскальзывает за крайний срок, это даст вам знать, что вам нужно что-то сделать, и, надеюсь, с достаточным временем, чтобы иметь эффект.
Есть одна небольшая точка, пропущенная предыдущими плакатами. Чтобы соответствовать сроку, прежде всего, должен быть определен реалистичный график. Проект должен быть разделен на небольшую задачу, зависящую от размера проекта, но в моем мире с проектами, занимающими около 3-4 месяцев, мы пытаемся разделить их на максимум 2-3 дня. Таким образом, оценка времени в основном реалистична, а риски вычисляются заранее и добавляются к предлагаемому графику.
В этой теме много хороших советов. Единственное, что я должен добавить, это принять регулярное расписание релизов. Моя компания переключилась на это несколько лет назад, и сначала это было больно, но у нее есть много преимуществ, самая большая из которых - позволить людям легко откладывать функции.
Вполне возможно отложить функции, потому что вы знаете, что ваша функция может превратиться в следующую версию, и вы знаете, когда будет эта релиза. Это означает, что вместо того, чтобы спешить, чтобы получить свою половину выпечки в последнюю минуту, вы можете потратить немного больше времени и получить ее в начале следующего выпуска.
Запрет необоснованных сроков продаж/маркетинга/управления, вы в значительной степени исключили все причины, по которым проекты не отправляются вовремя. История методологий разработки программного обеспечения представляет собой набор методов для работы, уменьшения воздействия и/или предотвращения:
Знайте, какие критически важные функции для клиента. Защитите прогресс на них. Часто очень верно, что 80% успеха приходится на 20% работы.
Этап Периодический (ежемесячно? еженедельно?) пошаговые руководства по продуктам с использованием текущей принятой сборки в интересах группы продуктов. Начните их как можно раньше. Демонстрируйте каждую функцию, независимо от ее текущей юзабилити; не пропускайте те, которые отстают.
Цель состоит в том, чтобы дать заинтересованным сторонам четкое представление о текущем состоянии продукта в ходе проекта. Таким образом, лица, принимающие решения, с большей вероятностью быстро справятся с рисками графика, вместо того, чтобы подвергать опасности дату отправки судна.
Мне нравится говорить, что вы можете выбрать набор функций или дату отправки, но не оба.
Вот некоторые отдельные мысли: - не будьте оптимистичны - сначала сделайте трудную часть - не добавлять функции без проскальзывания графика - писать функции таким образом, чтобы их можно было отбросить в расписание