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

Question

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

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