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

Гибкая методология 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 — обзор популярной методологии Agile-разработки

Scrum и Agile – понятия, которые идут рука об руку. Без понимания, что такое Agile, расшифровка термина Scrum будет неполной.

Итак, Agile – это целая философия, семейство гибких подходов к разработке программного обеспечения (ПО), а Scrum – один из них.

У Scrum есть еще братик – Kanban (тоже из Agile – такие доски с цветастыми наклейками, благодаря которым не простаивают задачи). Этот обзор – краткое сборное руководство по Скрам и описание сервисов, которые его поддерживают. 

В английском scrum – это «толкучка», схватка мяча в таком виде спорта как регби. 

Scrum: что такое и зачем?

Скрам – это фреймворк* для разработки и поддержки сложных продуктов. У него есть роли, события, правила и даже артефакты.

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

*Фреймворк – «каркас» в переводе с английского. Это набор базовых элементов и правил, на котором строится процесс разработки. 

И кстати, о книге. Ее автор утверждает, что именно Scrum – секрет успеха таких гигантов как Amazon и Google, и что якобы даже ФБР использует эту методологию для разработки данных.

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

Scrum и Kanban – в чем отличия?

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

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

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

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

Также есть другие отличия:

• в плане ролей – в Scrum-команде нужно больше ресурсов;
• в планировании – в Scrum приоритеты по задачам выставляет руководитель (владелец продукта), а в Канбан – команда;
• во временных промежутках – в Scrum сроки соблюдаются в обязательном порядке, и время делится на строгие «спринты», а в Kanban задача может находиться в работе столько, сколько нужно;
• в досках – они используются при обоих подходах, но Канбан-доска заполнена постоянно, а в Scrum ее очищают при каждой итерации. 

На чем стоит Scrum: роли, элементы и другое

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

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

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

Роли в Scrum

В Scrum всего 3 роли:

1. Скрам Мастер. Это бизнес-аналитик, руководитель проекта. Его задача – организовывать и проводить совещания и следить за тем, чтобы соблюдалась технология Scrum. Еще он снимает противоречия и направляет команду. 

2. Product Owner. А это уже владелец проекта, его функциональный заказчик. Он отвечает за разработку продукта и ставит задачи команде. Это всегда один человек, а не группа лиц.
3. Development Team. Команда из профильных специалистов – программистов, дизайнеров, аналитиков и т.д. Работает по принципам самоорганизации и самоуправления. Типичный размер команды – 7 человек (плюс/минус 2). За результат команда отвечает как единое целое. 

Артефакты (элементы) Scrum

В Скрам задействуется всего 4 артефакта.

Product Backlog

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

Sprint Backlog

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

Sprint Goal

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

Sprint Burndown Chart

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

Ритуалы (процессы) в Скрам

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

Sprint Planning Meeting

Это встреча по планированию спринта, на которой команда выбирает требования из Product Backlog и создает Sprint Backlog. На этой встрече Product Owner отвечает на вопросы участников команды.

Daily Meeting

Ежедневная встреча всей команды – она обязательно должна проходить каждый день, причем в одно и то же время. Интересный момент: на встрече все стоят (потому встречи еще зовут стендапами), потому длительность мероприятия не более четверти часа. В таком коротком временном промежутке каждый должен ответить на 3 вопроса:

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

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

Sprint Review

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

Retrospective

Это ритуал по обмену опытом в коллективе команды и конструктивное улучшение процесса разработки. На встрече обязательно присутствие всей команды, вместе со Скрам Мастером, а вот Product Owner сам решает – приходить или воздержаться. На встрече озвучивают ответы на ряд вопросов:

• Какие решения нужно принять, чтобы сделать процесс еще более предсказуемым?
• Какие проблемы мешают выполнять обязательства, возложенные на команду?
• Как еще лучше работать и взаимодействовать с Product Owner’ом?
• Какие ошибки допускаются в команде и почему это происходит?

Какие сервисы помогают внедрять Scrum?

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

• Atlassian – сервис с большим выбором продуктов и Scrum-досками Jira. Здесь есть и Scrum, и Kanban, и смешанная методология. Платформа позиционирует себя как «лучший инструмент для agile-команд». Есть бесплатный период. Можно отслеживать ход работы онлайн с помощью Jira на смартфоне. 

