Метод управления проектами scrum: Мини-справочник и руководство по Scrum / Хабр

Методология 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 в методе понимаются: бэклоги продукта и спринта, продукт проекта с новой функциональностью. Каждый спринт своей целью имеет создание новой функциональности продукта, пусть незначительного продвижения, но которое станет очевидным и может быть предъявлено заказчику проекта и другим заинтересованным сторонам. Во внутренней среде цикла спринта команда действует автономно, сопровождаемая «совещаниями на бегу» и перемещениями стикеров на доске Скрам. Пример внешнего вида доски показан ниже.

Пример доски Скрам

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

Комментарии по заполнению ролей

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

Шаг 1 алгоритма методологии Скрам

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

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

Шаг 2 алгоритма методологии Скрам

Наиболее ценный методологический посыл шага 2, на мой взгляд, – «обвинять глупо». «Золотой стандарт» численности команды Скрам также принимается без возражений. Для определенного типа культуры команды проекта, например, адхократической или, в другой классификации, партиципативной, я вполне согласен с принципом автономности команды Скрам. Все остальные тезисы шага 2 универсальны и идентичны классическому проектному подходу.

Шаг 3 алгоритма методологии Скрам

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

1. Если «лидер – не босс», а скрам-мастер – «играющий тренер», тогда кто управляет командой Скрам? Самоуправление, на мой взгляд, не укладывается в концепцию проектного управления.
2. Возникает вопрос мотивации владельца продукта проекта, скрам-мастера и команды Скрам. В методике описан принцип открытости информации, включая доступа к финансовым данным проекта. Идея неплохая, но, учитывая Макиавеллевскую позицию, присутствующую во многих российских компаниях, у такой возможности среди руководителей, наверное, окажется много противников.

Вопрос формирования артефактов

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

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

Шаг 4 алгоритма методологии Скрам

Пятый шаг алгоритма Scrum не менее интересен. Совершенно не хочется погружаться в мистические аспекты чисел. Но у нас с вами есть рядовая прагматическая задача: наилучшим образом составить прогноз продолжительности выполнения работ проекта, используя самую объективную экспертную оценку. К сожалению, «гадание на кофейной гуще» по проставлению часов в MS Project – нет ничего более тоскливого и изнурительного даже с привлечением знающих экспертов. Могу с уверенностью заявить, что лучшего метода, чем «покер планирования» я в проектной практике не встречал. Метод широко известен, поэтому заострять на нем внимание не будем. Замечу лишь, что сочетание метода Дельфи и последовательности Фибоначчи дает поразительные результаты.

Пример пасьянса метода «Покера планирования»

Причин для того, чтобы рассматривать метод Скрам не как тюнинг современной доктрины PM, а как поистине революционный метод управления проектами несколько. Одна из них – это отношение к описанию работы по выполнению проектного задания с позиции историй, что противоположно процессуальному подходу Д. Чампи и М. Хаммера. Люди действительно мыслят образами. С одной стороны, трудно согласиться с тем, что можно не бояться потерять однозначность трактовки результата работы. С другой стороны, если отвлечься от задачного давления и взглянуть на вопрос с позиции подлинной ориентации на клиента проекта, «мягкие» истории могут дать больше для получения нужных результатов заданий.

Шаг 5 алгоритма методологии Скрам

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

Шаг 6 алгоритма методологии Скрам

Вопросы активных действий в ходе процесса

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

Шаг 7 алгоритма методологии Скрам

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

Шаг 8 алгоритма методологии Скрам

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

Шаг 9 алгоритма методологии Скрам

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

Шаг 10 алгоритма методологии Скрам

Скрам как код антицинизма

Мне импонирует представленная в подзаголовке метафора. Она принадлежит Джеффу Сазерленду, и в ней чувствуется глубокое переживание цинизма как значительного порока современного бизнеса. В целом позиция автора метода Скрам, безусловно, искренняя. Это подкупает. И, в принципе, совсем неплохо, что Сазерленд вводит в управленческий контекст компонент счастья. Подобное делается так по-американски. Вместе с тем, хотелось бы разобраться, почему слово «счастье», и все, что с ним связано в рассматриваемой революционной проектной доктрине, вызывает внутренний дискомфорт. Только ли это субъективно-личностное восприятие, или это некоторый общий культурологический взгляд на предлагаемый подход?

Мы с вами, скорее всего, помним, что происходило в России в конце 90-х – начале 2000-х годов. В страну буквально хлынули «новоявленные нуворишы» со всех уголков мира, и в основном из США, вещающие «правду» о личной и корпоративной успешности. Надо честно сказать, что подобные «откровения» не прошли бесследно, многие бизнесмены взяли на вооружение ключевые аспекты привезенных с Запада теорий управления. Я специально не называю тренинговые курсы, авторские теории и именитые школы. Кто с ними сталкивался, поймут.

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

Происходит быстрое отрезвление и на уровне государства, и на уровне деловых людей. И они начинают понимать, что некоторые привносимые решения, способы ведения бизнеса, построения отношений с персоналом не просто полезны, они служили враждебным и разрушающим целям, приводящим к ломке нашей национальной культуры, в том числе культуре хозяйствования. Я приведу один единственный пример противопоставления двух идеологем: «Разделяй и властвуй!» и «Купеческое слово дороже договора!».

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

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

Зачем Нужен Метод Управления Проектами 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 на практике.

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

Scrum — современный метод управления проектами | Блог издательства «Манн, Иванов и Фербер»

Ирина Балманжи

