Как мы можем * установить * сроки, чтобы мы могли эффективно и гибко работать с ними?
Я работаю в команде, которая последовательно и достаточно успешно работает в гибком подходе, и это отлично работало для текущего проекта до сих пор, для нашей начальной работы, когда мы постепенно наращиваем продукт.
Мы сейчас переходим к следующему этапу этого процесса, и руководство заинтересовано в том, чтобы мы сами установили некоторые конкретные сроки, когда мы сможем продемонстрировать и продать это реальным клиентам в течение нескольких месяцев.,
У нас есть довольно хорошо организованное большое отставание по каждому элементу функциональности, которое мы хотели бы включить, и хорошее чувство приоритезации этих отдельных кусков функциональности.
Наивное решение состоит в том, чтобы получить минимальный список историй, которые могли бы предоставить демо-продукт, оценить их все по отдельности, сложить и объединить с нашей скоростью, чтобы получить дату, и объявить, что с этого момента мы будем демо-версии. Это не оставляет никакой свободы, и, вероятно, приведет к безумному кризису, когда мы подойдем к крайнему сроку, которого я отчаянно хочу избежать.
В качестве улучшения я хотел бы добавить некоторое соотношение более необязательных историй, которые будут действовать как непредвиденные или бонусные улучшения, в зависимости от того, как мы продвигаемся, но мы не имеем ни малейшего представления, какое соотношение будет разумным, или является ли это стандартный подход.
Я также обеспокоен необходимостью оценивать все наше отставание сразу, так как это кажется очень трудоемким, и вполне вероятно, что мы узнаем больше информации за несколько месяцев до того, как перейдем к этой истории, что повлияет на наши оценки.
Существуют ли рекомендуемые подходы к установлению крайних сроков для обеспечения гибкого процесса разработки? Большая часть информации, которую я видел, кажется, связана с обработкой ситуации, как только у вас есть установленный крайний срок. Я также был бы заинтересован в любой соответствующей литературе или интересных постах в блоге, которые освещают эту проблему.
3 ответа
Что касается литературы: лучшая книга, которую я знаю относительно оценки в программном обеспечении, - "Оценка программного обеспечения: демистификация черного искусства" Стива Макконнела. Это покрывает ваш случай. Кроме того, он описывает разницу между оценкой и обязательством (другими словами, установленным сроком) и объясняет, как надежно получить второе из первого.
Наивное решение состоит в том, чтобы получить минимальный список историй, которые могли бы предоставить демо-продукт, оценить их все по отдельности, сложить и объединить с нашей скоростью, чтобы получить дату, и объявить, что с этого момента мы будем демо-версии. Это не оставляет никакой свободы, и, вероятно, приведет к безумному кризису, когда мы подойдем к крайнему сроку, которого я отчаянно хочу избежать.
Это решение, которое я использовал в прошлом. Ваша первоначальная оценка будет немного ниже, так что добавьте немного провала через пару дополнительных спринтов, прежде чем устанавливать дату релиза. Если вы отстанете, вы можете наверстать упущенное. Если нет, то ваш бэклог продукта дает вам дополнительные функции, которые вы можете включить в релиз, если вы того пожелаете. Это будет зависеть от вашей метрики скорости для команды, хотя. Отрегулируйте свой провал в зависимости от того, насколько точным вы считаете этот показатель для текущей команды. Получив целевой выпуск, вы можете вернуться назад, чтобы узнать, есть ли у вас какие-либо известные ограничения ресурсов, которые могут повлиять на этот выпуск.
Подход, который вы описываете, вероятно, будет правильным. Возможно, вы захотите оценить все желаемые функции и расставить приоритеты для элементов пользовательского интерфейса (потому что инвесторы и клиенты в основном просто видят блестящий пользовательский интерфейс), и тогда вашим конечным сроком будет предполагаемая дата завершения; затем добавьте некоторую слабость в виде масштабирования ваших оценок. Используйте соотношение между текущей производительностью и вашим худшим периодом, чтобы создать пессимистическую оценку. Вы можете использовать это же соотношение для масштабирования более коротких оценок (например, для вашей оценки до минимального набора функций).