Методология scrum: эффективное управление проектами

«Цинизм является ответной реакцией нашего сознания на чувство отчаяния».
Джефф Сазерленд

Автор методологии Scrum относит данное проявление к числу одних из самых вредных человеческих антидобродетелей.

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

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

Насколько сильна альтернатива PM?

Действуя как топ-менеджер и проект-менеджер, я столкнулся с понятием Scrum как некой экзотической альтернативой классическому project management.

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

Методология Скрам показалась несколько ангажированной и неконкретной.

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

Метод применим при проектировании моделей образования, НИОКР, государственного и муниципального строительства. Однако, как для любого нового, важно:

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

Являются ли современная парадигма управления проектами, международные и национальные стандарты (ANSI PMbok Guide, PM ICB IPMA, НТК) продуктом, который используют потребители: государство, его институты, бизнес? Да, конечно. Какие проблемные зоны существуют в современной проектной практике, основанной на рабочей методологии? Их несколько, но основных две: невыполнение проектных сроков и превышение бюджета проекта.

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

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

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

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

В своей разработке авторы метода использовали элементы теории Х. Такеучи и И. Нонака, а также идеи системы компании Тoyota (Тайити Оно).

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

Терминология метода

Авторы метода небезосновательно подвергли критике классическую модель календарного планирования проектов, применяемую уже около 100 лет на основе подхода Г. Гантта.

Действительно, ничего нельзя противопоставить утверждению, что наглядная диаграмма Ганта, по существу является одноразовой в использовании.

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

1. Владелец продукта. Эта фигура несет ответственность за то, чтобы командная работа дала результат, который приносит компании прибыль (выгоды). Он должен прекрасно разбираться в сути продукта, в возможностях команды и в приоритетах рынка.
2. Скрам-мастер. Метафорически это очень интересная роль. «Лидер-слуга», «капитан команды», «тренер-коуч». Его главная задача – вести команду по пути непрерывного совершенствования, устраняя препятствия и причины помех.
3. Доска Скрам. Обычная офисная доска, разделенная на части: «бэклог», «в работу», «в работе», «на рассмотрение», «сделано!». По ней перемещаются наклеиваемые стикеры с заданиями.
4. Собрание Скрам. Итоговое собрание по завершении спринта.
5. Спринт. Временной промежуток от 1 до 4 недель, устанавливающий рабочий ритм деятельности команды Скрам по созданию новой функциональности.
6. Совещания на ходу или ежедневный Scrum. Короткие собрания команды проекта для ответа на вопросы скрам-мастера о результатах, планах на день и текущих препятствиях.
7. Бэклог (баклог). Список текущих требований-заданий к созданию функциональности продукта проекта.
8. Диаграмма выгорания задач. Диаграмма, показывающая количество сделанной и оставшейся работы в рамках поставленной задачи.
9. Последовательность Фибоначчи. Математическая закономерность, свойственная природе нашей Вселенной, при которой действует особый порядок чисел. Настоящая последовательность хорошо применима для альтернативной оценки продолжительности выполнения работ проекта, благодаря использованию так называемого «покера планирования». Ниже представлена визуальная модель числовой последовательности.
10. Сюхари (Shu Ha Ri). Сюхари – одна из концепций японских боевых практик (например, айкидо), которая вошла в число принципов метода Скрам как метафора возможности поэтапного (итерационного) достижения совершенства команды проекта.
11. OODA. Принцип метода Скрам по циклической реализации: наблюдать, ориентироваться, решать, действовать.

Модель последовательности Фибоначчи

Базовая модель метода Скрам. Источник: Асхат Уразбаев. Краткий обзор методологии Скрам

Краткое описание процесса

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

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

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

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

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

Проектная реализация с использованием процессов Scrum состоит из четырех крупных блоков.

1. Заполнение ролей команды Скрам.
2. Формирование артефактов Скрам.
3. Реализация активности.
4. Воспроизводство цикла Скрам.

Визуальная модель процесса метода Скрам

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

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

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

Под артефактами Scrum в методе понимаются: бэклоги продукта и спринта, продукт проекта с новой функциональностью.

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