Традиционные способы управления безнадежно устарели. Можно смириться с тем, к чему мы привыкли, и продолжать впустую растрачивать время и силы. А можно перейти на революционный метод, предложенный Джеффом Сазерлендом. В своей книге «Scrum» он подробно рассказывает об идеях, которые уже помогли наладить рабочий процесс в Microsoft, Morning Star, Google, Amazon и ФБР. Вот несколько из них.

Что точно не сработает

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

Источник

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

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

Командная работа

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

Источник

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

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

Команда моей мечты

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

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

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

Вот как описал это участник проектной группы компании Fuji-Xerox: «Когда все члены команды находятся в одной комнате, то вам дана возможность без всяких усилий пользоваться знаниями, которыми владеют коллеги. Тогда вы начинаете мыслить совсем другими категориями. Вас волнует работа не только в том случае, когда она касается непосредственно ваших интересов, нет, вы думаете, что пойдет на пользу всей группе и общему делу».

Оптимальный размер рабочей группы

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

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

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

Источник

Инструменты Scrum

Спринты  и собрания на ходу — два важнейших инструмента методики Scrum.

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

Перед каждым спринтом члены команды будут  наклеивать в колонку «Бэклог» стикеры с задачами, которые могут выполнить за неделю. Когда кто-то из команды возьмется за какую-либо задачу, он переклеит стикер в колонку «В работе». А потом стикер переместится в колонку «Сделано».

Источник

Собрания на ходу — ежедневные короткие (максимум на 15 минут) встречи, на которых каждый участник группы отвечает на три вопроса: «Что я делал вчера, чтобы помочь команде завершить спринт? Что я буду делать сегодня, чтобы помочь команде завершить спринт? Какие препятствия встают на пути команды?» Задача этих встреч в том, чтобы вся группа была в курсе, кто чем занимается, и вовремя могла скорректировать работу.

Как Scrum меняет мир

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

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

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

— Учитель химии из маленького городка Алфен-ан-ден-Рейн рискнул пойти наперекор традиционному методу преподавания и применить Scrum. За один год успеваемость его учеников повысилась на 10 процентов.

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

По материалам книги «Scrum»

P.S.: Подписывайтесь на нашу рассылку. Раз в две недели мы будем присылать вам 10 лучших материалов из блога.

Основные заблуждения о SCRUM / Хабр

SCRUM? Какой SCRUM?

Впервые подход SCRUM (англ. scrum «схватка вокруг мяча») описали Хиротака Такэути и Икудзиро Нонака, которые заметили, что небольшие команды (5 — 9 человек), укомплектованные разнопрофильными специалистами, дают лучшие результаты. Наиболее полное описание SCRUM впервые представил в своей книге Джефф Сазерланд. Книга так и называется — SCRUM. Джефф начинал свою карьеру как военный летчик, во время войны во Вьетнаме выполнивший более ста боевых вылетов. Затем Джефф занимался наукой, но мир его запомнит как одного из родоначальников SCRUM. Книга начинается с реальной истории из жизни ФБР, тратившего миллионы долларов на разработку автоматизированной системы, предназначенной для поиска и отслеживания преступников. Проблема заключалась в том, что по истечении сроков проекта подрядчики демонстрировали ФБР абсолютно нерабочий продукт. Это означало лишь одно — американские налогоплательщики потратили миллионы впустую. Ситуация казалась безвыходной до тех пор, пока руководство ФБР не обратилось к тогда еще зарождавшемуся методу управления проектами SCRUM. Этот метод описан доступным языком в вышеупомянутой книге, которая, кстати, переведена на русский язык. Далее в статье рассмотрены основные заблуждения и мифы, которые могут отпугнуть топ менеджеров, задумавших внедрить SCRUM в свои проекты.

1. Тотальный контроль, который убивает творческий подход

В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство. Такой метод мотивирует и стимулирует творческий подход, в отличие от классического менеджмента, где сотрудникам делегируют выполнение конкретных низкоуровневых действий, а те, в cвою очередь, часто даже не понимают, для чего это и как это повлияет на проект в целом. Таким образом, в SCRUM руководство не контролирует действия проектной команды, а та, в свою очередь, отчитывается только о результатах в конце каждого спринта (установленного заранее промежутка времени, например, 2 недели). Прозрачность существует только среди членов проектной команды. В чем она она проявляется? В первую очередь, ежедневные stand-up митинги, на которых каждый участник проектной команды рассказывает, что он сделал вчера, что сделает сегодня, какие проблемы у него возникли. Такая практика не преследует цели проконтролировать объем работ, выполненный каждым сотрудником. Stand-up митинги предназначены для того, чтобы помочь каждому члену команды устранить препятствия в работе и посвятить коллег в свои планы, чтобы каждый понимал куда движется проект сегодня и осознавал свою роль в развитии продукта. Для этих же целей, кстати, служит общая SCRUM доска со стикерами, которую может посмотреть каждый, и опенспейсы, которые уничтожают препятствия для свободного общения членов команды.

2. SCRUM лишает прав самых опытных инженеров, потому что они подчиняются решению команды

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

3. SCRUM нацелен на краткосрочные ценности бизнеса, а не на долгосрочное развитие проекта