Кстати, сервис Trello (популярная в рунете Скрам и Канбан-доска) – как раз разработка Atlassian. Весь список продуктов Atlassian тут. 

• Scrum-Time. Еще один русскоязычный менеджер задач для управления проектами в духе Agile. Есть бесплатный период, а платные тарифы ну очень со смешной ценовой политикой – до 1$ в месяц. Здесь есть три типа проектов: доска задач в стиле Scrum, но не со всеми возможностями подхода; доска задач со всеми инструментами Scrum; Kanban. Также тут подробно рассказывают о том, что такое Scrum.

Выводы

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

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

И главное, что сейчас есть онлайн-платформы для практически полноценной работы по Скрам-подходу – пробуйте, изучайте, разрабатывайте!

Почему вам обязательно нужно узнать, что такое 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 методология? Как ее применять в разработке и не только? Почему гибкость не всегда хороша?

Учеба продолжается, три раза в неделю я знакомлюсь с новыми знаниями из области разработки и понимания digital продуктов изнутри. Для маркетолога, это новый мир. Ты слышишь про какой-то там Agile, понимаешь, что связано это с разработкой и вполне можешь поддержать беседу в общих красках. Но как только дело доходит до деталей, “поплыл”.

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

Что такое Scrum

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

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

Как работает Scrum

Как Scrum устроен на самом деле смотрите ниже.

Пока это выглядит как китайская грамота, поэтому предлагаю посмотреть на отдельные части и разобрать каждый элемент структуры. Очень рекомендую книгу Бориса Вольфсана “Гибкие методологии” именно она легла в основу данного материала (часть картинок оттуда).

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

Роли

• Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
• Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.

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

• Команда – 7±2 человек, которые реализуют требования владельца продукта.

Артефакты

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

Процессы

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

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–

Пример Scrum

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

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

Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.

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

