Мне кажется основная причина почему ретроспективы не проводятся, это потому что все участники команды считают это пустой тратой времени. В конце концов заказчик не платит за это. Этой причины почему-то нет в списке, а ведь самое главное показать, что ретроспективы имеют большой смысл. Причём именно ретроспективы деятельности команды, а не отдельного человека. Причём именно с вовлечением всей команды, а не в рамках отдельной рабочей группы.
On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
Если заказчик не платит за такой важный этап внедрения, как cool-down period, а также, не требует final project report, в который входят в том числе и результаты ретроспективы, то... со временем этот заказчик поумнеет :)
> Мне кажется основная причина почему ретроспективы не проводятся, это > потому что все участники команды считают это пустой тратой времени. В конце > концов заказчик не платит за это. Этой причины почему-то нет в списке, а > ведь самое главное показать, что ретроспективы имеют большой смысл. Причём > именно ретроспективы деятельности команды, а не отдельного человека. Причём > именно с вовлечением всей команды, а не в рамках отдельной рабочей группы.
> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
Нельзя расчитывать на то, что заказчик и команда поумнеют, после того как им дать облажаться: хотя бы половину (а лучше всех) нужно убедить, что разборы полётов нужно проводить и определить глубину этих разборов.
В чём здесь менеждмент, если вы просто ждёте пока заказчик поумнеет? Между прочим, бывают успешные проекты без cool-down periodов и final project report!
> Если заказчик не платит за такой важный этап внедрения, как cool-down > period, а также, не требует final project report, в который входят в том > числе и результаты ретроспективы, то... со временем этот заказчик поумнеет > :)
> > Мне кажется основная причина почему ретроспективы не проводятся, это > > потому что все участники команды считают это пустой тратой времени. В конце > > концов заказчик не платит за это. Этой причины почему-то нет в списке, а > > ведь самое главное показать, что ретроспективы имеют большой смысл. Причём > > именно ретроспективы деятельности команды, а не отдельного человека. Причём > > именно с вовлечением всей команды, а не в рамках отдельной рабочей группы.
> > On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> > > всем привет.
> > > я решился написать ряд постов на тему ретроспектив. в ходе подготовки > > > к тренингу я проработали кучу материала по этой теме. хочу поделиться.
Разве я написал, что это правильная стратегия? :) Я исходил из фразы "В конце концов заказчик не платит за это.", которая для меня означает, что по той или иной причине (плохой менеджер, жадность, глупость, спешка - не важно) заказчик не считает нужным платить. Видимо, я неправильно понял эту фразу? :)
> Нельзя расчитывать на то, что заказчик и команда поумнеют, после того как > им дать облажаться: хотя бы половину (а лучше всех) нужно убедить, что > разборы полётов нужно проводить и определить глубину этих разборов.
> В чём здесь менеждмент, если вы просто ждёте пока заказчик поумнеет? Между > прочим, бывают успешные проекты без cool-down periodов и final project > report!
> > Если заказчик не платит за такой важный этап внедрения, как cool-down > > period, а также, не требует final project report, в который входят в том > > числе и результаты ретроспективы, то... со временем этот заказчик поумнеет > > :)
> > > Мне кажется основная причина почему ретроспективы не проводятся, это > > > потому что все участники команды считают это пустой тратой времени. В конце > > > концов заказчик не платит за это. Этой причины почему-то нет в списке, а > > > ведь самое главное показать, что ретроспективы имеют большой смысл. Причём > > > именно ретроспективы деятельности команды, а не отдельного человека. Причём > > > именно с вовлечением всей команды, а не в рамках отдельной рабочей группы.
> > > On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
Артур Ракицкий wrote: > Если заказчик не платит за такой важный этап внедрения, как cool-down > period, а также, не требует final project report, в который входят в том > числе и результаты ретроспективы, то... со временем этот заказчик поумнеет > :)
>> Мне кажется основная причина почему ретроспективы не проводятся, это >> потому что все участники команды считают это пустой тратой времени. В конце >> концов заказчик не платит за это. Этой причины почему-то нет в списке, а >> ведь самое главное показать, что ретроспективы имеют большой смысл. Причём >> именно ретроспективы деятельности команды, а не отдельного человека. Причём >> именно с вовлечением всей команды, а не в рамках отдельной рабочей группы.
>> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
заказчики нам платят (а большинстве случаев) за разработку продукта.
то, какие действия нам нужны для этой деятельности (митинги, разработка артефактов и прочее) - на усмотрение команды. так что фраза "нам не платят - делать не будем" как мне кажется весьма абстрактна, и используется больше как оправдание неделания тех же самых ретроспектив
> Артур Ракицкий wrote: > > Если заказчик не платит за такой важный этап внедрения, как cool-down > > period, а также, не требует final project report, в который входят в том > > числе и результаты ретроспективы, то... со временем этот заказчик > поумнеет > > :)
> >> Мне кажется основная причина почему ретроспективы не проводятся, это > >> потому что все участники команды считают это пустой тратой времени. В > конце > >> концов заказчик не платит за это. Этой причины почему-то нет в списке, > а > >> ведь самое главное показать, что ретроспективы имеют большой смысл. > Причём > >> именно ретроспективы деятельности команды, а не отдельного человека. > Причём > >> именно с вовлечением всей команды, а не в рамках отдельной рабочей > группы.
> >> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> заказчики нам платят (а большинстве случаев) за разработку продукта.
> то, какие действия нам нужны для этой деятельности (митинги, разработка > артефактов и прочее) - на усмотрение команды. > так что фраза "нам не платят - делать не будем" как мне кажется весьма > абстрактна, и используется больше как оправдание неделания тех же самых > ретроспектив
> или я не прав?
> 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:
> Это из опыта или жизненная позиция?
> > Артур Ракицкий wrote: > > > Если заказчик не платит за такой важный этап внедрения, как cool-down > > > period, а также, не требует final project report, в который входят в > > том > > > числе и результаты ретроспективы, то... со временем этот заказчик > > поумнеет > > > :)
> > >> Мне кажется основная причина почему ретроспективы не проводятся, это > > >> потому что все участники команды считают это пустой тратой времени. В > > конце > > >> концов заказчик не платит за это. Этой причины почему-то нет в > > списке, а > > >> ведь самое главное показать, что ретроспективы имеют большой смысл. > > Причём > > >> именно ретроспективы деятельности команды, а не отдельного человека. > > Причём > > >> именно с вовлечением всей команды, а не в рамках отдельной рабочей > > группы.
> > >> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> Артур Ракицкий wrote: > > Если заказчик не платит за такой важный этап внедрения, как cool-down > > period, а также, не требует final project report, в который входят в том > > числе и результаты ретроспективы, то... со временем этот заказчик > поумнеет > > :)
> >> Мне кажется основная причина почему ретроспективы не проводятся, это > >> потому что все участники команды считают это пустой тратой времени. В > конце > >> концов заказчик не платит за это. Этой причины почему-то нет в списке, > а > >> ведь самое главное показать, что ретроспективы имеют большой смысл. > Причём > >> именно ретроспективы деятельности команды, а не отдельного человека. > Причём > >> именно с вовлечением всей команды, а не в рамках отдельной рабочей > группы.
> >> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
Иногда заказчики платят не только за продукт. В случае с Agile (и его применением на Украине в аутстаффе) - это скорее правило - заказчики платят за часы аренды...
> заказчики нам платят (а большинстве случаев) за разработку продукта.
> то, какие действия нам нужны для этой деятельности (митинги, разработка > артефактов и прочее) - на усмотрение команды. > так что фраза "нам не платят - делать не будем" как мне кажется весьма > абстрактна, и используется больше как оправдание неделания тех же самых > ретроспектив
> или я не прав?
> 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:
> > Это из опыта или жизненная позиция?
> > Артур Ракицкий wrote: > > > Если заказчик не платит за такой важный этап внедрения, как cool-down > > > period, а также, не требует final project report, в который входят в > > том > > > числе и результаты ретроспективы, то... со временем этот заказчик > > поумнеет > > > :)
> > >> Мне кажется основная причина почему ретроспективы не проводятся, это > > >> потому что все участники команды считают это пустой тратой времени. В > > конце > > >> концов заказчик не платит за это. Этой причины почему-то нет в > > списке, а > > >> ведь самое главное показать, что ретроспективы имеют большой смысл. > > Причём > > >> именно ретроспективы деятельности команды, а не отдельного человека. > > Причём > > >> именно с вовлечением всей команды, а не в рамках отдельной рабочей > > группы.
> > >> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
Это просто разные модели. Есть fixed price, есть T&M. И в том, и в другом случае заказчик хочет заплатить меньше. И убедить его, что он должен платить за "работу над ошибками" совсем не просто. Особенно в случае T&M, где расчасовка по задачам ему доступна. :)
Артур Ракицкий wrote: > Иногда заказчики платят не только за продукт. В случае с Agile (и его > применением на Украине в аутстаффе) - это скорее правило - заказчики платят > за часы аренды...
>> заказчики нам платят (а большинстве случаев) за разработку продукта.
>> то, какие действия нам нужны для этой деятельности (митинги, разработка >> артефактов и прочее) - на усмотрение команды. >> так что фраза "нам не платят - делать не будем" как мне кажется весьма >> абстрактна, и используется больше как оправдание неделания тех же самых >> ретроспектив
>> или я не прав?
>> 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:
>>> Это из опыта или жизненная позиция?
>>> Артур Ракицкий wrote:
>>>> Если заказчик не платит за такой важный этап внедрения, как cool-down >>>> period, а также, не требует final project report, в который входят в
>>> том
>>>> числе и результаты ретроспективы, то... со временем этот заказчик
только хотела предложить прокомментировать если ретроспективы
заканчиваются ничем. А тут и статья подоспела! :) Отлично спасибо.
Таки часто они действительно заканчиваются ничем, ну сделают Action
Item, но после 10 ретроспектив уже такой внушительный список того, что
делать НЕ стоит собирается, что пересматривать его каждый раз на новой
ретроспективе становится очень скучным.
Жду продолжения :)
On Feb 20, 10:51 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> > заказчики нам платят (а большинстве случаев) за разработку продукта.
> > то, какие действия нам нужны для этой деятельности (митинги, разработка
> > артефактов и прочее) - на усмотрение команды.
> > так что фраза "нам не платят - делать не будем" как мне кажется весьма
> > абстрактна, и используется больше как оправдание неделания тех же самых
> > ретроспектив
> > или я не прав?
> > 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:
> > Это из опыта или жизненная позиция?
> > > Артур Ракицкий wrote:
> > > > Если заказчик не платит за такой важный этап внедрения, как cool-down
> > > > period, а также, не требует final project report, в который входят в
> > > том
> > > > числе и результаты ретроспективы, то... со временем этот заказчик
> > > поумнеет
> > > > :)
> > > >> Мне кажется основная причина почему ретроспективы не проводятся, это
> > > >> потому что все участники команды считают это пустой тратой времени. В
> > > конце
> > > >> концов заказчик не платит за это. Этой причины почему-то нет в
> > > списке, а
> > > >> ведь самое главное показать, что ретроспективы имеют большой смысл.
> > > Причём
> > > >> именно ретроспективы деятельности команды, а не отдельного человека.
> > > Причём
> > > >> именно с вовлечением всей команды, а не в рамках отдельной рабочей
> > > группы.
> > > >> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
А это как раз самая большая беда. Когда они заканчиваются ничем, а это
случается очень часто,
то выливается все просто в потраченное время. Часто это происходит из-
за безответственности
членов команды. Часто все высказывают претензии и пожелания к процессу
и ситуации на проекте, но
когда требуется участие с их стороны, то заканчивается все просто
разговорами. Но от ретроспектив
никуда не уйти, так же как и не заставить безответственного человека
стать более ответственным. :)
Надо бороться... :)
> только хотела предложить прокомментировать если ретроспективы
> заканчиваются ничем. А тут и статья подоспела! :) Отлично спасибо.
> Таки часто они действительно заканчиваются ничем, ну сделают Action
> Item, но после 10 ретроспектив уже такой внушительный список того, что
> делать НЕ стоит собирается, что пересматривать его каждый раз на новой
> ретроспективе становится очень скучным.
> > > заказчики нам платят (а большинстве случаев) за разработку продукта.
> > > то, какие действия нам нужны для этой деятельности (митинги, разработка
> > > артефактов и прочее) - на усмотрение команды.
> > > так что фраза "нам не платят - делать не будем" как мне кажется весьма
> > > абстрактна, и используется больше как оправдание неделания тех же самых
> > > ретроспектив
> > > или я не прав?
> > > 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:
> > > Это из опыта или жизненная позиция?
> > > > Артур Ракицкий wrote:
> > > > > Если заказчик не платит за такой важный этап внедрения, как cool-down
> > > > > period, а также, не требует final project report, в который входят в
> > > > том
> > > > > числе и результаты ретроспективы, то... со временем этот заказчик
> > > > поумнеет
> > > > > :)
> > > > >> Мне кажется основная причина почему ретроспективы не проводятся, это
> > > > >> потому что все участники команды считают это пустой тратой времени. В
> > > > конце
> > > > >> концов заказчик не платит за это. Этой причины почему-то нет в
> > > > списке, а
> > > > >> ведь самое главное показать, что ретроспективы имеют большой смысл.
> > > > Причём
> > > > >> именно ретроспективы деятельности команды, а не отдельного человека.
> > > > Причём
> > > > >> именно с вовлечением всей команды, а не в рамках отдельной рабочей
> > > > группы.
На многих конторах ПМ в основном тем и занимаются, что убеждают заказчиков вкладываться в ту работу, которая незаметна конечному потребителю. Это не просто, поскольку чаще всего это ничего не гарантирует, а просто снижает риски, которые могут сыграть, а могут не сыграть.
Я в IT бизнессе не больше 4 лет и УЖЕ кучу раз видел, как заказчик не платил за те или инные практики рекомендованные яйцеголовыми ребятами от Фредерика Брукса и Стива МакКоннала до Рекса Блека и Джоеля Спольски. И тем не менее они получали успешный продукт и прибыль. А также видел, когда вроде вкладываются немалые деньги в решение инфраструктурных задач, но проект тем не менее провальный.
Я могу прям завтра пройтись по нашему офису и позадавать заказчикам наводящие вопросы: знают ли они вообще что такое cool-down period, и как выглядит final project report. Уверен, что получу кучу не похожих один на другой ответов ...
On 2/20/08, Alexander Rivkind <alik1...@gmail.com> wrote:
> Это просто разные модели. Есть fixed price, есть T&M. И в том, и в > другом случае заказчик хочет заплатить меньше. И убедить его, что он > должен платить за "работу над ошибками" совсем не просто. Особенно в > случае T&M, где расчасовка по задачам ему доступна. :)
> Артур Ракицкий wrote: > > Иногда заказчики платят не только за продукт. В случае с Agile (и его > > применением на Украине в аутстаффе) - это скорее правило - заказчики > платят > > за часы аренды...
> >> заказчики нам платят (а большинстве случаев) за разработку продукта.
> >> то, какие действия нам нужны для этой деятельности (митинги, разработка > >> артефактов и прочее) - на усмотрение команды. > >> так что фраза "нам не платят - делать не будем" как мне кажется весьма > >> абстрактна, и используется больше как оправдание неделания тех же самых > >> ретроспектив
> >> или я не прав?
> >> 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:
> >>> Это из опыта или жизненная позиция?
> >>> Артур Ракицкий wrote:
> >>>> Если заказчик не платит за такой важный этап внедрения, как cool-down > >>>> period, а также, не требует final project report, в который входят в
> >>> том
> >>>> числе и результаты ретроспективы, то... со временем этот заказчик
> >>>>> Мне кажется основная причина почему ретроспективы не проводятся, это > >>>>> потому что все участники команды считают это пустой тратой времени. > В
> >>> конце
> >>>>> концов заказчик не платит за это. Этой причины почему-то нет в
> >>> списке, а
> >>>>> ведь самое главное показать, что ретроспективы имеют большой смысл.
> >>> Причём
> >>>>> именно ретроспективы деятельности команды, а не отдельного человека.
> >>> Причём
> >>>>> именно с вовлечением всей команды, а не в рамках отдельной рабочей
> >>> группы.
> >>>>> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> >>>>>> всем привет.
> >>>>>> я решился написать ряд постов на тему ретроспектив. в ходе
> >>> подготовки к
> >>>>>> тренингу я проработали кучу материала по этой теме. хочу > поделиться. > >>>>>> <
Они могут не знать терминов. Но после первого успешного запуска в промышленную эксплуатацию, узнают их суть. :) Как минимум первого. Суть второго узнаЮт только те, что считают стоимость разработки, а не тупо "башляют за сайт" ;)
> На многих конторах ПМ в основном тем и занимаются, что убеждают заказчиков > вкладываться в ту работу, которая незаметна конечному потребителю. Это не > просто, поскольку чаще всего это ничего не гарантирует, а просто снижает > риски, которые могут сыграть, а могут не сыграть.
> Я в IT бизнессе не больше 4 лет и УЖЕ кучу раз видел, как заказчик не > платил за те или инные практики рекомендованные яйцеголовыми ребятами от > Фредерика Брукса и Стива МакКоннала до Рекса Блека и Джоеля Спольски. И тем > не менее они получали успешный продукт и прибыль. А также видел, когда вроде > вкладываются немалые деньги в решение инфраструктурных задач, но проект тем > не менее провальный.
> Я могу прям завтра пройтись по нашему офису и позадавать заказчикам > наводящие вопросы: знают ли они вообще что такое cool-down period, и как > выглядит final project report. Уверен, что получу кучу не похожих один на > другой ответов ...
> On 2/20/08, Alexander Rivkind <alik1...@gmail.com> wrote:
> > Это просто разные модели. Есть fixed price, есть T&M. И в том, и в > > другом случае заказчик хочет заплатить меньше. И убедить его, что он > > должен платить за "работу над ошибками" совсем не просто. Особенно в > > случае T&M, где расчасовка по задачам ему доступна. :)
> > Артур Ракицкий wrote: > > > Иногда заказчики платят не только за продукт. В случае с Agile (и его > > > применением на Украине в аутстаффе) - это скорее правило - заказчики > > платят > > > за часы аренды...
> > >> заказчики нам платят (а большинстве случаев) за разработку продукта.
> > >> то, какие действия нам нужны для этой деятельности (митинги, > > разработка > > >> артефактов и прочее) - на усмотрение команды. > > >> так что фраза "нам не платят - делать не будем" как мне кажется > > весьма > > >> абстрактна, и используется больше как оправдание неделания тех же > > самых > > >> ретроспектив
> > >> или я не прав?
> > >> 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:
> > >>> Это из опыта или жизненная позиция?
> > >>> Артур Ракицкий wrote:
> > >>>> Если заказчик не платит за такой важный этап внедрения, как > > cool-down > > >>>> period, а также, не требует final project report, в который входят > > в
> > >>> том
> > >>>> числе и результаты ретроспективы, то... со временем этот заказчик
> > >>>>> Мне кажется основная причина почему ретроспективы не проводятся, > > это > > >>>>> потому что все участники команды считают это пустой тратой > > времени. В
> > >>> конце
> > >>>>> концов заказчик не платит за это. Этой причины почему-то нет в
> > >>> списке, а
> > >>>>> ведь самое главное показать, что ретроспективы имеют большой > > смысл.
> > >>> Причём
> > >>>>> именно ретроспективы деятельности команды, а не отдельного > > человека.
> > >>> Причём
> > >>>>> именно с вовлечением всей команды, а не в рамках отдельной рабочей
> > >>> группы.
> > >>>>> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> > >>>>>> всем привет.
> > >>>>>> я решился написать ряд постов на тему ретроспектив. в ходе
> > >>> подготовки к
> > >>>>>> тренингу я проработали кучу материала по этой теме. хочу > > поделиться. > > >>>>>> <
Сами по себе, ретроспектива - штука полезная. Главная роль ретроспектив - не столько улучшение процесса. Я бы определил их как официальный форум для "критических разговоров", место разрешения непонятностей/недосказонностей, и
Но при практическом применении возникает ряд вопросов
> Они могут не знать терминов. Но после первого успешного запуска в > промышленную эксплуатацию, узнают их суть. :) Как минимум первого. Суть > второго узнаЮт только те, что считают стоимость разработки, а не тупо > "башляют за сайт" ;)
> > На многих конторах ПМ в основном тем и занимаются, что убеждают > > заказчиков вкладываться в ту работу, которая незаметна конечному > > потребителю. Это не просто, поскольку чаще всего это ничего не гарантирует, > > а просто снижает риски, которые могут сыграть, а могут не сыграть.
> > Я в IT бизнессе не больше 4 лет и УЖЕ кучу раз видел, как заказчик не > > платил за те или инные практики рекомендованные яйцеголовыми ребятами от > > Фредерика Брукса и Стива МакКоннала до Рекса Блека и Джоеля Спольски. И тем > > не менее они получали успешный продукт и прибыль. А также видел, когда вроде > > вкладываются немалые деньги в решение инфраструктурных задач, но проект тем > > не менее провальный.
> > Я могу прям завтра пройтись по нашему офису и позадавать заказчикам > > наводящие вопросы: знают ли они вообще что такое cool-down period, и как > > выглядит final project report. Уверен, что получу кучу не похожих один на > > другой ответов ...
> > On 2/20/08, Alexander Rivkind <alik1...@gmail.com> wrote:
> > > Это просто разные модели. Есть fixed price, есть T&M. И в том, и в > > > другом случае заказчик хочет заплатить меньше. И убедить его, что он > > > должен платить за "работу над ошибками" совсем не просто. Особенно в > > > случае T&M, где расчасовка по задачам ему доступна. :)
> > > Артур Ракицкий wrote: > > > > Иногда заказчики платят не только за продукт. В случае с Agile (и > > > его > > > > применением на Украине в аутстаффе) - это скорее правило - заказчики > > > платят > > > > за часы аренды...
> > > >> заказчики нам платят (а большинстве случаев) за разработку > > > продукта.
> > > >> то, какие действия нам нужны для этой деятельности (митинги, > > > разработка > > > >> артефактов и прочее) - на усмотрение команды. > > > >> так что фраза "нам не платят - делать не будем" как мне кажется > > > весьма > > > >> абстрактна, и используется больше как оправдание неделания тех же > > > самых > > > >> ретроспектив
> > > >> или я не прав?
> > > >> 2008/2/20 Alexander Rivkind <alik1...@gmail.com>:
> > > >>> Это из опыта или жизненная позиция?
> > > >>> Артур Ракицкий wrote:
> > > >>>> Если заказчик не платит за такой важный этап внедрения, как > > > cool-down > > > >>>> period, а также, не требует final project report, в который > > > входят в
> > > >>> том
> > > >>>> числе и результаты ретроспективы, то... со временем этот заказчик
> > > >>>>> Мне кажется основная причина почему ретроспективы не проводятся, > > > это > > > >>>>> потому что все участники команды считают это пустой тратой > > > времени. В
> > > >>> конце
> > > >>>>> концов заказчик не платит за это. Этой причины почему-то нет в
> > > >>> списке, а
> > > >>>>> ведь самое главное показать, что ретроспективы имеют большой > > > смысл.
> > > >>> Причём
> > > >>>>> именно ретроспективы деятельности команды, а не отдельного > > > человека.
> > > >>> Причём
> > > >>>>> именно с вовлечением всей команды, а не в рамках отдельной > > > рабочей
> > > >>> группы.
> > > >>>>> On 2/19/08, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> > > >>>>>> всем привет.
> > > >>>>>> я решился написать ряд постов на тему ретроспектив. в ходе
> > > >>> подготовки к
> > > >>>>>> тренингу я проработали кучу материала по этой теме. хочу > > > поделиться. > > > >>>>>> <
Главная роль ретроспектив - не столько улучшение процесса. Я бы определил
> их как
- официальный форум для "критических разговоров", - место разрешения непонятностей/недосказонностей, - место разрешения конфликтов - и средство подчеркивания/усиления того хорошего, что есть на проекте
Какие сложности - проведение ретроспективы по пяти шагам (Ларсен и Дерби) требует достаточно большого времени (2 * продолжительность ретроспективы) - времени на подготовку к ретроспективе часто отсутствует/не хватает - должна быть определена четкая цель ретроспективы - проведение ретроспектив слишком часто (раз в неделю) - депресивно действует на команду - фасилитация - это навык, который требует хорошей подготовки, и кривая обучения достаточно кривая - фасилитатор в идеале должен быть человек внешний ( вне команды). Если скрам мастер/тим лид является фасилитатором, то это весьма сложно, так как фасилитатор должен концентрировать на процессе, а не на содержании. Скрам мастер/тим лид, являющийся частью команды, и технически подкованный, часто имеет свои мнения/решения, что мешает эффективно фасилитировать. - ретроспективы должны заканчиваться конкретным планом действий, и по плану действий должен быть follow-up.
Я согласен с Сергеем по ряду пунктов. В том числе с тем, что:
- ретроспективы - вещь полезная сама по себе; - что это официальный форум для разрешения конфликтов и недосказанностей; - про сложность фасилитации; - про выгоду от использования внешнего фасилитатора.
На счёт структуры, предложенной Ларсен и Дерби. Я думаю, что проведение ретроспективы без подобных чётких шагов вообще весьма сложно, особенно для начинающих команд. Так что даже если это и требует больше времени по сравнению с традиционными (неработающими?) подходами, то выгода очевидна.
> Сорри, предыдущее сообщени отправилось по ошибке.
> Мой опыт касательно ретроспектив
> > Сами по себе, ретроспектива - штука полезная.
> Главная роль ретроспектив - не столько улучшение процесса. Я бы определил > > их как
> - официальный форум для "критических разговоров", > - место разрешения непонятностей/недосказонностей, > - место разрешения конфликтов > - и средство подчеркивания/усиления того хорошего, что есть на проекте
> Какие сложности > - проведение ретроспективы по пяти шагам (Ларсен и Дерби) требует > достаточно большого времени (2 * продолжительность ретроспективы) > - времени на подготовку к ретроспективе часто отсутствует/не хватает > - должна быть определена четкая цель ретроспективы > - проведение ретроспектив слишком часто (раз в неделю) - депресивно > действует на команду > - фасилитация - это навык, который требует хорошей подготовки, и кривая > обучения достаточно кривая > - фасилитатор в идеале должен быть человек внешний ( вне команды). Если > скрам мастер/тим лид является фасилитатором, то это весьма сложно, так как > фасилитатор должен концентрировать на процессе, а не на содержании. Скрам > мастер/тим лид, являющийся частью команды, и технически подкованный, часто > имеет свои мнения/решения, что мешает эффективно фасилитировать. > - ретроспективы должны заканчиваться конкретным планом действий, и по > плану действий должен быть follow-up.
Рекомендуемая 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 ретроспективы. После этого по моему опыту стоит использовать другие цели.
> Я согласен с Сергеем по ряду пунктов. В том числе с тем, что:
> - ретроспективы - вещь полезная сама по себе; > - что это официальный форум для разрешения конфликтов и > недосказанностей; > - про сложность фасилитации; > - про выгоду от использования внешнего фасилитатора.
> На счёт структуры, предложенной Ларсен и Дерби. Я думаю, что проведение > ретроспективы без подобных чётких шагов вообще весьма сложно, особенно для > начинающих команд. Так что даже если это и требует больше времени по > сравнению с традиционными (неработающими?) подходами, то выгода очевидна.
> > Сорри, предыдущее сообщени отправилось по ошибке.
> > Мой опыт касательно ретроспектив
> > > Сами по себе, ретроспектива - штука полезная.
> > Главная роль ретроспектив - не столько улучшение процесса. Я бы > > > определил их как
> > - официальный форум для "критических разговоров", > > - место разрешения непонятностей/недосказонностей, > > - место разрешения конфликтов > > - и средство подчеркивания/усиления того хорошего, что есть на проекте
> > Какие сложности > > - проведение ретроспективы по пяти шагам (Ларсен и Дерби) требует > > достаточно большого времени (2 * продолжительность ретроспективы) > > - времени на подготовку к ретроспективе часто отсутствует/не хватает > > - должна быть определена четкая цель ретроспективы > > - проведение ретроспектив слишком часто (раз в неделю) - депресивно > > действует на команду > > - фасилитация - это навык, который требует хорошей подготовки, и кривая > > обучения достаточно кривая > > - фасилитатор в идеале должен быть человек внешний ( вне команды). Если > > скрам мастер/тим лид является фасилитатором, то это весьма сложно, так как > > фасилитатор должен концентрировать на процессе, а не на содержании. Скрам > > мастер/тим лид, являющийся частью команды, и технически подкованный, часто > > имеет свои мнения/решения, что мешает эффективно фасилитировать. > > - ретроспективы должны заканчиваться конкретным планом действий, и по > > плану действий должен быть follow-up.
