Фреймворк scrum что это
Scrum is a framework that helps teams work together. Much like a rugby team (where it gets its name) training for the big game, scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve.
While the scrum I’m talking about is most frequently used by software development teams, its principles and lessons can be applied to all kinds of teamwork. This is one of the reasons scrum is so popular. Often thought of as an agile project management framework, scrum describes a set of meetings, tools, and roles that work in concert to help teams structure and manage their work.
But, why scrum?
The scrum framework itself is simple. The rules, artifacts, events, and roles are easy to understand. Its semi-prescriptive approach actually helps remove the ambiguities in the development process, while giving sufficient space for companies to introduce their individual flavor to it.
The organization of complex tasks into manageable user stories makes it ideal for difficult projects. Also, the clear demarcation of roles and planned events ensure that there is transparency and collective ownership throughout the development cycle. Quick releases keep the team motivated and the users happy as they can see progress in a short amount of time.
However, scrum could take time to fully understand, especially if the development team is acclimatized to a typical waterfall model. The concepts of smaller iterations, daily scrum meetings, sprint reviews, and identifying a scrum master could be a challenging cultural shift for a new team.
But, the long-term benefits far outweigh the initial learning curve. Scrum’s success in developing complex hardware and software products across diverse industries and verticals makes it a compelling framework to adopt for your organization.
To learn scrum with Jira Software, check out this tutorial.
Claire Drumond is a marketing strategist, speaker, and writer for Atlassian. She is the author of numerous articles published on the Trello and Atlassian blogs and is a regular contributor to various publications on Medium including HackerNoon, Art+Marketing, and PoetsUnlimited. She speaks at tech conferences around the world about agile, breaking down silos, and building empathy.
Scrum — методология гибкой работы команды. На сегодняшний день пользуется большой популярностью, применяется во многих крупных компаниях. В этой статье разберемся, когда и при каких обстоятельствах возникла техника, на каких базовых принципах строится ее реализация, что важно учитывать при работе и многое другое.
Принципы работы Scrum-команды
Успешная работа по методологии Scrum возможна при соблюдении трех принципов:
- Постоянное самосовершенствование. Опытные разработчики рассказывают, что совершенствование продукта, доведение до идеального состояние невозможно без самосовершенствования каждого члена команды.
- Автономность. Все сотрудники должны отвечать не только за общий результат и уметь работать в коллективе, но и выполнять многие обязанности индивидуально.
- Кросс-функциональность. Любая команда самодостаточна, так как в нее входят специалисты с разными навыками.
Владелец продукта
Владелец — ответственное за разработку лицо. Эту роль занимает заказчик продукта или его официальный представитель. В редких случаях — представитель рынка, на котором впоследствии реализуют запланированный проект.
Владелец отвечает за составление бизнес-плана, в котором отражается ожидаемый экономический эффект. Также в нем он определяет план развития, в котором для каждого пункта рассчитывается коэффициент окупаемости вложений. Еще один важный документ, формированием которого занимается владелец, — список требований, они сортируются по важности.
Если говорить просто, то владелец продукта — центр принятия решения для проектной команды. Он должен быть единственным в рамках проекта, иначе принцип быстрого принятия важных решений нарушается.
Примерный перечень обязанностей владельца:
- формирование видения продукта;
- управление ожиданиями заказчика (и других заинтересованных лиц);
- координация и приоритизация бэклога продукта;
- предоставление команде понятных и тестируемых требований;
- взаимодействие с командой проекта и заказчиком;
- прием и оценка результата работы в конце каждой итерации.
Особенности Скрама
Scrum — прост. …
Фреймворк Scrum намеренно неполный, и определяет только части, необходимые для реализации теории Scrum.
Руководство по Scrum 2020”
В отличие от многих методологий разработки программного обеспечения, которые детально описывают процесс разработки на десятках страниц, в Скраме по сути нет ничего кроме вышеуказанных элементов и связывающих их немногочисленных правил. Скрам не вводит сложных схем взаимодействия, не диктует, каким именно должен быть ваш процесс разработки, и что именно нужно делать людям.
Scrum не предоставляет людям подробных инструкций, а вместо этого правила Scrum задают ориентиры для отношений и взаимодействий людей.
Руководство по Scrum 2020”
В частности, в Скраме отсутствуют конкретные рекомендации по техникам проведения скрам-мероприятий. Например, до 2020 года в Руководстве по Скраму в качестве примера приводился конкретный формат проведения мероприятия «Ежедневный Скрам» (с ответами каждого участника на 3 вопроса). Если команда не понимала ценностей Agile и Scrum, то этот формат зачастую приводил к бессмысленному механическому ритуалу проведения Ежедневного Скрама, поэтому его убрали даже как пример.
Прозрачность (Transparency)
Один из трёх Принципов Скрама. Значимые аспекты процесса и продукта должны быть доступны тем, кто отвечает за его результат. Соблюдение принципа прозрачности подразумевает, что эти аспекты объединены в общий стандарт, и все участники процесса обладают единым их пониманием.
Scrum articles
Sprints
A sprint is a short, time boxed period when a scrum team works to complete a set amount of work.
Sprint Planning
Sprint Planning is an event in scrum that defines what can be delivered in the upcoming sprint and how that work will be achieved.
Four agile ceremonies, demystified
Learn how to facilitate great agile ceremonies like sprint planning, daily stand-ups, iteration review and retrospectives.
The product backlog: your ultimate to-do list
What is a product backlog in agile or scrum? Learn about the best practices for managing and prioritizing a healthy product backlog.
Three steps to better sprint reviews
Learn how sprint reviews demonstrate the hard work of the entire team: designers, developers, and the product owner.
Standups for agile teams
Learn how standups contribute to a healthy agile program and some tips and tricks for you and your team.
What is a Scrum Master?
Learn what a Scrum Master is (and what they are NOT), and how the role supports and works with other members of an agile team.
Agile retrospectives: Use the past to define the future
A retrospective helps teams perform better over time. See what the agile community is saying and learn how to run your own retrospective meetings.
Agile Scrum Roles
Learn about the responsibilities and activities associated with the three major agile scrum roles: scrum master, product owner, and development team.
Scrum of scrums
Scrum of scrums is a scaled agile technique that offers a way to connect multiple teams who need to work together to deliver complex solutions. Learn how to scale scrum with examples from Atlassian and others.
Learn scrum with Jira Software
A step-by-step guide on how to drive a scrum project, prioritize and organize your backlog into sprints, run the scrum ceremonies and more, all in Jira.
From silo to cohesion with Jira Scrum Boards
The Jira Scrum Board is the visual display of progress during the development cycle.
Подведем итоги
Scrum — это методология гибкой разработки, основанная на принципах Agile. Ее разработкой занялись в 90-х годах прошлого столетия, а широкую известность она начала обретать в начале 00-х годов. На сегодняшний день скрам используют многие команды, чья деятельность тесно связана с проектами.
Scrum можно внедрить в свою компанию за 6 шагов, но следует тщательно подходить к организации процесса. Специальных знаний от сотрудников методология не требует, здесь скорее вопрос в организации и правильном построении рабочего времени.
При этом не забывайте, что скрам — не волшебная пилюля, если у вас наблюдается постоянный срыв дедлайнов, плохая атмосфера внутри коллектива, внедрение новой техники не решит всех проблем. Поэтому изначально наладьте коммуникации внутри команды, постройте эффективную работу, а затем внедряйте scrum для повышения продуктивности.
Я продолжаю работу над диссертацией по проектному менеджменту. Сегодня мы кратко рассмотрим Scrum, рассмотрим типичные ошибки, приводящие к проблемам. Данный пост не претендует на полноту, он является обзорным и адресуется тем, кто еще не знаком со Scrum, или знаком лишь частично (к примеру, работает в модифицированном Scrum).
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно :)
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии :)
Авторами Scrum заявлены следующие особенности:
-Легкий (англ. Lightweight)
-Понятный, доступный
-Сложный в освоении
(практически взаимоисключающие параграфы)
Роли в Scrum
В классическом Scrum существует 3 базовых роли:
-Product owner
-Scrum master
-Команда разработки (Development team)
Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.
Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).
Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO
Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:
-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде, как им преобразовать Product Backlog в работающий продукт
-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта
-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды
Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]
Процесс Scrum
Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.
Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.
Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint'а.
По окончанию Sprint'а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint'е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.
Схематическое изображение процесса приведено на следующем рисунке:
Важные, часто забываемые особенности
Часто можно услышать, что Scrum не работает, или работает хуже, чем ожидалось. Необходимо заметить, что чаще всего так происходит по одной из следующих причин:
1. Scrum применяется неверно или неполностью.
Согласно авторам Scrum, эмпирический опыт является главным источником достоверной информации. Необходимость полного и точного выполнения Scrum указана в The Scrum Guide и обусловлена нетипичной организацией процесса, отсутствием формального лидера и руководителя.
2. Недооценена важность работы по обеспечению мотивации команды.
Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].
Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменений в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.
3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.
Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.
Достоинства и недостатки
Scrum обладает достаточно привлекательными достоинствами. Scrum ориентирован на клиента, адаптивен. Scrum дает клиенту возможность делать изменения в требованиях в любой момент времени (но не гарантирует того, что эти изменения будут выполнены). Возможность изменения требований привлекательна для многих заказчиков ПО.
Scrum достаточно прост в изучении, позволяет экономить время, за счет исключения не критичных активностей. Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint'а.
Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.
Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.
Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.
Другой слабой особенностью Scrum является упор на самоорганизующуюся, многофункциональную команду. При кажущемся снижении затрат на координацию команды, это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. При определенных условиях рынка труда, формирование полноценной, эффективной Scrum команды может быть невозможным.
Помимо Scrum, я рекомендую обратить внимание на Канбан. В этом видео я сделал небольшой обзор метода Канбан:
Список использованных источников
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психология управления, учебное пособие. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Скрам — это фреймворк, предназначенный для решения нетривиальных задач, для эффективного и творческого создания продуктов с максимально возможной ценностью.
Руководство по Scrum 2017
”
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.
Руководство по Scrum 2020”
Эти слова из Scrum Guide требуют пояснений:
- Область применимости Скрама – это НЕ разовые проекты с фиксированным сроком и/или объемом работы; это «продукты», которые постоянно улучшаются во взаимодействии с клиентом. Причем Скрам нужен не для типовых задач, а для сложных продуктов, имеющих высокую степень неопределенности как в способах достижения результата, так и в востребованности результата рынком.
- Одна из целей Скрама – бизнес-ценность создаваемых продуктов. Он особенно эффективен в условиях, когда требуется быстро создавать MVP и затем быстро повышать ценность продукта на основе обратной связи от клиентов / с рынка. Но бизнес-ориентированность не означает, что в Скраме игнорируются потребности людей, которые создают продукт. Даже наоборот: исследования подтверждают, что мотивация разработчиков продуктов значительно возрастает после перехода на Скрам (в т.ч. за счет большей самостоятельности в принятии решений и за счет более творческого подхода к работе).
- Фреймворк – это набор базовых элементов – своего рода каркас, на котором могут строиться различные процессы в разных организациях и даже в разных командах одной организации. Элементы Скрама нельзя изменять, но можно дополнять, причем как именно реализуется каждый элемент – зависит от контекста конкретной команды.
- Элементы Скрама – это 5 событий (мероприятий), 3 зоны ответственности (которые присваиваются участникам Скрам-команды независимо от их должностей) и 3 артефакта (материальные представления работ и их результатов).
Скрам – эмпирический подход к управлению
Скрам основывается на эмпирическом управлении процессами, а не на детерминированном. Эмпиризм означает, что процесс адаптируется к данным, получаемым в ходе работы. Очевидно, процесс с эмпирическим управлением всегда дороже, чем обычный процесс с детерминированным управлением. Поэтому детерминированный подход применяется всегда, когда механизмы процесса достаточно хорошо понятны. Если же механизмы плохо известны, детерминированный подход не приводит к продукту с необходимым соотношением «цена / качество» с первого раза, и продукт приходится переделывать.
В конечном счете создание успешных продуктов с первого раза, используя эмпирическое управление процессом, окажется намного дешевле переделки неудачных продуктов, созданных по процессу с детерминированным управлением.
Скрам. Гибкое управление продуктом и бизнесом (Кен Швабер, 2004)”
Scrum-команда
Scrum-команда в большинстве случае состоит из 5-9 человек, реже — из 3-4. В рамках скрама коллектив не может быть больше, потому что усложняется взаимодействие между каждым звеном, что негативно сказывается на эффективности работы.
Состав
В команде есть три основные роли:
- Владелец продукта (Product Owner).
- Скрам-мастер (Scrum Master).
- Разработчики (Delivery Team).
The scrum product owner
Product owners are the champions for their product. They are focused on understanding business, customer, and market requirements, then prioritizing the work to be done by the engineering team accordingly. Effective product owners:
- Build and manage the product backlog.
- Closely partner with the business and the team to ensure everyone understands the work items in the product backlog.
- Give the team clear guidance on which features to deliver next.
Decide when to ship the product with a predisposition towards more frequent delivery.
The product owner is not always the product manager. Product owners focus on ensuring the development team delivers the most value to the business. Also, it's important that the product owner be an individual. No development team wants mixed guidance from multiple product owners.
Резюме: как описать Скрам простыми словами
Если обойтись почти без англицизмов, то вышесказанное можно сформулировать так:
- Скрам выгодно применять не для типовых проектов, а для новых сложных продуктов, требования к которым заранее не определены и быстро меняются под влиянием обратной связи с рынка. В том числе, Скрам предназначен для продуктов, не относящихся к разработке ПО.
- Скрам задает лишь основу (каркас) для ваших процессов разработки, т.е. его можно дополнять, а его обязательные элементы реализовывать по-разному в разных ситуациях.
- Скрам как эмпирический подход регулярно адаптирует продукт и процесс его разработки на основе быстрой обратной связи. Это приводит к дополнительным издержкам. Однако издержки с лихвой компенсируется тем, что продукты начинают зарабатывать намного быстрее, а их бизнес-ценность получается выше по сравнению с продуктами, созданными по заранее придуманным требованиям, которые не учитывали обратную связь от клиентов.
- Скрам прост для понимания: содержит всего дюжину обязательных элементов (мероприятий, артефактов и зон ответственности).
- Скрам сложен для освоения в совершенстве. Это связано, прежде всего, с нетипичной для большинства организаций структурой: Скрам требует делить людей на небольшие команды, которые могут без посторонней помощи разрабатывать продукт, а также самостоятельно решают, как именно это делать.
- Скрам является самым популярным среди «гибких» подходов, объединяемых словом Agile.
Подробнее о Скраме вы можете почитать в статье Scrum: что это и зачем нужно.
Журнал спринта
Как вы помните, в рамках скрам-методологии продукт реализуется мелкими итерациями. Как правило, один спринт — одна функция. Для эффективной работы она разбивается на мелкие задачи так, чтобы на реализацию уходило не больше 2-3 рабочих дней.
Грамотная разбивка функций на задачи позволяет к концу итерации выполнить все необходимое, чтобы определенная часть программного обеспечения работала корректно и представляла ценность для конечного потребителя.
После составления бэклога спринта его оценивает команда разработчиков и сопоставляет с журналом продукта. При наличии существенных отклонений коллектив определяет наиболее приоритетные задачи в рамках текущего спринта и менее важные, которые допустимо перенести на следующую итерацию.
Задача владельца продукта — исключить из бэклога мелкие и незначительные задачи, выполнение которых никак не повлияет на конечный результат работы.
The framework
People often think scrum and agile are the same thing because scrum is centered around continuous improvement, which is a core principle of agile. However, scrum is a framework for getting work done, where agile is a mindset. You can’t really “go agile”, as it takes dedication from the whole team to change the way they think about delivering value to your customers. But you can use a framework like scrum to help you start thinking that way and to practice building agile principles into your everyday communication and work.
The scrum framework is heuristic; it’s based on continuous learning and adjustment to fluctuating factors. It acknowledges that the team doesn’t know everything at the start of a project and will evolve through experience. Scrum is structured to help teams naturally adapt to changing conditions and user requirements, with re-prioritization built into the process and short release cycles so your team can constantly learn and improve.
While scrum is structured, it is not entirely rigid. Its execution can be tailored to the needs of any organization. There are many theories about how exactly scrum teams must work in order to be successful. However, after more than a decade of helping agile teams get work done at Atlassian, we’ve learned that clear communication, transparency, and a dedication to continuous improvement should always remain at the center of whatever framework you choose. And the rest is up to you.
Разработчики
Разработчики — те, кто отвечают за техническую реализацию продукта. Как правило, на одну команду приходится 5-9 разработчиков. Первая задача — постановка реально достижимых, прогнозируемых, интересных и значимых целей для каждого спринта.
Вторая задача — достижение поставленных целей каждого спринта в установленные сроки (дедлайн). Достижение цели — растяжимое понятие и определяется в каждом проекте индивидуально. Например, где-то задачу считают выполненной после написания всех кодов, а где-то добавляют еще и окончание тестирования. В общем, все руководствуются собственным видением и опытом.
Ключевые навыки для команды разработчиков — планирование, объективная оценка выполненной работы, умение взаимодействовать с другими членами коллектива.
Примерный перечень команды разработчиков:
- оценка элементов бэклога продукта;
- разработка продукта и предоставление его заказчику;
- отслеживание своего прогресса (совместно со скрам-мастером);
- предоставление результата владельцу продукта.
Связь Скрама с другими подходами
Фреймворк позволяет применять различные процессы, техники и методы. Scrum служит оберткой для существующих практик, или подсвечивает их ненужность.
Руководство по Scrum 2020”
В частности, в рамках Скрама нередко применяются элементы метода Канбан. Однако важно подчеркнуть, что если происходит скрещивание этих двух подходов, сопровождающееся отказом от каких-либо мероприятий Скрама, то такой процесс должен называться иначе.
Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом.
Руководство по Scrum”
Например, «давно работающие по Аgile» команды могут переходить со Скрама на какой-то собственный скрамоподобный процесс или на Scrumban. При этом они уменьшают время, затрачиваемое на мероприятия Скрама, получают возможность изменять длительность итерации (спринта) по ходу работы или даже отказываются от оценок работы на спринт, используя безоценочное (no estimate) планирование на основе собранной статистики. Для зрелых команд это полезно, но это не Скрам.
Однако для начинающих Agile-команд Скрам является отличным выбором, так что неудивительно, что этот фреймворк является самым популярным среди гибких подходов как в России, так и во всем мире.
Понимаете ли вы Скрам?
Ответьте на 8 вопросов теста по Agile/Scrum, получите подборку ссылок на статьи/видео/курсы и рекомендации в зависимости от результата теста.
Скрам сегодня – это не только про разработку программного обеспечения
- Остатки IT-терминологии из него были удалены в Scrum Guide 2020 (например, тестирование, требования, проектирование, система).
- При этом по факту еще в 2010-х годах Скрам вышел далеко за рамки ИТ-индустрии. Он успешно применяется командах маркетологов, дизайнеров, разработчиков материальной продукции; в розничной торговле, энергетике, промышленном проектировании/производстве и многих других отраслях.
- Подробнее про применение Скрама в не-ИТ отраслях можно прочитать в исследовании Agile в России 2019.
Процесс работы Scrum-команды
Работа команды, руководствующей методологии Scrum, условно делится на несколько этапов.
1. Планирование списка задач спринта. Каждый спринт начинается с планирования. Все члены команды собираются, оценивают бэклог продукта в целом и выбирают приоритетные задачи, которые необходимо выполнить в рамках текущей итерации. Так формируется список задач (бэклог) текущего спринта.
После этого на основе бэклога оговаривается объем работ и длительность цикла. Также заранее определяют результат: что должны получить по итогам спринта.
2. Проведение регулярных совещаний. Ежедневно или еженедельно команда проводит короткие совещания (не более 15-30 минут). В них участвуют владелец продукта, скрам-мастер и все разработчики. Цель встреч — получить от каждого ответы на три вопроса:
- Что сделано с момента прошлой встречи?
- Какие планы на сегодня?
- Есть ли препятствия к достижению цели?
3. Организация скрам-доски. В конференц-зале, где проводятся регулярные совещания, вешается доска, разделенная на три части: «что нужно сделать», «в работе» и «сделано».
В каждой части размещают стикеры разных цветов с основными задачами. По мере выполнения они перемещаются от одной части к другой. Это помогает отслеживать прогресс текущего спринта каждому члену команды.
4. Изменение планов в ходе итерации. Команда должна быть открытой и если один специалист не успевает уложиться в срок, то сообщает об этом владельцу продукта. Он поменяет расстановку задач, оптимизирует рабочее время и поможет уложиться в дедлайн.
То же самое делается и при слишком быстрой работе, когда задачи выполняются быстрее запланированных сроков. Руководитель дополняет бэклог новыми целями по собственному усмотрению, чтобы реализация продукта протекала быстрее.
5. Подведение итогов. После завершения каждого спринта проводится тестирование выполненной части программного обеспечения. В нем также принимают участие потенциальные потребители (фокус-группа). Владелец собирает обратную связь и принимает решения для успешной работы в дальнейшем.
История появления Scrum
У истоков развития разработки программного обеспечения стоял «водопадный» подход к работе, его использовало большинство команд и делило реализацию продукта на следующие этапы:
- определение требований к проекту;
- планирование операций от начала и до конца;
- написание кода;
- тестирование.
Так работали из года в год, пока одна команда новаторов долгое время наблюдала за успешными коллективами: теми, кому удавалось соблюдать дедлайны и делать качественный продукт. В результате у них возникло понимание, что успех кроется в гибкости процесса.
На основе выводов, сделанных по результатам долгих наблюдений, вывели «Манифест гибкой разработки программного обеспечения». В него включили четыре пункта:
- Люди важнее инструментов.
- Качество продукта важнее документации.
- Взаимодействие с заказчиком важнее контракта.
- Готовность к изменениям важнее установленного плана.
- Главное — хорошее ПО и довольный заказчик.
- Готовность к изменениям в любой момент.
- Добиваться работающего ПО по итогам разработки как можно чаще.
- Встреча команды — лучше всего для обмена информацией.
- Заказчик и команда разработки должны работать вместе.
- Доверять людям делать свою работу.
- Есть рабочее ПО — есть прогресс.
- Гибкие процессы — непрерывное развитие.
- Внимание к качеству способствует гибкости.
- Простота процесса позволяет не делать лишней работы.
- Самоорганизующаяся команда лучше работает.
- Постоянное стремление к большей эффективности.
В 2001 году они детально описали принципы своей методологии и выпустили книгу «Agile Software Development with SCRUM». На сегодняшний день этот подход считается одним из самых популярных среди разработчиков.
График спринта
График спринта — это расписанный задачами календарь работы в рамках текущей итерации. В нем отображается оставшийся до конца спринта объем работы. Команда регулярно оценивает график и при необходимости оперативно реагирует на какие-либо изменения.
Особое внимание календарю уделяет владелец продукта. По нему оценивается скорость работы и соблюдение дедлайнов. Например, если со временем объем работы не уменьшается, значит, в процессе есть какие-то отклонения и требуется срочная корректировка действий команды.
Scrum ceremonies or events
Some of the more well-known components of the scrum framework are the set of sequential events, ceremonies, or meetings that scrum teams perform on a regular basis. The ceremonies are where we see the most variations for teams. For example, some teams find doing all of these ceremonies cumbersome and repetitive, while others use them as a necessary check-in. Our advice is to start out using all of the ceremonies for two sprints and see how it feels. You can then perform a quick retro and see where you might need to adjust.
Below is a list of all the key ceremonies a scrum team might partake in:
Organize the backlog: Sometimes known as backlog grooming, this event is the responsibility of the product owner. The product owner’s main jobs are to drive the product towards its product vision and have a constant pulse on the market and the customer. Therefore, he/she maintains this list using feedback from users and the development team to help prioritize and keep the list clean and ready to be worked on at any given time. You can read more about maintaining a healthy backlog here.
Sprint planning: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific use stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.
At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered.
All the events — from planning to retrospective — happen during the sprint. Once a certain time interval for a sprint is established, it has to remain consistent throughout the development period. This helps the team learn from past experiences and apply that insight to future sprints.
Daily scrum or stand up: This is a daily super-short meeting that happens at the same time (usually mornings) and place to keep it simple. Many teams try to complete the meeting in 15 minutes, but that’s just a guideline. This meeting is also called a ‘daily stand-up’ emphasizing that it needs to be a quick one. The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours.
The stand up is the time to voice any concerns you have with meeting the sprint goal or any blockers.
A common way to conduct a stand up is for every team member to answers three questions in the context of achieving the sprint goal:
• What did I do yesterday?
• What do I plan to do today?
• Are there any obstacles?
However, we’ve seen the meeting quickly turn into people reading from their calendars from yesterday and for the next day. The theory behind the stand up is that it keep distracting chatter to a daily meeting, so the team can focus on the work for the rest of the day. So if it turns into a daily calendar read-out, don’t be afraid to change it up and get creative.
Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment, although in most cases the increment is released.
This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session. For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.
Sprint retrospective: The retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time, and less about what went wrong.
Инспекция (Inspection)
Один из трёх Принципов Скрама. Для своевременного выявления нежелательных отклонений участники Скрам процесса должны регулярно инспектировать (проверять) его артефакты и прогресс движения к Цели Спринта и Цели Продукта. Однако проверки не должны быть настолько частыми, чтобы мешать работе. Инспекция делает возможной адаптацию. Мероприятия Скрама спроектированы так, чтобы стимулировать как инспекцию, так и адаптацию.
Three essential roles for scrum success
A scrum team needs three specific roles: product owner, scrum master, and the development team. And because scrum teams are cross-functional, the development team includes testers, designers, UX specialists, and ops engineers in addition to developers.
Scrum articles
Sprints
A sprint is a short, time boxed period when a scrum team works to complete a set amount of work.
Sprint Planning
Sprint Planning is an event in scrum that defines what can be delivered in the upcoming sprint and how that work will be achieved.
Four agile ceremonies, demystified
Learn how to facilitate great agile ceremonies like sprint planning, daily stand-ups, iteration review and retrospectives.
The product backlog: your ultimate to-do list
What is a product backlog in agile or scrum? Learn about the best practices for managing and prioritizing a healthy product backlog.
Three steps to better sprint reviews
Learn how sprint reviews demonstrate the hard work of the entire team: designers, developers, and the product owner.
Standups for agile teams
Learn how standups contribute to a healthy agile program and some tips and tricks for you and your team.
What is a Scrum Master?
Learn what a Scrum Master is (and what they are NOT), and how the role supports and works with other members of an agile team.
Agile retrospectives: Use the past to define the future
A retrospective helps teams perform better over time. See what the agile community is saying and learn how to run your own retrospective meetings.
Agile Scrum Roles
Learn about the responsibilities and activities associated with the three major agile scrum roles: scrum master, product owner, and development team.
Scrum of scrums
Scrum of scrums is a scaled agile technique that offers a way to connect multiple teams who need to work together to deliver complex solutions. Learn how to scale scrum with examples from Atlassian and others.
Learn scrum with Jira Software
A step-by-step guide on how to drive a scrum project, prioritize and organize your backlog into sprints, run the scrum ceremonies and more, all in Jira.
From silo to cohesion with Jira Scrum Boards
The Jira Scrum Board is the visual display of progress during the development cycle.
Журнал продукта
Журнал продукта в самом начале готовит владелец. Документ (артефакт) включает в себя требования, отсортированные по значимости. Первичную версию дополняют разработчики: оценивают стоимость реализации каждого требования.
Бэклог продукта должен включать в себя не только технические аспекты, необходимые для реализации, но и функциональные. Для каждого требования определяется приоритет (например, от 1 до 5). Самые приоритетные описываются детально, чтобы команда смогла оценить их и протестировать.
Владелец продукта обязан не только подготовить журнал продукта, но и предоставить его в оговоренные сроки. В противном случае своевременная реализация проекта невозможна.
Как правильно внедрить Scrum-методологию
Для повышения эффективности работы команды необходимо правильное внедрение Scrum-методологии. Допущенные ошибки могут не только ничего не изменить, но и негативно сказаться на продуктивность.
Если вы решились на изменения, проводите внедрение поэтапно:
- Соберите команду. Основной шаг, от которого зависит успех продукта в будущем. Подбирайте квалифицированных специалистов, имеющих практический опыт в своей сфере. Не жалейте времени и помните: сбор кросс-функциональной команды — непростая задача.
- Назначьте владельца продукта. Эту роль отдайте заказчику или его представителю. Важно, чтобы человек имел опыт работы в этом направлении, так как от него зависит взаимодействие внутри команды и между заказчиком.
- Выберите скрам-мастера. Найдите человека, который хорошо знаком с методологией и имеет практический опыт ее внедрения в команду разработчиков. От него зависит, насколько комфортно будет протекать реализация нового продукта.
- Создайте список требований к продукту. Обдумайте требования к проекту. Желательно, чтобы в обсуждениях участвовал весь коллектив. Это позволит определить самые важные моменты. Должно получиться что-то вроде технического задания, которое направит разработку в нужное русло.
- Запланируйте спринты. Разделите разработку на несколько мелких и последовательных этапов. Изначально уделите внимание только первым итерациям. Не стоит планировать сразу всю реализацию, так как впоследствии потребуется внесение правок.
- Анализируйте и оценивайте результаты. После окончания каждого спринта проводите анализ и оценивайте результаты. К следующему этапу разработки приступайте только при полной удовлетворенности итогами предыдущего.
Кому-то из команды нововведения могут не понравиться. Это естественно, когда люди противятся чему-то новому. Ваша задача — донести до каждого члена команды пользу новой методологии.
Адаптация (Adaptation)
Один из трёх Принципов Скрама. При обнаружении отклонений от допустимых пределов одного или несколько элементов процесса или продукта, и если эти отклонения могут привести к бесполезности продукта, следует внести соответствующие изменения – либо в процесс, либо в разрабатываемые материалы (продукт).
Скрам предписывает четыре формальных мероприятия для инспекции и адаптации:
- Планирование Спринта
- Ежедневный Скрам
- Обзор Спринта
- Ретроспектива Спринта
Эмпиризм (Empiricism)
Скрам основывается на теории управления эмпирическими процессами – эмпиризме. Согласно этой теории, знания приобретаются опытным путем, а решения принимаются на основе реальных данных. Скрам использует итеративно-инкрементальный подход для повышения предсказуемости и управления рисками. В основе эмпиризма лежат три главных принципа: прозрачность, инспекция и адаптация.
Артефакты Scrum
Scrum-проекты включают в себя три важных документа, их еще называют артефактами:
- Журнал продукта (Product Backlog).
- Журнал спринта (Sprint Backlog).
- График спринта (Burndown Chart).
Скрам-команда
Вот, пожалуй, главная особенность Скрама в сравнении с другими подходами, следующими ценностям Agile-манифеста:
Основная единица Scrum — небольшая команда людей, Scrum Team. … Scrum Teams являются кросс-функциональными, то есть, их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint. Также они самоуправляемы, то есть, сами решают, кто, что, когда и как делает.
Руководство по Scrum 2020”
Именно c самоуправлением и кросс-функциональностью связан тот факт, что Скрам, несмотря на всю его простоту, достаточно сложно применять на практике. Откуда возникает потребность в самоуправлении/кросс-функциональности и как она реализуется в Скраме для IT-команд — рекомендуем посмотреть в 10-минутном видео от Асхата Уразбаева:
А в статье «От контроля к самоорганизации в команде» вы можете найти перечень проблем, с которыми сталкиваются команды на пути к самоуправлению, и рецепты для руководителей о том, как эти проблемы решать.
Scrum artifacts
Let’s start with identifying the three artifacts in scrum. Artifacts are something that we make, like a tool to solve a problem. In scrum, these three artifacts are a product backlog, a sprint backlog, and an increment with your definition of “done”. They are the three constants in a scrum team that we continue to revisit and invest in overtime.
- Product Backlog is the primary list of work that needs to get done maintained by the product owner or product manager. This is a dynamic list of features, requirements, enhancements, and fixes that acts as the input for the sprint backlog. It is, essentially, the team’s “To Do” list. The product backlog is constantly revisited, re-prioritized and maintained by the Product Owner because, as we learn more or as the market changes, items may no longer be relevant or problems may get solved in other ways.
- Sprint Backlog is the list of items, user stories, or bug fixes, selected by the development team for implementation in the current sprint cycle. Before each sprint, in the sprint planning meeting (which we’ll discuss later in the article) the team chooses which items it will work on for the sprint from the product backlog. A sprint backlog may be flexible and can evolve during a sprint. However, the fundamental sprint goal – what the team wants to achieve from the current sprint – cannot be compromised.
- Increment (or Sprint Goal) is the usable end-product from a sprint. At Atlassian, we usually demonstrate the “increment” during the end-of-sprint demo, where the team shows what was completed in the sprint. You may not hear the word “increment” out in the world, as it’s often referred to as the team’s definition of “Done”, a milestone, the sprint goal, or even a full version or a shipped epic. It just depends on how your teams defines “Done” and how you define your sprint goals. For example, some teams choose to release something to their customers at the end of every sprint. So their definition of ‘done’ would be ‘shipped’. However, this may not be realistic of other types of teams. Say you work on a server-based product that can only ship to your customers every quarter. You may still choose to work in 2-week sprints, but your definition of ‘done’ may be finishing part of a larger version that you plan to ship together. But of course, the longer it takes to release software, the higher the risk that software will miss the mark.
As you can tell, there are lots of variations, even within artifacts, that your team can choose to define. That’s why it’s important to be remain open to evolving how you maintain even your artifacts. Perhaps your definition of ‘done’ provides undo stress on your team, and you need to go back and pick a new definition.
You should be just as agile with your framework as you are with your product. Take the necessary time to check in on how things are going, make adjustments if needed, and don’t force something just for the sake of consistency.
Scrum, kanban, and agile
Scrum is such a popular agile framework that scrum and agile are often misunderstood to be the same thing. But there are other frameworks, like kanban, which is a popular alternative. Some companies even choose to follow a hybrid model of scrum and kanban, which has acquired the name of "Scrumban" or "Kanplan," which is Kanban with a backlog.
Both scrum and kanban use visual methods such as the scrum board or kanban board to track the progress of work. Both emphasize efficiency and splitting complex tasks into smaller chunks of manageable work, but their approaches towards that goal are different.
Scrum focuses on smaller, fixed-length iterations. Once the time period for a sprint is finalized, the stories or product backlog entries that can be implemented during this sprint cycle are then determined. In kanban, however, the number of tasks or the work in progress (WIP limit) to be implemented in the current cycle is fixed at first. The time taken to implement these features is then calculated backward.
Kanban is not as structured as scrum. Other than the WIP limit, it is fairly open to interpretation. Scrum, however, has several categorical concepts enforced as part of its implementation such as sprint review, retrospective, daily scrum, etc. It also insists on cross-functionality, which is the ability of a scrum team to not depend on external members to achieve their goals. Putting together a cross-functional team is not straightforward. In that sense, kanban is easier to adapt whereas scrum can be considered as a fundamental shift in the thought process and functioning of a development team.
Скрам-мастер
Скрам-мастер отвечает за соблюдение методологии Scrum в работе: контролирует инициативность и самостоятельность всех членов команды, удовлетворенность получаемыми результатами, атмосферу в коллективе и итоги работы в общем.
Причем важно понимать, что скрам-мастер — это не просто какое-то обособленное лицо, наблюдающее за разработкой со стороны. Он — член команды и должен наравне с контролем принимать непосредственное участие в технической реализации продукта.
Скрам-мастер отвечает за взаимодействие всех членов команды между собой, поддержание работоспособности на высоком уровне, устранение проблем, следованием намеченному графику работ.
Примерный перечень обязанностей скрам-мастера:
- создание доверительной атмосферы;
- участие в общих встречах и обеспечение успешной коммуникации участников;
- устранение препятствий в работе;
- обозначение проблем и открытых вопросов;
- обеспечение соблюдения практик процесса.
Базовые принципы Scrum
У методологии есть несколько базовых принципов, которые помогают ориентироваться на клиента и давать ожидаемый результат при минимальных ресурсных и временных затратах.
Базовые принципы Scrum:
- Работа короткими циклами (спринтами). Проект делится на части (спринты) и реализуется поэтапно. Спринт длится до момента окончания работы над определенной частью продукта.
- Гибкость. После окончания каждого спринта проводится тестирование. При наличии ошибок меняется стратегия реализации или пересматривается список текущих задач (бэклог) по продукту.
- Пользователи и заказчик участвуют в разработке. В любой скрам-команде есть «владелец продукта» — заказчик или его представитель. Через него команда взаимодействует с пользователями, которые участвуют в тестировании проекта по окончанию каждого спринта. Владелец продукта собирает фидбэк, передает команде и на основе этих данных принимаются решения по дальнейшему развитию.
- Взаимодействие команды. Scrum-team — это несколько человек, которые взаимодействуют друг с другом и стремятся к достижению общей цели.
The scrum master
Scrum masters are the champions for scrum within their teams. They coach teams, product owners, and the business on the scrum process, and look for ways to fine-tune their practice of it.
An effective scrum master deeply understands the work being done by the team and can help the team optimize their transparency and delivery flow. As the facilitator-in-chief, he/she schedules the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.
The scrum development team
Scrum teams get s*%& done. They are are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually five to seven members. One way to work out the team size is to use the famous ‘two pizza rule’ coined by Jeff Bezos, the CEO of Amazon (the team should be small enough to share two pizzas).
Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams are self-organising and approach their projects with a clear ‘we’ attitude. All members of the team help one another to ensure a successful sprint completion.
The scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.
Читайте также: