«С момента появления Scrum стал неотъемлемой частью проектного менеджмента во многих организациях», – пишут Medium.
Некоторые сотрудники жалуются на Scrum. Создается впечатление, что есть как сторонники использования Scrum в проектах, так и противники. Из-за этого у участников проектов зачастую формируются полярные точки зрения на полезность Scrum. Причем разногласия возникают не обязательно между программистами и менеджерами, или между программистами и руководством компании. Что интересно, неважно кто представляет ту или иную сторону в споре – аргументы всегда одни и те же. Так откуда же взялись эти разногласия?
Те, кто за Scrum, в качестве довода приводят гибкость разработки и более быстрый результат. Те, кто против, недовольны чрезмерным контролем над подчиненными и ограничением свободы программистов.
Так что же получается? Одним нравится, когда свободы много, а другим нет?
Дело в том, что Scrum не всегда одинаков.
Во-первых, в каждой организации или, вернее говоря, команде проекта, есть свой набор правил использования Scrum. Более того, в разных проектах манифест гибкой разработки, в частности основные положения, трактуется по-разному.
Вот почему люди по-разному относятся к Scrum. По той же причине в некоторых проектах эффективнее применять не Scrum, а более классические фреймворки.
Перед тем, как использовать Scrum, стоит уточнить несколько моментов:
- Готова ли компания к гибким методологиям разработки?
- Готов ли клиент к гибким методологиям разработки?
- Есть ли фиксированные требования к проекту?
- Хочет ли клиент быстрого выполнения проекта, или его больше волнует качество?
- Готовы ли участники проекта к использованию новых технологий?
И это далеко не все. После того, как эти пункты проанализированы, стоит внимательно изучить правила Scrum и понять, какие из них применимы в проекте. И вот здесь начинается самое интересное. Нужно научиться следовать не всем правилам Scrum, а только некоторым.
Scrum – это каркас разработки. Если использовать только часть его правил, то созданная структура проекта будет не настолько строго очерченной.
Что из этого следует? Сотрудники обычно предпочитают выходить за установленные рамки. Поэтому все члены команды должны осознавать свою ответственность.
Как использовать только часть фреймворка Scrum? Опять же, на этот вопрос нет однозначного ответа. Единственное обязательное условие – присутствие в команде Scrum-мастера. Не только потому, что проекту будет полезен человек, который работает 40 часов в неделю. Просто нужен профессионал, который не является ни Product Owner, ни разработчиком, ни участником проекта. Он будет объективно оценивать рабочий процесс и решать, какие средства разработки эффективны.
Итог
Как только руководство, Product Owner или даже команда начинает решать, какие элементы Scrum применять, а какие нет, проект обречен на провал.
Scrum подразумевает гибкий подход. Если нет понимания, как устроена гибкая разработка, лучше ее не использовать. Недостаточно просто показать руководству на графиках, что Scrum существенно снижает издержки проекта. Руководство должно понять, что гибкая разработка может повести процесс по незапланированной траектории. При использовании Scrum надо исходить не из списка характеристик продукта, а из цели проекта.