Аннотация: Актуальность темы данной статьи определяется сложившейся в настоящее время турбулентной внешней средой, ситуацией быстрых изменений. Чтобы оставаться «на плаву» компаниям необходимо обеспечивать постоянное гибкое адаптивное совершенствование своей деятельности, опережая конкурентов в уровне эффективности.

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

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

Введение. Прототип современного скрам подробно описан профессорами Hitotsubashi University Хиротака Такэучи и Икудзиро Нонака в 1986 году. В начале 1990-х американские разработчики Кен Швабер и Джефф Сазерленд сформулировали принципы Scrum. А в 2001 году Кен Швабер в соавторстве с Майклом Бидлом детально описал скрам в книге «Гибкая разработка программного обеспечения по SCRUM». Ценность методологии основывается на получение конечных результатов. Скрам подход к управлению проектами с использованием игровых элементов, основанный на принципах тайм-менеджмента, термин позаимствовали из спортивной игры Регби, который дословно означает «схватку вокруг мяча».

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

С помощью скрам можно улучшить процесс комплексной разработки продукта, улучшить управление продуктом и по-новому взглянуть на практику разработки, визуализировав процесс на одном листе. При использовании скрам выделяются три роли:  Владелец продукта (Product owner)  Скрам мастер (Scrum master) 

Команда разработки (Development-Team) Владелец продукта устанавливает связь между командой заказчиком и командой разработки. Он заинтересован в качественном конечном продукте, понимает, как продукт должен выглядеть и работать. Работает на стороне заказчика/клиента с командой: ставит задачи, устанавливает и корректирует приоритеты, отвечает за взаимодействие с рынком. Максимально увеличивать ценность продукта и работы команды, его основная задача. Например, в банке это может быть департамент выпуска пластиковых карт.

Скрам-мастер лидер команды с широким функционалом, решает проблемы команды, следит за конкретным применением и исполнением принципов и ритуалов эджаил (Agile) и скрам. Обеспечивает вовлеченность и все необходимые инструменты, обучает, мотивирует, защищает команду. Скрам-мастер не назначает людей на задачи это делает сама команда и не заставляет людей делать работу это ответственность команды. Команда-разработки межфункциональная команда проекта, реализующая всю непосредственную работу над проектированием и производством продукта/услуги, состоит из 5-10 человек разных профилей: тестировщиков, архитекторов, аналитиков, программистов и др.

Команда принимает все принципы скрам и готова с ними работать, отвечает за разработку продукта итерациями (спринтами). Процесс. Разработка продукта выполняется спринтами, отрезками времени (1-4 недели). Новая версия ПО, новый дизайн, улучшенная функциональность, выполнение задач, является результатом. В начале каждого спринта ставятся цели, определяется объем работ и обсуждаются детали реализации задач и требований, устанавливаются приоритеты и временные рамки. Далее происходят ежедневные собрания, для определения прогресса работы, задаются вопросы: «что сделано?», «что планируется сделать?», «какие препятствия обнаружены?» и происходит выработка решений по изменению стратегии, необходимых для достижения целей спринта. И в завершении спринта, оценивается эффективность предыдущего отрезка, делается работа над ошибками и вносятся изменения, для повышения эффективности работы над продуктом, это спринт ревью и спринт ретроспектива. Скрам является легким и простым в понимании, но сложным в овладении.

Основные причины неправильного использования заключаются в частичном или неполном использовании целостной методологии скрам. В книге «The Scrum Guide» описывается полная и точная схема организации процесса и управления персоналом. Также очень важно обеспечить вовлеченность команды, здесь ключевой принцип скрам это само-мотивация и самоорганизация многофункциональных команд.

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

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

