Что такое ежедневный scrum
Что такое Scrum и как правильно использовать его в рабочем процессе
Что такое Scrum
Коротко говоря, Scrum — это способ организации рабочего процесса. Он пришел из мира разработки программного обеспечения и сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам же термин пришел из регби и в переводе с английского означает «схватка».
Scrum принадлежит к Аgile — семейству »гибких» подходов к организации процессов. Он состоит из минимального количества элементов, которые помогают успешно организовать работу. При помощи метода Scrum можно быстро и эффективно разработать принципиально новый продукт, аналогов которому нет на рынке.
Особенность Scrum заключается в командном подходе и нестандартном распределении обязанностей внутри коллектива. В процессе участвуют не только сотрудники компании, но и бизнес-заказчики, которые должны включаться в процесс создания продукта чаще, чем при других подходах, и делать это преимущественно в личном общении, а не через документы. Команде приходит постоянная обратная связь от заказчика, что позволяет не сбиться с пути.
Если компания создает новый продукт, но имеет мало представлений о результате, к которому хочет прийти, и не видит перед собой четкий план, — методология Scrum поможет справиться с этой проблемой. Она позволяет постепенно идти к нужному результату и на протяжении всего пути проверять эффективность и ценность проделанной работы. Команда придет к итогу, который полностью устроит заказчика.
Состав scrum-команды
В первую очередь в команду входят разработчики. Так в Scrum называют специалистов, которые вносят вклад в продукт. Все разработчики — часть единой команды. У них нет отдельных заданий или подкоманд. При методе Scrum все работают как единое целое. Состав группы не должен меняться, поэтому важно, чтобы в нее изначально входили все необходимые для проекта профессионалы. Так команда становится независимой от всех внешних воздействий и может функционировать без посторонней помощи.
У сложившейся команды не должно быть лидера. Работа строится на взаимном обмене мнением и знаниями, за счет чего стимулируется кросс-функциональность. Разработчики дополняют друг друга и решают поставленные задачи совместными усилиями. Со временем команда становится все более сплоченной, что положительно влияет на ее продуктивность.
Для успешной работы в команде должно быть от пяти до девяти человек. Если проект большой, набирают несколько команд, которые распределяют между собой задачи.
В работе команды должен участвовать владелец продукта — сам заказчик или его представитель. Он консультирует разработчиков, передает свежие требования компании к будущему продукту и следит за тем, чтобы работа шла в верном направлении.
Третий элемент команды — scrum-мастер. Он выступает в роли куратора и помогает коллективу сплотиться. Мастер проводит ежедневные собрания, помогает найти выход из тупикового этапа разработки и перевести команду на нужное направление. Главный успех scrum-мастера — сделать так, чтобы команда стала самоуправляемой и перестала в нем нуждаться. В идеале должны остаться только разработчики и владелец продукта.
Основные принципы работы по Scrum
После создания команды нужно определить список требований к продукту и составить техническое задание, которое получат разработчики. Далее работу делят на спринты — одинаковые промежутки времени, которые не должны длиться дольше четырех недель. Каждому кругу ставится конкретная цель. Количество таких спринтов неограниченно. В конце спринта команда должна приходить к результату и получать обратную связь от заказчиков о проделанной работе.
Спринт считается завершенным, если команда смогла прийти к цельному итогу и создала продукт, который готов к использованию. К следующему спринту переходят только тогда, когда заказчики и члены команды довольны результатами предыдущего. Если разработчики не успевают уложиться в оговоренные сроки, они сообщают об этом владельцу продукта, и он перераспределяет время. Если команда справляется с задачей быстрей назначенного срока, она может подключить в текущий спринт дополнительные цели.
Чем Scrum отличается от Kanban
Метод управления проектами Kanban также принадлежит семейству Agile. Но Scrum — это структурированный подход с четко прописанными этапами создания продукта, а Kanban — сбалансированный. Его главная задача — сделать так, чтобы у всех членов команды было одинаковое количество работы. В Kanban не должно быть переработок части команды и ситуаций, когда некоторые сотрудники осталась без задач и не знают чем себя занять.
Основное отличие двух методов — это спринты. В Scrum предусмотрены четко организованные периоды работы с конкретными задачами на период, а в Kanban участники команды могут получать новые задачи хоть каждый день. Scrum-команды выполняют работу на время, в Kanban задачи поступают в непрерывном режиме. Для отслеживания достижений и процесса в Kanban используют доски — элемент управления, который наглядно показывает уровень выполнения задач. В Scrum этой задаче служат окончания спринтов.
Преимущества Scrum
Scrum хорошо подходит для быстрого создания новых продуктов. Он помогает объединить сотрудников из разных подразделений и наладить между ними слаженную работу. В результате такой системы увеличивается эффективность рабочей команды.
Вице-президент «Ренессанс страхование» Владимир Тарасов рассказал РБК Трендам, к каким результатам пришла компания после применения метода:
«Мы теряли эффективность при передаче работы из одной функции в другую. Подразделения компании, противодействующие мошенничеству, обладали собственными целями. Каждый сотрудник отвечал за свою работу и выполнял ее хорошо. Но общий результат оставлял желать лучшего.
Мы организовали кросс-функциональные команды, взяв за основу Scrum. Команды, состоящие из инженеров-автотехников, сотрудников службы безопасности, риск-менеджмента и юристов, получили общую цель. Из Scrum мы взяли принцип работы итерациями, а также основные элементы фреймворка. Скорость взаимодействия функций и координация между сотрудниками разных функций увеличилась кратно. С лета прошлого года у нас функционирует уже семь таких команд.
Команды создали скоринги и уникальные критерии выявления мошенничества, снизили уровень латентного мошенничества до минимальных значений. Мы отсекаем мошенников от наших клиентов при первом обращении в компанию. В некоторых ситуациях даже удавалось выявить криминальные случаи еще до подачи заявления о страховой выплате. В итоге уровень страхового мошенничества в самых проблемных регионах снизился без преувеличения в разы и произошло это в течение примерно шести месяцев с момента запуска первой команды. Очень крутой и где-то неожиданный результат!»
Недостатки Scrum
Scrum помогает быстро и эффективно решать задачи, но он подходит не для всех компаний и не для всех ситуаций. Чтобы метод заработал, у компании должно быть поле для экспериментов. Если фирма выполняет задачи по заранее выстроенному алгоритму, знает к чему хочет прийти и как достичь результата, теряется смысл использования такого метода.
Владимир Тарасов:
«Scrum не подходит для текущей операционной деятельности. Он больше ориентирован на проекты. У нас не классический Scrum. Мы объединили текущую работу по конкретным страховым случаям с проектами и задачами на улучшение процесса, разработку и испытание новых инструментов. Scrum не дает ответа, как сочетать операционную работу с проектами. Мы придумали свои собственные инструменты сочетания несочетаемого. Сам фреймворк это допускает».
У компании должны быть ресурсы на запуск такой программы. Scrum предполагает, что команда работает с проектом, аналогов которому нет на рынке. Получается, успех его разработки может не оправдаться или занять слишком много времени. Фирма должна быть финансово готова к такому результату.
Scrum не подходит для слишком сложных и больших проектов. Можно создать несколько команд, которые будут работать над разными деталями идеи, но их будет сложно скоординировать, и работа может зайти в тупик.
После продолжительного времени работы команды Scrum приходят к упадку. Заканчивается творческий потенциал, и падает динамика производительности. Команды приходится разрушать или перестраивать, поэтому Scrum больше подходит для краткосрочных проектов.
Важный критерий успешной работы — заказчик должен быть готов к постоянному общению с командой. Он должен следить за развитием проекта и давать свой фидбек. Без такой обратной связи не получится использовать методику.
Как внедрить Scrum для управления бизнес-процессами
Чтобы внедрить метод в компанию и получить первые результаты, нужно минимум три месяца. Через такой промежуток времени команда начинает работать эффективно и сплоченно. При условии, что выполнены все необходимые условия.
Как внедрить Scrum в компанию
Подробную инструкцию по внедрению Scrum и о его процессах можно посмотреть в гайде или в книге от соавтора методологии Джеффа Сазерленда «Scrum: революционный метод управления проектами». О том, как правильно распоряжаться ресурсами и повышать личную эффективность, читайте в материале РБК Трендов про бережливое производство в жизни.
Ежедневный Скрам (Daily Scrum)
Ежедневный Скрам — это встреча, которая длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. Является одним из 5 Мероприятий Скрама. В нем принимают участие все разработчики Скрам-команды.
Руководство по Scrum 2020 следующим образом описывает цель и содержание Ежедневного Скрама:
Скрам-мастер (как ответственный за процесс в Скраме) не участвует активно в Ежедневном Скраме, если он сам не является одним из Разработчиков. Однако он обучает Разработчиков достигать целей Ежедневного Скрама и при этом укладываться в 15 минут.
Чтобы соблюсти это ограничение по времени, разработчикам рекомендуется проводить Ежедневный Скрам не в форме свободной дискуссии, а выработать какой-либо удобный для себя конкретный формат и придерживаться его на каждом Ежедневном Скраме. Например, неплохо себя зарекомендовал себя формат с ответами каждого разработчика на 3 вопроса (который был приведен в качестве примера в прежних Руководствах по Scrum, но в 2020 году был удален оттуда, чтобы не ограничивать Разработчиков этим конкретным форматом):
Главное — чтобы подобный формат не превратился в формальность, а действительно позволял всем видеть статус Бэклога Спринта, развивал командный дух и взаимопомощь, ускорял решение проблем.
Зачастую Ежедневный Скрам проводится вокруг Доски Спринта, которая как раз дает наглядное представление о препятствиях, которые могут помешать успешному завершению Спринта.
Одно из 5 Мероприятий Скрама. Проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Скрам-команда, при необходимости, сделала адаптацию Бэклога Продукта. Для Спринта длиной в месяц Обзор Спринта длится не более 4 часов.
Одно из 5 Мероприятий Скрама. На этой встрече Скрам-команды происходит планирование работы на следующий Спринт. Для Спринта длиной в месяц встреча длится не более 8 часов. Она завершается созданием Бэклога Спринта и включает обсуждение 3-х тем:
Одно из 5 Мероприятий Скрама. Ретроспектива Спринта дает Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием Спринта. Для Спринта длиной в месяц эта встреча ограничивается 3 часами.
Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.
Активность, которая проводится Владельцем Продукта при участии всех членов команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
Уточнение бэклога обычно занимает не более 10% времени Скрам-команды в Спринте.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Scrum
Узнайте о методике Scrum от экспертов
Просмотр тем
Что такое 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 визуально отображает прогресс по ходу разработки.
Платформа
Понятия Scrum и Agile часто путают, потому что Scrum строится вокруг идеи о постоянном совершенствовании, которое является главным принципом Agile. И все же Scrum — это методика работы, а Agile — это образ мышления. Перейти на Agile не так-то просто; вся команда должна стремиться изменить свой подход к созданию ценности для клиентов. Но можно просто начать использовать методику, такую как Scrum. Это направит мышление в нужное русло и поможет практиковать принципы Agile в повседневном общении и работе.
Методика Scrum по своей сути является эвристической. В ее основе лежит постоянное обучение и адаптация к изменчивым факторам. Согласно Scrum, команда не знает всего в начале проекта, но будет развиваться, извлекая уроки из опыта. В структуре Scrum заложена та свобода, с которой команды приспосабливаются к меняющимся условиям и требованиям пользователей. Рабочий процесс предусматривает изменение приоритетов и короткие циклы релиза, что способствует постоянному обучению и совершенствованию команды.
Структурированность не мешает методологии Scrum быть гибкой. Ее можно адаптировать к нуждам организации. Существует множество теорий о том, как следует применять Scrum, чтобы достичь успеха. Однако более чем десятилетний опыт содействия agile-командам в выполнении работы с помощью продуктов Atlassian подсказывает, что независимо от того, какую методологию вы выберете, ее главными принципами должны быть ясность коммуникации, прозрачность и стремление к постоянному совершенствованию. Остальное вы вольны выбирать сами.
Артефакты Scrum
Сначала определим три артефакта Scrum. Артефакт — это то, что мы создаем, например инструмент для решения проблемы. В Scrum существует три артефакта: бэклог продукта, бэклог спринта и инкремент с вашими критериями готовности. Эти три постоянные присутствуют в каждой команде Scrum, мы постоянно к ним обращаемся и уделяем им время.
Как видите, допустимы различные варианты, даже когда речь идет об артефактах, которым ваша команда может придавать ту или иную форму. Это показывает, почему важно оставаться открытыми к совершенствованию, в частности к совершенствованию способа ведения артефактов. Возможно, из-за принятых критериев готовности ваша команда испытывает чрезмерное давление и вам нужно пересмотреть эти критерии.
В отношении методологии нужно сохранять ту же гибкость, что и в отношении продукта. Уделите какое-то время оценке общей ситуации, при необходимости внесите поправки и не пытайтесь добиться чего-либо любой ценой просто потому, что «так принято».
Собрания или мероприятия Scrum
Чуть более известны такие составляющие методики Scrum, как последовательные мероприятия, церемонии или собрания, которые регулярно проводят команды Scrum. Именно в подходе к собраниям заметнее всего проявляются различия между командами. Некоторым командам в тягость проводить однообразные собрания; в других рабочие встречи обязательны. Если вы только начинаете знакомство со Scrum, рекомендуется в течение первых двух спринтов провести все собрания, чтобы понять свое отношение к ним. После этого можно организовать короткую ретроспективу, чтобы решить, что нужно скорректировать.
Перечислим основные собрания, в которых может принять участие команда Scrum.
Организация бэклога. За это мероприятие, также известное как ведение бэклога, несет ответственность владелец продукта. В число его основных обязанностей входят приведение продукта в соответствие с его концепцией и постоянное отслеживание настроений на рынке и потребностей клиента. Для этого владелец продукта и ведет список, изменяя в нем приоритеты и поддерживая его в актуальном виде на основании информации от пользователей и команды разработчиков, чтобы в любое время можно было приступить к работе над внесенными в него задачами. Подробнее о том, как правильно вести бэклог, можно прочитать здесь.
Планирование спринта. На этом собрании команда разработчиков под руководством Scrum-мастера планирует работу (объем спринта), которую необходимо выполнить в течение текущего спринта. На нем выбирается цель спринта. Затем в спринт добавляются конкретные пользовательские истории из бэклога продукта. Эти истории всегда соотносятся с целью. При этом команда Scrum согласовывает такие истории, которые можно будет реализовать на практике в ходе спринта.
В конце собрания по планированию каждый член команды Scrum должен четко представлять, какие задачи можно выполнить за спринт и как поставить инкремент.
Спринт. Спринт — это фактический промежуток времени, в течение которого команда Scrum совместно работает над созданием готового инкремента. Как правило, спринт длится две недели, хотя некоторым командам проще спланировать объем спринта на одну неделю или поставить инкремент, обладающий достаточной ценностью, за месяц. Дейв Уэст из Scrum.org рекомендует планировать спринт тем короче, чем сложнее работа и чем больше в ней неизвестных. Но последнее слово всегда за командой. Не стесняйтесь менять продолжительность спринта, если покажется, что она вам не подходит. В течение этого периода владелец продукта и команда разработчиков могут пересмотреть объем спринта, если это необходимо. Это и есть ключ к пониманию эмпирической сути Scrum.
Все мероприятия, от планирования до ретроспективы, проводятся в течение спринта. После того как временной промежуток для спринта определен, он должен оставаться неизменным, пока ведется разработка. Так команда будет извлекать ценные уроки из прошлого опыта и применять выводы к будущим спринтам.
Ежедневное Scrum-совещание, или стендап. Это очень короткое ежедневное собрание, которое для удобства проводится в одно и то же время (обычно утром) и в одном и том же месте. Многие команды стараются уложиться в 15 минут, однако это лишь рекомендация. Такое собрание также называется «ежедневным стендапом», что подчеркивает его краткость. Ежедневное Scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, не отклонялся от цели и получал план работы на ближайшие 24 часа.
Стендап — подходящее время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.
Чаще всего в рамках стендапа каждому участнику команды предлагается ответить на следующие три вопроса, связанные с достижением цели спринта:
• «Что мне удалось сделать вчера?»
• «Что я планирую сделать сегодня?»
• «Может ли мне что-то помешать?»
Впрочем, такое собрание может превратиться в зачитывание людьми записей из ежедневника. Стендап нужен, чтобы вся болтовня оставалась в рамках ежедневного собрания, а в остальное время команда могла сосредоточиться на работе. Поэтому если кто-то начинает просто зачитывать свой ежедневник, не стесняйтесь внести изменения в собрание; проявите смекалку.
Обзор итогов спринта. В конце спринта команда собирается для просмотра демонстрации инкремента (или для его изучения) в неформальной обстановке. Команда разработчиков представляет заинтересованным сторонам и коллегам завершенные рабочие задачи из бэклога, чтобы собрать отзывы. Владелец продукта решает, стоит ли выпускать инкремент, хотя в большинстве случаев команда получает зеленый свет.
На собрании по обзору итогов владелец продукта также изменяет бэклог продукта на основании результатов последнего завершенного спринта. Этот процесс может перейти в планирование следующего спринта. Если спринт длится один месяц, отводите под собрание для обзора итогов не более четырех часов.
Ретроспектива спринта. Ретроспектива проводится, чтобы команда зафиксировала и обсудила все успехи и неудачи спринта, проекта, участников и их взаимоотношений, инструментов или даже определенных собраний. Цель ретроспективы — создать условия, чтобы команда могла уделить внимание всему, что удалось и что нужно улучшить в следующий раз, и не зацикливалась на неудачах.
Три важнейшие роли, от которых зависит успех применения Scrum
Состав scrum-команды предполагает три отдельные роли: владелец продукта, scrum-мастер и команда разработчиков. Поскольку scrum-команды сочетают в себе множество функций, в команду разработчиков также входят тестировщики, дизайнеры, UX-специалисты и инженеры по операциям.
Владелец продукта Scrum
Владельцы ратуют за свой продукт. Их задача — понимать требования бизнеса, клиента и рынка. На основе этого понимания они расставляют приоритеты между рабочими задачами, которые техническая команда будет выполнять в соответствующем порядке. Об эффективных владельцах продукта можно сказать следующее.
Они решают, когда поставить продукт, стремясь делать это как можно чаще.
Роль владельца продукта не всегда совмещена с ролью менеджера продукта. Владельцы стремятся создать все условия, чтобы команда разработчиков создавала максимальную ценность для бизнеса. Важно, чтобы владельцем продукта был один человек. Вряд ли команда разработчиков захочет получать разные указания от разных владельцев одновременно.
Scrum-мастер
Scrum-мастера следят за применением принципов Scrum в своих командах. Они обучают команды, владельцев продуктов и остальную компанию тонкостям Scrum-процесса и стараются оптимизировать применение этой практики.
Успех Scrum-мастера зависит от того, насколько хорошо он разбирается в работе, которую выполняет команда, и может помочь команде повысить прозрачность работы и оптимизировать процесс поставки продукта. Это главный координатор, который составляет перечень требуемых ресурсов (кадровых и материально-технических) для собраний по планированию спринта и обзору его итогов, стендапа и ретроспективы спринта.
Команда разработчиков Scrum
На команды Scrum ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос (в команде должно быть столько участников, чтобы им хватало двух пицц).
Каждый участник команды обладает своими компетенциями. Участники обучают друг друга выполнению разных задач, чтобы ни один из них не стал препятствием на пути к цели. Успешные Scrum-команды способны к самоорганизации, и их подход к проектам пронизан командным духом. Все участники команды помогают друг другу, чтобы успешно завершить спринт.
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, преодолении разрозненности и развитии эмпатии.