Данная проблема, действительно, актуальна. К счастью, на вопрос «Что же делать?» есть ответы. Следует начать с того, что если проект не долгоиграющий, с продолжительностью не более полугода, то данная проблема скорее всего не всплывет. Другое дело, когда софт развивается 2-3 и более лет. Существует множество статей, в которых авторы изливают свою боль касаемо таких проектов. Армия джунов и мидлов (синеры, как известно, стоят дорого и их мало) уверенно коммитит в master своё творчество, а заказчик спринт за спринтом пожинает блестящие результаты SCRUM. Но вот незадача, через 5-10 спринтов добавлять новые фичи становится проблематично, и чем дальше, тем сложнее. Следовательно, SCRUM — это хорошо, но о стратегии и об архитектуре задумываться надо. Предотвратить подобную ситуацию можно. Во-первых, на проекте должны работать как минимум 1-2 как можно больше опытных инженеров, которые будут пропускать через себя все коммиты в репозиторий во время code review. Во-вторых, уделять много времени обучению (не менее 3 часов в неделю) младших и средних инженеров архитектуре ПО, паттернам проектирования и тому, как это накладывается на существующий проект. Такие занятия должны сопровождаться практикой и минимальным домашним заданием для лучшего усвоения. Выполнение практических заданий можно встраивать в backlog проектных спринтов. Это не сильно ударит по рентабельности проекта, зато ускорит процесс роста сотрудников и предотвратит потенциальные проблемы с архитектурой ПО. Проведение периодических meetup-ов позволит проектным командам перенимать опыт друг у друга, что не навредит качеству выпускаемого софта.

4. SCRUM не дает развиваться инженерам

SCRUM предполагает, что все решения, касаемые способа достижения бизнес-целей делегируются команде. Владелец продукта решает, что нужно сделать, а команда решает — как. Из этого вытекает, что команда должна быть достаточно компетентной, чтобы принимать эффективные решения. Таким образом, краеугольным камнем методологии SCRUM является обучение. Вот почему во всех крупнейших банках и IT аутсорсерах так много внимания уделяется развитию: тренингам, семинарам, курсам. Профессиональный рост сотрудников — это неотъемлемая составная часть SCRUM. За счет того, что SCRUM команды относительно маленькие, членам команды приходится осваивать весь стек технологий в рамках проекта, над которым они работают. По окончании проекта инженер получает новые навыки, что увеличивает его стоимость на рынке труда.

Промежуточный итог

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

1. Джефф Сазерленд // SCRUM 2017.

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

запись вебинара

 1ч. 40 мин.

статья

 10 мин.

Экономия времени

 1ч. 30 мин.

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

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

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

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

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

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 — гибко менять список задач во время разработки, не делать лишнего и не получать тысячи правок после завершения проекта, как в каскадной методологии разработки.

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

• Trello — подходит для маленьких проектов, быстро и удобно.
• Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
• Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.

• Научиться вести бэклог и расставлять приоритеты.
• Проводить спринты.
• Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
• Контролировать работу с помощью диаграммы сгорания проекта.
• Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
• После каждого спринта демонстрировать проект.
• Изучить инструменты и найти самый удобный.

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

Курс «Руководитель digital-проектов»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Почему вам обязательно нужно узнать, что такое Scrum

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

Scrum («скрам») — практическое воплощение Agile-принципов. Это подход, позволяющий, по словам его создателя Джеффа Сазерленда (Jeff Sutherland), делать в два раза больше за вдвое меньшее время.

Вы, вероятно, хотели бы знать больше об Agile и Scrum, чтобы быть в теме. Мир IT уже невозможно представить без Agile, и эта «зараза» стремительно распространяется на традиционные офлайновые бизнесы.

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

Scrum появился около 20 лет назад как эффективный метод увеличения продуктивности при разработке программного обеспечения. Завоевав популярность в Кремниевой долине, Scrum быстро получил признание в других отраслях бизнеса. Его создатели Кен Швабер (Ken Schwaber) и Джефф Сазерленд изучили передовой мировой опыт успешных компаний и пришли к выводу, что «водопадная» модель, по которой прежде строилась работа над IT-проектами, безнадёжно устарела. Она не отвечала ожиданиям клиентов, поскольку работа продвигалась медленно, в строгом соответствии с долгосрочным планом, и часто на выходе получался не тот продукт, который на самом деле был нужен.

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

Познакомьтесь с ключевыми принципами Scrum, и, возможно, тема заинтересует вас настолько, что не прочитать книжку Сазерленда вы уже не сможете.

Люди важнее процессов

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

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

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

Продукт важнее документации

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

Scrum — это про смысл, а не про создание максимума бумажек ради создания максимума бумажек.

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

Сотрудничество с клиентом важнее идеально составленного контракта

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

Scrum — это про понимание и сотрудничество, а не про юристов и прикрывание мягкого места.

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

Способность меняться важнее следования планам

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

Scrum — это про науку и смысл, а не про веру и необоснованные надежды.

Как же быть? По Scrum, вы должны иметь большую цель, но идти к ней итеративно, не пытаясь предугадать каждый свой шаг в далёком будущем. Небольшими итерациями по 2–4 недели двигайтесь к цели, оборачивайтесь назад, делайте ретроспективу, оценивайте сделанное, отказывайтесь от результата последней итерации, если он не приближает вас к цели. Таким образом можно избежать глупых больших провалов. Итеративность — это научный подход. Надежды на правильность больших планов — это, скорее, похоже на религию.

Должности и титулы не важны — важно то, что вы делаете

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

Scrum — это про доверие, а не про силу и насилие.

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

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

Итак, узнать досконально всё о Scrum можно из книги его создателя Джеффа Сазерленда. В качестве альтернативы можно за 20–30 минут прочитать саммари этой книги в электронной библиотеке Smart Reading.

Читать на Smart Reading

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

Гибкая методология Scrum

Scrum представляет собой гибкую методологию управления проектами. Придумали её ещё во второй половине восьмидесятых, но настоящую популярность Scrum обрела в конце двухтысячных. Чем гибкие методики отличаются от остальных, и работает ли это?

Гибкие методологии

Начать стоит с самого происхождения Agile-методологий. Начало им положил «Манифест гибкой методологии разработки программного обеспечения» в 2001-м году. Agile — в переводе с английского «гибкий». Вот основные принципы Манифеста:

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