Во внутренней среде цикла спринта команда действует автономно, сопровождаемая «совещаниями на бегу» и перемещениями стикеров на доске Скрам. Пример внешнего вида доски показан ниже.

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

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

Источник: http://projectimo.ru/upravlenie-proektami/metodologiya-scrum.html

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

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

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

Сбор требований на этапе аналитики тоже не дает стопроцентной точности — заказчики не расскажут вам все сразу.

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

Плюсы методологии:

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

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

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

Минус водопадной схемы — процессы идут друг за другом. Это замедляет разработку

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

Удобно вести бэклог задач в Trello или Excel.

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

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

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

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

Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.

Так выглядит бэклог со спринтами.

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

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

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

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

Люди, которые непосредственно создают и тестируют код. 

К разработчикам есть несколько требований:

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

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

Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.

Так выглядит диаграмма сгорания в реальных проектах.

Контролируйте работу команды с помощью двух scrum-показателей:

• Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
• Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.

Стройте график планового и фактического расхода времени на задачи. Через несколько спринтов столбцы станут примерно одинаковыми.

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

• Что сделано вчера?
• Что будет сделано сегодня?
• Какие есть проблемы и препятствия для выполнения задач?

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

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

Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.

На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.

Попробуйте такой шаблон для ретроспективы.

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

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

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

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

Источник: https://skillbox.ru/media/management/kak_ispolzovat_agile_i_scrum/

SCRUM — революционный метод управления проектами

Scrum — наиболее действенная и популярная методология управления проектами при разработки информационных систем и программного обеспечения.

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

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

В чём заключается суть методики Scrum?

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

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

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

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

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

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

ЗАКАЗАТЬ ТРЕНИНГ «AGILE MENAGEMENT — ТРАНСФОРМАЦИЯ МЫШЛЕНИЯ» ВЫ МОЖЕТЕ ПОЗВОНИВ ПО ТЕЛЕФОНУ: +7 (495) 394-33-17 ИЛИ ЗАПОЛНИТЬ ФОРМУ НА САЙТЕ. 

Манифест гибкой методологии, его основные принципы

Авторы методики Scrum подписали, в числе других 17 участников, знаменитый манифест Agile Manifesto, в основу которого заложен определённый набор принципов, применяемых при разработке цифровых продуктов.

Они включают следующие моменты:

• Главным приоритетом становится удовлетворение всех потребностей клиента.

Источник: https://first-expert.ru/scrum-revolyutsionnyiy-metod-upravleniya-proektami/

Зачем Нужен Метод Управления Проектами SCRUM?

Абсолютная уверенность игроков друг в друге, полная согласованность действий и целей — вот что представляет собой величие.

Джефф Сазерленд

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

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

Классические

К классическим относится модель WATERFALL (или водопад). В данной модели этапы идут строго друг за другом:

1. Инициализация
2. Планирование и составление полной документации проекта
3. Разработка проекта
4. Тестирование
5. Завершение

В WATERFALL нельзя вернуться на шаг назад если что либо не учли — это ее основное отличие от гибких методов. Длительность каждого этапа может сильно варьироваться.

Гибкие

Гибкие или революционные методы управления — это все методы, построенные на базе AGILE. AGILE определяет ценности и принципы, которым руководствуются участники команд.

Наиболее популярным и эффективным фреймворком разработки проектов по методам AGILE является SCRUM. Про него сегодня и пойдет речь.

Почему гибкость побеждает в IT проектах?

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

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

WATERFALL в этом случае не сможет помочь. Ведь в нем все должно быть заранее описано в техническом задании.

Почему SCRUM?

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

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

Внедрение метода управления проектами SCRUM подходит для команд разработки от 3 до 9 человек. А для больших проектов существует Scrum of Scrums, где несколько Scrum команд объединены для достижения единой цели.

Именно поэтому Scrum получил такое распространение.

3 роли в SCRUM TEAM

Scrum team делится на 3 роли:

1. Development Team — команда разработки
2. Product Owner — связующий между заказчиком и командой разработки
3. Scrum Master — помощник, устраняющий проблемы внутри Scrum team

