Что такое спринты в программировании
Это время, за которое команда успевает решить какую-то часть задач.
Когда вы попадёте на работу в ИТ-компанию, вы обязательно услышите одну из этих фраз:
Разберём, что это за спринты такие и зачем они нужны.
Ситуация
У команды разработчиков есть большой проект, где нужно сделать много разных вещей:
Времени на всё — 6 месяцев, и кажется, что этого достаточно. Но это может быть обманчиво, потому что команда расслабляется, каждый начинает делать что-то своё, а за месяц до финала выясняется, что вместе эти отдельные части работать не будут. Например, сервер не отдаёт данные в нужном формате для веб-страницы, приложения хранят данные только у себя и не умеют отправлять их на сервер, а авторизация в соцсетях работает только на Андроиде.
Чтобы этого не произошло, используют спринты.
Что такое спринт
Спринт — это небольшой фиксированный отрезок времени, в который команда делает какую-то ограниченную часть проекта. Например, команда может двигаться двухнедельными спринтами, с каждым спринтом добавляя в проект новые возможности.
Задача спринта — чтобы по его итогу что-то работало. Например, если мы взяли в спринт единую авторизацию в сервисе, то к концу спринта она должна работать и быть протестированной. Нельзя к концу спринта сказать «Ой, ну ничего, в следующий раз доделаем». К концу спринта должно быть готово.
Что делают в спринте
Цели у спринта могут быть общими для всей команды. Например:
А могут быть для каждого свои:
Кто именно и что делает — это определяет кто-то из руководителей, например, тимлид или менеджер проекта. У него в голове цельная картинка проекта, которую он раскладывает на конкретные маленькие шаги. Менеджер отвечает за корректную постановку задач, а разработчик — за то, чтобы эта задача была выполнена в срок.
Что после спринта
После спринта проводят ретроспективу — это встреча, на которой команда сама оценивает свой результат. Например, они могут обсудить такое:
Цель ретроспективы — подвести итоги спринта и понять, как лучше строить работу в следующем спринте, чтобы всё получалось лучше и интереснее, чем в этом.
После ретроспективы всё по новой.
Где нужны спринты
Спринты применяют для сложных или долгих проектов — там, где на старте непонятно, что конкретно по шагам нужно сделать, чтобы получить результат. Если проект сложный, спринты помогают упростить его, разбивая задачи на более понятные, чтобы каждая задача занимала один спринт.
В долгих проектах спринты держат в тонусе всю команду и не дают расслабляться в самом начале, когда кажется, что времени ещё очень много. Тогда цель каждого спринта — планомерно улучшать то, что есть, и постепенно добавлять новые возможности в сервис или приложение.
Если же задача решается за пару дней или пару недель, то спринты не нужны — нужно просто собраться и сделать.
Все знают, что компьютеры состоят из единиц и нулей. Но что это значит на самом деле?
Если ты можешь сделать страницу о себе, ты можешь сделать всё.
Это виртуальная инструкция к любому «железу» в компьютере
Почему в айтишных коллективах бывает душно и тяжело
Это когда программисты делают то, что скажут дизайнеры, или наоборот.
Фраза из лексикона сильных профессионалов
Объясняем на картинках.
Это время, за которое команда успевает решить какую-то часть задач.
Одно делается для удобства, а другое — для защиты.
Автоматизация тестирования по методологии Scrum
Все больше и больше набирает обороты использование методологий семейства Agile, так называемых гибких методологий, в сфере IT. К этому семейству, как вы знаете, относятся такие методологии, как Kanban, XP, Scrum и прочие, менее известные методологии.
Напомню в чем смысл каждой из них по версии ISTQB:
Отличительными особенностями Kanban являются:
Отличительными особенностями Scrum являются:
А как построен Scrum у нас?
Команда состоит из PO (Product owner), Scrum Master и Developing Team, которая в свою очередь состоит из 1 QA Automation, 1 Backend developer, 1 Frontend developer, 1 UX и 1 верстальщика. Разработка идет итерационно, спринтами по 2 недели. Во время каждого спринта проводится несколько типов встреч:
Как пример для автоматизатора — внедрение Allure отчетов, для девелопера — оптимизация работы запросов.
Тестирование в Scrum
В начале процесса автоматизации тестирования необходимо настроить CI, чтобы проводить регрессионное тестирования автоматически. Цель — свести ручную работу к минимуму. Потому что времени ни на что нет, нужно работать быстро. После этого стоит заняться репозиторием, настроить запуск сборки по Merge request. Если кто-то из разработчиков отправил что то в основную ветку проекта, запускается сборка и по ее результатам можно понять корректны ли внесенные изменения.
Перед тем как приступить к написанию тестов, необходимо разобраться в основной бизнес-идее проекта, чтобы определить области высокого риска на которые обращается внимание в первую очередь. Все таки будем реалистами, полностью покрыть тестами приложение, пусть оно и маленькое, не получится. Сазерленд писал, что на реализацию всего Бэклога никогда нет времени, поэтому он всегда применял к Backlog принцип Парето. Пишем 20% автотестов, покрывающих 80% возможных дефектов.
При написании тестов нужно добиваться максимальной абстракции. Не стоит писать код функции, которую можно будет использовать только при определенных условиях. Намного лучше реализовать ее так, чтобы максимально переиспользовать код, изменяя входные параметры.
Эффективная работа в Scrum невозможна без тесной работы с разработчиком, потому что времени для самостоятельного изучения кода мало. Быстрее и качественнее получится результат, если получать информацию из первых уст. Как реализован тот или иной функционал, что при этом использовалось. Это важно для понимания внутренней структуры.
Необходимые качества автоматизатора тестирования
Автоматизатор, а в Scrum особенно, должен быть технически подкован, чтобы понимать как работает приложение так сказать “под капотом”. Важно уметь быстро и легко переходить с одной технологии на другую. Например, при изменении базы данных, нужно быть готовым изменить способ подключения к ней. Стек технологий должен быть как можно шире.
Scrum предполагает быструю реакцию на изменения, срочное внесение исправлений. Предположим, что пользователи обнаружили некое несоответствие в работе приложения, команда разработки должна как можно быстрее отреагировать и выпустить патч. Для этого важно уметь очень точно локализовать проблему. В этом очень хорошо помогает автотестирование. Допустим у нас есть трехуровневое web-приложение: есть DB, frontend, backend. Где то в приложении есть баг. При использовании ручного тестирования поиск проблемы может занять не один день, затем проблему нужно будет исправить и вновь протестировать. При автотестировании мы запускаем регрессоное тестирование и в течение пары часов получаем полный отчет, в котором отражено точное местоположение бага.
Scrum. Взгляд программиста
О методологии Scrum
Scrum является одной из разновидностей гибких методологий Agile и позволяет быстро реагировать на изменяющиеся внешние требования. В Scrum основными понятиями являются итерация и спринт. Весь рабочий процесс разбивается на временные отрезки, которые называются итерация. В итерацию входит планирование, непосредственная разработка (спринт) и тестирование. Итерация имеет жесткие временные ограничения. Таким образом, Scrum ориентирован в первую очередь на сроки выполнения задач.
О процессе
Давайте теперь рассмотрим как именно был реализован Scrum внутри нашей команды. Сначала мы окинем весь процесс общим взглядом, а потом рассмотрим каждый этап подробно. Каждая итерация у нас длилась один месяц. Начиналась она с планирования и оценки задач, затем шел спринт, во время которого проводились ежедневные пятиминутки и прочие митинги по необходимости. По окончанию разработки была демонстрация нового функционала и ретроспектива.
Планирование
Все начиналось с того, что Product manager создавал список задач на основе целей продукта и отзывов пользователей. Затем из этого списка он выбирал первоочередные задачи и отдавал нам на оценку. Этот список был немного больше, чем мы реально могли сделать за месяц на тот случай если вдруг случится чудо. Мы много жаловались на то, что в задачах не было прописано всё до мелочей. Но сейчас, я могу сказать точно, что ни в одной другой команде я еще не видел такого качественного оформления задач от PM.
Далее, команде предстояло оценить каждую задачу и по оценкам понять, что войдет в предстоящий спринт. Про оценивание надо рассказать подробнее. На первых этапах оценивали так: тимлидер назначал каждую задачу на каждого разработчика и разработчик давал оценку. Если оценка разработчика сильно отличалась от ожиданий, то пытались разобраться в причине расхождений и корректировали либо оценку либо задачу. Это занимало много времени у тимлидера, а он всегда стремился сделать систему самостоятельной, что привело в итоге к использованию Planning-poker’а. Каждый разработчик оценивал все задачи команды на предстоящий спринт, а затем тимлидер вычислял среднюю оценку на каждую задачу. Минусом такого подхода было то, что оценку давали разработчики разных уровней и если потом задача попадала новичку, то конечно он делал задачу дольше этой оценки. Пытались вводить коэффициенты по каждому разработчику, но это еще больше все усложняло. В итоге, потом, с приходом новой системы стимулирования вообще отказались от индивидуальной оценки задач, но об этом будет чуть ниже.
После того, как все задачи были оценены, выбирались все задачи по приоритету, которые укладывались в длину спринта и начинался процесс разработки. После этого момента ничего нового PM уже добавить не мог в список до окончания итерации.
Пятиминутка
Процесс разработки был самым длительным в итерации. В это время ежедневно по утрам проводилась пятиминутка. У нас он назывался stand up митинг. Все вставали в кружок и каждый рассказывал, что он делал вчера и что собирается делать сегодня.
Целью этого митинга была синхронизация задач между участниками команды и выявление возникших проблем. Помимо этого был еще психологический момент. Если человек утром давал обещание перед командой что-то сделать, то ему уже труднее было не сдержать это обещание. У участников команды было очень разное отношение к этому митингу. Были так называемые “солдаты” — люди, которые понимали суть митинга, приходили и по-солдатски докладывали обстановку. Были и “бунтари” — люди, которые никак не хотели отрываться от мониторов и стоять в круге со всеми. Но большинство относилось к этому спокойно, как к части работы.
Спринт
Интересной особенностью нашей разработки было то, что наш тимлидер был категорически против разделения на специальности. То есть программист должен был уметь сделать любую задачу или починить баг за другим программистом. Этот подход достаточно спорный и если хотите — его можно обсудить в комментариях…
В качестве планировщика задач мы использовали систему Target Process. По началу у нас не было настоящей доски, только список задач в этой системе. Позже появилась доска, но она не была центральной частью процесса и пятиминутные митинги не строились вокруг нее. Скорее это было просто визуальное представление, где находится задача на отрезке спринта.
Поскольку тимлидеру надо было как-то отслеживать успевает программист внутри своей задачи или нет, то у нас была практика отчетов о потраченном времени на каждую задачу и помимо этого, каждый день программист должен был обновлять у задачи оценку — сколько времени по его мнению осталось потратить на эту задачу.
На основе этих данных руководство строило burndown диаграммы, по которым можно было увидеть успеваем мы или нет.
Ревью кода мы проводили в специальной программе Code Collaborator. При отправке кода на ревью можно было назначить только одного ревьюера и любое количество обозревателей. Только ревьюер решал можно коммитить данный код или нет. Комментарии обозревателей носили только рекомендательный характер. Интересно, что если член команды не был в списке обозревателей и ревьюеров, то он даже посмотреть не мог этот код.
После того, как все задачи были сделаны и протестированы наступало время митинга под названием “Демо”. На этом митинге собирались все участники команды от дизайнеров до отдела технической документации и смотрели выступления разработчиков.
Каждый разработчик на большом экране показывал, что он сделал за текущий спринт. Особенно эффектно это выглядело у frontend разработчиков, но и backend разработчики открывали на экран консоль и показывали новый крутой API запрос.
А еще есть и побочный эффект. Нередко бывало такое, что во время демо случались казусы и что-то шло не так или придумывались новые интересные кейсы поведения и поэтому команда тестирования всегда уходила с полным блокнотиком багов.
Ретроспектива
Ретроспектива — это митинг, который проводится после завершения итерации с целью выявить текущие проблемы и улучшить процесс на будущее. В нашей команде этот митинг назывался Post mortem. Наш тимлидер хотел, чтобы этот митинг проходил в максимально расслабленной атмосфере, поэтому мы покупали пиво и закуску, садились за стол, отмечали окончание итерации и заодно обсуждали кому что понравилось в прошедшей итерации и что не понравилось. Равнодушных в команде почти не было, поэтому это застолье обычно было очень жарким и долгим. Product manager жаловался на программистов, что задачи не сделаны в срок, тестировщики жаловались на программистов, что слишком поздно отдаются задачи в тестирование и они не успевают их проверить до окончания итерации. А программисты жаловались, что задачи приходят не продуманными и приходится много времени тратить на продумывание специфических ситуаций.
В какой-то момент мы заметили, что на каждой ретроспективе жалуемся на одно и то же и решили записывать все моменты. Потом мы поняли, что на каждой ретроспективе мы записываем одно и тоже. Тогда мы решили не просто записывать, а назначать решение каждой проблемы на конкретного человека и он на следующей ретроспективе должен был отчитаться. Потом мы поняли, что пока все отчитаются, пока запишут новые проблемы — времени выпить уже не остается и решили отделить ретроспективу от пьянки. После этого стало уже не так интересно и ретроспектива превратилась в сухой неинтересный митинг.
От себя могу отметить, что ретроспектива помимо своего основного значения несет очень важный момент — психологическую разрядку. Это время, когда человек совершенно безнаказанно может высказать все, что у него накопилось за месяц и продолжить спокойно работать. Несмотря на явную агрессию во время митинга, после его окончания команда становилась каждый раз еще более сплоченной.
Прочие мероприятия
Еще у нас был митинг “one and one”. Раз в две недели тимлидер разговаривал с каждым членом команды, где тот мог сказать всё то, что нельзя сказать на ретроспективе.
Были и неофициальные мероприятия за пределами офиса. Например два раза в год мы ездили командой на шашлыки.
Стимулирование
В жизни любой команды есть начальный период, когда все полны энтузиазма и работа кипит, но если команда в одном и том же составе работает несколько лет, то наступает период спада производительности. И тут дело не только в том, что накапливается усталость, но и в том, что продукт становится сложнее и больше времени тратится на его поддержку и расширение.
Когда наш тимлидер увидел, что у команды наступил именно такой момент он решил сильно поменять весь процесс и ввести дополнительное стимулирование. Основная его идея была в том, что перестает существовать понятие программист и член команды. Команда становится минимальной неделимой единицей. В конце каждой итерации команда определяет какой набор задач она берет на себя на следующий спринт. И выполняет эти задачи. Если задачи выполнены и протестированы за два дня до окончания спринта, то команда может использовать эти оставшиеся дни по своему усмотрению. Хоть даже не ходить на работу. К сожалению финансово простимулировать нас тимлидер не мог, поэтому поощрение выражалось свободным временем.
Схема выглядела вот так:
| 22 дня | |||
| 10 дней | 8 дней | 2 дня | 2 дня |
| разработка | тестирование и багфиксинг | оценка | отдых |
Отсюда видно, что два дня в месяц мы не занимались программированием. Весь отдел собирался в конференц-зале. Мы брали все задачи, которые нам предоставлял менеджмент и пытались рассмотреть все сложные моменты и дать оценку по каждой задаче.
Могу сказать, что идея оказалась провальной. Мы всего один раз смогли заработать эти поощрительные два дня. Оценки на задачи давались очень завышенные и на каждое действие создавался отдельный митинг с участием всей команды, т.к. все боялись не успеть и потерять поощрительные два дня. Завышенные оценки приводили к расслабленности во время реализации этих задач, а куча митингов мешала сосредоточится на программировании и в итоге общая производительность отдела упала. К этому моменту команда уже понимала, что нужно сделать шаг назад и вернуться к прежней системе, но не успела. Отдел закрыли по независящим от команды причинам.
Заключение
Несмотря на провал с введением системы стимулирования до этого эксперимента вышеописанная методология в течение нескольких лет давала превосходные результаты, команда показывала высокую скорость работы и продукт развивался очень быстро. В качестве заключения, я бы хотел дать несколько советов начинающим тимлидерам.
Мини-справочник и руководство по 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-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?