В основе таких методологий лежит итеративный подход: когда разработка ведётся циклами (итерациями). После каждого цикла определяются планы по изменению продукта на следующий.

Различные гибкие методики существовали и до выпуска Манифеста. Как следует из его названия, применялись они в разработке ПО, и долгое время никто не пробовал использовать их в других сферах. Некоторые из гибких методологий, которые использовались до 2001-го года:

• DSDM с начала 90-х,
• FDD с 97-го,
• Kanban ещё с 60-х годов, однако эта методология использовала лишь часть приёмов от гибких методик.

Srum тоже был разработан во второй половине 80-х годов прошлого века.

История Scrum

Впервые слово «Скрам» не в контексте регби (там этот термин обозначает позицию игроков, борющихся за мяч в плотном скоплении), а в контексте разработки использовали Хиротака Такеучи и Нонака Икуджир в статье в 1986-м году. Там учёные описывали новый гибкий геймификационный подход к разработке коммерческого продукта, позволяющий выполнять работу в быстрые сроки. Команда разработчиков сравнивалась с командой в регби: действует во время «Скрама», как единый организм, для достижения общей цели.

Статью заметил Джефф Сазерленд, бывший военный лётчик США, занимающийся поиском новых подходов к разработке ПО. В это же время Кен Швабер, тоже разработчик, также искал новые подходы для оптимизации своей деятельности. В 1995-м году Сазерленд и Швабер объединяются и создают документ, отражающий основы методологии Scrum. В 2001-м они участвуют в создании Манифеста Agile.

В этом же году создаётся Scrum Alliance. Его миссия: направлять лидеров, компании и людей в целом на создание правильной организации рабочего процесса — «Transform the World of Work». Альянс существует и сегодня и занимается внедрением методологии Scrum.

На чём базируется Scrum

Основные принципы организации рабочего процесса в Scrum во многом являются эталоном и совпадают с другими Agile-методологиями.

• Работа над проектом состоит из спринтов (итераций), длина которых две–четыре недели. В течение спринта необходимо выполнить заданный заранее объём работ. Обычно это либо новая функциональность продукта, либо готовый продукт в целом, который в ходе следующих спринтов улучшается. Нельзя менять задачи в ходе спринта, спринт можно остановить только в исключительных ситуациях.
• Численность команды: четыре–десять человек. Такое ограничение обеспечивает максимальную производительность и сводит к минимуму отвлечения от работы и разговоры. Команда должна содержать всех необходимых для создания продукта специалистов.
• Задачи спринта излагаются в Product Backlog. Product Backlog составляется из пожеланий пользователей (user stories) — то, что заказчик или потребитель желает видеть в проекте.
• Каждый спринт начинается с планирования — на нём обсуждается, какие задачи нужно будет выполнить, завершается ретроспективой — оценка эффективности команды. Каждый день проходят 15-минутные собрания — члены команды, обязательно стоя, обсуждают: что удалось сделать вчера, что нужно сделать сегодня и что может этому препятствовать.
• Отсутствие многозадачности. Единовременно команда работает только над одной задачей.
• Помимо команды разработчиков обязательно присутствуют ещё две роли. Scrum-мастер, который следит за соблюдением принципов Scrum и убирает препятствия для эффективной работы, и Product Owner. Он взаимодействует с заказчиком и передаёт его требования команде.

Доска и Диаграмма сгорания задач

Отдельно стоит поговорить о методах визуализации работы, используемых в Scrum и некоторых других Agile-методиках. Две главных из них: Burndown Chart и Desk.

Burndown Chart — Диаграмма сгорания задач. Такая диаграмма отображает процесс работы над проектом. По ней легко отследить, насколько команда приблизилась к выполнению задачи. По горизонтали откладывается время: остаток дней до конца стрима. По вертикали — количество подзадач, человеко-часов или Story Points — единиц измерения работы. График Диаграммы сгорания стремится вниз, от первого дня к последнему, от максимального количества подзадач/человеко-часов к их отсутствию. Отдельным цветом изображается идеальный график — прямая: когда за каждый день выполняется одинаковый объём работы, что в итоге приводит к равномерной нагрузке и выполнению цели в срок. Плохим результатом на Диаграмме сгорания будет не только возвышение реального графика над идеальным. Если команда выполнила весь объём работ на несколько дней раньше, значит неправильно был определён размер итерации либо поставлена слишком маленькая или простая задача.

Другой, более простой инструмент: Desk. Диаграмма сгорания визуализирует эффективность команды, а Доска помогает работникам ориентироваться в текущих заданиях. Это таблица, состоящая из трёх или более столбцов: запланировано, выполняется, готово. В некоторых случаях добавляется столбец Stories, где могут отображаться истории пользователей — не только на текущий спринт, но и на следующие. По этим колонкам расклеиваются стикеры, на которых кратко изложена суть подзадачи: нарисовать эскиз, протестировать код, добавить кнопку на сайт. Стикеры постепенно переходят из «запланировано» в «выполняется», а из «выполняется» в «выполнено». Таким образом становится моментально ясно, что уже сделано, а что ещё в процессе, о каких делах сотрудники забывают.

Два этих способа визуализации обязательны в Scrum. Burndown chart и Desk — статистика и мотивация для команды. Однако применять такие инструменты можно и без перехода к гибким методикам: они отлично покажут эффективность любого рабочего коллектива.

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

Где применяется Scrum

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

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

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

Scrum и крупные компании

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

Легко ли внедрять Scrum в большие компании? Гибкая методология требует полного изменения рабочего процесса, а далеко не все сотрудники будут к такому готовы. Как правило, легче всего вводить «Скрам» постепенно, набирая работников, которые заинтересованы в проекте, желают изменить привычный график. Точно не стоит сразу переводить на новый режим работы всю компанию целиком.

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

