Все, что вам нужно знать про методологию SCRUM

1109
Все, что вам нужно знать про методологию SCRUM
Кочешков Андрей
главный аналитик ОАО «Издательство «Просвещение»
Конец двадцатого – начало двадцать первого века породили ряд новых сфер бизнеса, характеризующихся коротким циклом разработки и вывода продукции на рынок, ориентацией не на функционал, а на потребности потребителя. Для этих сфер инструментарий традиционных методологий управления проектами оказался слишком громоздким и сложным, у менеджеров нет достаточно времени для полноценного развертывания процессов управления, более того часто нет возможности получить формализованный и согласованный список требований к конечному продукту – менеджер не имеет представления о том, что он должен создать в качестве результата проекта. Поэтому специалисты обратили свое внимание на альтернативные технологии. Сегодня обсудим одну из них – методологию SCRUM.

Методология SCRUM: основные понятия

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

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

В команде нет единого руководства, нет лидера. Возможные роли в команде:

  • Product owner (владелец продукта): специалист, отвечающий за связь всей команды с заинтересованными сторонами (stakeholders), такими как руководство и сотрудники компании, заказчик, потребители, клиенты и др. Его можно назвать куратором проекта.
  • Scrum-master (скрам-мастер): это специалист по технологии Scrum, который следит за правильностью ее реализации, соблюдением всех принципов, защищает команду от отвлекающих факторов, ведет документацию. Подобно ответственному секретарю на мероприятиях, отвечающему за регламент.
  • Scrum-team (скрам-команда) проекта: все остальные участники команды равноправны в команде и работают над задачами определенными на этапе планирования.

В Scrum-методологии стартовым документом является так называемый product backlog – это список пожеланий к результатам, ранжированный по важности и, иногда, по сложности. Каждый элемент списка называется «пользовательской историей» – что отражает клиенто-ориентированный подход к разработке продукта. В течение срока реализации проекта в product backlog могут вноситься изменения скрам-командой. Product backlog – заменяет спецификации в традиционном подходе к планированию проектов, но не идентичен ему: пожелания к проекту («пользовательские истории») могут меняться в течение проекта и даже перевернуть изначальную суть продукта «с ног на голову».

Другой ключевой элемент методологии – спринты (sprints) – минимальный временной период (итерация), в течение которого готовится очередная новая версия продукта (прототип и т.п.). Перед стартом спринта формируются sprint backlog (спринт-бэклог) – список задач для спринта из product backlog (список задач для текущей итерации разработки продукта), которые планируются к реализации за время текущего спринта. При реализации проекта в соответствии со Scrum-методологией менеджеры регулярно обращаются к инструментарию «customer development», проверяя гипотезы, тестируя промежуточные идеи и прототипы.

Скачайте дополнительный материал к статье:

Иконка PDF12 жизненных правил управления проектами финансовой службы

Пример применения SCRUM для управления проектами

