Что такое Scrum
и зачем он нужен?
Содержание страницы
Программа для ИТ-компаний и управления командами – это и есть SCRUM. Что в ней есть нужного? Мы перечислим свойства этой программы и ее некоторые преимущества.
- SCRUM очень подходит для организации работы над софтом
- Операции в скраме делятся на мелкие временные циклы (итерации)
- В результате такой работы продукт должен получиться стабильным и активным
- Работа завершается разбором действий, выявлением ошибок и поиском решений для их устранения
- Главное отличие скрама от других подобных программ – улучшенная организация работы сотрудников
- Пошаговая разработка продукта в таком режиме приводит к отличному эффекту
- В такой команде не будет конфликтов, потому что все вопросы решаются заранее.
Отступление
Представим, что нам необходимо сотворить уникальное блюдо, а для основы дан обычный чебурек. Ваш суперчебурек должен быть уникальным и практически совершенным, и отличаться от обычного полезным составом и новыми вкусовыми качествами.
Точно так же может быть необходимо и усовершенствовать, например, приложение – расширить возможности, улучшить функциональность, протестировать. Обычная система организации тут не подойдет, так как мы еще не знаем, что получится в результате. Поэтому канбан можно заменить скрамом, который для таких случаев и предлагается.
Что такое скрам - еще раз подробно
SCRUM – это система управления проектом с помощью структурирования. Все задачи разбиваются на элементы, выполнение каждого из которых приносит положительный результат. Отдельные части программы выполняются последовательно – одна за другой, и это видимо улучшает весь проект.
Если человек сам наблюдает, как его кусочек работы приносит улучшение всего общего дела, мотивация на дальнейшую деятельность. Если сравнить скрам с другими сервисами, где на первое место ставится дедлайн или степень важности задач, то он (скрам) выигрывает по всем статьям.
Компоненты SCRUM
Бэклог
Постановка задач. Формируется список задач, он разбивается на колонки для последовательности действий. Скрам-доска содержит “территории” для пользовательских историй, которые называются “Что сделать”, “В процессе” и “Готово”.
Ответственным за пользовательские истории назначается product owner – человек, который составляет список. В его компетенции – общение с заказчиком и делегирование его пожеланий членам команды. Этот человек:
- становится связующим звеном между сторонами,
- решает организационные вопросы,
- предотвращает конфликты,
- регулирует этапы процесса
- доводит его до конца.
За выпуск в свет качественного продукта отвечает именно product owner. Если провести нашу ассоциацию, то исполняет роль шеф-повара, тогда как клиент выступает директором ресторана, который заказывает суперчебурек. Оунер же регулирует процесс создания данного блюда.
Почему сценарий
Мы выяснили, что в блэклоге приложения – не кнопки, а сценарии, которые могут существовать автономно. Например, сценарием может быть опция “войти в приложение через соцсети”. Ее можно разработать и выпустить отдельно.
Но если есть опция “поддержка плагина авторизации через ОК”, это уже не будет отдельным сценарием. Это будет частью сценария, так как понадобится дорабатывать интерфейс, делать “подсказки” и прочее.
Так что мыслить здесь лучше сценариями, но это не всегда возможно, не в каждом продукте. Проверить сценарное мышление можно, задав себе вопрос: “Если выполнить этот список задач, получится ли новая версия продукта?” Если да – то мы говорим о сценарии.
Примеры сценариев с нашими ассоциациями: создаем чебурек новой формы, потом нового размера и т.д. Все это будут сценарии.
Интерации
Это “рывок” в работе. После формирования блэклога члены команды взвешивают силы и срок итерации, – время, необходимое для рывка. В ИТ, например, это до 3 недель. Здесь рассчитывается количество историй для одной итерации. Если она длится неделю, и в нее входит пять пользовательских историй, то для реализации проекта нужно пять недель.
Каждая итерация начинается с составления плана работы над каждой из историй. Каждый день проводятся встречи, где каждый член команды делает краткий отчет о том, что сделано, какие есть проблемы и что будет делать дальше. Длительность планерки – не более 15 минут, в скрам-команде может быть не более 9 участников.
Модератор встреч – скрам-мастер, он отвечает за выполнение задач и создание условий труда. Через него проходят все коммуникации между членами команды. Возникают проблемы – скрам-мастер их решает. Отвечает за исправность техники, выполнение дедлайна, и должен добиться положительного результата – вплоть до снабжения работника новым ноутбуком, продуктами или кофе.
Инкремент
Каждая итерация должна завершиться инкрементом – выдачей промежуточной версии продукта. И каждый инкремент предоставляется заказчику для обсуждения. Все участники на встрече выслушивают его, рассказывают, что сделали и предлагают свои варианты улучшения.
Заказчик принимает или не принимает инкремент, во втором случае отправляет на доработку. Бывает, что досрочно закрывает проект. Но в идеале каждый инкремент – это готовая версия продукта, и новые сценарии тут неуместны, так как из-за них могут нарушиться старые возможности.
Команда должна включать тестирование продукта в срок итерации. Тогда версия его будет надежной и стабильной, и это будет лучше, чем сырой продукт в результате многих сценариев.
Ретроспектива
Следующий этап – определение в продукте недочетов, проводимое всеми членами команды. Это собрание и есть ретроспектива, так нелюбимая многими разработчиками. Ведь на нем будет “разбор полетов” с не всегда приятными вещами. Ретроспектива скрама складывается из четырех этапов.
- Обсуждение положительных итогов и моментов итерации. Например, соблюдение дедлайна.
- Обозначение проблем. Например, вместо пяти вариантов продукта сделали три.
- Высказывание идей по улучшению работы. Например, лучше предлагать заказчику сделать меньше, но качественней.
- Составление плана по введению в жизнь предложенных идей.
Цель ретроспективы – определить, почему в процессе появились баги, и понять, как их избежать. Важно, что члены команды не ищут виновных в ситуации, а выясняют причины, которые привели к этому. Интересно: все исходят из того, что каждый член команды сделал все, зависящее от него.
Результаты каждой предыдущей ретроспективы учитываются при проведении следующей. Тогда продуктивность реально повысится.
Диаграмма сгорания
Чтобы понять, соответствует ли реальное время выполнения задач назначенному ранее, в скраме есть полезный график – диаграмма сгорания. С ее помощью отслеживается прогресс работы.
Диаграмма сгорания, которая показывает, что задача сделана не вовремя – не выполнена одна итерация. Зеленым отмечен план, красным – то, что получилось.
Готовность
Самый важный критерий готовности – результат. Часто оказывается, что команда думала, что нужно сделать так, а заказчик хотел совсем по-другому. Проблему можно не допустить, если четко прописывать результат: как должен выглядеть продукт, как – работать.
За этот вопрос отвечает скрам-мастер, он общается с заказчиком на протяжении всего процесса. Но и он далеко не всегда добьется идеала – ведь заказчик может сказать, что да, он хотел так, но теперь обстоятельства изменились, и нужно по-другому.
Что говорят о скраме
О скраме часто отзываются с критикой. Говорят, что в нем слишком много ритуальности – мол, вместо реального выполнения задач люди сидят и обсуждают собственную работу.
О SCRUM говорят, что многие хотят его использовать, но он не везде уместен, и внедрить его непросто. Если программу внедряют неграмотные руководители, и тогда ритуальные действия действительно приводят просто к потере времени. Задачи же не выполняются.
Читая все эти отзывы, важно понять, что люди, у которых не получилось внедрить скрам, неуместно либо неправильно его используют.
Вернемся к чебуреку
В идеале. Суперчебурек создан через назначенное время, одобрен скрам-мастером и принят заказчиком. Сделали презентацию, которая имела успех, появилось много покупателей, чебуречная стала получать хорошую прибыль.
В реале. Стартапер чебуречной купил дорогой автомобиль и попал на нем в ДТП. Инвесторам стало не интересно вкладывать деньги в его проект, члены команды ушли в другие компании, а кто-то перестал заниматься айти.
Можно добиться невероятных успехов, а потом жизнь обломает. Она сложнее, чем думал о ней скрам-мастер. Впрочем, такое могло произойти и с другим проектом и другой программой, не только со SCRUM. Тут пошла жизненная философия: человек только предполагает.
Вывод
Мы говорим о том, что скрам помогает решать задачи маленькими “рывками”, последовательно и надежно. Он однозначно поможет организовать бизнес, если вы знаете эту методику.
Если еще не готовы – можно подготовиться, в интернете есть различные сообщества, знатоки и тренеры по скраму делятся информацией и даже предлагают курсы. Успехов!