ретроспективы ретроспективы ретроспективы

[Alexey Krivitsky]

всем привет.

я решился написать ряд постов на тему ретроспектив.  в ходе подготовки к тренингу я проработали кучу материала по этой теме. хочу поделиться.

читать первый вступительный пост

комменты как всегда приветствуются.

--
Alexey Krivitsky,

[Borys Lebeda]

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

[Артур Ракицкий]

Если заказчик не платит за такой важный этап внедрения, как cool-down period, а также, не требует final project report, в который входят в том числе и результаты ретроспективы, то... со временем этот заказчик поумнеет :)

19.02.08, Borys Lebeda <borys....@gmail.com> написал(а):

--
С уважением,
Артур Ракицкий

------------------
ICQ: 21062147

[Borys Lebeda]

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

 

В чём здесь менеждмент, если вы просто ждёте пока заказчик поумнеет? Между прочим, бывают успешные проекты без cool-down periodов и final project report!

2008/2/20 Артур Ракицкий <art...@gmail.com>:

[Артур Ракицкий]

Разве я написал, что это правильная стратегия? :) Я исходил из фразы "В конце концов заказчик не платит за это.", которая для меня означает, что по той или иной причине (плохой менеджер, жадность, глупость, спешка - не важно) заказчик не считает нужным платить. Видимо, я неправильно понял эту фразу? :)

20.02.08, Borys Lebeda <borys....@gmail.com> написал(а):

[Alexander Rivkind]

Это из опыта или жизненная позиция?

Артур Ракицкий wrote:
> Если заказчик не платит за такой важный этап внедрения, как cool-down
> period, а также, не требует final project report, в который входят в том
> числе и результаты ретроспективы, то... со временем этот заказчик поумнеет
> :)
>
> 19.02.08, Borys Lebeda <borys....@gmail.com> написал(а):
>
>> Мне кажется основная причина почему ретроспективы не проводятся, это
>> потому что все участники команды считают это пустой тратой времени. В конце
>> концов заказчик не платит за это. Этой причины почему-то нет в списке, а
>> ведь самое главное показать, что ретроспективы имеют большой смысл. Причём
>> именно ретроспективы деятельности команды, а не отдельного человека. Причём
>> именно с вовлечением всей команды, а не в рамках отдельной рабочей группы.
>>
>> On 2/19/08, Alexey Krivitsky <alexeyk...@gmail.com> wrote:
>>
>>> всем привет.
>>>
>>> я решился написать ряд постов на тему ретроспектив. в ходе подготовки к
>>> тренингу я проработали кучу материала по этой теме. хочу поделиться.

>>> <http://www.scrum.com.ua/2008/02/retrospections-formality-or-usefulness.html>
>>> читать первый вступительный пост<http://www.scrum.com.ua/2008/02/retrospections-formality-or-usefulness.html>

[Alexey Krivitsky]

привет,

заказчики нам платят (а большинстве случаев) за разработку продукта.

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

или я не прав?

2008/2/20 Alexander Rivkind <alik...@gmail.com>:

[Alexey Krivitsky]

следующий пост на тему ретроспектив

предлагаю обсудить и пополнить список проблем, возникающий при проведении ретроспектив

лёша

2008/2/20 Alexey Krivitsky <alexeyk...@gmail.com>:

[Артур Ракицкий]

[off]
Это из опыта :) Позиция у меня обычно относится к проекту/деятельности, а в жизни - ценности, традиции, привычки и предрассудки ;)
[/off]

20.02.08, Alexander Rivkind <alik...@gmail.com> написал(а):

[Артур Ракицкий]

Иногда заказчики платят не только за продукт. В случае с Agile (и его применением на Украине в аутстаффе) - это скорее правило - заказчики платят за часы аренды...

20.02.08, Alexey Krivitsky <alexeyk...@gmail.com> написал(а):

[Alexander Rivkind]

Это просто разные модели. Есть fixed price, есть T&M. И в том, и в
другом случае заказчик хочет заплатить меньше. И убедить его, что он
должен платить за "работу над ошибками" совсем не просто. Особенно в
случае T&M, где расчасовка по задачам ему доступна. :)

[irina.pi...@gmail.com]

Алексей,

только хотела предложить прокомментировать если ретроспективы
заканчиваются ничем. А тут и статья подоспела! :) Отлично спасибо.
Таки часто они действительно заканчиваются ничем, ну сделают Action
Item, но после 10 ретроспектив уже такой внушительный список того, что
делать НЕ стоит собирается, что пересматривать его каждый раз на новой
ретроспективе становится очень скучным.

Жду продолжения :)

On Feb 20, 10:51 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> следующий пост на тему
> ретроспектив<http://www.scrum.com.ua/2008/02/retrospectives-what-we-do-wrong.html>

>
> предлагаю обсудить и пополнить список проблем, возникающий при проведении
> ретроспектив
>
> лёша
>

> 2008/2/20 Alexey Krivitsky <alexeykrivit...@gmail.com>:

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

> > 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:

>
> > Это из опыта или жизненная позиция?
>
> > > Артур Ракицкий wrote:
> > > > Если заказчик не платит за такой важный этап внедрения, как cool-down
> > > > period, а также, не требует final project report, в который входят в
> > > том
> > > > числе и результаты ретроспективы, то... со временем этот заказчик
> > > поумнеет
> > > > :)
>

> > > > 19.02.08, Borys Lebeda <borys.leb...@gmail.com> написал(а):

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

> > > >> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
>
> > > >>> всем привет.
>
> > > >>> я решился написать ряд постов на тему ретроспектив.  в ходе
> > > подготовки к
> > > >>> тренингу я проработали кучу материала по этой теме. хочу поделиться.
> > > >>> <