Удобнее всего проиллюстрировать применение методологии Scrum на разработке программного обеспечения. Допустим, совет директоров компании «Вандекс» принял решение выйти на рынок сервисов для такси со своим продуктом на основе собственного программного обеспечения. Реализовать проект предполагается силами специально нанимаемой для этого команды профессионалов. Расскажем, как бы выглядел процесс работы над этой задачей по методологии Scrum.

  1. На этапе формирования команды топ-менеджмент назначил владельца продукта (product owner).
  2. Владелец продукта приступил к сбору информации и формированию списка пожеланий к результатам product backlog на основе данных рынка, опроса топ-менеджеров «Вандекс» и фокус-групп с потенциальными клиентами.
  3. Нанятая команда (scrum-team) совместно с владельцем проекта провела установочную встречу, на которой определила размер спринта в две недели, приняла и расставила приоритеты для «пользовательских историй» из списка задач (product backlog). Затем уже без владельца продукта, команда, под контролем и управляющим воздействием скрам-мастера, распределила задачи по спринтам, сформировала спринт-бэклог предстоящего спринта; каждый участник команды взял себе в работу задачи из списка бэклога. Не используя специфическую терминологию все действия этого этапа сводятся к следующему: определяется длительность каждой итерации работы команды до очередной встречи с куратором, формируется и согласовывается окончательный список требований и спецификаций для начала работы, затем из него членами команды выбираются задачи для первой итерации, остальные распределяются по будущим и команда приступает к разработке.
  4. Идет первый спринт: в течение, которого каждый день команда собирается на 15 минутные скрам-летучки (scrum-meeting). На этих встречах участники команды посвящают коллег в статус выполнениями ими выбранных задач, делятся планами на день, возникающими сложностями, что позволяет всем участникам команды быть в курсе текущего статуса проекта. Например, у одного из членов команды ответственного за дизайн «слетел софт» и у него нарушается привычный ритм работ и возможно он не уложится в срок, надо будет переносить задачу, но не факт. Другой член команды ответственный за разработку, нашел в сети готовый блок кода и поэтому освободится раньше. Так как оба специалиста кросс-функциональны и вся команда отвечает за продукт, второй предложил помощь первому и скорее всего в срок они уложатся.  Удобно для такой встречи использовать визуализацию в виде доски или специального программного обеспечения, в котором отмечены задачи текущего спринта и все product backlog (все задачи из списка спецификаций) каждая с учетом ее статуса: «к выполнению», «в работе», «на тестировании», «выполнено». Доска соответственно разделена на соответствующие столбцы, и участники команды переносят свои задачи из одного столбца в другой, иллюстрируя статус своих задач и вводя в курс дела своих коллег.
  5. По завершению спринта, команда демонстрирует выполненную работу владельцу продукта, который в свою очередь дает обратную связь в ответ. Без владельца продукта команда обсуждает итоги проведенного спринта и полученные новые вводные от владельца продукта, планирует следующий спринт. Например, команда демонстрирует работающий прототип программы: интерфейс пользователя, водителя и администратора сервиса такси.
  6. Цикл спринтов повторяется до тех пор, пока не будет готов продукт, проведено его тестирование и он не будет принят владельцем продукта и заказчиком. Но в ходе работ может быть создан первый релиз, который будет предложен потребителю для проверки в условиях реального рынка сформированных перед реализацией проекта гипотез, получения новых вводных, новой информации в отношении потребностей конечного пользователя. Современное производство программного обеспечения подразумевая априори регулярный выпуск обновлений на основе выявленных недостатков и проблем, а также новых запросов потребителя.
  7. По завершению проекта скрам-команда проведет ретроспективное совещание, на котором проанализирует все сложности и вызовы при реализации проекта, запротоколирует сам ход реализации, характеристики продукта и как они менялись по ходу разработки и т.п. Чтобы сохранить полученные знания в ходе реализации проекта для своих будущих проектов и для отчета перед заказчиком.

Как соотносятся Agile и Scrum

Agile в перевроде с английского – быстрый, гибкий, живой, динамичный, маневренный. Зимой 2001 года в горах американского штата – Юта, собрались представители нескольких альтернативных методологий управления проектами (альтернативных принятой до того момента классической каскадной модели управления), для того чтобы разработать и описать единые принципы нового подхода к разработке проектов, который бы отвечал требованиям современности, согласовать усилия по продвижению гибкой методологии. По-видимому, и сама встреча в Юте была в большой степени PR-акцией, так как именно после нее началось масштабное продвижение идеологии гибкой (agile) разработки в массы. Результатом встречи стал Agile-manifesto, свод ценностей и принципов гибкой разработки.

Все методики, присоединяющиеся к Agile-manifesto, должны отвечать ценностям гибкой разработки, изложенным в нем:

  • люди и взаимодействие – первичны, процессы и инструменты – вторичны;
  • работающий продукт в приоритете перед полной и исчерпывающей документацией;
  • возможность постоянного взаимодействия и сотрудничества с заказчиком важнее согласования условий контракта.
  • вчень важно быть готовым к изменениям первоначального плана.

