Управление задачами развертывания и настройки в Scrum [закрыто]

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

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

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

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

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

"теория" Agile заключается в том, что у вас есть зрелая инфраструктура.

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

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

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

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

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

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

но, как правило, конфигурация и развертывание-как зрелая инфраструктура-являются основополагающими. Они уже часть вашего процесса. Ты уже делаешь это. Как они могут быть "потеряны"?

Что вы подразумеваете под "усилием, как правило, теряется"? Что значит "потерял"? Ты знал, что должен это сделать. Ты сделал это. Что потеряно?

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

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

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

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

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

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

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

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

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

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

У нас есть типы действий задачи в Redmine, где мы определяем тип действия рабочего элемента, когда мы заканчиваем / завершаем его. Эти типы действий рабочих элементов включают регулярные командные действия, такие как разработка, тестирование, документация и т. д., Но они также включают такие действия, как требования, развертывание, проектирование, анализ и т. д. Мы помечаем ими нашу деятельность, а затем можем анализировать наши усилия также в соответствии с этими типами деятельности.