Популярные заблуждения о методологии Scrum

С появлением Scrum на массовом рынке увеличилась вероятность того, что компании попытаются внедрить Scrum, не имея о нем полного представления. Это может привести к половинчатому или гибридному внедрению Scrum, что приведет к провалу проекта. Эти неудачи порождают волну сомнений и неверных представлений о том, как реализуется Scrum, и о последствиях Scrum.

Вышеупомянутые случаи заставляют каждого лидера или менеджера убедиться, что Scrum глубоко понят, прежде чем внедрять его, и, как могут сказать эксперты, лучший способ узнать что-то — это узнать, чем эта вещь не является.

Как появился Scrum?

Прежде чем перечислять заблуждения, давайте сначала разберемся в происхождении Scrum. Первые истоки концепции Scrum восходят к 1980-м годам, когда Хиротака Такеучи и Икудзиро Нонака упомянули ее в игре «Разработка нового продукта». Они назвали это целостным и регбийным подходом.

В начале 1990-х Кен Швабер использовал Scrum в своей компании, а Джефф Сазерленд разработал аналогичный подход в Easel Corporation. Позже они создали официальную среду Scrum и руководство по Scrum, которые приобрели большую популярность, особенно в индустрии разработки программного обеспечения.

Некоторые формы Scrum были приняты Google, Yahoo, Microsoft и несколькими другими компаниями из списка Fortune 500.

10 заблуждений о методологии Scrum

Ниже приведены 10 самых распространенных заблуждений о Scrum и почему они вредны для клиентов и сотрудников.

Scrum — это процесс

Это одна из самых распространенных ошибок, которую люди совершают, рассказывая о Scrum. Распространенный термин, который вы можете услышать, — это процесс Scrum. По сути, Scrum — это не процесс, а набор облегченных правил, которые помогают Scrum-команде разработать собственный процесс.

Scrum — это аббревиатура

Это довольно коварное заблуждение. Я говорю это, потому что вы могли бы использовать это как вопрос с подвохом в интервью. Если кто-то утверждает, что является экспертом по Scrum, спросите его, что означает аббревиатура «SCRUM». Если бы они были экспертами по Scrum, они бы сказали, что это не аббревиатура. Scrum происходит от термина, используемого в регби. Заглавные буквы Scrum часто можно увидеть в резюме и описании работы, сделанных людьми, которые не знают, как возник Scrum.

Scrum — это серебряная пуля

Я снова и снова видел, как менеджеры думали, что Scrum является причиной провала и успеха проекта. На самом деле это не может быть правдой. Я говорю это потому, что Scrum — это всего лишь набор правил, соблюдение которых помогает команде выработать индивидуальный процесс. Люди, внедряющие Scrum, добиваются успеха или терпят неудачу в зависимости от того, насколько они адаптивны и проницательны. Хорошая аналогия для понимания этого — игра в шахматы. Если вы проиграли партию в шахматы, вы не можете винить в проигрыше сами шахматы. Шахматы — это просто игра с набором правил, люди, которые играют в шахматы, проигрывают или выигрывают, а не шахматы. Scrum — это как шахматы.

Scrum означает отсутствие документации

Это заблуждение, кажется, исчезает, но оно все еще существует. Принятие Scrum не означает отказа от всей документации. У вас по-прежнему может быть документация в виде блок-схем, которые выходят из сессий белой доски, пользовательских историй, заметок по бизнес-анализу или любой другой вспомогательной документации, необходимой для пользовательской истории.

Scrum — это микроуправление

Как сотрудник компании, которая внедряет Scrum, не следует предполагать, что Scrum — это микроуправление. Микроуправление может возникнуть как побочный эффект того, что менеджер не понимает, что такое Scrum, но Scrum не рекомендует микроуправление. На самом деле Scrum дает команде больше возможностей для создания продукта.

Scrum — это только итеративная разработка

Если вы думаете, что следуете Scrum, занимаясь только итеративной разработкой, у вас есть только половина картины. Несколько новых команд, перешедших на Scrum, могут попасть в эту ловушку, и это не принесет много пользы ни команде, ни заказчику. Scrum — это не только встречи и итерации по Scrum, но и культура, командная работа и кросс-функциональное поведение.

Scrum-команды занимаются ковбойским кодированием

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

Scrum не оставляет времени для выполнения реальной работы

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

Scrum не может работать с CMMI

Я видел проекты, в которых была получена успешная сертификация CMMI при следовании Scrum. Могут быть определенные проекты, основанные на правительстве, где клиент требует, чтобы проект был сертифицирован CMMI. Можно по-прежнему получить сертификат CMMI уровня 3, внеся несколько изменений в процесс, которому вы следуете в рамках Scrum.

Заказчик может изменить требования в любое время и в любом месте

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

Подведем итог

Согласно статистике, Scrum на сегодняшний день является самой популярной методологией.
Никакая другая Agile-инфраструктура не придает большего значения клиенту.