Что такое скрам коротко

SCRUM – эффективный метод управления проектами

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

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

Scrum: определение и краткая история

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

Позже, в 1993 году американский программист Джеф Сазерленд применил этот подход, когда разрабатывал методологию для компании «Easel» (детально об этом можно прочитать в его книге «Scrum – революционный метод управления проектами»). Тогда он и назвал его официально «Скрам». А два года спустя разработчик и консультант по разработке ПО Кен Швабер формализовал этот процесс применительно ко всей индустрии вообще.

В 1995 году на конференции «Объектно-ориентированные системы, языки и приложения для программирования» Швабер указал, что основой Scrum-методологии является итеративная разработка, а сама она определяет несколько характеристик при работе с проектами:

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

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

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

Концепция Scrum-методологии

В системе Agile Scrum-управление проектами состоит из трех основополагающих частей:

Чтобы уяснить суть, лучше разобрать эти части отдельно.

Роли в Scrum

Всего в Скрам есть три роли:

О них тоже имеет смысл сказать в отдельности.

Владелец продукта

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

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

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

Краткий перечень обязанностей владельца продукта:

Скрам-мастер

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

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

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

Краткий перечень обязанностей скрам-мастера:

Команда разработчиков

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

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

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

Краткий перечень обязанностей команды разработчиков:

Все вместе участники проекта проделывают не только основную работу, но и реализуют скрам-практики.

Практики в Scrum

Как и ролей, практик в Scrum-управлении проектами существует три:

Все эти практики имеют самое прямое отношение к спринтам, поэтому сначала скажем несколько слов о том, что вообще такое спринт.

Спринт

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

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

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

Команда разработчиков определяет оценки требований, чтобы убедиться, что они точны в степени, необходимой для начала работы. Затем определяется объем работ, который может быть успешно выполнен за один спринт. При этом нужно исходить из численности команды, доступного времени и производительности. Очень важно, чтобы команда разработчиков внимательно изучала журнал продукта и выбирала требования, первые по приоритету.

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

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

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

Ежедневные Скрам-встречи

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

Проводит ежедневные встречи скрам-мастер. Поочередно каждому участнику он задает вопросы:

Все открытые вопросы скрам-мастер заносит в список «Пункты действий». Здесь очень подходит формат «Что? Кто? Когда?». Вот простой пример такого списка:

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

Встречи по обзору спринта

По окончании каждого спринта принято проводить демонстрационную встречу, на которой происходит обзор спринта. Оптимальная продолжительность этих встреч – не более 4 часов.

В начале встречи команда разработчиков показывает владельцу продукта его рабочую версию (демонстрирует результаты проделанной работы). Встреча проходит под контролем самого владельца, причем он имеет право пригласить на нее всех заинтересованных людей и их представителей.

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

Во второй половине встречи скрам-мастер вместе с остальными участниками анализирует прошедший спринт. Команда разработчиков определяет эффективные и неэффективные методы совместной работы, проводит их анализ, делает выводы и принимает решения, которые улучшат дальнейшую работу.

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

Аварийная остановка спринта

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

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

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

Артефакты в Scrum

В любом Scrum-проекте есть три основных артефакта (документа):

У каждого из артефактов есть свои особенности.

Журнал продукта

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

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

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

Журнал спринта

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

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

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

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

График спринта

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

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

Таковы общие особенности Scrum-методологии. Если у вас возникло желание разобраться в этом методе более детально, то вам поможет в этом Джеф Сазерленд – познакомьтесь с уже упоминаемой книгой «Scrum – революционный метод управления проектами». А нам остается только подвести итоги этого краткого обзора Скрам.

Выводы о Scrum

Итак, относящийся к системе методов гибкого управления Agile, Scrum можно смело назвать настоящей находкой для людей, чья деятельность связана с проектами. Среди его достоинств выделяется, в первую очередь, ориентированность и адаптивность. Метод позволяет изменять требования к проекту в любое время (пусть и не дает гарантии того, что эти изменения будут реализованы). А такая возможность очень привлекает заказчиков.

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

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

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

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

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

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

Источник

Что такое Scrum и как правильно использовать его в рабочем процессе

Что такое Scrum

Коротко говоря, Scrum — это способ организации рабочего процесса. Он пришел из мира разработки программного обеспечения и сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам же термин пришел из регби и в переводе с английского означает «схватка».

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

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

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

Состав scrum-команды

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

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

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

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

Третий элемент команды — scrum-мастер. Он выступает в роли куратора и помогает коллективу сплотиться. Мастер проводит ежедневные собрания, помогает найти выход из тупикового этапа разработки и перевести команду на нужное направление. Главный успех scrum-мастера — сделать так, чтобы команда стала самоуправляемой и перестала в нем нуждаться. В идеале должны остаться только разработчики и владелец продукта.

Основные принципы работы по Scrum

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

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

Чем Scrum отличается от Kanban

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

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

Преимущества Scrum

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

Вице-президент «Ренессанс страхование» Владимир Тарасов рассказал РБК Трендам, к каким результатам пришла компания после применения метода:

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

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

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

Недостатки Scrum

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

Владимир Тарасов:

«Scrum не подходит для текущей операционной деятельности. Он больше ориентирован на проекты. У нас не классический Scrum. Мы объединили текущую работу по конкретным страховым случаям с проектами и задачами на улучшение процесса, разработку и испытание новых инструментов. Scrum не дает ответа, как сочетать операционную работу с проектами. Мы придумали свои собственные инструменты сочетания несочетаемого. Сам фреймворк это допускает».

У компании должны быть ресурсы на запуск такой программы. Scrum предполагает, что команда работает с проектом, аналогов которому нет на рынке. Получается, успех его разработки может не оправдаться или занять слишком много времени. Фирма должна быть финансово готова к такому результату.

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

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

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

Как внедрить Scrum для управления бизнес-процессами

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

Как внедрить Scrum в компанию

Подробную инструкцию по внедрению Scrum и о его процессах можно посмотреть в гайде или в книге от соавтора методологии Джеффа Сазерленда «Scrum: революционный метод управления проектами». О том, как правильно распоряжаться ресурсами и повышать личную эффективность, читайте в материале РБК Трендов про бережливое производство в жизни.

Источник