Недавно прочитал любопытную статейку от Максима Дорофеева с письмом от одного из его знакомого менеджера. В двух словах проблема примерно выглядит так:
Как и практически любой человек, который прочитал книжку Голдратта, менеджер из письма во всем видит потенциальное поле для улучшения эффективности. Причем, сразу и с текущего положения. В разы, чтобы как в книжке…
Лирическое отступление. Я когда-то давно прочитал “Цель” и “Цель-2” (кстати, всем настоятельно рекомендую) и до такой степени проникся идеями эффективности, что планировал чуть ли не по руководителям IT компаний ходить и “открывать им глаза” на неэффективность. Но когда начал больше расспрашивать в процессе консалтинга о деталях работы некоторых компаний, команд и проектов, осознал, что не все так просто и быстро. У некоторых царил полный хаос и они не были готовы к культуре “экономного эффективного производства”. Низкий уровень квалификации, бюрократия, навязанные извне правила и обязательства, специфические детали культуры компании и ситуация на рынке – все это требовало гораздо более примитивных мер на первых этапах борьбы за эффективность…
Scrum со своей итеративностью разработки позволяет перейти от хаоса к чуть более контролируемому процессу. Scrum далеко не идеален и, чем быстрее двигается бизнес, тем более очевидны становятся недостатки той же итеративности. Но когда у вас нет ничего, никто не может дать ответ о сроках выполнения задач, в команде разброд и шатание, заказчик не понимает что творится в команде, невозможно сделать хоть немного реалистичный план, команда не готова работать как команда, то “прогрессивные подходы” наподобие агрессивного планирования с отслеживанием выполненных работ и добавлением новой по факту или перехода на Kanban просто обречены на провал.
Scrum пытается научить команду давать осязаемые оценки своей продуктивности, выбрать самостоятельно объем работ на итерацию и сделать его успешно. Это очень важно! Во-первых, появляется предсказуемость для представителей бизнеса. Они теперь могут хоть как-то планировать. Во-вторых, появляется понятие командной ответственности за свои собственные решения и обратная связь по результатам выполнения работ (успели или нет, была ли возможность взять еще работ, нет ли проблем с качеством). Команда начинает работать как команда. И тут очень важно, чтобы начало хоть что-то получаться. Для некоторых команд непростой задачей является взять одну User Story и довести ее до конца в итерации. ОДНУ! Scrum же не исправляет ваши проблемы, а показывает их как в зеркале. Он дает вам данные, чтобы задуматься о причинах провала и неудач. Поэтому нет ничего зазорного или плохого в том, что команда ввела для себя (или кто-то другой ввел) жесткий критерий “все к концу итерации должно быть готово и качество должно быть на уровне”.
И вот, когда команда научилась давать нормальные оценки и делать хоть какую-то работу в срок от итерации к итерации, стоит задуматься об эффективности. Для этого в Scrum есть замечательные инструменты – burndown chart и ретроспектива. Первый может подтвердить описанное в статье подозрение, что команда первые две трети времени занимается чем угодно но не работой. А второй позволяет задать вопрос об эффективности и обсудить картину burndown chart за предыдущую итерацию. И команда сама примет решение, может ли она увеличить количество задач на итерацию или это слишком рискованно. В конце концов иногда проще брать на себя надежные обязательства и, если остается время, добавлять новые задачи. Чтобы ни при каких обстоятельствах не поломать ожидания представителей бизнеса. Все проекты разные и для некоторых это ну оооочень важно.
Все перечисленное будет работать, если в команде есть хотя бы кто-то ответственный. Если вся команда безответственная, то она будет филонить при любом процессе. Любая задача может быть искусственно затянута и оценки повышены. Поэтому сам процесс или подход не является решением. В Agile очень многое зависит от “правильных людей”, а иначе просто не работает, как бы грамотно не насаживались сверху практики замера и улучшения эффективности… 🙂
Через некоторое время необходимость в итерациях перестанет быть такой острой, и тут уже можно начать применять другие подходы к планированию. Еще через некоторое время итерации начнут просто мешать работать более эффективно для хороших команд. И тут время искать или строить более эффективный процесс разработки, например Kanban. Но рубить с плеча сразу может быть очень вредным для команды…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Совершенно согласен. Мы вот перешли от скрама к канбану в своей команде, но только после того как за 10 месяцев мы “выросли” из процесса, только после этого мы перешли к канбану. Если бы мы очертя голову сразу ломанулись чинить процесс которого нет, то я боюсь представить чем бы это кончилось. У того же Дорофеева есть отличное “бухтелово” на тему частных случаев и системной проблемы: там к станку приделали компенсирующую систему чтоб он работал точнее, а в результате получили еще больший разброс параметров.