Оценка Scrum

Scrum существует уже достаточно долго и за это время приобрела много сторонников и немало противников.

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

• Быстрое удовлетворение большинства требований заказчика или клиентов.
• Высокая конкурентоспособность продукта за счёт его постоянной оптимизации.
• Большая эффективность рабочей команды: каждый сотрудник постоянно занят своим делом, не тратит время на лишние разговоры, при этом постоянно взаимодействует с коллегами и через Product Owner с заказчиками.
• Готовый продукт производится в быстрые сроки.
• Экономия на менеджерах, так как команда управляется изнутри только Scrum-мастером, а извне лишь получает требования к продукту от заказчика.

Недостатки

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

Дэйв Томас, один из авторов Манифеста, считает, что Agile-методологии так и не получили воплощения. Вместо этого были придуманы наборы жёстких правил (как в Scrum), а слово «Agile» превратилось в бессмысленный маркетинговый термин.

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

Обучение Scrum

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

1. «Scrum. Революционный метод управления проектами» Джеффа Сазерленда.

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

2. «Софт за 30 дней» Джеффа Сазерленда.

Эта книга также написана Джеффом Сазерлендом совместно с Кеном Швабером — другим создателем Scrum. В книге описывается процесс быстрой разработки программного обеспечения на основе методики, а дополнение Scrum Guide описывает все роли, артефакты, процессы.

3. «Scrum и XP: заметки с передовой», Хенрик Книберг. 

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

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

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

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

1. JIRA. Это приложение позволяет с удобством управлять проектами разной величины. Применяет шаблоны не только Scrum, но и Kanban. Доступно на мобильных устройствах, отправляет e-mail-уведомления и обладает ещё рядом полезных функций. Для Open Source проектов JIRA бесплатна.
2. Version One. Платформа для организации деятельности при различных Agile- и DevOps-методологиях. Визуализирует рабочие процессы, планирует спринты и релизы. Присутствуют Доска, Диаграмма сгорания и другие средства визуализации. Позволяет команде или командам коммуницировать между собой. Version One была первой программой, выпущенной для гибких методик, и до сих пор остаётся одной из лучших.
3. Taskify.us. Это интерактивный вариант Доски. Довольно простое приложение, которое, тем не менее, отлично выполняет свои функции.
4. Trello. Ещё одна интерактивная Доска, но с гораздо большими возможностями. Базовый вариант программы включает обычный Desk с карточками, в которых задача может быть очень подробно расписана. При потребности можно подключить дополнительные опции: календарь, голосование, «старение» карточек.
5. SprintGround. Таск-менеджер, оптимизированный под Agile-методики. Распределяет задачи, выводит информацию об эффективности команды на графиках, позволяет получать User stories.

Scrum 101: Введение в управление проектами Scrum

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

Что такое управление проектами Scrum?

Scrum — это Agile, но Agile — это , а не Scrum.Вы часто слышите термины «Scrum» и «Agile», используемые вместе, и из-за этого их значения понимаются неправильно.

Разница между Scrum и Agile:

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

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

Краткая временная шкала История Scrum :

• 1986: Хиротака Такеучи и Икудзиро Нонака ввели термин «Scrum» в контексте разработки продукта в статье Harvard Business Review «Игра по разработке новых продуктов». .
• 1990-е: Кен Швабер и Джефф Сазерленд по отдельности использовали аналогичные подходы в своих компаниях.
• 1995: Швабер и Сазерленд представили доклад на семинаре по проектированию и реализации бизнес-объектов, который был частью объектно-ориентированного программирования, систем, языков и приложений ’95 в Остине, штат Техас, известного нам скрама. Cегодня.
• 2001: Швабер работал с Майком Бидлом, чтобы объяснить метод в книге «Гибкая разработка программного обеспечения с помощью Scrum».
• 2009: После создания и ухода из Scrum Alliance, Швабер основал Scrum.org, который управляет параллельной серией профессиональной аккредитации Scrum.
• 2010: Руководство по Scrum создано Швабером и Сазерлендом, часто пересматриваемый публичный документ, который определяет Scrum.

Ценности управления проектами Scrum

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

Пять ценностей Scrum:

1. Приверженность
2. Смелость
3. Фокус
4. Открытость
5. Уважение

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

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

Команда Scrum

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

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

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

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

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

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

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

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

Scrum Master

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

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

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

Получите вам команду управления проектами Scrum, которая рада вас видеть!

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

События управления проектами Scrum

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

Sprint

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

Планирование спринта

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

1. Чего можно достичь в конце этого предстоящего спринта?
2. Как мы собираемся этого добиться и какие действия необходимы для этого?

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

Ежедневный Скрам

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

Обзор спринта

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

Ретроспектива спринта

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

Есть еще два действия, которые, хотя и не являются ключевыми для управления проектами Scrum, происходят достаточно часто, чтобы их стоило упомянуть.

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

Артефакты Scrum

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

Бэклог продукта

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

Бэклог спринта

Бэклог спринта перечисляет задачи и требования, которые команда должна выполнить во время следующего спринта. Это актив команды разработчиков, который иногда сопровождается доской задач Scrum. Доска задач Scrum используется для визуализации хода выполнения задач в текущем спринте и любых внесенных изменений в формате «To Do, Doing, and Done» — аналогично Zenkit’s Kanban board feature layout .

Управление проектами Scrum в действии

User Story

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

В качестве [роли] мне нужна [функция], потому что [причина].

Прирост продукта

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

Как управлять проектом Scrum

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