Взаимодействия в SCRUM TEAM

Взаимодействия в SCRUM:

1. Планирование — совещание где разбирается что необходимо сделать в текущем спринте. Проводится вначале каждой итерации.
2. Daily Scrum Meeting — Ежедневное совещание длительностью порядка 15 минут.
3. Sprint Review Meeting — демонстрация функционала по завершению итерации.
4. Sprint Retrospective Meeting — смотрим на результат команды

3 SCRUM вопроса

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

1. Что я сделал для того чтобы приблизить команду к цели спринта?
2. Что я сделаю сегодня для того чтобы приблизить команду к цели спринта?
3. Какие препятствия стоят на моем пути?

Внедрение SCRUM

Внедрение SCRUM происходит легко благодаря его гибкости. Вы можете встретить сопротивление команды на начальных этапах. Но после 3 циклов команда поймет новые правила и начнет их соблюдать.

Задачи SCRUM

Ведение задач в SCRUM можно производить в специальных программах и веб сервисах, имитирующих SCRUM board. Одним из наиболее популярных является trello.

Заключение

Теория SCRUM проста. Основная сложность заключается в применении метода управления проектами SCRUM на практике.

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

Источник: https://mazurinv.ru/metod-upravleniya-proektami-scrum/

Методология SCRUM. Управление проектами SCRUM

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

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

Используйте пошаговые руководства:

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

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

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

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

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

В течение срока реализации проекта в product backlog могут вноситься изменения скрам-командой.

Product backlog – заменяет спецификации в традиционном подходе к планированию проектов, но не идентичен ему: пожелания к проекту («пользовательские истории») могут меняться в течение проекта и даже перевернуть изначальную суть продукта «с ног на голову».

Другой ключевой элемент методологии – спринты (sprints) – минимальный временной период (итерация), в течение которого готовится очередная новая версия продукта (прототип и т.п.).

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

При реализации проекта в соответствии со Scrum-методологией менеджеры регулярно обращаются к инструментарию «customer development», проверяя гипотезы, тестируя промежуточные идеи и прототипы.

Пример применения 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 из-за его сниженных требований и ограничений, относительно методологии Scrum.

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

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

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

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

Источник: https://www.fd.ru/articles/158926-vse-chto-vam-nujno-znat-pro-metodologiyu-scrum

Scrum — ЭТО ЭФФЕКТИВНОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ

Аджайл и скрам

Aджайл — это подход к разработке программ, описанный в Aджайл-манифесте. Этот документ раскрывает философию Aджайл через четыре главные ценности:

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

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

Один из самых популярных среди них — SCRUM.

Согласно опросу за 2015 год (2015 State of Scrum Survey Report) от ScrumAlliance, SCRUM широко применяется и будет применяться в разных бизнес-отраслях для успешной разработки различных проектов.

Эта статья посвящена SCRUM-фреймворку, его истории, преимуществам применения SCRUM в компаниях, его ограничениям и тому, как применять SCRUM-структуру в вашей организации.

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

Любой разговор об успешном управлении проектами с помощью SCRUM стоит начинать с определения SCRUM.

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

«В SCRUM есть система ролей, встреч, правил и артефактов. В этой модели за создание и адаптацию рабочих процессов отвечают команды».

«В SCRUM используются итерации фиксированной длины, называемые Спринтами. Они обычно занимают 1-2 недели (до 1 месяца). SCRUM команды стремятся создавать готовый к поставке (качественно протестированный) Инкремент продукта в каждой итерации».

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

Чем scrum-процесс не является

SCRUM — не линейный метод разработки; это не каскадная модель. Каскадная модель (Водопад — от англ. Waterfall) — линейная последовательность событий, когда продукт планируют, разрабатывают, тестируют и так далее. Ни один её этап нельзя начинать, пока не завершен предыдущий.

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

Зачем нужен скрам?

У SCRUM-фреймворка Aджайл-разработки четыре главных преимущества:

1. Отклик на потребности клиента. Компаниям-разработчикам программ слишком хорошо знакомо требование «разработать на вчера». Традиционные организации, которые работают по методу водопада, встраивают важные фичи и функции в расписание с двумя релизами в год — и в процессе нередко теряют клиентов. Если же клиенты не уходят, они всё равно могут остаться недовольными и уйти со временем, когда встретят более ответственного конкурента. Работая короткими и частыми циклами, вы можете предоставлять клиентам продукты почти по требованию и быстро адаптироваться к новым требованиям.
2. Снижение стоимости разработки. Aджайл и SCRUM доказали свою экономичность и эффективность. В этих моделях роли разработчиков более разнообразны, ведь небольшие единицы можно эффективно тестировать той самой командой, которая разработала их. Специализация исчезает или сокращается, в конечном счете сокращая издержки.
3. Удовольствие от работы. Поставляя продукты быстро, команда переживает дополнительную радость каждый раз, когда работа сделана и отправляется в мир. Каждая команда разработки знает, как приятен релиз. Со SCRUM команда радуется ему не два, а 12 раз в году, минимум.
4. Больше быстрых доходов. Средства от клиентов поступают не дважды в год, а гораздо чаще. Кроме того, новые фичи тоже можно добавлять не дважды в год, а гораздо чаще, таким образом приводя больше клиентов и быстрее обрабатывая их особые запросы.

Краткая история

После выхода исследования доктора Уинстона Ройса «Управление разработкой крупных программных систем» (Managing the Development of Large Software Systems) в 1970 году многие начали искать новый подход к разработке, который бы помог бороться с недостатками модели водопада, раскритикованной в статье.

Название «SCRUM» происходит из исследования Такеучи и Нонаки 1986 года «Новые правила разработки новых продуктов» (The New New Product Development Game). В этой работе говорится, что лучший способ достичь цели — предоставить точные планы небольшой команде.

В 1995 году Джефф Сазерленд и Кен Швабер привели SCRUM в систему в статье «Разработка программного обеспечения по SCRUM» (SCRUM Software Development Process).

Как работает структура scrum

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

Роли в скрам

В СКРАМ три роли, которые вместе образуют SCRUM команду:

• Владелец Продукта — апологет продукта, который полностью понимает его ценность для бизнеса. Этот человек доносит потребности кастомера/стейкхолдера до Команды разработки, но не отвечает за техническую сторону процесса. Владелец Продукта также отвечает за пользовательские истории и определяет их приоритетность.
• Команда разработки выполняет все технические задачи по разработке. Команда кроссфункциональна и отвечает за анализ, дизайн, программирование, тестирование, техническую коммуникацию и т. д. В этом она руководствуется пользовательскими историями и их приоритетностью.
• SCRUM-Мастер выступает фасилитатором работы СКРАМ команды. SCRUM-мастер помогает Владельцу Продукта и Команде разработки выполнять работу без препятствий и отвлекающих факторов. Вся коммуникация людей вне команды с Командой разработки проходит через SCRUM-Мастера. (Иногда СКРАМ команды взаимодействуют в формате SCRUMа SCRUMов, то есть собрания со SCRUM-мастерами каждой команды).  

Встречи в scrum

Есть четыре типа SCRUM-мероприятий:

• Планирование Спринта (Sprint Planning) — в нём участвуют все члены SCRUM команды. На этом мероприятии презентуют Продукт. Также каждый член команды может высказаться о том, что его интересует или беспокоит. В ходе встречи назначаются приоритеты и проводятся оценки сроков.
• Ежедневный СКРАМ (Daily Scrum) — SCRUM-мероприятия, которые проходят ежедневно во время спринтов. Они короткие (до 15 минут) и предназначены для того, чтобы спланировать дневное расписание Команды разработки. Здесь можно обсудить рабочие сложности или прояснить пользовательские истории. Встреча обязательна для Команды разработки в полном составе. SCRUM-мастер может на ней присутствовать.
• Обзор Спринта (Sprint Review)  — демонстрация действующего продукта, разработанного во время спринта. Это мероприятие проходит в конце спринта и предназначено в первую очередь для того, чтобы в подробностях показать достигнутое стейкхолдерам.
• Ретроспектива Спринта  (Sprint Retrospective) — это своего рода вскрытие, обсуждение того, как  команда справилась во время спринта и как можно повысить качество её работы в будущем.

