Комментарии 25
сколько человек у вас в команде?
Хорошая статья, спасибо.
Я бы жирным отметил, что ретроспектива — это обсуждение положительных и отрицательных элементов процесса.
Насчет ведущего: главная задача ведущего, кроме записи и собственно организации митинга, не давать команде сваливаться в бурные обсуждения одной проблемы, это роль фасилитатора — а значит ее не факт что может выполнять каждый.
«собираются только разработчики» — хм, а как же тестеры? они не входят в проектную команду?
ps. а вы используете «доску»?
Я бы жирным отметил, что ретроспектива — это обсуждение положительных и отрицательных элементов процесса.
Насчет ведущего: главная задача ведущего, кроме записи и собственно организации митинга, не давать команде сваливаться в бурные обсуждения одной проблемы, это роль фасилитатора — а значит ее не факт что может выполнять каждый.
«собираются только разработчики» — хм, а как же тестеры? они не входят в проектную команду?
ps. а вы используете «доску»?
Вообще с ведущим мы еще точно не решили, возможно остановимся на ком-нибудь одном, у кого лучше всего будет получаться :)
Идея участия тестеров в ретроспективах у нас была и есть, но пока с этим трудности: тестеры у нас находятся в другом офисе и поэтому существует этакое разделение. Хотя утренние скрамы у нас совместные.
Если Вы про доску с задачами, то да, используем.
Идея участия тестеров в ретроспективах у нас была и есть, но пока с этим трудности: тестеры у нас находятся в другом офисе и поэтому существует этакое разделение. Хотя утренние скрамы у нас совместные.
Если Вы про доску с задачами, то да, используем.
подключайте тестеров. это полезно и для девелоперов, и для самих тестеров, и для проекта :)
А мы вот доску использовали всего три двухнедельных спринта и отказались от нее. построили процесс занесения и ведения тикетов в баг-трекере так, чтобы главный принцип agile соблюдался — таски не назначаются на конкретных людей, а любой член команды берет на выполнение любой тикет из спринта и ставит in progress — в итоге все видят, у кого что и доска становится не нужна.
А мы вот доску использовали всего три двухнедельных спринта и отказались от нее. построили процесс занесения и ведения тикетов в баг-трекере так, чтобы главный принцип agile соблюдался — таски не назначаются на конкретных людей, а любой член команды берет на выполнение любой тикет из спринта и ставит in progress — в итоге все видят, у кого что и доска становится не нужна.
Спасибо за совет и внимание к статье :)
Мы с доски думаем перейти на «виртуальную» в Jira. Хотя реальная с цветными листочками удобна и привычна :)
Мы с доски думаем перейти на «виртуальную» в Jira. Хотя реальная с цветными листочками удобна и привычна :)
Agile Wall Report в Jira мы используем для наглядности прогресса спринта :)
А интерес к статье раскрывается просто: применяем в команде (6 человек) Agile Scrum с октября месяца. Методология показала себя весьма эффективной и кроме этого приносит нам fun в работе :)
Поэтому интересует все, связанное со scrum, особенно, когда приводят примеры внедрения scrum'а из личного опыта.
Обязательно пишите еще статьи, буду с удовольствием читать и комментировать.
А интерес к статье раскрывается просто: применяем в команде (6 человек) Agile Scrum с октября месяца. Методология показала себя весьма эффективной и кроме этого приносит нам fun в работе :)
Поэтому интересует все, связанное со scrum, особенно, когда приводят примеры внедрения scrum'а из личного опыта.
Обязательно пишите еще статьи, буду с удовольствием читать и комментировать.
Мне кажется, что доска сильно удобнее Jira:
1. Cоздает командное пространство — рядом с доской удобно проводить scrum meetings и обсуждения.
2. Способствует коммуникации — движение задач происходит не в виртуальном мире, а в реальном. Вся команда видит все изменения на доске не прилагая к получению этой информации никаких усилий (открыть браузер).
3. Субъективно улучшает настрой — приятно пару раз в день вставать из-за стола и перевешивать реальную бумажку.
1. Cоздает командное пространство — рядом с доской удобно проводить scrum meetings и обсуждения.
2. Способствует коммуникации — движение задач происходит не в виртуальном мире, а в реальном. Вся команда видит все изменения на доске не прилагая к получению этой информации никаких усилий (открыть браузер).
3. Субъективно улучшает настрой — приятно пару раз в день вставать из-за стола и перевешивать реальную бумажку.
У меня есть вопрос по «гибкой методологии», на который мне мало кто может дать внятный ответ.
Как вы ведете проектную документацию и согласовываете ее с заказчиком? Согласовываете при каждом изменении?
По сути большинство документации о внедрении, и разработки ПО, составляется для того, что бы менеджеры или руководители прикрыли свою жопу. Как они вообще соглашаются, что-либо делать, без прикрытия своей 5 точки?
Как вы ведете проектную документацию и согласовываете ее с заказчиком? Согласовываете при каждом изменении?
По сути большинство документации о внедрении, и разработки ПО, составляется для того, что бы менеджеры или руководители прикрыли свою жопу. Как они вообще соглашаются, что-либо делать, без прикрытия своей 5 точки?
Тут дело в следующем, когда подписывается договор, до заказчика доносится идея о том, что представитель заказчика обязательно учавствует в работе команды.
На основе спецификации (ТЗ) на весь проект пишутся UserStory.
В начале каждого спринта представитель заказчика вместе с руководителем проекта планируют задачи на этот спринт. Сколько и какие конкретно userstory должны быть реализованы (напоминаю, что результат спринта — готовый продукт, в котором реализованы не все фичи).
Заказчик сам утверждает спринт, а значит понимает, что будет сделано. постоянно видит работу. и внесение изменений в изначальное ТЗ — означает только, что на следующий спринт могут быть выбраны фичи, которые не планировались при старте проекта.
На основе спецификации (ТЗ) на весь проект пишутся UserStory.
В начале каждого спринта представитель заказчика вместе с руководителем проекта планируют задачи на этот спринт. Сколько и какие конкретно userstory должны быть реализованы (напоминаю, что результат спринта — готовый продукт, в котором реализованы не все фичи).
Заказчик сам утверждает спринт, а значит понимает, что будет сделано. постоянно видит работу. и внесение изменений в изначальное ТЗ — означает только, что на следующий спринт могут быть выбраны фичи, которые не планировались при старте проекта.
shtulberg правильно написал. Хотя основное ТЗ согласовывается изначально, но доработки идут все время, обычно это дополнения и уточнения. Конечно же, их обсуждают с заказчиком.
Раньше я называл это разбором полётов. Теперь буду знать, что это практика называется ретроспективой. =)) Спасибо, полезная статья.
Ну все-таки разница есть :) Вот у меня выражение «разбор полетов» сразу же ассоцируется с негативом, а ретроспектива очень положительное мероприятие. Как по результатам, так и по процедуре проведения.
Обсуждаются не личные промахи людей, а проблемы в самом процессе :) Ведь многие ошибкииз-за этого и происходят.
Обсуждаются не личные промахи людей, а проблемы в самом процессе :) Ведь многие ошибкииз-за этого и происходят.
Нет, это не разбор полетов :) Главная задача и, одновременно, проблема рестроспектив — это не превращать собрание в утомительную «обязаловку», где начинаются взаимные обвинения.
Кстати, у нас выходило так, что заказчик был основным «ступором» митинга, то есть описание какой-то проблемы занимало достаточно долгое время, прерывать его никому не хотелось, — в итоге большая часть времени уходила, к сожалению, впустую
Кстати, у нас выходило так, что заказчик был основным «ступором» митинга, то есть описание какой-то проблемы занимало достаточно долгое время, прерывать его никому не хотелось, — в итоге большая часть времени уходила, к сожалению, впустую
Разбор полетов обычно проводится после завершения проекта, когда уже поздно что-то менять (и скорее всего проект уже оказался не совсем успешным:) ).
Прелесть ретроспективы же в том, что мы анализируем двух (или одно-)недельную итерацию и можем улучшить свою работу прямо на следующий день после ретроспективы.
Прелесть ретроспективы же в том, что мы анализируем двух (или одно-)недельную итерацию и можем улучшить свою работу прямо на следующий день после ретроспективы.
Отличная статью. С удовольствием прочту продолжение
В прошлом году проводили встречу AgileRussia на тему ретроспектив, осталась достаточно подробная презентация.
Еще из полезного — помимо опроса в стиле «что было хорошо, а что плохо», очень здорово проходят ретроспективы c помощью диаграммы starfish, когда команда опрашивается в стиле «что работало хорошо, чего не хватало, что нужно улучшить и т.п. (см картинку по ссылке)».
Этот способ позволяет взглянуть на прошедшую итерацию немного под другим углом, нежели обычная ретроспектива.
Еще из полезного — помимо опроса в стиле «что было хорошо, а что плохо», очень здорово проходят ретроспективы c помощью диаграммы starfish, когда команда опрашивается в стиле «что работало хорошо, чего не хватало, что нужно улучшить и т.п. (см картинку по ссылке)».
Этот способ позволяет взглянуть на прошедшую итерацию немного под другим углом, нежели обычная ретроспектива.
сорри, ссылки почему-то не отобразились.
на презентацию по ретроспективам: lobasev.ru/2008/06/blog-post.html
на Starfish ретроспективу: www.thekua.com/rant/2006/03/the-retrospective-starfish/
на презентацию по ретроспективам: lobasev.ru/2008/06/blog-post.html
на Starfish ретроспективу: www.thekua.com/rant/2006/03/the-retrospective-starfish/
Спасибо за идею, может попробуем в будующей ретроспективе ее реализовать :)
У нас тоже каждая итерация заканчивается ретроспективой. Понравилась идея разделить мнения на три группы:
1) В следующей итерации я бы сделал это так же
2) В следующей итерации я бы это улучшил
3) Конкретные идеи по улучшению
На практике это легко позволяет выявить что идет хорошо, а где есть проблемы.
1) В следующей итерации я бы сделал это так же
2) В следующей итерации я бы это улучшил
3) Конкретные идеи по улучшению
На практике это легко позволяет выявить что идет хорошо, а где есть проблемы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гибкие методологии. Ретроспектива