Для команд управления проектами Scrum с рассредоточенными участниками или для команд, которые хотят обновить свои инструменты, использование веб-инструмента управления проектами (например, Zenkit!) Может быть более идеальным способом управления проектом. Программное обеспечение включает в себя функции, которые позволяют централизовать деятельность и беспрепятственно осуществлять межгрупповую совместную работу. Гибкость в координации задач и доступ к информации о ходе выполнения могут улучшить совместную работу команды и предложить более оптимизированную доставку.

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

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

Cheers,

Динни и команда Zenkit

Была ли эта статья полезной? Пожалуйста, оцените это! [Всего: 11 Среднее: 4,5 / 5].Руководство

для новичков по управлению проектами Scrum 101

«Скрам» — феноменальная тема, если вы с ней знакомы. Как менеджер проекта Agile, я видел свою долю так называемых «Scrum Masters» и «Agile Experts», утверждающих, что они мастера своего дела. Однако правда в том, что они многого не знают о Scrum Project Management и Agile. На самом деле, я был удивлен, что некоторые из «экспертов» даже не знали, что Скрам-мастер и Владелец продукта — не одно и то же.

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

Источник видео — DevelopmentThatPays.com

Scrum Project Management — это структура, основанная на методологии управления проектами Agile. Термин Agile относится к способу управления проектами, который включает в себя постоянное улучшение, гибкость масштабов, участие команды и предоставление важнейших качественных продуктов.

Некоторые из его подходов, кроме Scrum , включают Extreme Programming (XP) для качественного предварительного строительства, Lean для устранения отходов и Agile Unified Process (AUP) подход к разработке бизнес-приложений программное обеспечение с использованием гибких методов.

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

Введение — Почему Scrum Project Management?

Разработанная Кеном Швабером и Джеффом Сазерлендом в начале 1990-х годов, Scrum Project Management предоставляет упрощенную структуру процессов, которая включает в себя итерационные и инкрементные практики.Это способствует более быстрой доставке и более частому выпуску программного обеспечения организациями. Цикл проекта включает в себя набор повторений, называемых спринтами, где в конце каждого спринта команда проекта выпускает улучшенный, проверенный и потенциально поставляемый продукт.

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

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

Из чего состоит Scrum?

Scrum состоит из сахара, специй и секретного ингредиента, из которого сделаны Power Puff Girls! Просто шучу.Есть три основных компонента, но ни один из них не похож на вышеупомянутый. Читайте дальше…

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

• Владелец продукта
• Команда разработчиков и
• мастер Scrum.

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

Это означает, что Владелец продукта должен:

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

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

Подробнее:

Канбан против Scrum: какой подход лучше использовать в 2020 году?

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

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

Служба Скрам-мастера Владельцу продукта: Скрам-мастер может помочь Владельцу продукта следующими способами:

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

Служба Scrum Master для команды разработчиков: Scrum Master может принести пользу команде разработчиков:

• Обучение команды разработчиков самодисциплине и кросс-функциональности
• Минимизация препятствий для команды разработчиков и максимизация ценности

Служба Scrum Master для Организации: Организация нуждается в Scrum Master для:

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

События:

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

В первую очередь, Scrum состоит из 4 формальных событий или фаз для обзора и адаптации:

• Планирование спринта
• Ежедневный Scrum
• Обзор спринта и
• Ретроспектива спринта.

Спринт, который является основным видом деятельности в Scrum, представляет собой период времени от 1 до 4 недель. В среднем спринт длится 2 недели.

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

Daily Scrum или Daily Standup: Ежедневный Scrum — это примерно 15-минутное ежедневное мероприятие, посвященное деятельности команды. Каждый член команды делится работой, проделанной днем ​​ранее, работой, проделанной за день, а затем выявляет любые проблемы. Цель этого ежедневного собрания — убедиться, что все члены команды находятся на одной странице и их действия синхронизированы.

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

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

Также прочтите:

4 причины, почему вам нужно программное обеспечение для управления проблемами

Артефакты:

Scrum Project Management опирается на 3 основных артефакта, которые помогают сосредоточиться на доставляемости и ценность бизнеса.Это:

• Журнал невыполненных работ по продукту : Журнал невыполненных работ по продукту представляет собой список функций, которые необходимо включить в результат. Владелец продукта расставляет приоритеты, чтобы команда могла сосредоточиться на самых высоких требованиях. Это исключает путаницу или трату времени на ненужные элементы.
• Журнал спринта : Журнал спринта также представляет собой список приоритетных функций или действий, которые необходимо выполнить во время соответствующего спринта.
• Приращение : Приращение относится к проверяемой, проверенной работе, выполненной в конце спринта. Он обозначает все завершенные элементы бэклога продукта в сочетании со значением приращений всех предыдущих спринтов. В конце каждого спринта новое Приращение должно быть «Выполнено» в соответствии с определением Скрам-команды. Разные команды Scrum могут по-разному определять «Готово» в зависимости от того, какие элементы необходимо выполнить. Чтобы обеспечить прозрачность всего проекта, каждая команда должна понимать тип и степень, в которой задачи должны быть выполнены.

1. Примеры из отрасли

1.2. Scrum в Intel История началась с «маленькой проблемы»

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

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

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

1.3. Путешествие

Изначально в нем участвовало 6 команд с их многочисленными подгруппами. CollabNet использовался для обучения и тренинга Scrum. Около 20 руководителей групп и технических руководителей присоединились к 2-дневному тренингу для сертифицированных Scrum Master. Он состоял из введения в принципы и практики Scrum.

