Сроки проекта на ранней стадии (проект Scrum)

Как поступать с ранними проектами, когда еще не могут быть достигнуты серьезные соглашения о сроках?

  1. Мы находимся на ранней стадии проекта с новыми людьми.

  2. Команда небольшая и все новое (технологии и люди): Короче. Много динамических факторов.

  3. Мы все еще находимся в той фазе, когда выясняем, сколько мы можем сделать за один спринт.

  4. Многие важные вещи еще не определены в Бэклоге (просто существуют в виде расплывчатых маркетинговых заявлений).

В то же время некоторые заинтересованные стороны уже хотят установить сроки или контрольные точки.

Но мне нужны эти две вещи, чтобы серьезно договориться о чем-то:

  1. Иметь больше опыта в том, как быстро работает команда
  2. Бэклог с каждой функцией, для которой заинтересованная сторона хочет определить дату или крайний срок.
  3. Серьезно согласен в чем-то означало бы для меня, что между ожиданием и реальностью нет факторов типа в два раза длиннее или выше.

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

Обновление относительно комментария Джеффа: очень интересно иметь эти два вида аспектов: по дате и по объему. Я думаю, что комбинация будет лучше всего. Я имею в виду, что цель, привязанная к дате, будет означать, что вы сделаете релиз в указанную дату, что бы ни случилось, верно? (Мы все еще находимся в процессе изучения методологий Scrum. Так что я думаю, что намеки на дорожные карты и Scrum помогают нам в целом.)

Взгляните на этот вопрос: pm.stackexchange.com/questions/29/… вы можете найти несколько полезных исходных моментов.
Вы упомянули, что это проект Scrum и что заинтересованные стороны хотят установить сроки, что само по себе вызывает много вопросов. Больше контекста поможет нам помочь вам больше. :) Например, понимают ли заинтересованные стороны Scrum или Agile (практики и менталитет), или они прошли какое-либо формальное обучение? Нужны ли им сроки (определяемые датой) или вехи (возможно, зависящие от масштаба) или их комбинация?
@Джефф Линдси: см. мое обновление. Было бы интересно получить ответ с вашей точки зрения.
Как правило, подходы Scrum направлены на сохранение гибкости объема, что помогает избежать «железного треугольника» фиксированного объема/дат/бюджета. Итак, если у вас есть требование к фиксированной дате, с некоторыми показателями (включая отклонения) вы можете начать оценивать диапазон объема , который должен быть завершен к дате; если у вас фиксированный охват, вы можете начать оценивать диапазон наиболее вероятных дат . Хорошим общим ресурсом как для команд, так и для заинтересованных сторон была бы книга Майка Кона Agile Estimating and Planning. Удачи!

Ответы (1)

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

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

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

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

  3. Затем определите метрики, измерения или ключевые показатели эффективности (KPI), которые помогут определить, достигнута ли цель и был ли выпуск успешным.

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

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

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

Сроки проекта на ранней стадии (проект Scrum)
СпросиСетьПолитика конфиденциальности1y, 0v