Скрам — це ефективне управління проєктами

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

1. люди і взаємодії важливіші, ніж процеси й інструменти;
2. працююча програма важливіша, ніж вичерпна документація;
3. співпраця з Замовником важливіша за узгодження умов контракту;
4. готовність до змін важливіша, ніж вірність початковому плану.

Aджайл-маніфест — це скоріше посібник про аджайл і його використання, ніж методологічний припис. Цінності й принципи Аджайл-маніфесту передбачають його адаптацію під кожну конкретну ситуацію. Тому аджайл втілюється в різних фреймворках.

Один із найрозповсюдженіших фреймворків — скрам. Згідно з опитуванням ScrumAlliance за 2015 рік (2015 State of Scrum Survey Report), скрам широко застосовується і буде застосовуватися в різних бізнес-галузях для успішної розробки різних проєктів. Ця стаття присвячена скрам-фреймворку, його історії, перевагам використання скраму в компаніях, його обмеженням і тому, як застосовувати скрам-структуру в вашій організації.

Що таке скрам

Будь-яка розмова про успішне управління проєктами через скрам має починатися з визначення скраму.

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

«У скрамі є система ролей, подій, правил і артефактів. У цій моделі за створення й адаптацію робочих процесів відповідають команди».

«У скрамі використовуються ітерації фіксованої тривалості, які називаються спринтами. Зазвичай вони займають 1-2 тижні (не більше 1 місяця). Скрам-команди прагнуть створювати готовий до релізу (якісно протестований) інкремент продукту в кожній ітерації».

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

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

Приходьте на Scrum Core 2.0

Чим не є скрам

Скрам — не лінійний метод розробки; це не каскадна модель. Каскадна модель (англ. waterfall) — лінійна послідовність подій, коли продукт планують, розробляють, тестують і так далі в суворій послідовності. Жоден наступний етап не починається, допоки не завершено попередній.

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

Нащо потрібен скрам

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

1. Відгук на потреби клієнта. Компанії-розробники програм добре знайомі з вимогою «зробити на вчора». Традиційні організації, які працюють за методом водоспаду, вбудовують важливі фічі й функції у розклад з двома релізами на рік — і через це часто втрачають клієнтів. Ті, що не пішли зразу, можуть зостатися невдоволеними й покинути вас з часом, коли зустрінуть більш відповідального конкурента. Працюючи короткими й частими циклами, ви можете надавати клієнтам продукти практично зразу за вимогою, а також швидше адаптуватися до нових вимог.
2. Зменшення вартості розробки. Aджайл і скрам довели свою економічність і ефективність. У цих моделях ролі розробників більш різноманітні, адже невеликі одиниці можна ефективно тестувати тією ж командою, котра їх розробила. Спеціалізація зникає чи скорочується, скорочуючи витрати.
3. Задоволення роботою. Постачаючи продукти швидко, команда переживає ситуацію успіху щоразу, коли роботу виконано і представлено до релізу. Кожна команда розробки знає, як це приємно. Зі скрамом команда радіє релізу не двічі, а як мінімум дванадцять разів на рік.
4. Більше швидких доходів. Кошти від клієнтів також надходять не двічі на рік, а значно частіше. Нові фічі також можна додавати частіше, завдяки чому вдається приводити більше клієнтів і швидше обробляти їхні особливі потреби.

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

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

Назва «скрам» походить із дослідження Такеючі й Нонаки 1986 року «Розробка нових продуктів: нові правила гри» (The New New Product Development Game). У цій статті говориться про те, що найкращий спосіб досягти мети — дати невеликій команді точний план дій.

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

Відтоді головний посібник зі скраму — Скрам Гайд — регулярно обновлялось. Самая свежая информация по нему содержится в Скрам Гайде 2020 года, а в этой статье мы коротко приводим основные ее разделы.

Як працює структура скраму

Процес розробки за скрамом

Скрам як фреймворк управління проєктами базується на тому, що самоорганізовані команди постачають закінчені продукти у фіксовані терміни, які також називаємо спринтами. Щоб успішно застосовувати скрам, потрібно використовувати його структуру. Вона складається з ролей, подій, правил і артефактів.

Ролі в скрамі

У скрамі існує три ролі, що разом утворюють скрам-команду.

1. Власник продукту — апологет продукту, який повністю розуміє його цінність для бізнесу. Ця людина доносить потреби замовника і стейкхолдерів до розробників, але не відповідає за технічний бік процесу. Власник продукту також відповідає за історії користувачів і визначає їх пріоритетність.