На практике, историй пользователя (типа “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо. В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи.

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

Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.

Стена работает тоже хорошо, так как на этапе создания вся команда увлечена и чувствует свой вклад в общее дело. Но после ее нужно перенести в подходящий инструмент.

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

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

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

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

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

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

Как расставлять приоритеты

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

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

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

Оценка историй пользователей внутри беклога

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

Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами”  стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

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

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

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

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

Можно ли применять Scrum не только в разработке

И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.

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

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

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

Когда применять Scrum

В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.

Нюансы

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

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

Завершим

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

Читайте также:

Великолепный ролик от Николая Дроздова и Huawei. Обязательно смотреть!

Вконтакте

Facebook

Twitter

Google+

Загрузка…

Основные заблуждения о 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. Революционный метод управления проектами». Книга за 15 минут

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

Что такое Scrum. Суть методики

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

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

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

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

1. Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
2. Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
3. Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
4. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
5. Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
6. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — «наращивать динамику производительности».
7. Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано».
8. Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста — ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».
9. По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт.
10. После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

Недостатки традиционного подхода к управлению проектами

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

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

Изображение с сайта www.quickiwiki.com

«С распространением в 1980-е годы персональных компьютеров стало проще создавать разные затейливые диаграммы — и делать их по-настоящему комплексными — они превращались в подлинные художественные произведения. Весь ход проекта детально размечен. Каждый отдельный шаг. Любая стадия. Всякая дата поставки. Действительно, диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они всегда неправильны — без исключения».

Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, «каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „окопные“ организационные идеи остаются популярными и по сей день».

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

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

Планы рассыпаются в прах. Альтернатива — это Scrum

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

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

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

Изображение с сайта brendanmarsh.com

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

«Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт».На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот — недостаточное количество задач. В данном случае важно другое: у группы развивается чувство собственной скорости».

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

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

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

Философия scrum

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

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

Суть командной работы в Scrum

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

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

На многофункциональности стоит заострить внимание особо. Автор приводит пример многофункциональной команды из спецназа — группу «Альфа» (команда «А»). Каждая такая «команда „А“ сформирована таким образом, чтобы все ее члены были разносторонними мастерами боевой подготовки, что позволяет им выполнять операции от начала до конца. Бойцы спецназа постоянно проводят обучение взаимозаменяемости по нескольким специальностям. Команда должна быть уверена, что если убьют обоих медиков, то, скажем, специалист по связи сможет оказать первую медицинскую помощь раненому товарищу. Существенная особенность, отличающая работу спецназа от действий„обычных“ армейских сил, заключается в том, что „зеленые береты“ самостоятельно выполняют и сбор разведывательных данных, и планирование операций. В их практике не допускается передача эстафетной палочки от одного подразделения другому — ведь именно в таких „швах“ таится слабое место, из-за которого возникают ошибки».

Какого размера должна быть команда? Джефф Сазерленд рекомендует малочисленные группы — около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает.

Кроме того автор напоминает о «законе Брукса»:

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

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

Нет мультизадачности

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

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

Никаких переработок

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

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

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

«Методология Scrum подразумевает, что те, кто применяет ее, перестают измерять свою работу только часами. Часы отражают лишь затраты. Измеряйте лучше результат. Кого волнует, сколько кто-то потратил времени на то, чтобычто-то сделать? Единственное, что имеет значение, — как быстро и качественно это было сделано».

Суть работы — поток

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

Как его достичь? За состоянием потока стоит внутренняя дисциплина,

«Не должно быть ни одного движения впустую».

Скрам и счастье

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

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

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

Элементы скрам

Спринты

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

Изображение с сайта nyaski.ru

Однако есть важное замечание — «ничто не переносится в колонку „Сделано“ до тех пор, пока эта часть проекта не будет опробована клиентом».

«Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка „блокируются“. Никто не имеет права их менять или вносить добавления». Автор рекомендует это из-за того, что любое вмешательство замедлит работу команды.

Ежедневные собрания

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

Делайте до конца

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

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

Планирование в Scrum

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

Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи «в собаках». Эта проблема — такса или ретривер? А может быть, дог?

Но в любом случае удобнее установить числовые значения. Например, «Такса — единица; дог — тринадцать; лабрадор стал пятеркой, а бульдог — тройкой».

Автор также предлагает использовать интересную методику покер планирования. Ее суть — каждому участнику процесса планирования дается колода карт с числами Фибоначчи — 1, 2, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. «Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными».

Требования — это истории

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

«Представьте, что вы составляете „пожелание пользователя Amazon.com“. Пробный вариант выглядит так: „Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время“.Это описание вполне отвечает характеру Amazon, но история получилась слишком расплывчатой, чтобы с ней можно было что-то сделать. Нужно фрагментировать нашу историю. Сделать ее действительно очень конкретной и функциональной. Приведу несколько образцов пользовательских историй, которые вы можете написать, имея в виду книжный интернет-магазин:Как потребителю мне удобно искать книги по жанрам, чтобы быстро найти те, которые я люблю читать.Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину.Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать.Вот профессионально сделанные пожелания пользователя, характер которых группа должна принять во внимание».

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

Как планировать спринт

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

После этого команда дружно произносит: «Вперед!» — и принимается за работу

Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа — это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.

Командам нужно хорошо узнать свою динамику — сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.

«Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише».

Открытость во всем

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

Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.

«Секретность — яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды».

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

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

• Вы выдвигаете на первый план то, что вы можете предложить. Тогда возникает риск сделать никому ненужный продукт;
• Вы ориентируетесь на рынок. Тогда вас могут опередить или уничтожить конкуренты;
• Ваше главное стремление — большие продажи. Тогда вы рискуете выпустить на рынок посредственный продукт.

Бэклог

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

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

Как правильно расставить приоритеты? «Для этого нужно выяснить, какие пункты списка:

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

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

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

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

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

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

Минимизация рисков в скраме

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

«Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное?»

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

Как внедрить Scrum прямо сейчас

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

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

О нас

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

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

Также читайте: Как мы делали SCRUM

Подходит ли это вашей команде?

Вы, наверное, слышали о всевозможных методологиях управления проектами — Scrum, Waterfall, Kanban, Agile, — но какая из этих методологий подходит вашей команде?

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

Что такое методология Scrum?

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

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

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

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

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

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

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

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

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

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

Роли Scrum

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

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

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

Роль product owner-а — направлять команду и поощрять открытое общение на всех должностях. Успешный владелец продукта организован и готов ответить на вопросы и обеспечить ясность на протяжении всего жизненного цикла проекта.

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

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

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

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

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

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

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

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

Узнайте, как

3 шага процесса Scrum

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

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

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

• Какие функции мы можем предложить в этом спринте?
• Как мы будем работать для достижения этих результатов?

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

2. Ежедневная встреча Scrum

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

В идеале ежедневная встреча Scrum не должна превышать 15 минут.

3. Обзор спринта и ретроспектива спринта

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

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

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

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

Ключевые инструменты Scrum, которые помогут вам пройти следующий спринт

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

Товар в очереди

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

Пример невыполненных работ по продукту (Щелкните изображение, чтобы изменить в Интернете)

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

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

Доска схватки

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

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

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

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

Подробный пример доски задач Scrum (Нажмите на изображение, чтобы изменить онлайн)

Графики выгорания

Графики выгорания

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

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

Ежедневная диаграмма выгорания (Нажмите на изображение, чтобы изменить онлайн)

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

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

• Рад, грустен, сумасшедший: Члены команды определяют свои чувства, чтобы работать над получением приятных впечатлений для каждого спринта.
• Старт, Стоп, Продолжить: Улучшите процесс спринта, спросив членов команды, что команда должна начать делать, прекратить делать и продолжать делать.
• 4 Ls: Этот метод подробно описывает, что каждому члену команды понравилось, чему он научился, чего не хватало и чего желал во время спринта.

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

Нажмите, чтобы использовать этот шаблон
Щелкните, чтобы использовать этот шаблон

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

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

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

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

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

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

Читать

.

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

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

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

Кто использует методологию Agile Scrum?

Scrum широко используется командами разработчиков программного обеспечения.Фактически, это самая популярная гибкая методология. Согласно 12-му ежегодному отчету State of Agile, 70% команд разработчиков программного обеспечения используют Scrum или гибрид Scrum. Однако Scrum распространился на другие бизнес-функции, включая ИТ и маркетинг, где есть проекты, которые должны продвигаться вперед при наличии сложности и двусмысленности. Руководящие группы также основывают свои методы гибкого управления на Scrum, часто комбинируя его с практиками Lean и Kanban (подгруппы гибкого управления проектами).

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

Scrum — это подгруппа Agile:

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

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

Какие преимущества дает методология Scrum?

Организации, внедрившие Agile Scrum, испытали:

• Повышение производительности
• Продукция лучшего качества
• Время выхода на рынок сокращено
• Повышение уровня удовлетворенности заинтересованных сторон
• Лучшая командная динамика
• Более довольные сотрудники

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

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

Чем отличается методология Scrum от других гибких подходов?

Большинство предприятий сначала переводят отдельные команды на Agile, прежде чем они «масштабируются» для остальной части организации. Масштабировать Agile непросто, что недавно привело к появлению новых фреймворков, таких как Scaled Agile Framework® и Disciplined Agile Delivery (DAD). Эта популярность сделала Scrum важной частью многих инициатив по управлению жизненным циклом гибких приложений (Agile ALM).

Каковы компоненты разработки Agile Scrum?

Методология Scrum определяется ролями в команде, событиями (церемониями), артефактами и правилами.

Команда Scrum

Scrum-команды обычно состоят из 7 +/- 2 участников и не имеют руководителя, который мог бы делегировать задачи или решать, как решить проблему. Команда как единое целое решает, как решать проблемы и решать проблемы. Каждый член команды Scrum является неотъемлемой частью решения и должен вести продукт от начала до завершения. В команде Scrum есть три ключевые роли:

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

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

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

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

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

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

Scrum Events (Церемонии)

Спринт

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

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

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

Ежедневный стенд-ап

Daily Stand-up — это короткая коммуникационная встреча (не более 15 минут), на которой каждый член команды быстро и прозрачно освещает прогресс с момента последней встречи, запланированную работу перед следующей встречей и любые препятствия, которые могут блокировать его или ее прогресс.

Обзор Sprint

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

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

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

Артефакты Scrum

Резерв продукта

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

S печать Задержка

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

Приращение

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

Правила Scrum

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

Практика Scrum

Начало работы

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

Переход на новый уровень гибкости

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

.

Что такое Scrum? Руководство по пониманию методологии Scrum

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

Хорошие продукты привлекают целевую аудиторию, удовлетворяя потребности клиентов. Человек, который достигает этого для своей компании, — это Certified Scrum Master , и он / она получает за то же самое щедрое вознаграждение.

В этой статье мы собираемся изучить вопрос «Что такое Scrum?».

Что такое Scrum?

Руководство по Scrum определяет схватку как:

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

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

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

Итак, scrum — это гибкий способ работы над любыми проектами в этом быстро меняющемся мире.Но это по-прежнему оставляет много вопросов о Scrum Framework. Первый шаг — немного углубиться в происхождение и историю Scrum.

Что такое Scrum? Scrum за 20 минут | Обучение Scrum Master | Эдурека

История Scrum

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

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

Давайте перейдем к следующей части этого «Что такое Scrum?» статью и узнайте о людях и частях, вовлеченных в Scrum Framework.

Люди и части Scrum Framework

Scrum Framework состоит из трех различных категорий:

Давайте посмотрим на каждую из них.

Роли Scrum

В Scrum определены три разные роли:

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

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

События в Scrum

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

Спринт — это, по сути, определенный период времени, в течение которого scrum-команда производит продукт.

Четыре события или церемонии Scrum Framework:

• Планирование спринта: Это собрание, на котором работа, которая должна быть выполнена во время спринта, намечена на карту и члены команды назначил работу, необходимую для достижения этой цели.
• Daily Scrum: Также известное как стендап, это 15-минутное ежедневное собрание , на котором у команды есть шанс выйти на ту же страницу и разработать стратегию на следующие 24 часа.
• Обзор спринта: Во время обзора спринта владелец продукта объясняет, в чем заключалась запланированная работа, а что не было завершено во время спринта. Затем группа представляет выполненную работу и обсуждает, что прошло успешно и как были решены проблемы.
• Ретроспектива спринта: Во время ретроспективы спринта команда обсуждает, что пошло правильно, что пошло не так и как улучшить . Они решают, как исправить проблемы, и создают план улучшений, которые будут внесены в следующий спринт.

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

Артефакты Scrum

Артефакты — это просто физические записи, которые предоставляют сведения о проекте при разработке продукта. Артефакты Scrum включают:

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

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

Ну, это охватывает все термины, с которыми вы можете столкнуться при работе со Scrum Framework. Но как на самом деле работает схватка?

Как работает Scrum-процесс?

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

Шаг 2: Scrum-команда собирается для планирования спринта , когда команда вместе решает, над чем работать в первую очередь из бэклога продукта. Это подмножество элементов из невыполненной работы по продукту становится невыполненной печатью s .

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

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

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

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

Шаг 6: Цикл повторяет для оставшихся задач в очереди продукта.Это продолжается до тех пор, пока не произойдет одно из нижеперечисленных событий:

• Достигнут крайний срок
• Бюджет исчерпан
• Владелец продукта удовлетворен конечным продуктом

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

На этом мы подошли к концу статьи «Что такое Scrum?».Я рассмотрел все основы, о которых вам следует знать, если вы планируете использовать методологию Scrum. Надеюсь, вы понимаете все, что было поделено с вами в этой статье.

Убедитесь, что вы хорошо разбираетесь в терминологии Scrum, прежде чем начать ее использовать.

Есть вопрос к нам? Пожалуйста, укажите это в комментариях к статье «Что такое Scrum?» артикул и мы свяжемся с вами в ближайшее время.

.Методология

Scrum — начало работы с Agile Scrum

Перейти к основному содержанию

Поиск

США (английский)
Великобритания (английский)
нидерландский язык
Немецкий
Шведский

Авторизоваться

Рабочий фронт
ProofHQ

Связаться с отделом продаж

США (английский)
Великобритания (английский)
нидерландский язык
Немецкий
Шведский

• Почему Workfront

  Обзор
  Клиенты

• Решения

  Все решения
  Маркетинг
  ЭТО
  Агентства
  Профессиональные услуги
  Разработка продукта

• Товары

.