Scrum - популярный в командах разработки фреймворк. Но так ли он важен и нужен в действительности?
В статье в формате "вредных советов" приведены порочные практики, которые можно встретить в Scrum-командах.
Некоторые из них противоречат принципам фреймворка, некоторые наоборот. Тем не менее, если предлагаемые в статье практике стоят на повестке дня в вашей команде/компании, вероятно имеет смысл приостановиться и задуматься - вводятся ли нововведения осмысленно, и нет ли в них элемента Карго-культа.
1. Обязательно сверяйте точность стори-пойнтов перед планированием
Неоднозначное представление о соотношении стори-пойнтов и времени, необходимого на выполнение задачи - очень серьёзная проблема. Может оказаться, что в середине итерации команде не хватает задач, и придётся инициировать планирование второй раз за спринт.
Если вдруг окажется, что оценка завышена, Product-owner'у придётся переносить задачи в следующий спринт, и он будет очень недоволен этим фактом.
2. Планирование не закончено, пока все участники команды не сошлись в единой оценке
Для наиболее точной оценки, важно услышать каждого участника, имеющего представление, как делать задачу.
Чтобы убедиться, что каждый разработчик делает оценку осмысленно, а не просто соглашается с чужой оценкой, не вовлекаясь в процесс, можно использовать такую технику как Scrum-покер.
3. Имейте план на ближайшие несколько спринтов
Гарантированно избежать проблем, описанных в пунктах 2 и 3, можно при оценке задач не ограничиваться только задачами текущего спринта. Например, можно оценивать задачи при попадании в бэклог или иметь список оцененных задач на N следующих спринтов.
Чтобы всё работало правильно, также учитывайте, что оптимальная длина Scrum-спринта - 2 недели, а не столько сколько нужно, для выполнения цели спринта.
4. Обсуждайте все накопившиеся вопросы на Дейли-скрам
Daily stand-up - важный ритуал скрама, обеспечивающий коммуникацию между участниками команды.
Во время ежедневного стэндапа разработчики могут обсудить проблемы, возникшие в ходе решения их задач. Стейкхолдерам участие в дейли-скрам даёт возможность получить более точную оценку каждой задачи.
Есть мнение, что дейли-скрам нужно проводить стоя, чтобы уложиться в 5 минут, но это не наш случай.
5. Учитывайте фидбек от разработчиков во время ретроспективы
Ретроспектива в Скраме обязательна для получения фидбека от разработчиков. В ходе ретроспективы Тимлид или Скрам-мастер должны опросить каждого разработчика и составить список вещей, которые:
а) Помогли разработчику приблизиться к выполнению цели спринта;
б) Мешали разработчику эффективно приближать выполнение цели спринта.
При отсутствии ретроспективы может случиться ситуация, когда разработчик отвлекает тимлида своими проблемами в неподходящее для этого время, а не ждёт две недели до ретроспективы.
6. Обязательно проводите Sprint-review в запланированное время
Обзор спринта необходим для понимания, чем занималась команда последние 2 недели.
Идеально для полного контроля, если каждый разработчик по очереди продемонстрирует, какие задачи сделал лично он.
7. Настоящая Agile-команда должна строго следовать принципам Scrum
Разработчики, не понимающие ценности Scrum, могут пытаться саботировать выполнение необходимых ритуалов.
Задача Скрам-мастера в этом случае - пресекать подобное и направлять команду в правильное русло.
8. Помните, Scrum - простая методология
Если вы начинающий тимлид, внедрение Scrum будет первым шагом к успеху вашей команды карьеры.
9. Выше velocity - выше продуктивность
При оценке команд или индивидуальных разработчиков обязательно учитывайте, сколько стори-пойнтов успевает выполнить человек за спринт.
Наиболее отличившихся можно награждать премиями.
10. Scrum не сделал команду эффективнее?
Вы делаете Scrum неправильно. Для того, чтобы достоверно проверить соответствие команды scrum-ценностям и корректность соблюдения ритуалов, вам необходимо привлечь сертифицированного Scrum-мастера со стороны. Желательно в штат.