> > >http://www.scrum.com.ua/2008/02/retrospections-formality-or-usefulnes...
>
> > > >>> читать первый вступительный пост<
> > >http://www.scrum.com.ua/2008/02/retrospections-formality-or-usefulnes...

>
> > > >>> комменты как всегда приветствуются.
>
> > > >>> --

> > > >>> Alexey Krivitsky,- Hide quoted text -
>
> - Show quoted text -

[Alimenkou Nikolay]

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

On Feb 21, 2:57 pm, "irina.pivovar...@gmail.com"

[Borys Lebeda]

Абсолютно согласен!

 

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

 

Я в IT бизнессе не больше 4 лет и УЖЕ кучу раз видел, как заказчик не платил за те или инные практики рекомендованные яйцеголовыми ребятами от Фредерика Брукса и Стива МакКоннала до Рекса Блека и Джоеля Спольски. И тем не менее они получали успешный продукт и прибыль. А также видел, когда вроде вкладываются немалые деньги в решение инфраструктурных задач, но проект тем не менее провальный.

 

Я могу прям завтра пройтись по нашему офису и позадавать заказчикам наводящие вопросы: знают ли они вообще что такое cool-down period, и как выглядит final project report. Уверен, что получу кучу не похожих один на другой ответов ...

 

--
Borys L.

[Артур Ракицкий]

Они могут не знать терминов. Но после первого успешного запуска в промышленную эксплуатацию, узнают их суть. :) Как минимум первого. Суть второго узнаЮт только те, что считают стоимость разработки, а не тупо "башляют за сайт" ;)

21.02.08, Borys Lebeda <borys....@gmail.com> написал(а):

[Serhiy Yevtushenko]

Мой опыт касательно ретроспектив

 

Сами по себе, ретроспектива - штука полезная.

Главная роль ретроспектив - не столько улучшение процесса. Я бы определил их как

официальный форум для "критических разговоров", место разрешения непонятностей/недосказонностей, и

 

 

Но при практическом применении возникает ряд вопросов

 

1)

 

21.02.08, Артур Ракицкий <art...@gmail.com> написал(а):

[Serhiy Yevtushenko]

Сорри, предыдущее сообщени отправилось по ошибке.

 

Мой опыт касательно ретроспектив

 

Сами по себе, ретроспектива - штука полезная.

 

Главная роль ретроспектив - не столько улучшение процесса. Я бы определил их как

- официальный форум для "критических разговоров",

- место разрешения непонятностей/недосказонностей,

- место разрешения конфликтов

- и средство подчеркивания/усиления того хорошего, что есть на проекте

 

Какие сложности

- проведение ретроспективы по пяти шагам (Ларсен и Дерби) требует достаточно большого времени (2 * продолжительность ретроспективы)

- времени на подготовку к ретроспективе часто отсутствует/не хватает

- должна быть определена четкая цель ретроспективы

- проведение ретроспектив слишком часто (раз в неделю) - депресивно действует на команду

- фасилитация - это навык, который требует хорошей подготовки, и кривая обучения достаточно кривая

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

- ретроспективы должны заканчиваться конкретным планом действий, и по плану действий должен быть follow-up.

[Alexey Krivitsky]

Привет.

Я согласен с Сергеем по ряду пунктов. В том числе с тем, что:

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

На счёт структуры, предложенной Ларсен и Дерби. Я думаю, что проведение ретроспективы без подобных чётких шагов вообще весьма сложно, особенно для начинающих команд. Так что даже если это и требует больше времени по сравнению с традиционными (неработающими?) подходами, то выгода очевидна.

По сему, я написал пост, где описал предлагаемую мной структуру и описал фазу подготовку аудитории.

Предложенная структура - это результат переработки структуры Ларсен и Дерби, Глогера, других материалов плюс собственного опыта. Но суть та же.

Далі буде.
Алексей.

2008/2/25 Serhiy Yevtushenko <syevtu...@gmail.com>:

[Serhiy Yevtushenko]

Привет, Леша.

 

Несколько комментов по поводу поста:

 

Рекомендуемая Derby и Ларсен структура ретроспективы является вариантом метода Consensus Workshop, который разработан в ICA (Institute for Cultural Affairs, Canada)

 

Метод включает в себя следующие 5 фаз

Set the context (Установите контекст обсуждения) - Введение и цель

Brainstorm (Harvesting the Group Ideas) - Бреншторминг Соберите идеи группы

Clustering (Order out of Chaos) - процесс группировки большого количества сгенерированных идей в кластеры (именование кластеров избегается на этом шаге, чтобы избежать стереотипов и оценки- принцип разделения генерации идей и их оценки - одного из самых важных при брейншторминге и фасилитации

Naming - именование кластеров

Resolve - принятие решений

 

Второе перспектива этой последовательности -

ORID

Objective (Data)

Reflective (Feeling)

Interpretation

Decision

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

 

 

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

 

Далее, цель улучшение процесса работает максимум 2-3 ретроспективы. После этого по моему опыту стоит использовать другие цели.

 

 

26.02.08, Alexey Krivitsky <alexeyk...@gmail.com> написал(а):

[Serhiy Yevtushenko]

Публикации о ретроспективах на InfoQ:

 

 

О валидности /не валидности основной директивы, лежащей в основании ретроспектив:

Questioning the Prime Directive:

News - http://www.infoq.com/news/2008/02/retrospective-prime-directive

Talk transcript - http://www.infoq.com/articles/retrospective-prime-directive

 

 

Вторая директива (которая часто неявно предпалагается при использовании первой)

Second Directive (Dale Emery) - http://cwd.dhemery.com/2003/06/the_second_directive/ -