Что такое планирование спринтами
Как съесть слона и при чём тут метод управления проектами SCRUM
Как часто проекты в вашей компании не укладываются в заданные временные рамки? Хотя, казалось бы, планирование, графики, отчёты… Организовать работу максимально эффективно можно, для этого нужно знать некоторые инструменты-помощники. Один из них – метод SCRUM.
Метод SCRUM – часть идеологии Agile, представленной в начале этого века группой независимых разработчиков программного обеспечения. Она объединяет несколько гибких методик управления, основанных на эффективной организации труда небольших групп специалистов. Метод оказался настолько эффективным, что теперь применяется и за пределами сферы разработки ПО: везде, где есть проекты, жёсткие сроки, небольшая команда и возможность разбивки проекта на составные, логически завершенные, части. Как съесть слона? По кусочкам.
Весь проект в SCRUM делится на итерации длительностью кратной неделе. Наиболее распространенное время – от 1 до 4 недель. Каждая итерация называется «спринт».
Цель спринта – за отведенное время создать продукт, готовый к демонстрации заказчику или потребителю.
Особенность спринтов в том, что одновременно решается только одна задача.
После каждой итерации вы получаете отзыв о том, движетесь ли вы в том направлении, которое нужно. Это и есть главное преимущество SCRUM – гибкость в разработке благодаря постоянной обратной связи.
Если проект делается без спринтов, весь сразу, то есть вероятность, что от него придётся отказаться, если в итоге выяснится, что продукт имеет критические недостатки. Те проблемы, которые можно выявить на ранних стадиях, используя SCRUM, могут быть слишком поздно обнаружены при использовании других методов.
Каждый человек, участвующий в проекте SCRUM, выполняет только отведенную ему роль. Чаще всего этих ролей три: владелец продукта, мастер и команда.
Владелец продукта, он же PO (Product Owner), не является в прямом смысле собственником. Это менеджер, через которого идет связь между клиентом или потребителем и командой, делающей продукт.
Главная задача – коммуникация с заказчиком и оперативное донесение информации до исполнителей.
Мастер является частью команды, но со специфическими обязанностями. Его основная задача – обеспечить рабочий процесс. Также он берет на себя роль модератора во время совещаний, разрешает противоречия в команде и следит за исполнением принципов метода.
Это те люди, которые непосредственно работают над проектом. Обычно их от 4 до 6 человек. Все члены команды берут на себя коллективную ответственность за задачи спринта как единое целое.
Совещаний в рамках использования этой методики проводится много, они различаются по целям и продолжительности.
Планируется весь объём работ, который будет выполняться за следующий спринт.
Должны быть чётко поставлены цели и определены методы их достижения.
Также определяется трудоёмкость тех задач, которые запланированы на текущий спринт. Члены команды поясняют PO и мастеру, как они планируют работать, чтобы достичь цели.
Каждый член команды отвечает SCRUM-мастеру на 3 вопроса:
Решение проблем не ищется в рамках ежедневного совещания. Всё общение занимает не более 15 минут.
Презентация законченной части продукта, которая проводится в присутствии всех заинтересованных сторон, включая клиента.
Подведение итогов спринта
Обсуждение того, что удалось достичь и что не получилось.
Здесь должны быть получены ответы на 3 вопроса:
Метод SCRUM применяется в работе над рядом проектов в бизнес-клубе «Атланты». Более 140 мероприятий в год, в том числе открытые и эксклюзивные – только для резидентов – встречи с интересными спикерами, форум-группы, обсуждения, собрания клубов в клубе… Всё это нуждается в чётком планировании. Команда клуба тестирует на себе разные методики и готова делиться наработками.
Если вам был полезен этот материал, поставьте + в комментариях, чтобы подобных публикаций было больше.
В следующей статье расскажем о распространённых ошибках и трудностях внедрения SCRUM в работу.
Планирование спринтов
Планирование спринта — это событие в scrum, в рамках которого определяется объем работы на следующий спринт и критерии выполнения этой работы.
Просмотр тем
Из этой статьи Дейва Уэста, генерального директора Scrum.org, вы узнаете, как понимают совещание по планированию спринта в Scrum.org. Главным учебным пособием Scrum.org по методике является Руководство по Scrum, официальное руководство, признанное всеми последователями Agile. Просмотрите видеозапись ниже, чтобы узнать, что думает о планировании спринта Меган Кук из компании Atlassian.
Что такое планирование спринта?
Планирование спринта — это событие в scrum, которое знаменует начало спринта. В ходе планирования определяется объем работы на спринт и способы выполнения этой работы. Планирование спринта осуществляется при содействии всей команды scrum.
В Scrum спринт — это фиксированный отрезок времени, за который выполняется вся работа. Но прежде чем начать действовать, спринт нужно спланировать. Необходимо определить продолжительность и цель спринта, а также отправную точку работы. На совещании по планированию спринта определяется круг основных задач и вектор развития спринта. Если совещание проводится правильно, команда покидает его мотивированной, заряженной решать амбициозные задачи и нацеленной на успех. Плохие планы спринтов могут загнать команду в тупик, если ей сообщают нереалистичные ожидания.
Подготовка к собранию по планированию спринта
Чтобы собрание по планированию спринта прошло успешно, требуется определенная организованность. Владелец продукта должен подготовиться: освежить в памяти выводы, сделанные при прошлом обзоре итогов спринта, ознакомиться с мнениями заинтересованных сторон и их концепцией продукта. Можно сказать, что они подготавливают почву для спринта. Чтобы текущая ситуация была прозрачна и понятна, бэклог продукта следует привести в соответствие с современными реалиями и скорректировать. Уточнению бэклога посвящено отдельное мероприятие Scrum; некоторые бэклоги в нем не нуждаются, поэтому проводить его не обязательно. И все же большинству команд стоит собраться перед планированием спринта, чтобы просмотреть и скорректировать бэклог.
Если у вас каждый спринт длится две недели, проводите совещание по улучшению бэклога в середине спринта. Команде полезно отвлечься от спринта и оценить перспективы. Это не только поможет подготовиться к планированию спринта, но и позволит взглянуть на текущую работу со стороны.
Ограничение времени, отведенного на планирование спринта
На планирование спринта должно отводиться не более двух часов за каждую неделю спринта. Так, собрание по планированию двухнедельного спринта не должно длиться больше двух часов. В данном случае вы ограничиваете максимальный период времени, отведенный команде на планирование спринта. Scrum-мастер отвечает за то, чтобы каждый участник собрания понимал ограничения по времени. Если команда справляется с работой раньше, собрание завершается. С помощью ограничений определяется только максимальная продолжительность собрания; минимальная продолжительность не задается.
Сосредоточьтесь на результатах, а не работе
Во время планирования спринта можно легко зайти в тупик, если пытаться непременно решить, какое задание выполнить в первую очередь, кто должен им заниматься и сколько времени это отнимет. Если у предстоящей работы много составляющих, поначалу у участников совещания может быть недостаточно информации, и они будут в основном исходить из собственных допущений. В основе Scrum лежит эмпирический подход, а значит, вместо того чтобы заблаговременно составлять план, стоит учиться на практике и затем использовать полученную информацию.
Цель спринта показывает, что ожидается от этого спринта в общих чертах, однако нужный результат можно сформулировать и в содержании бэклога. Описать работу с точки зрения клиента можно, например, с помощью пользовательских историй. Пользовательские истории, написанные по модели, приведенной ниже, позволяют взглянуть на дефекты, проблемы и улучшения по-другому и увидеть, какой результат нужен клиенту, не зацикливаясь на проблеме разработчиков.
Когда в пользовательской истории прописаны однозначные измеримые результаты, можно с точностью определить, насколько успешно выполнена работа, и установить для нее критерии «готовности». Заранее проясните как можно больше аспектов предстоящей работы, чтобы у команды было четкое представление о работе. Задать вопрос, ответ на который будет найден во время спринта, гораздо лучше, чем промолчать и затем страдать от неопределенности.
Незнание и неопределенность — это две разные вещи. Не закрывайте глаза на то, что вы не знаете; сложная работа всегда связана с неизвестным. Не стоит скрывать свое незнание за расплывчатыми формулировками. Лучше будьте искренни, когда вы что-то не знаете, и, описывая работу, говорите, что вы стремитесь понять.
При оценке сложности работы не нужно преувеличивать свои знания
При планировании спринта нужно хотя бы приблизительно оценить сложность работы. Команда должна понять, что можно сделать за спринт, а также сопоставить ожидаемые усилия со своими возможностями. Часто командам кажется, что, проводя оценку, они принимают на себя определенные обязательства, но это не так. Оценка сложности по своей сути является прогнозом на основе имеющихся знаний. Целесообразно использовать для оценки сложности очки за пользовательские истории или обозначения размеров одежды, ведь так команды могут рассмотреть проблему с разных сторон. Однако не стоит считать, что эти инструменты как по волшебству откроют вам объективную истину (ее не существует). Чем больше неизвестных, тем меньше вероятность того, что оценка будет точной.
Для хорошей оценки сложности нужна доверительная обстановка, в которой участники команды без стеснения обмениваются информацией и делятся предположениями, чтобы узнать больше и приблизиться к совершенству. Если оценки используются в отрицательном, конфликтном ключе после того, как работа завершена, скорее всего, в будущем прогнозы будут сделаны с большим запасом, чтобы исключить вероятность повторной ошибки, или на оценку будет потрачено гораздо больше времени, потому что команда будет сомневаться в себе, опасаясь последствий ошибки.
Ознакомьтесь с разными способами оценки сложности, такими как использование размеров футболок или очков за пользовательские истории. С их помощью можно рассмотреть проблему с разных сторон.
Рекомендации по планированию спринта
В тонкостях планирования спринта легко увязнуть слишком глубоко, забыв, что это событие нужно, чтобы составить план для следующего спринта со всей необходимой информацией и без лишних подробностей. Этот план не должен быть обузой для команды; напротив, он должен акцентировать ее внимание на ценности, которая будет создана в результате выполнения, и поспособствовать самоорганизации. В хорошем плане спринта определен желаемый результат и подробно расписаны действия для его достижения, и этим план мотивирует команду. Однако не пытайтесь предусмотреть в плане все. Вместо того, чтобы составить наиболее подробный план, «учитывающий каждую минуту спринта», сосредоточьтесь на цели спринта и внесите в бэклог спринта ровно столько задач, сколько нужно для начала работы. Затем убедитесь, что команда может браться за выполнение дополнительных задач из бэклога продукта, если цель спринта достигнута раньше установленного срока.
Scrum — это методология процессов, предназначенная для решения сложных проблем. Для этого в ее основу заложен эмпирический подход (то есть для решения задач используется опыт практической работы). Зависимость от реальных данных и опыта значительно ограничивает возможность планирования, поэтому не обольщайтесь: составить идеальный план невозможно. Вместо этого сосредоточьтесь на результатах и принимайтесь за работу. Она не обязательно будет сложной, даже если стоящая перед вами проблема такой является.
Мини-справочник и руководство по Scrum
Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.
Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.
Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.
Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Мини-справочник Scrum
Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.
Основные обязанности и ответственность Product Owner при управлении Product Backlog:
Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.
Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.
Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
User – пользователь продукта.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.
Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.
User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.
Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.
Sprint Goal (спринт гоол) – цель спринта.
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.
Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.
Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?
Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.
Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.
Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.
Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.
Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.
Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.
Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.
Руководство Scrum
Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?
Scrum — реальный опыт работы по методологии
В данной статье я привожу обзор организации процесса создания программного обеспечения в команде, в которой работаю. Моя цель – это поделиться опытом разработки и управления командой разработчиков.
Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».
Какие роли есть в Scrum
С чего обычно начинается разработка программного обеспечения? С идеи: «Как было бы замечательно, если бы у меня было некое ПО, которое делало бы примерно вот это. Было бы просто супер!» Человека, который в команде будет представлять эту идею, называют Product Owner (PO) или Владелец продукта. Product Owner – это тот, кто видит цель продукта или кому кажется, что он видит цель продукта, но важно то, что он может ее сформулировать и начать процесс движения к ее достижению. Цель он формирует в виде списка своих пожеланий (хотелок). Этот список называется Product Backlog Items (PBI). Он постоянно модифицируется в зависимости ситуации на рынке или от разрастающегося аппетита Product Owner’a.
Команда. По Scrum считается, что наибольшая эффективность разработки достигается в том случае, если команда сама будет самостоятельно принимать решения в отношении того, как она будет двигаться к цели. Поэтому основное требование к команде – она должна быть самоорганизующейся и самоуправляемой. Обеспечьте одно это требование, и этого будет достаточно для успеха проекта. Так как требование серьезное, то в команду вводится роль ScrumMaster’a, который следит за тем, чтобы соблюдались правила Scrum.
Что такое спринт и зачем он нужен
ProductOwner сформулировал свою цель в виде некого пункта B, который нужно достичь, начав движение с пункта A. Но пункт B – это не точка, в которую можно попасть, просто нарисовав прямую линию между ней и пунктом А. На самом деле пункт B это окрестность точки, и радиус ее может варьироваться.
Чтобы попасть в эту окрестность, лучше всего разрабатывать ПО короткими шагами (точнее забегами): спринтами. В конце спринта все оценивают, что получается, и корректируют направление движения. ProductOwner всегда в курсе того, что его идеи правильно поняты (а если нет, то это можно скорректировать уже на следующем спринте), и спокоен. Команда знает, что делает то, что нужно, и удовлетворена своей работой.
Как формируется список задач на спринт
В команде спринт длится 2 недели. За неделю ничего не успевается, за месяц все забывается. Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня. Планирование – это процесс, при котором команда берет из списка требований наиболее приоритетные и разбивает на задачи, которые позволяют достичь результата. Каждая задача оценивается в часах. Желательно, чтобы задача не занимала времени больше, чем 4 часа. Если участник команды говорит, что сделает задачу за 5 дней, значит, он понятия не имеет, что нужно сделать.
Общее количество часов в спринте на каждого человека рассчитывается из того, что спринт длится 2 недели или 10 рабочих дней. Это 80 часов минус один день на планирование. Итого 72 часа. Но это идеальные часы. Это значит, что человек ни на что не отвлекается, не ест, не пьет, с места не встает, а только работает и не устает. Во время планирования задача оцениваются в идеальных часах. Но набирается для человека не 72 часа, а 72 часа, умноженные на некий коэффициент, который называется производительностью команды. Обычно это 0.5. Удивительно, но это какое-то магическое число, именно при нем весь спринт сдается успешно. Кто-то из великих сказал: «Возьмите время, которые назвал вам разработчик, умножьте его на два и еще немного прибавьте и получите срок, за который вам программист выдаст результат». И это действительно так.
В Scrum есть несколько рекомендаций в отношении того, как исполнителю оценивать время на задачу. Например, играть в покер. Но мы этим не грешим. Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт. И только он может оценить, сколько ему нужно времени на выполнение задачи. Единственные, кто ему может помешать завысить сроки, это его совесть (помните про самоорганизацию) и ScrumMaster.
Как проверить, что требование ProductOwner’а выполнено
Есть список требований. Но как проверить, достигнуто это требование в ходе разработки или нет? Для этого необходимо написать тесты, в которых будет детально описано то, что считать достижением требования. Просто говоря, в них описано то, на какую кнопку нажать, и что при этом получится. В команде тесты пишут аналитики. И тесты эти должны быть готовы к моменту запуска очередного спринта. У нас в команде аналитики и дизайнеры работают с опережением команды разработчиков на 1 спринт.
Главное требование – тесты должны быть очень подробными.
Что происходит во время спринта
Начинается процесс исполнения спринта. Главная его цель – добиться, чтобы тесты, предъявляемые к требованиям, к концу спринта выполнялись.
Для сплоченного движения команды к цели Scrum предлагает делать ежедневные митинги. Митинг – это когда каждый, стоя у доски с маркером, вычеркивает то, что он сделал вчера и пишет то, что он собирается сделать сегодня.
Это очень мощная практика. Благодаря ей каждый знает, куда движется проект в целом. К тому же когда человек, рассказывает, что он будет делать сегодня, то он автоматически координирует свои действия с другими участниками. Другие участники могут тут же предложить лучшие решения задачи. А еще написанная на доске задача, а по сути — это обещание всем своим коллегам, очень хорошо мотивирует самого исполнителя. Единственное, ScrumMaster не должен забывать объявлять, что начался митинг.
Митинги проводить желательно стоя и длительностью не более 15 минут. Мы начинаем митинги в 9 утра.
Что происходит в конце спринта
Наступает долгожданный конец спринта, обычно это пятница в 16:00, и команда сдает спринт Product Owner’у и всем-всем, кто заинтересован в продукте. Каждый отчитывается по задачам, которые выполнял и рассказывает о том, каких успехов достиг, а также объясняет причины, по которым не удалось достичь цели. Главное правило — никогда не переносите срок сдачи спринта.
Иногда после сдачи спринта делается анализ того, почему что-то происходит или не происходит, и что нужно предпринять, чтобы исправить ситуацию.
А в понедельник все повторяется сначала.
Накопленный опыт
Мы для себя выработали несколько правил, несоблюдение которых приводило к провалу спринта:
• Спринт надо планировать детально, не жалея на это сил. Если что-то из требований непонятно, то надо прояснять требование. Если это не удается сделать, то не надо брать задачу в спринт, а требование отправлять на доработку.
• Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
• Количество человек в команде не должно превышать 5-6 человек. Когда наша команда выросла до 16 человек, митинг начал затягиваться на 2 часа. Ввели фиксированное время выступления для каждого и стояли с секундомером. Но тогда человек не успевал донести свою мысль, и митинг превращался в формальность. Поэтому мы просто разделились. Сначала поделились на клиентщиков и ядерщиков, а потом начали делиться по задачам. Т.е. каждая команда делает свою фичу, и в этой подкоманде есть как клиентщики, так и ядерщики. Этот подход используется до сих пор, и для нас он наиболее эффективен.
Вывод
Scrum может быть хорошей отправной точкой для начала движения. В процессе работ некоторые правила могут эволюционировать или отпасть за ненадобностью. Это уже будет решать команда, отношения в команде и сама жизнь. Но правила, которые сформируются на основе Scrum, послужат хорошим плацдармом для достижения командой желаемого результата.
Кто мы?
Команда, в которой я работаю, называется «Юниклауд Лабс». Это дружный коллектив интересных людей, реально болеющих за свое дело.
Вариков Андрей VAndrey
Технический директор ООО «Юниклауд Лабс»