Что такое спринты в эджайл
Спринты
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.
Просмотр тем
Что такое спринты?
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile, и правильный выбор спринтов поможет вашей agile‑команде выпускать более качественное программное обеспечение без лишней головной боли.
«При использовании scrum продукт разрабатывается в ходе нескольких итераций с фиксированной продолжительностью, которые называются спринтами и разбивают большие сложные проекты на небольшие задачи», — говорит Меган Кук, менеджер группы товаров для Jira Software в Atlassian.
Многие ассоциируют Scrum-спринты с Agile-разработкой программного обеспечения настолько часто, что Scrum и Agile принимают за синонимы. Однако это не так. Agile — это набор принципов, а Scrum — методика для активного решения задач.
Многочисленные сходства между глобальными задачами agile и процессами scrum вполне справедливо приводят к тому, что эти два понятия ассоциируются друг с другом. Благодаря спринтам команды могут следовать agile‑принципу «частой поставки рабочего программного обеспечения», а также реализовать agile‑задачу «реагирования на изменения в соответствии с планом». Установки scrum — прозрачность, проверка и адаптация — дополняют agile‑методику и играют главную роль в концепции спринтов.
Руководство по Scrum закладывает прочную теоретическую основу для обсуждения спринтов. Мы хотим внести немного красок в эту тему и делимся рекомендациями от людей, которые занимаются этой работой каждый день.
Как планировать и выполнять спринты в scrum
Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?
Выбором подходящих рабочих задач для спринта занимаются совместно владелец продукта, Scrum-мастер и команда разработчиков. Владелец продукта определяет цель спринта и задачи из бэклога продукта, при выполнении которых она будет достигнута.
Затем команда создает план, согласно которому будут выполняться задачи бэклога, чтобы к окончанию спринта вся работа была завершена. Выбранные рабочие задачи и план по их выполнению называется бэклогом спринта. К концу совещания по планированию спринта команда готова приступить к работе. Для этого необходимо просто выбирать задачи из бэклога спринта и менять их статус с «В работе» на «Готово» по мере завершения работы.
В течение спринта команда собирается на ежедневные Scrum‑совещания (стендапы), чтобы обсудить ход работы. Такие совещания нужны, чтобы выявить блокеры и проблемы, которые могут повлиять на достижение цели спринта.
По окончании спринта команда показывает выполненную работу на обзоре итогов спринта. Здесь можно продемонстрировать итоги работы заинтересованным сторонам и другим участникам команды до того, как они попадут в рабочую среду.
Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!
Что стоит и не стоит делать
Даже если основы уже известны, большинство команд спотыкается в начале работы со спринтами. Меган Кук завершает эту дискуссию списком действий, которые стоит и не стоит делать при использовании спринтов, которые она сформулировала за годы своей работы.
И если уж вы работаете над тем, чтобы стать сильным специалистом по scrum, выполняя рекомендации, ознакомьтесь также с действиями, которые выполнять не следует.
Чего не стоит делать.
Оптимизируйте спринты с помощью автоматизации
Когда вы поймете, как работают спринты, вы сможете оптимизировать процессы, используя автоматизацию. Вот три правила автоматизации, которые часто используются в спринтах Jira.
Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.
Подробнее о спринтах
Спринты настолько известны (и настолько эффективны), что их часто считают первым шагом на пути к повышению гибкости. Но мы выяснили, что для освоения спринтов необходимо овладеть некоторыми взаимосвязанными понятиями Scrum и Agile. Изучите остальные статьи по Scrum, чтобы расширить знания и стать еще на шаг ближе к счастью от использования Scrum.
Спринты
Спринты
Что такое спринты?
ТВИИТ :«Спринты делают проекты более управляемыми, позволяют командам быстрее и чаще выполнять высококачественную работу и дают им больше гибкости для адаптации к изменениям».
Многочисленные сходства между ценностями Agile и scrum-процессами приводят к справедливой ассоциации. Спринты помогают командам следовать Agile принципу «частой поставки рабочего программного обеспечения», а также использовать Agile ценность «реагирования на изменения в соответствии с планом». Scrum-значения прозрачности, проверки и адаптации дополняют Agile и играют центральную роль в концепции спринтов.
Как планировать и выполнять scrum-спринты
Затем команда создает план того, как они будут создавать элементы списка необходимых требований (backlog) и получать их «Готов(-ыми)» до конца спринта. Выбранные рабочие элементы и план их выполнения называются «спринтом списка необходимых требований (backlog)». К концу планирования спринта команда готова приступить к работе с списком необходимых требований (backlog) спринта, перенеся элементы из этого списка в «Выполняется» и «Готово».
Во время спринта команда проверяет, как продвигается работа во время ежедневного scrum или летучки. Целью этой встречи является выявление любых препятствий и проблем, которые могут повлиять на способность команд к достижению цели спринта.
После спринта команда демонстрирует, что они выполнили во время ревью спринта. Это возможность вашей команды продемонстрировать свою работу заинтересованным сторонам и партнерам по команде до того, как она попадет в производство.
Что можно и нельзя
Даже когда основы не работают, большинство команд спотыкаются, когда начинают запускать спринты. Меган Кук завершает эту дискуссию некоторыми вопросами о том, что можно и чего нельзя делать, которые она отобрала за эти годы.
Что можно:
Пока вы работаете над тем, чтобы быть звездой Scrum с этими «разрешениями» (“do’s,”), следите также за несколькими красными флагами:
Не рекомендуется:
Узнайте больше о спринтах
Спринты настолько известны (и настолько эффективны!), что их часто считают первым шагом на пути к большей гибкости. Как мы узнали, освоение спринтов требует овладения горстки scrum и Agile концепций, которые опираются друг на друга. Пожалуйста, используйте остальные наши статьи о scrum, чтобы пополнить свои знания и приблизиться к блаженству scrum.
По материалам Agile Coach «Sprints»
Agile по правилам Scrum
Что такое Scrum и как он работает?
Про людей и итерации
На заметку
Фреймворк — это руководство по организации рабочего процесса. Может содержать в себе описание типовых ролей, правил взаимодействия, событий рабочего процесса. Фреймворки опираются на принципы и ценности методологии.
Scrum заменяет запрограммированный алгоритмический подход эвристическим, основной упор в нем делается на уважение к людям и самоорганизацию, которые помогают справляться с непредсказуемостью и сложными проблемами.
Любопытно
Термин Scrum пришел из популярной американской игры регби. Дословно переводится как «схватка». Scrum формируется на игровом поле. От каждой команды участвуют по восемь игроков, которые обхватывают друг друга руками, выстроившись в три линии и сомкнувшись с соперниками.
Scrum прекрасно иллюстрирует итерационный подход, присущий гибким методологиям. Короткие отрезки разработки здесь называются спринтами, в финале которых команда презентует готовое решение, позволяющее протестировать какие-то гипотезы. По результатам каждого последующего спринта продукт становится все боле совершенным, приближаясь к тому состоянию, которое было задумано.
Любопытно
Спринт — тоже спортивный термин, означающий забег на короткое расстояние.
Длительность спринта варьируется от 1 до 4 недель, но обычно это 2 недели. Чем короче спринт, тем гибче процесс. В идеале каждый спринт должен иметь цель, которая мотивировала бы всю команду.
Плюс скрама в том, что изначально установленные требования в ходе работы могут меняться, если того требует рынок. В итоге вы с меньшей вероятностью получите на выходе продукт, который уже не отвечает запросам целевой аудитории.
Scrum на заводе Grass
От внедрения Scrum компания ожидала кратного роста выручки и выхода на новые рынки. Именно эти цели и были обозначены перед моей командой.
В результате внедрения Scrum заводу за год удалось добиться 40-процентного роста выручки по отношению к прошлогодним результатам и сократить время вывода нового продукта на рынок на 30%.
Среди дополнительных бонусов — увеличение количества обрабатываемых бухгалтерских документов вдвое при неизменном составе сотрудников. А также повышение вовлеченности и мотивации персонала, рост кроссфункциональных связей и прозрачности информации в компании, повышение предсказуемости бизнес-результатов.»
Алексей Дерюшкин, основатель Better Life Company, консультант по гибким методологиям в бизнесе
Scrum как театр
Скрам — ролевая практика, где ключевые функции выполняют:
Владелец продукта, или Product Owner — несет ответственность за получение максимальной ценности продукта. Он следит за ситуацией на рынке и в компании, общается с заказчиками и другими командами. На основании этого он корректирует процесс разработки таким образом, чтобы продукт получился максимально ценным. Владелец продукта создает бэклог и управляет им, исключая неактуальные задачи или добавляя новые. Он также отвечает за доступность и понятность бэклога для команды — все задачи должны быть описаны понятно для всех участников процесса. В больших продуктах владельцев продуктов может быть несколько.
Если команду рассматривать как микропредприятие внутри большой компании, то владелец продукта — микрособственник.
основатель Better Life Company, консультант по гибким методологиям в бизнесе
Если владелец продукта отвечает за результат, скрам-мастер — за процесс.
Скрам-команда, или Scrum Team — состоит из кроссфункциональных специалистов, например, дизайнеров, программистов, бизнес-аналитиков, юристов, маркетологов, инженеров и т.д. Руководство по скраму рекомендует включать в команду от 3 до 9 человек.
Если мы строим дом, то в короссфункциональной команде у нас будет архитектор, каменщик, логист, электрик, дизайнер. То есть все те люди, которые необходимы для того, чтобы построить дом.
Скрам-команды — самоорганизующиеся. Это значит, если у инженера проблема, он не будет сигнализировать о ней менеджеру и ждать, пока тот что-то предпримет. Наш инженер самостоятельно поймет причину проблемы, встретится с нужными людьми, выработает план действия и в конце концов решит проблему.
Никто в компании не диктует команде, как ей работать. Ее участники сами решают этот вопрос, самостоятельно определяя, что именно и как они будут делать. Владельцу продукта остается лишь контролировать процесс достижения цели.
Команде не нужно диктовать правила работы. Вы наняли профессионалов, так доверяйте им. Они работают «руками», они лучше знают, «как надо». Ставьте им цели и контролируйте их, но не вмешивайтесь в процесс.
Правила игры
Скрам разделяет проектную деятельность на ряд событий:
1. Планирование спринта. В ходе этого собрания, обычно длящегося 1-2 часа, команда самостоятельно выбирает из бэклога продукта ряд задач для спринта (цель спринта) и формирует из них список подзадач на данный период — бэклог спринта.
Основное правило: количество задач не ограничивается, а сами они не критикуются. После формирования списка задач для спринта проводится их приоритизация. В спорных вопросах последнее слово остается за владельцем продукта.
То, что команда самостоятельно определяет задачи и их число, повышает уровень вовлеченности участников в процесс и степень ответственности за результат.
2. Ежедневный скрам, дейли, дейли-митинг, стендап — 15-минутная ежедневная встреча команды и скрам-мастера. В ходе собрания каждый член команды рассказывает о том, что он сделал вчера и будет делать сегодня, какие видит препятствия для выполнения работы. Причины проблем и способы их устранения на собрании не обсуждаются. Цель ежедневного скрама — отслеживание хода работы команды.
3. Обзор спринта, демо — презентация продукта в конце спринта и получение обратной связи от заинтересованных сторон. На собрание приглашаются владелец продукта, представители целевой аудитории, высшее руководство, заказчики и другие заинтересованные стороны. Цель демо — получить обратную связь, на основе которой улучшить продукт. Обычно встреча длится 1-2 часа.
4. Ретроспектива спринта, ретро — после демо команда разработки вместе со скрам-мастером собирается и обсуждает рабочие процессы спринта: чего не хватало, какие были проблемы и что можно улучшить. Ретро — точка самоорганизации команды и ключ успеха в долгосрочной перспективе. Если вы правильно используете ретроспективы, то команда сильно прирастает по скорости и результатам.
Как запустить скрам
Процесс трансформации компаний небыстрый. Сначала подход отрабатывается в рамках пилота на одном подразделении компании, далее идет разворачивание на всю компанию и отработка практик. По данным исследования 2019 года, 73% компаний внедряют Agile в течение 3 лет экспериментов, а у 41% компаний это занимает не более одного года.
Среди главных проблем масштабирования:
Недостаточность опыта специалистов.
Непоследовательность внедрения практик и процессов.
Низкая вовлеченность бизнеса, заказчика или владельца продукта.
Доминирование традиционных подходов.
Противоречие корпоративной культуры ценностям Agile.
С другой стороны, к факторам, повышающим успех разворачивания гибких подходов управления проектами, можно отнести:
Поддержку руководства компании.
Поддержку изменений большинством сотрудников.
Согласованность между собой процессов и практик.
Внедрение общих инструментов между командами.
Давать рекомендации по внедрению Agile по скрам или с помощью любого другого фреймворка — дело неблагодарное, считает Алексей Дерюшкин. В каждом конкретном случае требуется свой подход. Однако ряд общих советов Алексей все же дает:
Управляйте не людьми, а задачами.
Уберите весь лишний контроль, кроме контроля за результатами.
Каждый день в одно и то же время проверяйте, как идут дела по реализации задач.
Не мешайте людям работать, но проверяйте, как достигаются цели.
Scrum и Agile для чайников
Комментарий Котиков
Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.
На этой неделе я прошла двухдневный тренинг по Agile/Scrum (произносится «эджайл» и «скрам»). По гибким методологиям разработки программного обеспечения написано много заумной и не очень литературы, многое я читала. Но только после двухдневного погружения в тему у меня наконец собралось базовое понимание предмета, из которого я пишу эту заметку.
Эджайл и скрам помогают организовать процесс работы в команде так, чтобы выпускать интересный пользователю продукт регулярно и часто.
В некоторых банках путь идеи к пользователям благодаря эджайлу сократили с двух лет до шести месяцев — в других компаниях шесть месяцев цикла разработки сжались в три. В наше суматошное время это истинное конкурентное преимущество, особенно для малых игроков.
Принципы скрама можно применить совершенно ко всему: например, к работе над творческим продуктом. Это, конечно, не «канонический эджайл», скрам-евангелисты будут скрежетать зубами, зато ваши процессы будут двигаться бодрее. Шашечки или ехать?
Кое-что из эджайла и скрама можно взять даже в индивидуальную работу. Обеспечить регулярную публикацию постов, отмерять нагрузку на исполнителя, оценивать будущие задачи по времени и не забывать анализировать качество проделанной работы — смотрите, за нас уже всё придумали. Осталось внедрить.
Эджайл
(англ.agile —«проворный, шустрый, сообразительный»)
Концепция гибкости:
Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.
«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?
Книжку «Открывая организации будущего» Фредерика Лалу я читала совсем недавно. Вполне бодрый подход ко всем отраслям на свете
Скрам
(англ. scrum — толкотня в борьбе за мячик в регби)
Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.
Жесткость скрама заключается в структуре. Есть некий набор подходов, работающих вместе лучше, чем по отдельности. Вытащить что-нибудь и заиспользовать вам, я надеюсь, никто не запретит.
Обычно скрам происходит там, где есть некий продукт, имеющий ценность для пользователей и заказчиков, и нужно как можно быстрее на пути к цели понимать, в том ли направлении мы сейчас бежим — или надо корректировать курс. Формат скрама позволяет выпускать очередную версию чаще, регулярно получать обратную связь и быстро дорабатывать продукт, а также — улучшать процесс работы.
Если вы работаете в команде, скрам предписывает всем участникам процесса стремиться к взаимозаменяемости, к способности «подхватить» провисающую задачу, если сосед заболел, к обмену навыками и коллективной ответственности за продукт. Индивидуализма в скраме мало. Решения принимаются коллективно (по строгим принципам), никто не может надавить и заставить выбрать другое решение, если команда уверена, что остановилась на верном.
Поэтому даже если мы все уверенно побежали в неправильном направлении, у нас будет в конце спринта возможность его скорректировать и починить то, что нас направляет не туда. Команда в скраме самоорганизующаяся и самонастраивающаяся.
Команда в скраме
Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.
В каждой команде есть:
Устройство спринт
Работа в скраме состоит из спринтов. Все спринты устроены одинаково. Предполагается, что с каждым следующим спринтом команда становится всё сыграннее и эффективнее. В скраме учишься на своих ошибках, но быстро — каждый спринт анализируешь, что именно натворил и как хочешь это исправить.
У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.
В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.
Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.
В начале своей жизни команда всегда плохо планирует. Это объективная реальность. Но она ведет статистику того, что ей удается сделать за спринт, и со временем планирует всё точнее. Ей помогает итоговая встреча спринта — ретроспектива. На ней можно обсудить слабые моменты уходящего спринта и придумать способы делать по-другому.
Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.
В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.
Результатом спринта всегда является что-то, что можно показать. Показывает работу команда на демо в конце спринта.
На мой взгляд, скрам-процесс похож на работу над коллективным блогом. Такой процесс помог бы соблюсти регулярность, свести воедино экспертизу авторов и не набирать столько, что не успеешь сделать.
Структура спринта
Спринт начинается с планирования: команда садится и обсуждает: вот эту идею берем, вон ту не берем. В IT этот процесс может затягиваться на пару часов, потому что обсуждение идет вплоть до деталей. В случае работы с блогом это может превратиться в обсуждение тем и плана статей, которые потом останется сесть и написать — понимая, что пишем, когда и зачем.
Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.
Каждый участник стендапа по очереди отвечает на три вопроса:
Все завязывающиеся в процессе детальные разговоры уходят за пределы стендапа. Стендап — это точка, в которой можно поймать проблемы или узнать, что мы с коллегой почему-то делаем одно и то же одновременно, а значит — кто-то из нас может заняться чем-то другим.
Вообще поддержанием всех вот этих четких правил поведения должен заниматься скрам-мастер. Это обычно идеологи технологии, верящие в нее и готовые выстраивать процесс для максимальной эффективности проведенного вместе времени. Без скрам-мастера процессы выродятся в минимально возможные, потому что человек ленив и экономичен.
В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.
«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)
Как использовать Agile и Scrum для управления проектами
Agile и Scrum для руководителя проекта — основы гибких методологий, инструкция по ведению бэклога и спринтам, контроль процессов и организация работы.
Для чего внедрять гибкие методологии
Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.
Неожиданности появляются не только из-за бизнес-процессов, здесь работает и человеческий фактор. Например, представители заказчика могут намеренно затягивать внедрение ПО, преследуя личные цели. Сбор требований на этапе аналитики тоже не дает стопроцентной точности — заказчики не расскажут вам все сразу. Плюс сейчас ПО требует мгновенной реакции на отзывы пользователей — подход с долгой тщательной подготовкой не работает.
Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.
Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.
Начните с бэклога
Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.
Вместо проектного задания используется бэклог — список функций, требований к системе, желаний заказчика. В Scrum они сортируются по приоритету. Это живой документ, добавляйте в него новые задачи по ходу работы.
Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.
Не нужно прорабатывать и продумывать полностью все функции сразу. Все «хотелки» и то, что появляется в процессе, добавляются в бэклог. Решайте, что делать сразу, а что стоит отложить на следующую версию.
Внедряйте спринты
Scrum создавался в первую очередь для гибкости и ускорения разработки. Для этого появилась механика спринтов — весь процесс делится на отрезки, обычно от одной до четырех недель.
Как это работает? Команда забирает из бэклога часть задач. Каждая разбивается на максимально мелкие тикеты. Теперь нужно оценить время на задачу, и вот здесь проявляется особенность Scrum.
Дело в том, что люди плохо считают процессы в абсолютных величинах. Сложно сказать, сколько часов что займет. Поэтому в Scrum используется относительная оценка. За основу берется простая функция, которую все оценивают одинаково — например, понятно, что ее сделают за час. Остальные тикеты вычисляются так — «это мы будем делать раз в пять дольше по времени».
Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.
Ключевая идея — до тех пор, пока команда не забрала задачи на спринт, их можно бесконечно видоизменять в бэклоге. В разработку уходит согласованная часть. Каждый спринт — это небольшой релиз, в конце которого команда показывает работающую функцию ПО.
Распределите роли в команде
В идеальном мире на ключевые роли в scrum-команде назначаются люди, выращенные на проекте. Такой человек будет знать процессы изнутри, лучше ориентироваться в оценках и понятнее ставить задачи.
Cвязующее звено между командой разработки и пользователями. Этот человек собирает общую концепцию продукта из мнений заказчиков и других заинтересованных в выпуске ПО людей. Он формирует задачи и расставляет приоритеты.
Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.
Люди, которые непосредственно создают и тестируют код.
К разработчикам есть несколько требований:
У такого принципа формирования команды есть минус — сложно заменить неожиданно выпавшего человека. Но скорость разработки на практике все равно выше, чем у других подходов.
Контролируйте процессы
Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.
Контролируйте работу команды с помощью двух scrum-показателей:
Организуйте работу команды
В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:
Задача руководителя — выяснить и устранить трудности, которые мешают разработчику добиться прогнозируемого результата. Для сотрудников это три-пять минут — ответили на вопросы, поставили оценки, разбежались работать дальше. Никаких решений или дискуссий.
В конце каждого спринта проводится ретроспектива. Команда встречается, озвучивает мнение, что в отрезке было хорошо, что плохо. Спросите у сотрудников идеи — что поможет им работать быстрее и эффективнее, что исправит проблемы. Запишите их в отдельный план — забирайте туда только те идеи, которые возможно сделать за следующий спринт.
Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.
На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.
Формируйте организацию процесса постепенно. Разбивайте день — например, шесть часов люди работают по спринтам, два часа остаются на срочные и случайные моменты. Если все пойдет без неожиданностей, ничего страшного, продолжайте спринт, сделайте больше тикетов.
Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.
Демонстрируйте проект
Не затягивайте с первой версией продукта. Демонстрацию лучше проводить после каждого спринта — пусть даже релиз не пойдет к пользователям. Не копите внутри команды много функций — покажите их заинтересованным лицам и получите обратную связь. После — сразу измените бэклог.
В этом основное преимущество Scrum — гибко менять список задач во время разработки, не делать лишнего и не получать тысячи правок после завершения проекта, как в каскадной методологии разработки.
Изучите инструменты для контроля
Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:
Чек-лист — как начать использовать Agile и Scrum на проекте
Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.
Делает из вебинаров статьи, пишет про все и даже немного больше.