Проблемы и ошибки при внедрении Scrum

Введение

При первом прочтении какой-нибудь статьи о Scrum складывается впечатление, что внедрить Scrum проще простого. Всего-то daily stand-up, planning meeting и sprint review. На самом деле, формальный Scrum отличается от работающего Scrum’a. Поэтому предлагаю рассмотреть некоторые ошибки, которые часто встречаются при внедрении Scrum’a без помощи опытного Scrum master’a.

Product ownership

Отсутствие product owner’a

Product owner должен предоставлять видение продукта, истории пользователя, определять приоритеты, отвечать на вопросы и давать постоянную обратную связь. Если такой роли нет, то проект будет двигаться непонятно куда, не удастся получить максимальную бизнес-полезность, команда будет периодически простаивать, продукт в итоге может получиться совсем не тот, что ожидался.

Заказчик не всегда готов (или может) выделить отдельного человека на роль product owner’a. В таком случае можно ввести Proxy product owner’a.

Скрытый product backlog

Product backlog должен быть доступен всем членам команды и всем stakeholder’ам.

Done criteria

Done criteria определяет критерии, при которых user story (аналогично можно ввести done criteria для задачи, спринта, релиза) считается сделанной.

Нет done criteria

Если нет четких done criteria, то нельзя с уверенностью сказать, что история пользователя завершена. К тому же done criteria неявно требуют хорошего качества (как правило, в таких критериях указывают наличие тестов, документации, и т.д.)

Done criteria навязаны

Если done criteria выработаны не командой, а навязаны снаружи, то они будут неэффективны.

Done criteria динамические

Done criteria должны быть более-менее постоянными. Они могут меняться, но это должно быть достаточно редко.

Много начатых, но ни одной законченной user story в конце спринта

Это может быть следствием или отсутствия четких done criteria, или неправильного понимания результата спринта: в конце спринта пользователь, как правило, должен получить работающий продукт (незавершенная user story практически равна несделанной).

Sprint review meeting

Sprint review meeting проводится в конце спринта, на котором команда демонстрирует заказчику, что было сделано в течение этого спринта.

PowerPoint презентация вместо работающего приложения

Должно показываться именно работающее приложение.

Команда

Команда – это основа Scrum’a.

QA не является частью команды

QA должен быть частью команды. При этом резко уменьшаются потери на коммуникацию, ускоряется обнаружение ошибок.

Микроменеджмент

Менеджерам проектов, которые привыкли напрямую управлять людьми, нелегко привыкнуть к тому, что команда сама может работать (да еще и более эффективно). Микроменеджмент убивает мотивацию, снимает ответственность за результат спринта. Да, сначала это нелегко – положиться на команду и ее профессионализм. Зато сколько появляется свободного времени, которое можно потратить на более существенные проблемы.

Навязывание процесса

Если команда не примет процесс, то практически нереально сделать его эффективным. Есть несколько вариантов: или сначала оказать небольшое давление и внедрить Scrum «сверху» (с объяснением причин, почему был выбран именно Scrum), или описать существующие проблемы и предложить команде как вариант Scrum. В любом случае, процесс должен доказать свою пригодность и полезность для данной команды и данного проекта.

Daily meeting

Что делал, а не что сделал

Во время daily meeting’a нужно рассказать команде, какие задачи были завершены (а не просто, что делал вчера), какие задачи планируется завершить (а не что планируется делать) за сегодня и какие проблемы возникли.

Daily meeting как status report

Иногда daily stand-up превращается в отчет руководителю команды/проекта. Чтобы этого избежать, можно использовать какой-нибудь маркер, которым владеет тот, кто говорит в данный момент (например, обыкновенная ручка).

Обсуждение проблем во время daily meeting’a

Daily meeting должен предоставлять только необходимую информацию по прогрессу. Обсуждения проблем должны проводиться отдельно. Обсуждение проблем во время daily meeting’a неоправданно затягивает его (и отнимает время у тех, кто не принимает участия в обсуждении).

Планирование

Планирование производится во время sprint planning meeting для каждого спринта.

Скрытые задачи

Они возникают, когда какие-то задачи не были учтены во время планирования (например, написание тестов, настройка билда, документация и т.д.). Следует стремиться к минимизации количества таких задач. В случае скрытых задач тяжелее оценить реальный прогресс.

Очень длительное планирование

Не стоит стремиться спланировать спринт с точностью до минуты (или сделать настолько детальный дизайн, что уже и программировать то в принципе нечего). Нужно делать только необходимый объем планирования и дизайна.

Очень большие задачи

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

Скорость работы команды не вычисляется, а навязывается

Т.н. velocity – это какой объем работы команда может выполнить за спринт. При требовании более высокой скорости, чем оптимальная скорость для данной команды, приводит ко множеству проблем: раздражение со стороны команды, снижение качества, увеличение количества ошибок (что может привести к значительному снижению скорости).

Оценки времени, сделанные командой, занижаются

Это ведет к тем же проблемам, что и навязывание скорости. Хорошая команда сама стремится работать качественно и быстро.

Ретроспектива

Во время retrospective meeting обсуждается, что работало хорошо во время спринта, а что можно улучшить.

Ретроспектива только в конце проекта

К тому времени многие ошибки уже забылись. Да и поздно уже. Частая ретроспектива позволяет постоянно совершенствовать процесс.

Слишком много планируемых улучшений

Лучше выбрать 2-3 самых существенных улучшения и начать их внедрять.

Заключение

Конечно, отличный вариант, когда процесс на проекте помогает внедрить человек с реальным опытом работы по Scrum’у. Но и самостоятельно это можно сделать. Нужно только понимать, что должно быть в результате, постоянно анализировать текущее состояние, находить, что работает неправильно, и улучшать это. И у Вас все получится!

Tags: , ,

Post Author

This post was written by who has written 29 posts on Agile.by.

  • Денис Петелин

    У Хенрика кстати есть классный чеклист, где практики SCRUM собраны по приоритетам – 1, 2, 3 – ну и можно как бы самопроверку сделать: “Делаем ли мы SCRUM?”.

  • Dmitry Zdanovich

    Посмотрел этот чек-лист.
    Действительно очень классно сделано.

  • http://dotfix.ru/ Юрий Гугнин

    Спасибо за полезную статью, но одного не понял. Чем заниматься руководителю проекта, если не руководством? Что это за “более полезные дела”?

  • Денис Петелин

    Юра, привет!
    Ну негласно подразумевалась такая простая вещь – у отличного менеджера все подгадано так, что он сидит, пьет кофе и умиляется “Ай, парни, какие мы молодцы, ай, какой класс!”

    И что характерно – молодцы действительно дают класс 🙂 Задача менеджера – так запроектировать события, чтобы команда САМА заделала проект наилучшим возможным способом.

    Получается это засчет того, что каждый из специалистов в команде в своей области безгранично компетентней менеджера. Руководство обычно заключается в принуждении этих людей к действию в общем ключе. Если же они САМИ хотят – то менеджмент такой команды сводится к администрированию ее работы – счета выставить, данные в план проекта внести, расходы в экспенс трэкер вписать и т.д.

    Конечно, чтобы такой сценарий реализовался, нужно совпадение мотивации людей с целями проекта -> желание сделать проект -> самостоятельное преодоление разногласий -> самоорганизованность. Обеспечение условий, в которых цели проекта = мотивация людей собственно и есть главная задача менеджера.

    Есть еще кой-какая побочная работенка, конечно, и ее объем значителен 🙂