После тренинга была проведена ретроспективная встреча в отсутствие представителей Collabnet. Участники встречи обсудили свои идеи и оговорки относительно принятия структуры Scrum. В итоге участники согласились опробовать подход Scrum в течение 3 месяцев. Группа действий по процессу (PAT) была создана для мониторинга развития Scrum. Несмотря на соглашение, между группами уже возникло чувство разлада.

Примерно через 5 месяцев масштабирование работы в Scrum-командах превратилось в огромную проблему.Организация не знала, как управлять зависимостями между несколькими командами и улучшить взаимодействие между ними. Еще один курс был проведен CollabNet, в котором основное внимание уделялось основным принципам планирования спринтов, планирования выпуска и масштабирования между несколькими командами. Изучив еще несколько лучших практик, добавив больше ролей для решения технических проблем и больше уровней организации, в течение года было создано 12 Scrum-команд, в каждой из которых было от 5 до 9 разработчиков, в течение года.

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

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

1.4. Успех

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

Сокращение времени цикла: Scrum внес основной вклад в сокращение времени цикла на 66 процентов.

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

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

Повышенная прозрачность: принят официальный стандарт. Выявлены проблемы и слабые практики.

Scrum внес большой вклад в последовательное, повторяемое сокращение времени цикла на 66% при создании нашего рабочего продукта.

1.5 Резюме

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

2.2. Михайловская школа

2.2.1. Проблема

В 2013 году сотрудники СПб.Michael’s School искали способы улучшить отношения между местным сообществом и учениками в возрасте от 12 до 15 лет. Школа расположена в нескольких милях от Вулверхэмптона в Центральной Англии. Идея заключалась в том, чтобы заставить студентов разработать приложение, более эффективное взаимодействие между подростками и полицией; и особенно в снижении уровня преступности.

Они слышали о Ройле и его инициативе Scrummy School. По словам Ройла, концепция Scrummy School была разработана в Белградском университете в сотрудничестве с Ясминой Николич.Она является пионером в использовании Scrum, Kanban и Open Space в различных контекстах, особенно в образовании, и это было ее оригинальным подходом к использованию Scrum в образовании.

Ройл хотел опробовать эту инициативу в школе, поэтому он и Уэйн Хилл, заместитель главы Сент-Майклс, решили попробовать.

2.2.2. Путешествие

История началась с обращения к местной полицейской службе — полиции Западной Мерсии и полицейскому констеблю (ПК) Хьюи Треже, сотруднику по связям с общественностью.К счастью, при поддержке PC Treasure эксперимент начался.

Состоялось собрание Open Space среди полицейских, студентов и сотрудников университета для выработки идей. План был разработан дальше. Ройл решил использовать «быструю версию» Скрама, чтобы лучше соответствовать структурированному и разнообразному школьному дню. Было 5 спринтов по 20 минут. После первого спринта ученики смогли сами справиться с остальными. Наконец, были разработаны приложение и бумажный прототип с презентацией для полиции.

Принимая во внимание ограниченные сроки и разнообразные навыки, Ройл чувствовал, что Scrum будет особенно полезен для данного проекта. Более того, это может предложить студентам среду для самостоятельной работы в командах, что позволит им почувствовать себя более связанными с проектом. Как объяснил Ройл: «Использование философии Agile обучения в Scrum направлено на развитие того, что могут делать члены команды, а не того, чего они не могут», — говорит он. «Вместо того, чтобы оценивать то, что дети не могут делать, структура Scrum дает им возможность использовать присущие им способности и развивать новые навыки в безопасной среде.”

2.2.3. Успех

Вот некоторые из заслуживающих упоминания преимуществ, которые принес этот эксперимент:

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

2.2.4. Резюме

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

2.3. Швейцарская строительная компания

2.3.1. Проблема

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

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

2.3.2. Путешествие

В исследовательской работе «Внедрение Scrum в строительной индустрии» было изучено использование Scrum для строительства здания.В рамках проекта было построено 3 четырехэтажных многоквартирных дома для швейцарского рынка с общей площадью 2 100 м ² , разделенных на 11 квартир и 200 м ² коммерческих площадей. Scrum был реализован на этапе проектирования текущего проекта, при этом проектирование, проектирование и производство выполнялись в Эстонии. Затем сборные деревянные модули пришлось перевезти в Швейцарию.

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

2.3.3. Успех

Результаты этого исследования подчеркнули потенциал Scrum следующим образом:

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

3. Другие варианты использования и приложения для Scrum

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

3.1. Пример использования 1: веб-разработка

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

Участники:

Владелец продукта: руководитель группы

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

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

Базовый поток событий:

1. Веб-сайт необходимо обновлять в разных категориях.
2. Команде разработчиков необходимо делегировать задачи и сроки.

Использование Scrum:

1. Владелец продукта создает бэклог, то есть приоритетные изменения, которые необходимо внести.
2. Создана команда разработчиков и команда QA.
3. Спринт 7 дней решен.
4. Скрам-мастер назначается для облегчения встреч и решения проблем.
5. Задачи назначены команде
6. Ежедневный 15-минутный Scrum настроен для проведения встреч команды
7. Каждый член команды для обеих команд подтверждает, что задачи выполнены, и те, которые находятся в стадии разработки
8. Веб-сайт обновляется каждый день с работа выполнена
9. QA уведомляет о проблемах в тот же день.
10. Каждую неделю проводится встреча по обзору спринта с генеральным директором для получения последней информации о ходе работы.

3.2. Вариант использования 2: Разработка игры

Постановка проблемы: клиент требует, чтобы игра была разработана с нуля.

Участники:

Владелец продукта: Руководитель группы

Команда разработчиков: Программисты

Мастер Scrum: Координатор проекта

Базовый поток событий:

