X Международная студенческая научная конференция Студенческий научный форум - 2018

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

С выходом на мировой рынок таких компании, как Google, Amazon, Toyota, перед менеджерами менее производительных компаний встал вопрос о том, благодаря чему их производительность поднялась на 300-400 процентов? Во многом это результат работы высокоэффективных проектных групп, которые реализовывали масштабные проекты, используя гибкую методику управления проектами. Одной из таких методик является Scrum.

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

Термин Scrum выбран не случайно. Это не аббревиатура. Этот термин взят из регби (американский футбол), означает специфическую игровую ситуацию, в которой участники команд смыкаются в три линии с каждой стороны – так вводится в игру мяч после нарушения правил и задача участников каждой из команд выиграть этот розыгрыш за счет совместных усилий команды. В переводе с английского языка scrum означает «схватка».

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

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

Методика Scrum имеет свои основные роли:

Владелец продукта (Product owner) — человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как это продукт должен выглядеть/работать. Этот человек не работает в команде, он работает на стороне заказчика/клиента (это может быть как другая компания, так и другой отдел), но этот человек работает с командой. И это тот человек, который расставляет приоритеты для задач.

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

Scrum-команда — это непосредственно команда исполнителей проекта.

Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность определяется командой один раз). В конце каждого спринта команда должна продемонстрировать всем участникам проекта работающий функционал продукта.

Бэклог (backlog) — это список всех работ, необходимых к выполнению для реализации проекта.

Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог.

Product-бэклог — это список работ, ранжированный по важности и, иногда, по сложности. Каждый элемент списка называется «пользовательской историей», что отражает клиентоориентированный подход к разработке продукта.

Спринт-бэклог — это список работ, который определила команда и согласовала с Владельцем продукта, на ближайший отчетный период (спринт). Задания в спринт-бэклог берутся из product-бэклога.

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

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

Удобнее всего проиллюстрировать применение методологии Scrum на разработке программного обеспечения. Допустим, совет директоров компании «Вандекс» принял решение выйти на рынок сервисов для такси со своим продуктом на основе собственного программного обеспечения. Реализовать проект предполагается силами специально нанимаемой для этого команды профессионалов. Расскажем, как бы выглядел процесс работы над этой задачей по методологии Scrum. На этапе формирования команды топ-менеджмент назначил владельца продукта (product owner). Владелец продукта приступил к сбору информации и формированию списка пожеланий к результатам product backlog на основе данных рынка, опроса топ-менеджеров «Вандекс» и фокус-групп с потенциальными клиентами. Нанятая команда (scrum-team) совместно с владельцем проекта провела установочную встречу, на которой определила размер спринта в две недели, приняла и расставила приоритеты для «пользовательских историй» из списка задач (product backlog). Затем уже без владельца продукта, команда, под контролем и управляющим воздействием скрам-мастера, распределила задачи по спринтам, сформировала спринт-бэклог предстоящего спринта; каждый участник команды взял себе в работу задачи из списка бэклога. Не используя специфическую терминологию, все действия этого этапа сводятся к следующему: определяется длительность каждой итерации работы команды до очередной встречи с куратором, формируется и согласовывается окончательный список требований и спецификаций для начала работы, затем из него членами команды выбираются задачи для первой итерации, остальные распределяются по будущим и команда приступает к разработке.

Идет первый спринт, в течение которого каждый день команда собирается на 15 минутные скрам-летучки (scrum-meeting) или «собрания на ногах». На этих встречах участники команды посвящают коллег в статус выполнениями ими выбранных задач, делятся планами на день, возникающими сложностями, что позволяет всем участникам команды быть в курсе текущего статуса проекта. Например, у одного из членов команды ответственного за дизайн «слетел софт» и у него нарушается привычный ритм работ и возможно он не уложится в срок, надо будет переносить задачу, но не факт. Другой член команды ответственный за разработку, нашел в сети готовый блок кода и поэтому освободится раньше. Так как оба специалиста кросс-функциональны и вся команда отвечает за продукт, второй предложил помощь первому и скорее всего в срок они уложатся.

Удобно для такой встречи использовать визуализацию в виде доски или специального программного обеспечения, в котором отмечены задачи текущего спринта и все product backlog (все задачи из списка спецификаций) каждая с учетом ее статуса: «к выполнению», «в работе», «на тестировании», «выполнено». Доска соответственно разделена на соответствующие столбцы, и участники команды переносят свои задачи из одного столбца в другой, иллюстрируя статус своих задач и вводя в курс дела своих коллег. По завершению спринта, команда демонстрирует выполненную работу владельцу продукта, который в свою очередь дает обратную связь в ответ. Без владельца продукта команда обсуждает итоги проведенного спринта и полученные новые вводные от владельца продукта, планирует следующий спринт. Например, команда демонстрирует работающий прототип программы: интерфейс пользователя, водителя и администратора сервиса такси. Цикл спринтов повторяется до тех пор, пока не будет готов продукт, проведено его тестирование и он не будет принят владельцем продукта и заказчиком. Но в ходе работ может быть создан первый релиз, который будет предложен потребителю для проверки в условиях реального рынка сформированных перед реализацией проекта гипотез, получения новых вводных, новой информации в отношении потребностей конечного пользователя. Современное производство программного обеспечения подразумевая априори регулярный выпуск обновлений на основе выявленных недостатков и проблем, а также новых запросов потребителя. По завершению проекта скрам-команда проведет ретроспективное совещание, на котором проанализирует все сложности и вызовы при реализации проекта, запротоколирует сам ход реализации, характеристики продукта и как они менялись по ходу разработки и т.п. Чтобы сохранить полученные знания в ходе реализации проекта для своих будущих проектов и для отчета перед заказчиком.

Помимо Scrum известной гибкой методикой управления проектами является Agile. 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-методология по сути своей широко применяется при ежегодном запуске процесса бюджетирования на следующий год.

Список используемой литературы

Scrum. Революционный метод управления проектами/ Джефф Сазерленд; пер. с англ. М. Гескиной – 2-е изд. – М.: Манн, Иванов и Фербер, 2017.

Майк Кон. Scrum: гибкая разработка ПО — М.: «Вильямс», 2011.

Код для цитирования: Скопировать