Что такое недельный спринт
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
Технический директор ООО «Юниклауд Лабс»
Мини-справочник и руководство по 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-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?
Спринты
Спринты
Что такое спринты?
ТВИИТ :«Спринты делают проекты более управляемыми, позволяют командам быстрее и чаще выполнять высококачественную работу и дают им больше гибкости для адаптации к изменениям».
Многочисленные сходства между ценностями Agile и scrum-процессами приводят к справедливой ассоциации. Спринты помогают командам следовать Agile принципу «частой поставки рабочего программного обеспечения», а также использовать Agile ценность «реагирования на изменения в соответствии с планом». Scrum-значения прозрачности, проверки и адаптации дополняют Agile и играют центральную роль в концепции спринтов.
Как планировать и выполнять scrum-спринты
Затем команда создает план того, как они будут создавать элементы списка необходимых требований (backlog) и получать их «Готов(-ыми)» до конца спринта. Выбранные рабочие элементы и план их выполнения называются «спринтом списка необходимых требований (backlog)». К концу планирования спринта команда готова приступить к работе с списком необходимых требований (backlog) спринта, перенеся элементы из этого списка в «Выполняется» и «Готово».
Во время спринта команда проверяет, как продвигается работа во время ежедневного scrum или летучки. Целью этой встречи является выявление любых препятствий и проблем, которые могут повлиять на способность команд к достижению цели спринта.
После спринта команда демонстрирует, что они выполнили во время ревью спринта. Это возможность вашей команды продемонстрировать свою работу заинтересованным сторонам и партнерам по команде до того, как она попадет в производство.
Что можно и нельзя
Даже когда основы не работают, большинство команд спотыкаются, когда начинают запускать спринты. Меган Кук завершает эту дискуссию некоторыми вопросами о том, что можно и чего нельзя делать, которые она отобрала за эти годы.
Что можно:
Пока вы работаете над тем, чтобы быть звездой Scrum с этими «разрешениями» (“do’s,”), следите также за несколькими красными флагами:
Не рекомендуется:
Узнайте больше о спринтах
Спринты настолько известны (и настолько эффективны!), что их часто считают первым шагом на пути к большей гибкости. Как мы узнали, освоение спринтов требует овладения горстки scrum и Agile концепций, которые опираются друг на друга. Пожалуйста, используйте остальные наши статьи о scrum, чтобы пополнить свои знания и приблизиться к блаженству scrum.
По материалам Agile Coach «Sprints»
Что такое недельный спринт
Умение управлять своим временем — одно из ключевых компетенций современного успешного человека. Кто умеет правильно ставить задачи на каждый день, на каждый месяц, тот их и выполняет и двигается вперед. Но как быть, когда сложно организовать себя и выбрать нужные техники для достижения целей?
Самое гениальное решение — это использовать специальные ежедневники. Сегодня мы с вами заглянем внутрь ежедневника «Космос. Agile-ежедневник для личного развития» от Катерины Ленгольд.
Катерина в свои 23 года стала самым молодым вице-президентом в мировой аэрокосмической индустрии. Она уж точно знает, как правильно использовать время и достигать невозможного. Ну что, погнали?
Система ежедневника
Сегодня существует огромное количество техник и систем по эффективному управлению временем. В систему ежедневника Космос входят всего четыре элемента:
1. Планирование целей на спринты по 9 недель.
2. Формирование полезных привычек.
3. Планирование дня 30-минутными блоками.
4. Ежедневная рефлексия (ведение журнала).
Давайте вместе разберем каждый элемент.
1. Постановка целей на
9-недельный спринт
Почему именно 9 недель? Потому что это идеальный срок для планирования. Наверняка каждый ставил себе под Новый Год цели на ближайшие 12 месяцев и забывал о них уже через пару недель. Это естественно. Статистика говорит, что такие долгосрочные цели не сбываются в 80% случаев. Чтобы эффективно работать, «дедлайн» должен постоянно маячить впереди. Так уж мы устроены.
Но при краткосрочном планировании мы не видим перспективы развития и заполняем время только насущными делами. Поэтому срок планирования должен быть таким кратким, чтобы мы чувствовали «давление дедлайна», но и настолько длинным, чтобы за это время можно было реализовать значимый проект.
Катерина предлагает ставить конкретные и относительно небольшие цели на 9 недель вперед. За год таким образом вы пройдете 6 спринтов.
Все ключевые дедлайны, важные поездки, даты нужно зафиксировать в удобной таблице «Обзор спринта».
Чтобы постоянно держать фокус, нужно выбрать три главные цели и расписать промежуточные этапы.
И не забывайте о главных правилах постановки целей. Цели должны быть: конкретными, измеримыми и важными лично для вас.
Обязательно придумайте себе вознаграждение за успешный спринт. Это будет мотивировать вас в моменты упадка настроения и сил. Что это может быть — шопинг, посещение спа-салона, вечеринка с друзьями — решать лично вам.
После каждых 9 недель рекомендуется проводить «разбор полетов»: проанализировать ошибки, оценить результаты и запланировать следующий спринт.
2. Формирование полезных привычек
Как ни крути, но нашу жизнь определяют не сами цели, а правильные привычки.
К примеру, вы хотите похудеть к лету. Можно поставить цель — сбросить 10 килограмм за 3 месяца. Все эти три месяца вы будете прилагать усилия, чтобы контролировать себя. А после успешного достижения цели можно очень легко набрать свой вес обратно, если не контролировать себя. Постоянно держать себя в ежовых рукавицах достаточно сложно.
А можно сделать по-другому. Можно привить себе полезные привычки — йога каждое утро, отказ от фастфуда, прогулки каждый вечер. Когда привычка укоренится, вам не нужно будет прилагать усилий. Она будет работать автоматически.
На страничках с привычками отмечайте каждый вечер, выполнили вы привычку или нет.
Вот несколько правил от автора, как привить полезные привычки.
Во-первых, начните с легких привычек и постепенно наращивайте их сложность. Например, вместо того, чтобы пытаться каждый день тратить час на пробежку (а спортом вы занимались последний раз в школе), попробуйте прыгать на скакалке 100 раз. Это легко и не требует сверхусилий. Когда привыкнете, добавьте еще нагрузки.
Во-вторых, разрешается пропускать только один день. Регулярность — это очень важно.
В-третьих, придумайте план Б. Если ваша привычка — каждый вечер готовить ужин с семьей, то в командировке это сделать невозможно. Как вариант, можно ужинать с семьей по скайпу.
3. Планирование дня 30-минутными блоками
Катерина предлагает все задачи разбивать на 25-минутные блоки с обязательным 5-минутным перерывом. Эта техника называется Pomodoro, и, несмотря на кажущуюся простоту, она очень эффективна. Во-первых, тикающий таймер с обратным отсчетом создает ощутимое «давление дедлайна». Во-вторых, любые помехи, возникающие во время рабочего блока (ответить на сообщение другу), легко отложить на несколько минут до ближайшего перерыва.
Еще одно важное действие — это каждый день выбирать три приоритетные задачи. Что нужно сделать в первую очередь, чтобы знать, что день прошёл не зря? Что приближает меня к реализации целей спринта? На эти задачи лучше всего выделить 3–4 часа в первой половине дня, когда уровень энергии и креативности на максимуме. А все рутинные дела, встречи и совещания, не требующие творческого подхода, переносить на послеобеденное время.
4. Ежедневная рефлексия
Счастье только на 10% определяется внешней средой — образованием, социальным статусом, финансовыми и личными достижениями. Остальные 90% зависят от нашей интерпретации реальности. Каждый день происходит что-то хорошее и что-то плохое. То, на чем мы фокусируем внимание, и определяет, будем мы счастливы или нет. Чтобы приучить себя обращать внимание на позитивные события, каждый вечер ведите журнал. Нужно всего 2–3 минуты, чтобы ответить на два простых вопроса: 1. Какое мое главное достижение дня? и 2. Кому и за что я благодарна?
Фиксируя достижения, мы празднуем маленькую победу каждый день и становимся увереннее в своих силах.
Ежедневное «спасибо» обращает наше внимание на людей и события, пусть незначительные и мимолетные, которые вызвали улыбку, озадачили или научили чему-то новому. Это простое упражнение, без преувеличения, может изменить вашу жизнь. Если из всей системы вы возьмете только одну идею — пусть это будет ведение журнала.
На этом все! Желаю вам продуктивного дня и успеха в достижении целей!
Остальные иллюстрации взяты из книги.