Scrum-методология – одна из тех, что отвечает этим ценностям и следует изложенным в Agile-manifesto принципам. То есть разница в том, что это не две различным методики, а то, что Agile является философской концепцией, которой следует Scrum и ряд других методологий в том числе, Scrum – подмножество множества методологий, следующих принципам Agile и отвечающих ценностям гибкой разработки.

Так наравне со Scrum, принципам Agile следует и методология Kanban, которая имеет как свои особенности, так и общие со Scrum элементы. Так и в Scrum и в Kanban работают небольшие команды, отношения внутри которых не регламентируются и не контролируются из вне. Еще общим является то, что за успех проекта отвечает вся команда, а не отдельные личности; обе методологии требуют, чтобы команда располагалась в одном пространстве, чтобы обеспечивать свободное перемещение информации внутри команды. Но в Kanban в отличие от Scrum в команде могут быть узкопрофильные специалисты и они могут принимать участие в работе над задачей на разных этапах, Kanban не требует ритмичности, итерации могут быть разных длительностей, а не равных как в Scrum, в Kanban задачи могут добавляться в работу в любое время – и это только некоторые отличия.

Kanban считается проще и легче для внедрения, чем Scrum из-за его сниженных требований и ограничений, относительно методологии Scrum.

Вне всяческих сомнений – гибкие методологии находят широкое применение в бизнесе сегодня, особенно в разработке ит-продуктов, корпоративного программного обеспечения, интернет и мобильных приложений. Стартап-индустрия в настоящее время построена так, что кроме гибкой разработки все прочие методологические подходы наносят ущерб вновь созданному бизнесу. Agile-методологии эффективны там, где есть высокая степень неопределенности относительного требованиям к новому продукту (отсутствие четких требований) или аналогов создаваемого никогда не существовало (стартапы).

В сфере финансов гибкие методологии находят себя в разработке нового прикладного ПО, внедрение на предприятии ERP и подобных систем, запуске Fintech стартапов. Agile-методология по сути своей широко применяется при ежегодном запуске процесса бюджетирования на следующий год.

Методические рекомендации по управлению финансами компании



Ваша персональная подборка

    Подписка на статьи

    Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

    Рекомендации по теме

    Школа

    Школа

    Проверь свои знания и приобрети новые

    Записаться

    Самое выгодное предложение

    Самое выгодное предложение

    Воспользуйтесь самым выгодным предложением на подписку и станьте читателем уже сейчас

    Живое общение с редакцией

    А еще...




    © 2007–2017 ООО «Актион управление и финансы»

    «Финансовый директор» — практический журнал по управлению финансами компании

    Зарегистрировано Федеральной службой по надзору в сфере связи,
    информационных технологий и массовых коммуникаций (Роскомнадзор)
    Свидетельство о регистрации ПИ № ФС77-62253 от 03.07.2015;
    Политика обработки персональных данных
    Все права защищены. email: fd@fd.ru

    
    • Мы в соцсетях
    Сайт использует файлы cookie. Они позволяют узнавать вас и получать информацию о вашем пользовательском опыте. Это нужно, чтобы улучшать сайт. Посещая страницы сайта и предоставляя свои данные, вы позволяете нам предоставлять их сторонним партнерам.Если согласны, продолжайте пользоваться сайтом. Если нет – установите специальные настройки в браузере или обратитесь в техподдержку.
    ×
    Чтобы скачать документ, зарегистрируйтесь на сайте!

    Это бесплатно и займет всего 1 минуту.

    У меня есть пароль
    напомнить
    Пароль отправлен на почту
    Ввести
    Я тут впервые
    И получить доступ на сайт Займет минуту!
    Введите эл. почту или логин
    Неверный логин или пароль
    Неверный пароль
    Введите пароль