К основному контенту

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn)
Перевод с английского


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

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

Хотя существует множество способов организации Ретроспективы спринта, я рекомендую проводить ее в формате «старт-стоп-продолжить» (start-stop-continue) . Это, пожалуй, самый простой, но часто наиболее эффективный способ проведения ретроспектив. При таком подходе каждому участнику команды будет предложено определить конкретные вещи, которые команда должна:
  • Начать делать 
  • Прекратить делать 
  • Продолжать делать
Есть множество вариаций, построенных на этом простом формате. Скрам-мастер может фасилитировать проведение этой встречи, предлагая каждому участнику просто выкрикивать свои идеи. Скрам-мастер может в это время просто ходить по комнате, спрашивая каждого присутствующего какую, на его взгляд, любую вещь мы должны начать, прекратить, или продолжать делать. Или, например, Скрам-мастер может попросить всех сосредоточиться на определении чего-то, что мы должны прекратить делать в этот раз, поскольку на прошлых ретроспективах этим вещам было уделено слишком мало внимания.

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


Переведено с английского проектом Agile Translations.
Оригинальная статья: Sprint Retrospective.

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Календарь тренингов по Agile

Наши партнёры по тренингам: