Выдержка из книги Нормана Керта «Ретроспектива проекта»:
Однажды я получил письмо от сотрудницы одной из компаний, чей менеджер выделил один час на ретроспективу проекта, продолжавшегося шесть месяцев. Автор письма была назначена ответственным за то, чтобы ретроспектива прошла успешно, и искала у меня совета. Я написал ей, что такая короткая ретроспектива не может быть успешной.
И хоть я и слышал о ретроспективах, проводимых за один час или за полдня, следующие комментарии описывают итоги таких ретроспектив:
Было бы ошибкой предполагать, что можно за один час понять что-то существенное о проекте, в котором участвовало много человек на протяжении нескольких месяцев. В лучшем случае короткая ретроспектива поможет выявить несколько симптомов реальной проблемы, но участники врядли смогут сделать что-то, кроме как предложить плохо проанализированное одностроннее решение, не закрывающее проблему полностью. ©
**************
Далее автор пишет о двух аргументов менеджеров в пользу короткой ретроспективы и о том, как их опровергнуть. Но за этим уже обращайтесь к оригиналу
Я понимаю, что в ИТ чаще всего ретроспективы проводятся в agile и прочих «гибких» командах, где ретроспективы проводятся каждый месяц, а не каждый год, поэтому ретроспектива на полдня не кажется такой уж короткой. Но книга про agile-ретроспективы на русском еще не вышла, черпаю опыт из проектных работ
Меня зацепил этот отрывок словами «каждая ретроспектива приводила к одним и тем же рекомендациям». Бывало ли у вас такое? Что периодически одна и та же мысль всплывала на ретроспективе раз за разом. Например, делать большие задачи в отдельном бранче или начинать тестирование до линии N?
Разумеется, тупо выделить больше времени на ретроспективу тут не поможет. Однако стоит задуматься... Если одна и та же идея всплывает раз за разом → необходимо уделить ее анализу чуть больше времени. Да, тогда ретро займет не час, а полтора или два, но это окупится! Ведь ведь смысл ретроспектив — научиться. Научиться быть лучше, повторять успех и не повторять ошибок.
А как можно не повторять ошибку, если не проанализировать ее? Только задумайтесь, мы же тестировщики. Как можно вообще завести баг-репорт, не проанализировав ошибку, не найдя корня зла? Да, разработчик исправит поверхностное проявление, но через месяц ошибка снова всплывет. Снова исправим последствие — снова всплывет. И так по кругу. А все потому, что лень было найти причину, а не последствия.
Также и с ретроспективами. Если какая-то мысль мелькает уже не первый и даже не пятый раз, чуть приостановитесь и задумайтесь, а не поверхностное ли ваше «решение» проблемы?
Однажды я получил письмо от сотрудницы одной из компаний, чей менеджер выделил один час на ретроспективу проекта, продолжавшегося шесть месяцев. Автор письма была назначена ответственным за то, чтобы ретроспектива прошла успешно, и искала у меня совета. Я написал ей, что такая короткая ретроспектива не может быть успешной.
И хоть я и слышал о ретроспективах, проводимых за один час или за полдня, следующие комментарии описывают итоги таких ретроспектив:
«Мы пробовали проводить ретроспективы. Через некоторое время мы заметили, что каждая ретроспектива приводила к одним и тем же рекомендациям. Было очевидно, что ничего не менялось, и мы решили, что ретроспектива — это потеря времени. Поэтому больше их не проводим»Очень грустно осознавать, что столь эффективный инструмент обучения был похоронен только лишь потому, что на него не отводилось достаточное количество времени. И ирония заключается в том, что из-за «потери времени» они отказались от ретроспектив, на которые всего лишь не выделялось достаточно времени.
Было бы ошибкой предполагать, что можно за один час понять что-то существенное о проекте, в котором участвовало много человек на протяжении нескольких месяцев. В лучшем случае короткая ретроспектива поможет выявить несколько симптомов реальной проблемы, но участники врядли смогут сделать что-то, кроме как предложить плохо проанализированное одностроннее решение, не закрывающее проблему полностью. ©
**************
Далее автор пишет о двух аргументов менеджеров в пользу короткой ретроспективы и о том, как их опровергнуть. Но за этим уже обращайтесь к оригиналу
Я понимаю, что в ИТ чаще всего ретроспективы проводятся в agile и прочих «гибких» командах, где ретроспективы проводятся каждый месяц, а не каждый год, поэтому ретроспектива на полдня не кажется такой уж короткой. Но книга про agile-ретроспективы на русском еще не вышла, черпаю опыт из проектных работ
Меня зацепил этот отрывок словами «каждая ретроспектива приводила к одним и тем же рекомендациям». Бывало ли у вас такое? Что периодически одна и та же мысль всплывала на ретроспективе раз за разом. Например, делать большие задачи в отдельном бранче или начинать тестирование до линии N?
Разумеется, тупо выделить больше времени на ретроспективу тут не поможет. Однако стоит задуматься... Если одна и та же идея всплывает раз за разом → необходимо уделить ее анализу чуть больше времени. Да, тогда ретро займет не час, а полтора или два, но это окупится! Ведь ведь смысл ретроспектив — научиться. Научиться быть лучше, повторять успех и не повторять ошибок.
А как можно не повторять ошибку, если не проанализировать ее? Только задумайтесь, мы же тестировщики. Как можно вообще завести баг-репорт, не проанализировав ошибку, не найдя корня зла? Да, разработчик исправит поверхностное проявление, но через месяц ошибка снова всплывет. Снова исправим последствие — снова всплывет. И так по кругу. А все потому, что лень было найти причину, а не последствия.
Также и с ретроспективами. Если какая-то мысль мелькает уже не первый и даже не пятый раз, чуть приостановитесь и задумайтесь, а не поверхностное ли ваше «решение» проблемы?
"ректроспектива" исправь плз
ОтветитьУдалитьОх! Спасибо большое, поправила!
Удалитьhttp://screencast.com/t/13Uglp6VUnb и здесь еще:)
ОтветитьУдалитьНастоящий тестировщик проверит не только там, где сломалось, но и в связанных местах))) Спасибо!
Удалитьда незачто :)
ОтветитьУдалить