fbpx
Так ли плохо безопасное планирование?

Недавно прочитал любопытную статейку от Максима Дорофеева с письмом от одного из его знакомого менеджера. В двух словах проблема примерно выглядит так:

  • есть команда, которая работает по Scrum (причем сравнительно недавно);
  • эта команда планирует итерации так, чтобы успевать сделать все запланированное;
  • в команде считается “смертным грехом” не выполнить обязательства и провалить спринт;
  • автор письма очень переживает, что команда может работать гораздо эффективнее, но за процессом эта эффективность теряется.

Scrum

Как и практически любой человек, который прочитал книжку Голдратта, менеджер из письма во всем видит потенциальное поле для улучшения эффективности. Причем, сразу и с текущего положения. В разы, чтобы как в книжке…

Лирическое отступление. Я когда-то давно прочитал “Цель” и “Цель-2” (кстати, всем настоятельно рекомендую) и до такой степени проникся идеями эффективности, что планировал чуть ли не по руководителям IT компаний ходить и “открывать им глаза” на неэффективность. Но когда начал больше расспрашивать в процессе консалтинга о деталях работы некоторых компаний, команд и проектов, осознал, что не все так просто и быстро. У некоторых царил полный хаос и они не были готовы к культуре “экономного эффективного производства”. Низкий уровень квалификации, бюрократия, навязанные извне правила и обязательства, специфические детали культуры компании и ситуация на рынке – все это требовало гораздо более примитивных мер на первых этапах борьбы за эффективность…

Scrum со своей итеративностью разработки позволяет перейти от хаоса к чуть более контролируемому процессу. Scrum далеко не идеален и, чем быстрее двигается бизнес, тем более очевидны становятся недостатки той же итеративности. Но когда у вас нет ничего, никто не может дать ответ о сроках выполнения задач, в команде разброд и шатание, заказчик не понимает что творится в команде, невозможно сделать хоть немного реалистичный план, команда не готова работать как команда, то “прогрессивные подходы” наподобие агрессивного планирования с отслеживанием выполненных работ и добавлением новой по факту или перехода на Kanban просто обречены на провал.

Scrum пытается научить команду давать осязаемые оценки своей продуктивности, выбрать самостоятельно объем работ на итерацию и сделать его успешно. Это очень важно! Во-первых, появляется предсказуемость для представителей бизнеса. Они теперь могут хоть как-то планировать. Во-вторых, появляется понятие командной ответственности за свои собственные решения и обратная связь по результатам выполнения работ (успели или нет, была ли возможность взять еще работ, нет ли проблем с качеством). Команда начинает работать как команда. И тут очень важно, чтобы начало хоть что-то получаться. Для некоторых команд непростой задачей является взять одну User Story и довести ее до конца в итерации. ОДНУ! Scrum же не исправляет ваши проблемы, а показывает их как в зеркале. Он дает вам данные, чтобы задуматься о причинах провала и неудач. Поэтому нет ничего зазорного или плохого в том, что команда ввела для себя (или кто-то другой ввел) жесткий критерий “все к концу итерации должно быть готово и качество должно быть на уровне”.

И вот, когда команда научилась давать нормальные оценки и делать хоть какую-то работу в срок от итерации к итерации, стоит задуматься об эффективности. Для этого в Scrum есть замечательные инструменты – burndown chart и ретроспектива. Первый может подтвердить описанное в статье подозрение, что команда первые две трети времени занимается чем угодно но не работой. А второй позволяет задать вопрос об эффективности и обсудить картину burndown chart за предыдущую итерацию. И команда сама примет решение, может ли она увеличить количество задач на итерацию или это слишком рискованно. В конце концов иногда проще брать на себя надежные обязательства и, если остается время, добавлять новые задачи. Чтобы ни при каких обстоятельствах не поломать ожидания представителей бизнеса. Все проекты разные и для некоторых это ну оооочень важно.

Все перечисленное будет работать, если в команде есть хотя бы кто-то ответственный. Если вся команда безответственная, то она будет филонить при любом процессе. Любая задача может быть искусственно затянута и оценки повышены. Поэтому сам процесс или подход не является решением. В Agile очень многое зависит от “правильных людей”, а иначе просто не работает, как бы грамотно не насаживались сверху практики замера и улучшения эффективности… 🙂

Через некоторое время необходимость в итерациях перестанет быть такой острой, и тут уже можно начать применять другие подходы к планированию. Еще через некоторое время итерации начнут просто мешать работать более эффективно для хороших команд. И тут время искать или строить более эффективный процесс разработки, например Kanban. Но рубить с плеча сразу может быть очень вредным для команды…

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Обсуждение (
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
1)

Совершенно согласен. Мы вот перешли от скрама к канбану в своей команде, но только после того как за 10 месяцев мы “выросли” из процесса, только после этого мы перешли к канбану. Если бы мы очертя голову сразу ломанулись чинить процесс которого нет, то я боюсь представить чем бы это кончилось. У того же Дорофеева есть отличное “бухтелово” на тему частных случаев и системной проблемы: там к станку приделали компенсирующую систему чтоб он работал точнее, а в результате получили еще больший разброс параметров.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

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

принять
Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online