Руководящее развертывание и задачи конфигурации в [закрытой] Толпе

Мы используем два подхода. Такие вещи, как развертывание приложения, включены в пользовательскую историю жизни. История делается после развертывания.

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

Я не понимаю «потерянный» в вопросе. Это работа, которую вы должны сделать. Так как это может быть потеряно?

«Теория» за Agile - это то, что у вас возникает зрелая инфраструктура.

Существует две разные проблемы инфраструктуры.

• Создание новой инфраструктуры.

• Использование существующей инфраструктуры.

При создании новой инфраструктуры мы создаем разведку в первые несколько спринтов. Вы не можете запланировать это. Вы не можете предсказать различные пути, контрольные блоки, подводные камни, ловушки и ловушки в этом. Это требует обучения. Не пытайтесь предсказать время, необходимое для прокладки новой инфраструктуры. Вещи пойдут не так. Если это не так, то инфраструктура не на самом деле «новая» - это клон или копирование.

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

Некоторые вещи (например, наш новый брандмауэр) бросили реальные сложности в некоторые релизы.

Но в целом, конфигурация и развертывание - как зрелая инфраструктура - являются основой. Они уже являются частью вашего процесса. Вы уже делаете их. Как они могут быть «потерянными»?

Что вы подразумеваете под «усилиями, как правило, теряются»? Что означает «потерянный»? Вы знали, что вы должны были сделать это. Ты сделал это. Что потеряно?

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

Это просто вещи, которые вы делаете. Это часть выпуска. Это просто работа, как разработка, что вы просто делаете.

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

Если график является священным - и день миграции - это «проблема» - вы должны спросить, у кого есть «проблема» и какая «проблема» у них есть? Это проблема руководителя проекта? Если это так, график преграл набор поставленных функций, и этот менеджер проекта должен переосмыслить свое мнение о реальности. Набор функций пользователя реален. Расписание - это просто хорошая идея, которая не всегда работала.

У нас есть отдельная списка задач для задач, таких как администрирование сервера, и планировать наши результаты вокруг этого. Например, через опыт я знаю, что я потрачу около 2 часов в день, делая административные задачи, поэтому, когда я скажу моим менеджером проекта, что что-то займет 4 часа, он автоматически добавляет ~ 2 часа до доставки, и позволяет генеральному директору займет 6 часов (или 1 рабочий день).

В качестве альтернативы, некоторые «административные» задачи предрешены реквизиты для получения доставки проектов. Например, если проект включает в себя повторное написание медленной части нашего веб-сайта, чтобы быть более эффективным, и часть проблемы состоит в том, что наши серверы не настроены для использования Memcached, которые нам нужны, то настройка и настройка Memcached становится Предварительный необходимый проект повторно написать код. Причина, по которой она не свернута вместе, это потому, что когда мы правильно настроили кэширование, то интенсивная часть сайта может работать достаточно хорошо, что мы хотим вставить еще один важный проект, связанный с продажами. Это продолжает проворно.

Я думаю, что это актуально: http://joeelonsoftware.com/articles/seteourpriorites.html - специально к концу, где он описывает свой способ для приоритетных функций.

Эта статья о расписании на основе доказательств, также кажется актуальной: http://joeelonsoftware.com/items/2007/10/26.html

Любой может добавить в отставание продукта, включая разработчиков, но его решение владельцев продукции относительно возникает ли работа.

Итак, если у вас будет созданная новая производственная среда, добавьте ее в отставку продукта, в собрании планирования SCRIM вы можете объяснить владельцу вашего продукта относительного значения, они могут решить, что это должно быть сделано сейчас или поздно. (То же самое относится и к развертыванию и / или настроив приложения)

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

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