2. Розробники виконують всі технічні задачі. Вони кросфункціональні, їхня кросфункціональність залежить від області роботи. Так чи інакше, розробники завжди відповідають за створення беклогу спринту, забезпечення якості відповідно до визначення готового, адаптацію плану щодо цілі спринту і власні експертні зони відповідальності.

3. Скрам-майстер виступає фасилітатором роботи скрам-команди. Скрам-майстер допомагає власнику продукту і розробникам виконувати роботу без перешкод і відволікаючих факторів. Уся комунікація людей з-поза команди з командою розробки відбувається через скрам-майстра. (Часом скрам-команди взаємодіють у форматі скраму скрамів, коли скрам-майстри команд мають власні окремі зустрічі).

Події в скрамі

Існує п’ять типів скрам-подій:

1. Спринт (Sprint) — самісіньке серце скраму, де ідеї набувають цінності. Всередині спринту виконується вся робота, необхідна для досягнення цілі продукту, в тому числі планування спринту, дейлі скрами, огляд і ретроспектива спринту.
2. Планування спринту (Sprint Planning) — в ньому беруть участь усі члени скрам-команди. На цій зустрічі відбувається презентація продукту. Кожен член команди може висловитися про те, що цікавить або турбує його. Під час зустрічі встановлюються пріоритети й оцінюються терміни.
3. Дейлі скрам (Daily Scrum) — скрам-події, які проходять щодня під час спринтів. Вони короткі (до 15 хвилин) і призначені для планування денного розкладу розробників. На цих зустрічах обговорюють робочі труднощі, пояснюють незрозумілі історії користувачів. Дейлі є обов’язковим для розробників. Присутність скрам-майстра необов’язкова.
4. Огляд спринту (Sprint Review) — демонстрація діючого продукту, розробленого протягом спринту. Ця подія відбувається наприкінці спринту і призначена в першу чергу для того, щоб детально продемонструвати досягнення стейкхолдерам.
5. Ретроспектива спринту (Sprint Retrospective) — щось схоже на розтин. Це обговорення того, як команда спрацювала протягом спринту, і пошук, як підвищити якість її роботи в майбутньому.

На додаток до цих подій під час спринту команди можуть проводити також уточнення беклогу (Backlog Refinement) — обговорювати елементи беклогу й готуватися до наступного спринту. В рамках цієї зустрічі можна обговорити пріоритетність елементів і розділити елементи беклогу на дрібніші складові.

Артефакти

Aртефакти скраму — це робота, яку потрібно виконати, щоб завершити проєкт або спринт. Завдяки їм інформація про проєкт залишається прозорою для всіх, хто над ним працює.

Існує три обов’язкові/основні артефакти у скрамі — беклог продукту, беклог спринту й інкремент. Вони необхідні, щоб постачати програмне забезпечення, яке буде цінним для ваших замовників. Є й необов’язкові артефакти, які, втім, можуть полегшити життя вашої команди (наприклад, берн-даун чати).

Aртефакти спринту і їх компоненти — це:

• Беклог продукту — всі необхідні дії, пов’язані з користувацькою і технічною сторонами проєкту.
• Беклог спринту — сукупність всіх задач, які потрібно виконати протягом ітерації спринту. Його отримують із беклогу продукту під час планування спринту.
• Інкремент — це сума всіх елементів беклогу продукту, виконаних під час спринту, а також цінність інкрементів усіх попередніх спринтів. До закінчення спринту новий інкремент має бути готовий, тобто працездатний і відповідний визначеним раніше критеріям готовності.
• Елемент беклогу продукту — частина роботу, яку слід виконати протягом ітерації спринту. Зазвичай розбивається на декілька малих задач.
• Ціль спринту — те, що треба зробити, щоб виконати елемент беклогу продукту.
• Бьорн-даун чат спринту — робота, що залишається до повного виконання задач спринту. Бьорн-даун чат може мати висхідний або низхідний характер, залежно від того, з чим стикається команда при виконанні задачі. Він слугує не звітом про прогрес команди, а методом подолання труднощів і підтримки активності.
• Реліз продукту/бьорн-даун чат продукту — наприкінці кожного спринту оновлюється скрам-майстром. Горизонтальна вісь відповідає спринтам, вертикальна — показує, скільки роботи (на початку кожного спринту) залишилось до кінця проєкту.

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

Ролі, події й артефакти — основні правила скраму, та є й інші, що також підвищують ефективність процесу:

• Скрам-команда складається тільки з власника продукту, скрам-майстра і команди розробки;
• усі спринти повинні мати однакову тривалість;
• по завершенню одного спринту відразу ж починається інший;
• кожен спринт починається з планування спринту. Команда розробки щоранку проводить дейлі скрам;
• у кожному спринті проводиться огляд спринту, щоб стейкхолдери могли надавати зворотний зв’язок;
• доповнювати беклог спринту під час спринту — не найкраща практика.