Скрам бережлив и в нем нет ничего лишнего, поэтому он задает несколько жестких правил и это иногда конфликтует с идеей клиентоориентированности, т.к. клиенту не важны внутренние правила работы команды, если они ограничивают его. Пример. Клиенту нужно срочно в аэропорт Внуково. Звонит в такси, заказывает машину. Оператор говорит, что поездка в аэропорт будет стоить 1500 рублей, время в пути 40 минут, машина подъедет через 10 минут. В данном процессе участвуют заказчик, оператор и подрядчик таксист, т. е. исполнитель, который работает по скрам. Условия заданы, есть два сценария развития событий: Сценарий 1: «Классический скрам». Такси приезжает не через 10 минут, как сказали в службе заказа, а через 15. Клиент в машине, поехали. По пути заезжаем на заправку, тратим драгоценное время. Неожиданно таксист обнаруживает, что в городе пробки. И за 40 минут не добраться придется ехать в объезд. За дополнительный километраж нужно будет доплачивать, это указано в правилах поездки, на сайте, мелким шрифтом. Дальше просьба остановить, метро, вокзал, Аэроэкспресс.

По расписанию, точно вовремя, 500р. Удивительная ситуация. Заказчик наблюдает следующую картину: ему сразу выдвинули условие, что за все форс-мажоры и неправильные оценки со стороны службы такси отвечает он, на что заказчик в спешке согласился. Затем этот самый форс-мажор случается (причем трижды): ошибка с временем старта, техническое состояние автомобиля (бензин), и неожиданная проблема (пробки). В итоге сроки не соблюдены, а бюджет увеличен. Странно, что многие западные разработчики пытаются работать по этому сценарию, аргументируя это тем, что невозможно все предугадать и изменения всё равно будут, «все субъективно». И все-таки, гибкость отличный инструмент. Заказчик хочет слышать фиксированную сумму. А в скрам бюджет гибкий.

Вывод, на каждый этап четко определять время и фиксированную стоимость процесса. Главная задача руководителя проектов в условиях неопределенности сделать наилучшее предположение о том, как пойдет проект, и реализовать его. Для этого на каждый этап гибкой разработки, есть вполне жесткая оценка по координатам проекта: «деньги/сроки/объем работы(качество)». Если не укладываемся в бюджет это наша проблема, оплачиваем ее тоже мы. Сценарий 2: «Правильный скрам».

Такси приезжает вовремя. Заказчик едет в Домодедово, тут внезапно ему звонит оператор авиакомпании и говорит, что рейс перенесен во Внуково. Он незамедлительно сообщает об этом таксисту и тот не едет до Домодедово, а потом разворачивается. Просто сворачивает на ближайшем перекрестке, выбирает самый короткий маршрут. По пути решает вопрос о новой цене. Главное убедиться, что нововведения идут на пользу потребителю, энтузиазму и дисциплине в коллективе. Это основной принцип такого рода импровизаций.

Библиографический список

1. Вумек Джеймс П., Джонс Дэниэл Т. Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании/пер. с англ. 6-е изд. – М.: Альпина Бизнес Букс, 2015. – 473 с

2. Девенпорт Т. Аналитика как конкурентное преимущество. Новая наука побеждать. М.: БэстБизнесБукс, 2010. 264с.

3. Книберга Х. и Скарина М. "Scrum и Kanban: выжимаем максимум". 2010 C4Media Inc

4. Кон М. Scrum: гибкая разработка ПО. Издательство: Вильямс, 2016, 576с.

5. Ригби Д., Сазерленд Д., Х. Такеучи. Новый рецепт инноваций: модель Agile. HBR август 2016.

6. Сазерленд Д. Scrum. Революционный метод управления проектами. Издательство: Манн, Иванов и Фербер, 2016-273с.

7. Alan Trefler – Build for Change: Revolutionizing Customer Engagement through Continuous Digital Innovation. NY. Wiley. 2014.175p/ 8. http://www.hbs.edu/faculty/Pages/profile.aspx?facId=6563 9. http://agilemanifesto.org/iso/ru/principles.html 10. http://www.scrumguides.org

В. А. Баринов, Д. С. Ильдеменов