Agile и потребности мозга: управление стрессом

[saboteur_kiev]

Ретроспективные митинги вообще один из важнейших моментов в agile, но почему-то на них очень часто забивают.
А именно они и призваны для того, чтобы ваш agile процесс оставался agile — благодаря именно ретроспективе, процесс глобально должен меняться под проект, под местные условия, под местные проблемы. Ибо Agile это не просто спринты и бэклог, а именно возможность подстроить процесс разработки под мелкие нюансы любого проекта. Без ретроспективы, изменения будут мелочными. Но да, именно менеджер должен сделать ретро-митинги полезными.

[azaraf]

Наши скрам мастера проводили отличные ретроспективы и да согласен задача менеджера помочь воплотить в жизнь 1-2 реальных улучшения. Так чтоб на следующей ретроспективе изменения отметили как то что помогало.

[FF9_Dagger]

Спасибо за статью.
Пишите, пожалуйста, еще.

[azaraf]

Спасибо

[GruSer]

Ретроспектива хороша если команда новая и не сработанная. Также если есть проблемы в проекте и спринтах. Но когда все хорошо в проекте то про ретроспективу забывают…

[azaraf]

Верно, когда все хорошо — хорошо, нарабатывается автоматизм успеха! Но на мой взгляд, без ретроспектив такой автоматизм недостаточно осознан.

[ggo]

Но когда все хорошо в проекте то про ретроспективу забывают…

Если все хорошо, то ретроспектива переходит на 4-й уровень — неосознанная компетентность.

[nitso]

В идеальном случае вести ретроспективу должен внешний фасилитатор. Его основная задача помимо непосредственно модераторства самой встречи — взглянуть на участников и их обсуждение со стороны и обратить внимание на моменты, на которые у команды глаз замылилился за время совместной работы.
Очень часто именно сработанные команды забивают на "настоящую" ретроспективу из-за отсутствия фасилитатора, способного выдернуть их из привычного состояния, чтобы взглянуть на друг на друга с другого ракурса.
Для того, чтобы ретроспективу мог проводить кто-то из членов команды, нужно иметь хороший опыт и навыки в этом, и постоянно переключаться между ролями, что совсем не простая задача.
Ну и отдельная тема — подготовка к ретроспективе, потому как просто собраться и поболтать на тему "Ну что, как оно?" — это не ретроспектива. Мне в этом плане очень понравился Retromat.

[azaraf]

Наверное, даже базовая ретроспектива полезна — выбрать 1-2 действия из зоны влияния своей команды, и развивать их. Какие наши действия помогали добиваться целей итерации? Что будет полезно делать еще больше?

[emacsway]

У вас такое когда-либо было? Пишите в комментариях, что вы предприняли.

Было, можно почитать тут как мы внедряли Agile и повысили экономические показатели разработки более чем в 5 раз в течении года. Стресс навсегда ушел из рабочей атмосферы.

Автору спасибо за то, что он затронул важную и интересную тему. Психология и в самом деле существенно повлияла на становление Agile, и все потому что Kent Beck испытал в детстве приступ панической атаки, когда он заблудился вместе с мальчишками в лесу, об этом он рассказывает в "Planning Extreme Programming". А если открыть список использованной Кент Беком литературы в «Extreme Programming Explained» 1st edition, то можно обнаружить весьма внушительный список книг по психологии и философии.

[azaraf]

Спасибо. Взял на заметку «Extreme Programming Explained» 2 edition (November 17, 2004).

[emacsway]

Лучше начинать с первого издания. Второе издание подходит лучше для формализации процессов, и оно лучше адаптировано под сложившуюся на рынке обстановку. Но для понимания лучше все-таки первое издание. Это почти что две разные книги. Прочесть стоит обе. На русский было переведено только первое издание, если я не ошибаюсь. Ценность второго издания еще и в том, что его легче сочетать со Scrum-процессом (подробней эту тему раскрывает Henrik Kniberg в «Scrum and XP from the Trenches: How We Do Scrum» 2nd edition).