Pull to refresh

Comments 25

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

ps. а вы используете «доску»?
Вообще с ведущим мы еще точно не решили, возможно остановимся на ком-нибудь одном, у кого лучше всего будет получаться :)

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

Если Вы про доску с задачами, то да, используем.
подключайте тестеров. это полезно и для девелоперов, и для самих тестеров, и для проекта :)

А мы вот доску использовали всего три двухнедельных спринта и отказались от нее. построили процесс занесения и ведения тикетов в баг-трекере так, чтобы главный принцип agile соблюдался — таски не назначаются на конкретных людей, а любой член команды берет на выполнение любой тикет из спринта и ставит in progress — в итоге все видят, у кого что и доска становится не нужна.
Спасибо за совет и внимание к статье :)

Мы с доски думаем перейти на «виртуальную» в Jira. Хотя реальная с цветными листочками удобна и привычна :)
Agile Wall Report в Jira мы используем для наглядности прогресса спринта :)

А интерес к статье раскрывается просто: применяем в команде (6 человек) Agile Scrum с октября месяца. Методология показала себя весьма эффективной и кроме этого приносит нам fun в работе :)
Поэтому интересует все, связанное со scrum, особенно, когда приводят примеры внедрения scrum'а из личного опыта.

Обязательно пишите еще статьи, буду с удовольствием читать и комментировать.
Мне кажется, что доска сильно удобнее Jira:

1. Cоздает командное пространство — рядом с доской удобно проводить scrum meetings и обсуждения.
2. Способствует коммуникации — движение задач происходит не в виртуальном мире, а в реальном. Вся команда видит все изменения на доске не прилагая к получению этой информации никаких усилий (открыть браузер).
3. Субъективно улучшает настрой — приятно пару раз в день вставать из-за стола и перевешивать реальную бумажку.
В каждом методе есть свои достоинства и недостатки. А когда команда распределенная без «виртуальной доски» никак :)

Хотя кинуть взгляд на белую доску в цветных листочках, что бы посмотреть сколько в работе, сколько закрытых, а сколько еще новых задач — очень приятно :)
С распределенной командой — да, ничего не поделаешь ;)
Можно попытаться слегка развиртуализировать доску в jira повесив проектор с taskboard на стену, который бы обновлялся раз в минуту. Проекторы нынче не дорогие =)
У меня есть вопрос по «гибкой методологии», на который мне мало кто может дать внятный ответ.

Как вы ведете проектную документацию и согласовываете ее с заказчиком? Согласовываете при каждом изменении?
По сути большинство документации о внедрении, и разработки ПО, составляется для того, что бы менеджеры или руководители прикрыли свою жопу. Как они вообще соглашаются, что-либо делать, без прикрытия своей 5 точки?
Тут дело в следующем, когда подписывается договор, до заказчика доносится идея о том, что представитель заказчика обязательно учавствует в работе команды.
На основе спецификации (ТЗ) на весь проект пишутся UserStory.
В начале каждого спринта представитель заказчика вместе с руководителем проекта планируют задачи на этот спринт. Сколько и какие конкретно userstory должны быть реализованы (напоминаю, что результат спринта — готовый продукт, в котором реализованы не все фичи).
Заказчик сам утверждает спринт, а значит понимает, что будет сделано. постоянно видит работу. и внесение изменений в изначальное ТЗ — означает только, что на следующий спринт могут быть выбраны фичи, которые не планировались при старте проекта.
shtulberg правильно написал. Хотя основное ТЗ согласовывается изначально, но доработки идут все время, обычно это дополнения и уточнения. Конечно же, их обсуждают с заказчиком.
Раньше я называл это разбором полётов. Теперь буду знать, что это практика называется ретроспективой. =)) Спасибо, полезная статья.
Ну все-таки разница есть :) Вот у меня выражение «разбор полетов» сразу же ассоцируется с негативом, а ретроспектива очень положительное мероприятие. Как по результатам, так и по процедуре проведения.
Обсуждаются не личные промахи людей, а проблемы в самом процессе :) Ведь многие ошибкииз-за этого и происходят.
Нет, это не разбор полетов :) Главная задача и, одновременно, проблема рестроспектив — это не превращать собрание в утомительную «обязаловку», где начинаются взаимные обвинения.
Кстати, у нас выходило так, что заказчик был основным «ступором» митинга, то есть описание какой-то проблемы занимало достаточно долгое время, прерывать его никому не хотелось, — в итоге большая часть времени уходила, к сожалению, впустую
Разбор полетов обычно проводится после завершения проекта, когда уже поздно что-то менять (и скорее всего проект уже оказался не совсем успешным:) ).

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

Еще из полезного — помимо опроса в стиле «что было хорошо, а что плохо», очень здорово проходят ретроспективы c помощью диаграммы starfish, когда команда опрашивается в стиле «что работало хорошо, чего не хватало, что нужно улучшить и т.п. (см картинку по ссылке)».

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

На практике это легко позволяет выявить что идет хорошо, а где есть проблемы.
Sign up to leave a comment.

Articles