Scrum/Agile: Как вы планируете внутренние улучшения?

Теперь я работал над двумя разными командами, которые используют подход Agile/Scrum за последние два года, и обе команды стремились улучшить подход к разработке программного обеспечения. В первой команде мы могли легко убедить нашего владельца продукта получить время для внутренних вещей, таких как совершенствование системы сборки, создание лучших интеграционных тестов, лучшая стратегия выпуска и т.д. В настоящее время ПО также желает дать нам время, но он больше отталкивает назад, что разумно, так как он также должен добиться своих целей.

В любом случае мой вопрос сейчас, как другие команды справляются с этим? Создаете ли вы историю улучшения и ставите ее на стол во время планирования или вы держите "ведро" времени для таких вещей? Насколько сложно в вашем опыте убедить владельца продукта сделать время для улучшения? После того, как все эти улучшения будут полезны команде, но не сразу или сразу, владелец/бизнес-производитель.

Ответ 1

Отличный вопрос. Я думаю, что есть несколько разновидностей "элементов действия" от ретроспектив, которые заслуживают разных подходов.

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

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

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

Вторая категория должна обрабатываться/управляться менеджером итерации, менеджером проектов, диспетчером scrum и т.д. Я (как Scrum Master или Project Manager) обычно перечисляю их в вики проекта и рассказываю о них в ретроспективе, проверяю их когда они адресованы, и сообщите команде о статусе. Я продолжаю гореть.

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

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

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

Ответ 2

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

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

Ответ 3

Crystal Methods имеет концепцию Reflection Workshop как средство настройки вашего процесса разработки. Команды встречаются периодически (реже, чем ваш цикл разработки, возможно), чтобы обсудить улучшения и статус процесса. Придумайте 0-3 вещи, которые мы пробовали на этот раз, которые работали, и мы будем держать, 1-3 вещи, которые не работают, и 1-3 вещи, чтобы попробовать в следующий раз. Идея заключается в постепенном улучшении процесса, а также в продукте.

Ответ 4

В прошлом году я работал в одном из самых ранних Agile (xp) усыновителей/консультантов/тренеров. Думаю, у него был хороший подход.

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

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

То, что не сработало, было столь же простым и случайным. Некоторые люди могут сопротивляться парированию или даже "Босс не вывел нас на лодку, как обещал".

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

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

После того, как элемент проведет неделю или две в столбце "Хорошо обработанный", мы отбросим его, поскольку он стал более или менее ожидаемым (если он не будет продолжать улучшаться).

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

Ответ 5

Я бы использовал "шип" для таких вещей. Внутреннее/процессное улучшение не может быть историей пользователя, но это сделает идеальный всплеск.

Ответ 6

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

Ответ 7

Нет, нельзя создавать технические истории пользователей: теоретически, и поскольку они обычно не приносят никакой прямой ценности клиенту, у них очень мало шансов быть выбранным на итерации. Убедить владельца продукта - это вариант, чтобы облегчить это, но есть еще один инструмент, который можно использовать здесь: slack.

Slack - это небольшая часть вашего времени итерации, отведенная для этих задач улучшения. Если во время итерации все будет хорошо, тогда вы сможете использовать это время для этих улучшений. С другой стороны, вы получите еще один шанс выполнить свои обязательства в случае, если команда переопределена для итерации (или задача была недооценена, сложнее, чем ожидалось...)

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

Обратитесь к Tom DeMarco Slack: получение прошлого выгорания, занятость и миф об общей эффективности (ссылка Amazon) - ISBN 0767907698.