1. Объем проекта должен быть определен в срок и бюджет.
2. Команде разработчиков и команде QA необходимо делегировать задачи и сроки.

Использование Scrum :

1. Владелец продукта создает бэклог, то есть требования и наиболее важные функции для работы и платформу.
2. Создана команда разработчиков и команда QA.
3. Еженедельный спринт решен.
4. Задачи назначены командам
5. Ежедневный 15-минутный Scrum настроен для проведения встреч команд, на которых каждый член команды для обеих команд повторяет, что задачи выполнены и находятся в стадии разработки
6. Скрам-мастер координирует выполнение задач между командами делается.
7. Программисты предоставляют ежедневное обновление Scrum.
8. QA уведомляет о проблемах в тот же день.
9. Еженедельная встреча спринта проводится для закрепления успешных практик и устранения неудачных.
10. Владелец продукта, мастер схватки и команда разработчиков организуют представление клиенту ежемесячного обзора спринта.

3.3. Пример использования 3: Тестирование программного обеспечения

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

Участники:

Владелец продукта: руководитель группы контроля качества

Команда разработчиков: тестировщики контроля качества

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

Базовый поток событий:

1. Продукт необходимо объяснить тестеры.
2. Определены методы тестирования программного обеспечения и платформа.

Также читайте:

Является ли JIRA контрпродуктивным ПО для управления проектами на современном рынке?

Использование Scrum

1. Владелец продукта создает отставание i.е. наиболее важные функции приложения, которые необходимо протестировать.
2. Функции для тестирования передаются команде QA.
3. Решен спринт продолжительностью 10 дней.
4. Ежедневный 20-минутный Скрам запланирован для обновлений команды.
5. На основе обновлений владелец продукта повторно назначает задачи или меняет приоритеты тестирования.
6. Спринт-встреча через 10 дней проводится с компанией-клиентом.
7. Сообщения об ошибках программного обеспечения поступают ежедневно, и Scrum Master отправляет отчет клиенту.
8. Программисты на стороне клиента обновляют программное обеспечение.
9. Ежемесячный обзор Sprint проводится между клиентом, программистами и командами QA.
10. Новое отставание создается в соответствии с изменениями в программном обеспечении для следующего Спринта.

3.4. Пример использования 4: ИТ-поддержка

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

Участники:

Владелец продукта: Менеджер по ИТ-поддержке

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

Мастер Scrum: Руководитель группы ИТ-поддержки

Базовый поток событий:

1. Сообщается о проблемах клиентов в службу поддержки.
2. Группа поддержки сообщает о проблемах группе разработчиков для улучшения.
3. Журнал проблем создан.

Использование Scrum Project Management:

1. Владелец продукта создает бэклог i.е. самые важные проблемы, с которыми сталкиваются клиенты.
2. Скрам-мастер сообщает о проблемах группе поддержки.
3. Группа поддержки сообщает об этих проблемах программистам.
4. Ежедневная 20-минутная встреча по схватке с владельцем продукта, персоналом службы поддержки и мастером схватки.
5. Еженедельная встреча спринта проводится для обсуждения частоты повторяющихся проблем с командой поддержки и командой программистов.
6. Ежемесячное совещание по обзору спринта проводится между менеджером ИТ-поддержки, руководителем группы программирования, группой поддержки и группой программирования.

3. nTask для управления проектами Scrum

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

4. Прозрачность

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

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

4.1. Назначение задач

Раздел «Проекты» позволяет определять и назначать задачи владельцем продукта. Обновление для каждой задачи предоставляется самими назначенными членами команды без необходимости запроса менеджера проекта. За каждым обновлением задачи следят члены команды.

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

4.2. Ход проекта

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

4.3. Расписание встреч

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

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

4.4. Easy Collaboration

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

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

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

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

Также читал:

Понравилась статья? Вы можете помочь нам расти, поделившись им со своей сетью:
.

Объяснение методологии управления проектами SCRUM

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

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

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

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

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

Краткое объяснение Scrum

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

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

Спринт длится в среднем две недели , в зависимости от сроков проекта и сложности задачи.

История Scrum восходит к 1986 году, когда Хиротака Такеучи и Икудзиро Нонака впервые использовали этот термин для описания более эффективного подхода к разработке продукта. Слово «схватка» происходит от игры «регби» и относится к ситуации, когда команда сбивается в кучу и атакует, пытаясь отобрать мяч у противоположной команды.

В 1990-х годах Кен Швабер и Джефф Сазерленд использовали и усовершенствовали этот метод специально для разработки программного обеспечения , поскольку методы прогнозирования и каскадные методы не всегда подходили. Они объединили свои практики, идеи и наблюдения и создали то, что официально известно как Scrum .

Они представили свои выводы на OOPSLA (объектно-ориентированное программирование, системы, языки и приложения) в 1995 году, и сейчас Scrum является самой популярной методологией управления проектами Agile для большинства отраслей.

Кому следует использовать Scrum?

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

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

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

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

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

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

Плюсы и минусы Scrum

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

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

.

Гибкое управление проектами с использованием методов Scrum

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

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

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

Что такое Scrum и как он работает

Методологию

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

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

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

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

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

Методология

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

Основные виды деятельности

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

Управление проектом Scrum включает следующие основные виды деятельности:

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

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

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

• Ретроспектива спринта , которая проводится в конце каждого спринта и перед началом следующего спринта.Это касается всех участников спринта, включая ScrumMaster и Product Owner, и используется для размышления о только что завершенном спринте вместе с предложениями по улучшениям.

Прочие компоненты Scrum
Помимо бэклога продукта и бэклога спринта, управление проектами Scrum включает в себя следующий компонент:

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

Инструменты Scrum

Проектами

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

.