Дополнительно к этим типам мероприятий иногда во время спринта команды могут проводить уточнение бэклога (Backlog Refinement) — обсуждать элементы бэклога и готовиться к следующему спринту. В рамках этой встречи можно обсудить приоритетность элементов и разделить элементы бэклога на более мелкие составляющие.

AРТЕФАКТЫ

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

Существует три основных/обязательных артефакта в СКРАМ — Бэклог Продукта, Бэклог Спринта и Инкремент. Они необходимы, чтобы поставлять программное обеспечение, которое будет ценным для ваших кастомеров. Есть и необязательные артефакты, которые, в прочем, могут облегчить жизнь вашей команде (например, Берн-даун чаты) и сам “контейнер” — Спринт.

Aртефакты Спринта и их компоненты включают:

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

• Инкремент — Инкремент представляет собой сумму всех элементов Бэклога Продукта, выполненных во время спринта, и ценность инкрементов всех предыдущих Спринтов. В конце спринта новый Инкремент должен быть «Готов», что означает его работоспособность и соответствие определению «Критериев Готовности» СКРАМ команды.

• Элемент Бэклога Продукта — элемент Бэклога Продукта, который нужно выполнить за итерацию спринта. Обычно разбивается на несколько меньших подзадач.
• Цель Спринта — то, что нужно сделать, чтобы выполнить элемент Бэклога Продукта.
• Берн-даун чат Спринта — работа, которая остается до полного выполнения задач спринта. Берн-даун чат может быть восходящим или нисходящим в зависимости от того, с чем команда сталкивается при выполнении задачи. Он служит не отчетом о продвижении команды, а методом преодоления трудностей и поддержания активности.
• Релиз Продукта/Берн-даун чат Продукта — его в конце каждого спринта обновляет СКРАМ-мастер. Горизонтальная ось соответствует спринтам, вертикальная — показывает, сколько работы (в начале каждого спринта) осталось до завершения проекта.  

Правила скрам-фреймворка

Роли, встречи и артефакты — основные правила SCRUM, но есть и другие, которые также добавляют процессу эффективности:

• СКРАМ команда состоит только из Владельца Продукта, SCRUM-мастера и Команды разработки.
• Все спринты должны быть одинаковыми по длине.
• Когда завершается один спринт, следующий начинается немедленно.
• Каждый спринт начинается с Планирования Спринта. Команда разработки каждое утро проводит Ежедневный SCRUM.
• В каждом спринте проводят Обзор Спринта, чтобы стейкхолдеры могли предоставить обратную связь.
• Дополнять Бэклог Спринта во время спринта — не лучшая практика.

Больше сведений по терминологии SCRUM вы сможете получить из глоссария SCRUM-терминологии (см. scrum.org).

Ограничения в скрам

SCRUM был разработан, чтобы усилить сотрудничество в проектах. Как следствие, среда, где сотрудничество не складывается, неидеальна для SCRUM. Например, Ежедневный SCRUM невозможен для некоторых членов международных команд. Если такая важная часть SCRUM, как ежедневное мероприятие, начинает раздражать, а не помогать, это знак того, что СКРАМ может не сработать.

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

ИСТОЧНИК

Источник: https://davtyan.pro/scrum-eto-effektivnoe-upravlenie-proektami/

Scrum: методика эффективного управления проектами

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

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

Это пособие станет настоящей библией для всех менеджеров проектов, руководителей и ИТ-специалистов, которые хотят справиться с недостатками классических систем управления проектами.

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

Основная характеристика Scrum — гибкость. Данный подход позволяет оперативно реагировать на изменения в требованиях заказчика и быстро адаптировать продукт к ним.

Планировать полезно. Слепо следовать плану — глупо.

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

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

Сделать половину — не сделать ничего.

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

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

Планируйте реальность, а не пустую мечту.

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

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

Не смешно? А здесь смешно: @ithumor

Источник: https://tproger.ru/books/scrum/