Більше інформації щодо термінології скраму можна отримати з глосарію.

Обмеження в скрамі

• Scrum часто спричиняє скорочення об’єму робіт через відсутність загального дедлайну проєкту;
• високі шанси провалити проєкт, якщо команда не надто зацікавлена чи не готова до співпраці;
• застосовувати структуру Scrum у великих командах складно, але можливо. Для цього існують фреймворки масштабування: LeSS, SAFe, Nexus та інші;
• якщо один із членів команди звільниться під час проєкту, це може дуже негативно вплинути на проєкт.

Яка аджайл-методологія підійде вашій команді?

Як і при прийнятті будь-якого іншого важливого рішення, при виборі аджайл-методології слід спершу розглянути варіанти. Наприклад, eXtreme Programming (XP).

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

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

Перекладено, адаптовано й доповнено командою BrainRain у відповідності з єдиним офіційним документом, де пояснюється зміст скраму — Скрам Гайдом (The Scrum Guide Reordered, 2020).

Что такое Scrum и как начать с ним работать

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

Что такое Scrum?

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

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

В этой статье мы рассмотрим, из чего состоит традиционная методика Scrum. В этом нам помогут руководство по Scrum и Дэвид Уэст, генеральный директор компании Scrum.org. Мы также рассмотрим на примерах, как наши клиенты отходят от базовых принципов ради достижения уникальных целей. Для этого специалист нашей компании, менеджер группы продуктов Jira Software и бывший тренер по Agile Меган Кук поделится советами и рекомендациями в рамках серии видеороликов «Тренер по Agile»:

Статьи по теме Scrum

Спринты

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

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

Планирование спринта — это событие в scrum, в рамках которого определяется объем работы на следующий спринт и критерии выполнения этой работы.

Развеиваем мифы о четырех agile-собраниях

Узнайте, как проводить первоклассные agile-собрания, такие как планирования спринта, ежедневные стендапы, обзоры итогов итерации и ретроспективы.

Бэклог продукта — совершенный список задач

Что такое бэклог продукта в agile или Scrum? Ознакомьтесь с рекомендациями по управлению успешным бэклогом продукта и расстановке приоритетов.

Три шага к эффективному обзору итогов спринта

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

Стендапы для agile-команд

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

Кто такой scrum-мастер?

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

Ретроспективы agile: используйте прошлое, чтобы определять будущее

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

Agile-роли в scrum

Узнайте об обязанностях и объеме работ, связанных с тремя основными agile-ролями в scrum: scrum-мастер, владелец продукта и команда разработчиков.

Scrum of scrums

Scrum of scrums — это масштабируемая agile-техника, предлагающая способ объединения нескольких команд, которые должны работать вместе для поставки сложных решений. Узнайте, как масштабировать доску Scrum с помощью примеров от Atlassian и других экспертов.

Изучите scrum с помощью Jira Software

Пошаговое руководство по ведению scrum-проекта, расстановке приоритетов в бэклоге, упорядочиванию работы в спринты, проведению scrum-собраний, другим вопросам — и все это в Jira.

Сделайте команду сплоченнее с помощью Scrum-досок Jira

Scrum-доска Jira визуально отображает прогресс по ходу разработки.

Сравнение Agile и Scrum

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

Различие между определениями Agile и Scrum можно найти в руководстве по Scrum и Манифесте Agile. В этом манифесте приведены четыре ценности.

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

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

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

Методика Scrum

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

Члены scrum-команды

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

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

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

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

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

Scrum-мастер

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

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

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

На scrum-команды ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные scrum-команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос: в команде должно быть столько участников, чтобы им хватало двух пицц.

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

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

Артефакты Scrum

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

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

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

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

Собрания или мероприятия Scrum

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

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

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

Стендап — подходящее время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.

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

• Что мне удалось сделать вчера?

• Что я планирую сделать сегодня?

• Может ли мне что-то помешать?

Начните бесплатно с шаблоном Scrum для Jira

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

Ценности Scrum

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

Подтверждение

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

Смелость

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

Ключевая деятельность

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

Открытость

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

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

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

Уважение

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

Scrum, Kanban и agile

Scrum — настолько популярная agile-методика, что слова Scrum и Agile многие ошибочно используют как синонимы. Но есть и другие популярные методики, например Kanban. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.

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

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

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

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

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

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

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

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

Чтобы изучить Scrum с помощью Jira Software, прочитайте это руководство.

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она написала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

Начните бесплатно с шаблоном Scrum для Jira

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