что делает спринт в мм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
Технический директор ООО «Юниклауд Лабс»
Спринт в Формуле-1: Что это такое, как будут начисляться очки, зачем он нужен
В 2021-м году в Формуле-1 появится совершенно новый формат гонки – это квалификационный спринт. В апреле руководство «королевских гонок» утвердило, что уже в текущем сезоне будет проведено три спринта, а через год их может стать шесть. Рассказываем о том, что такое квалификационный спринт.
РЕГЛАМЕНТ И ФОРМАТ
Квалификационный спринт – это мини-гонка на 100 километров. Предполагает, что она будет длиться примерно 25-30 минут. По итогу этой гонки победитель получит три очка, два очка – обладатель второго места и одно – финишировавший на третьем месте. При этом во время спринта не будет пит-стопов.
Результаты квалификационного спринта определят стартовую решётку во время основного гран-при.
ЧТО БУДЕТ С КВАЛИФИКАЦИЕЙ И ПРАКТИКАМИ НА ТАКИХ ЭТАПАХ?
Классическая квалификация будет перенесена на пятницу, а вот количество свободных заездов уменьшится на один. Теперь будет две сессии свободных заездов.
Стоит сказать, что на таких этапах квалификации будет изменены правила использования шин. Теперь команды будут использовать только «софт». При этом во время основной гонки пилоты могут самостоятельно выбирать комплект резины, а не тот, на котором они показали лучшее время во втором сегменте.
ГДЕ ПРОЙДУТ СПРИНТЕРСКИЕ ГОНКИ?
На текущий момент точно известно, что первая спринтерская гонка пройдет на гран-при Великобритании в Сильверстоуне. Скорее всего, такая гонка будет и в итальянской Монце. А вот по поводу третьего этапа пока что остаются вопросы – больше всего шансов в бразильского Интерлагоса.
Спортивный директор Формулы-1 Росс Браун считает, что в 2022-м будет как минимум шесть спринтерских гонок.
ЧТО ДУМАЮТ ПИЛОТЫ И БОССЫ КОМАНД?
Мнений относительно нового формата разделились практически пятьдесят на пятьдесят. Приведем лишь несколько цитат.
Жан Тодт, президент ФИА:
— Если честно, мне не нравится идея спринтерских гонок. Мне кажется, что Формуле-1 это не нужно. Тем не менее, мы понимаем, что Формуле-1 нужны новые форматы, все хотят попробовать что-то новое. Давайте попробуем сделать этот эксперимент, посмотрим, как пойдет. Самое главное, чтобы это не навредило воскресной гонке.
Андреас Зайдль, руководитель «Макларена»:
— Мы всегда выступали за спринтерские гонки. Здорово, что уже в этом году мы сможем опробовать данный формат. При этом мы понимаем, что нужно действовать достаточно осторожно. Посмотрим, добавит ли спринт интригу в борьбу в чемпионате.
Себастьян Феттель, пилот «Астон Мартин»:
— Я считаю, что новый формат сделает уикенд ещё более напряженным. У нас будет меньше времени на подготовку, сразу нужно будет показывать результат. При этом все будут в равных условиях, так что скоро мы узнаем, понравится ли такой формат зрителям или нет.
Хельмут Марко, консультант «Ред Булл»:
— Я не буду пока делать никаких выводов. Давайте завершатся три экспериментальных спринта, и тогда мы точно скажем, есть ли в них смысл или нет. Мы открыты к тому, чтобы дать спринтерским гонкам шанс закрепиться в календаре чемпионата.
Эрик Булье, руководитель гран-при Франции:
— Мне нравится идея спринтерских гонок, но я считаю, что они должны использоваться или на всех этапах или вообще не использоваться. Условия должны быть одинаковыми для всех.
Мини-справочник и руководство по 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-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?
Workflow одного спринта команды разработки
Если вы озаботитесь хотя бы некоторыми полезными вещами:
а. базовой дисциплиной
б. формированием оговоренных процессов взаимодействия друг с другом и смежниками
в. объяснением, чем и как занимаются смежники
г. гибкостью в управлению процессами
д. своевременным реагированием на возникающие проблемы
то они улучшат рабочий климат в команде разработке.
Если вы хотите спокойно разрабатывать, то вам нужно собраться, договориться и записать прозрачные правила взаимодействия друг с другом. Хотя бы самые базовые.
Любые процессы и договоренности должны составляться при участии всех заинтересованных лиц, а негативно влияющие процессы должны изничтожаться.
Хочу расписать на примере workflow одного спринта какую пользу приносят его элементы: какие действия выполняются, какие артефакты присутствуют, и зачем каждое из них нужно. Предварительно стоит ознакомиться с определениями эвентов и артефактов scrum.
Спринт N-1: Подготовительный. Который не совсем спринт.
До начала спринта N самой разработки, часть команды занимается подготовительной работой: тестированием, одобрением, проработкой, визуализацией и т.п.
Смысл: Чтобы разработчики могли качественно выполнить поставленную задачу, достичь требуемых параметров или решить чью то проблему, до начала самой разработки следует:
а. тщательно проделать всю подготовительную работу,
б. уменьшить разночтение,
в. протестировать на пользователях или получить одобрение от стейкхолдеров,
г. создать детальную визуализацию.
Выход: набор артефактов и данных, удовлетворяющих чек-листу Definition Of Ready.
Если вы хотите улучшить взаимодействие между кодерами и всеми остальными прямыми участниками процесса разработки, то будет полезно ознакомить и разъяснить базовые функции и процессы всех участников. Среди кодеров хватает интровертов, которым не нравится, когда нарушают их процесс, но и они должны разбираться, как работают остальные, чтобы не получилось обратного эффекта. Начинаем:
OKR, KPI, Требования стейкхолдеров и т.п. — набор входящих внешних условий, которые направляют разработку.
Цель спринта N.
В зависимости от входящих условий, куда разработке следует двигаться, каких параметров требуется достигнуть, кому и зачем помочь, формируется цель грядущего спринта разработки.
Смысл: цель спринта выступает как мотивация команде, объяснение смысла их деятельности, установка показателей.
При отсутствии: немотивированными кодерами в основном управляют с помощью кнута, мата, штрафов.
Любой команде нужна мотивация, чтобы разработка не превращалась в бесконечную череду бессмысленных задач, которые непонятно нужны ли кому то. Особенно в компаниях, где разработка не является основой бизнеса, часто возникает проблема, когда отдел не ценят, отчего у них падает самооценка и мотивация. Нужна прозрачная и понятная цель — помочь кому то решить проблему, повысить какие то параметры бизнеса, улучшить чью то жизнь. Даже в самой убогой компании хорошо иметь осознание смысла своей деятельности.
Backlog grooming — митинг или постоянная деятельность. Управление backlog ограниченной частью команды.
Смысл: Каждый спринт проводится встреча ограниченным составом для чистки, базовой проработки, первичной оценки сложности и реализуемости, декомпозиции, приоритезации задач в backlog.
Выход: Список релевантных и выполнимых задач.
При отсутствии: Огромный список хотелок в backlog, который никто не читает, где задачи лежат забытые годами.
Планирование спринта N-1 — митинг, на котором часть команды подготовки, на основе цели и scope грядущего спринта N выбирает, предварительно оценивает и приоритезирует задачи.
Смысл: деятельность по подготовке к спринту тоже требует некоторого порядка. Упрощается управление ресурсами.
Выход: backlog спринта N.
Разработка тестов
Зависит от стиля разработки и наличия тестировщиков в команде.
Смысл: стоит иметь готовые планы проверки работоспособности кода.
Предлагаю рассмотреть 2 варианта:
При отсутствии тестировщиков, есть вариант передачи создания тестов команде разработки. В этом случае эта деятельность производится в рамках разработки задач в спринте N. По некоторым отзывам такой подход улучшает качество кода, написанного разработчиками.
При наличии тестировщиков, можно использовать подход, когда тесты пишутся до кода. Одна из полезность в том, что разработка задачи заканчивается на разработчике, и уменьшает шанс возвращения готовой задачи от тестировщиков, когда разработчик уже переключился на выполнение другой задачи.
Проработка Use Case’ов — подробная проработка сценариев взаимодействий и результатов внутри задачи.
Смысл: описание сценариев взаимодействия задачи текстом или диаграммами улучшает понимание проблемы всеми заинтересованными сторонами. Дешевый по созданию выход может использоваться для создания тест-кейсов и прототипирования.
При отсутствии: низкая проработка ведет к расхождению понимания, что реально требуется от задачи, возможна потеря альтернативных вариантов использования.
Wireframing, mockuping и prototyping по большому счету являются одним итеративным процессом по проработке визуализации интерфейса, с последовательно увеличивающейся детализацией. Начиная с самого простого и дешевого варианта, происходит тестирование на пользователях/стейкхолдерах, соответствует ли предложенный вариант ожиданию по решению проблемы. Визуальное тестирование настолько полезно в уменьшении разночтения текстового описания и очень дешево, по сравнению с кодингом, что в компаниях с сильным дизайнерским и продуктовым лобби их начали выделять его в отдельную методологию со своими процессами, артефактами и расписанием.
Wireframing — черновая зарисовка элементов интерфейса. Ручкой на бумажке, либо в софте без особых изысков.
Смысл: быстрое и дешевое тестирование/одобрение заинтересованными сторонами выполняемой задачи. Дополнительная демонстрация визуализации резко улучшает восприятие, чем просто описательный текст.
При отсутствии: расхождение понимания, что реально создается. Повышение стоимости разработки.
При отсутствии одобрения: получайте документальное одобрение при разработке под стейкхолдера, для минимизации шанса “а я не это просил”.
Выход: одобренный/протестированный черновой wireframe.
Mockuping — второй шаг проработки визуализации вашего интерфейса. Увеличение детализации.
Смысл и Отсутствие: аналогично с wireframing. Подготовка контента под верстку.
Выход: одобренный/протестированный mockup и верстка.
Prototyping — третий шаг проработки визуализации вашего интерфейса. К высокой детализации визуализации добавляется демонстрация имитации взаимодействия пользователей с продуктом.
Смысл и Отсутствие: аналогично с wireframing и mockuping.
Выход: имеем детальный прототип продукта и визуализацию взаимодействия. Плюс документальное одобрение стейкхолдерами или результат тестирования на пользователях.
DoReady = Definition of Ready — оговоренный командой разработки и предподготовки чек-лист условий, по которым будет проверяться: имеет ли проработка задач достаточный уровень, наличие всех требуемых артефактов, чтобы задача могла быть принята в разработку.
Смысл: наличие оговоренного всеми заинтересованными сторонами формального чек-листа улучшает понимание и взаимодействие внутри команды. Все знают, что и как надо сдать. Можно ткнуть носом в чеклист и послать доделывать нерадивых работников.
При отсутствии: “ой, я почти доделал, там на 95% выполнено”. и… это никогда не будет доделано.
Имхо это самый главный артефакт, по разрешению базовых конфликтов между кодерами и всеми остальными. Сразу видно кто и как не доделал свою работу, что нарушил, и как это отразится на других. С прописанными правилами спорить намного сложнее, чем в случае, когда идет спор на основе мнений или давление авторитетом/должностью. Хотя модератор ПМ, который ткнет в нужный пункт всё равно полезен.
Передали всё дальше:
Спринт N. Начинаем разработку.
Definition of Ready, Цель спринта, Список первично оцененных задач — условия (и артефакты), требуемые для начала спринта.
Планирование спринта N — митинг, на котором команда разработки, на основе цели и scope спринта N выбирает, оценивает, приоритезирует и декомпозирует задачи. В зависимости от средней скорости работы команды набирается определенный объем задач.
Смысл: основная встреча, на которой команда проверяет удовлетворительно ли проработаны задачи. Правильно ли они понимают поставленные задачи, критерии приемки. Разработчики финально оценивают стоимость задач.
При отсутствие: хаос, задачи будут ставиться в любое время, любыми непонятными людьми, даже посреди выполнения других задач.
Выход: backlog спринта N.
Замечание: в зависимости от скорости команды в спринт часто берут 70-80% задач под цель спринта, и 20-30% задач под баги, технический долг или внезапные критические задачи.
Декомпозиция и назначение задач — часто мини-митинг для команды разработки без лишних людей.
Смысл: команда с тимлидом декомпозирует задачи спринта на саб-таски сроком выполнения не более 1 дня (край 2). Саб-таски назначаются берутся разработчиками в зависимости от их специализации или предпочтений.
При отсутствии: от участия команды в процессе зависит будут ли разработчики получать интересные задачи, которые способствуют их развитию.
Выход: детализация backlog спринта N до 1 дневных саб-тасков.
Daily meeting — ежедневный короткий митинг команды разработки.
Смысл: каждый день разработчики должны синхронизироваться друг с другом: кто и что выполнил за предыдущий день, что планирует выполнять в текущий, и какие проблемы мешают выполнить задачу.
При отсутствии: никто не знает над чем работают другие, их проблемы с выполнением. Срываются сроки разработки.
Выход: прогресс фиксируется в burn down chart — графике выполнения задач.
Моё мнение, что один из основных смыслов в существовании ежедневных митингов, это внедрение дисциплины. В кодерах много интровертов, которые не хотят общаться, не хотят знать, чем занимаются другие, не хотят тратить время на митинги. Отсюда и правила проводить стоя, коротко.
На самом деле, если команда хорошо сработалась, качественно общается в чате и сразу делится любыми проблемами, то количество митингов можно сократить, перестроив встречи в постоянно идущий процесс. Но совсем отсекать не стоит.
Обсуждение и решение помех — прямое продолжение daily meeting.
Смысл: после того как разработчики озвучили проблемы с реализацией задач, проходит обсуждение задач, которые команда может решить внутри, тогда она уходит к участникам, а помехи с внешним решением уходят к PM.
При отсутствии: проблемы с реализацией должны решаться сообща, максимально быстро, чтобы никто искусственно не затягивал прогресс.
Когда интроверты сбежали по своим углам, вот тут уже можно обсудить проблемы и варианты их решения.
Commits/Code Review — верификация кода другими членами команды.
Смысл: 1-2 других члена команды должны посмотреть новый код и одобрить качество, стиль и т.п.
При отсутствии: повышение количества ошибок в коде, низкое качество и стиль.
Предлагают проводить code review 2 другими разработчиками с разными уровнями, даже для джуниоров это является неплохим способом обучения. Так или иначе команда получает приемлемый стиль, кто знает когда и кому придется вернуться к рабочему коду.
Deploy to Development server/пред демонстрация — залить код на девелоперское окружение/сервер.
Смысл: любую реализацию задачи можно залить на девелоперское окружение и пригласить заинтересованных лиц для тестирования и предварительного одобрения выполненной работы.
При отсутствии: на финальном демо спринта можно попасть в неудобное положение продемонстрировав неработающую или неправильную реализацию.
Выход: неформальное одобрение выполненной задачи.
Всё равно до этого этапа иногда добираются неправильные интерпретации задания, или прочитанные критерии задачи наискосок. Чем раньше верифицируется, протестируется задача, тем реже придется к ней возвращаться.
Definition of Done — аналогично с Definition of Ready, это чек-лист принципов, по которым PM/PO принимает выполненные задачи.
Смысл: создается командой разработки совместно с PM/PO для предсказуемости параметров принятия работы. Все знают, что является критерием выполненной задачи, а что нет.
При отсутствии: без четких критериев появляется “доработка” задач после попыток сдать их. Либо задачи остаются недоделанными до финальных требований.
Документальное соглашение, по которым PM/PO принимает задачу и её критерии, одобренное обеими сторонами. Хорошо уменьшает количество спорных моментов.
Не дает PM/PO внаглую давить должностью. Отсекает “выполненные” на 95% задачи. Разработчики не должны доделывать завершенные задачи после спринта, если задача четко не удовлетворяет чек-листу, то она не должна считаться принятой, и уходит на будущий спринт.
Review и демонстрация инкремента продукта — митинг, на котором разработчики демонстрируют заинтересованным лицам реализацию цели спринта.
Смысл: разработчики сами демонстрируют работоспособный новый инкремент продукта. PM/PO формально сверяет с критериями оценки задач и соответствие с DoD. Заинтересованные лица решают соответствует ли новый инкремент продукта Цели спринта.
При отсутствии: отсутствие формальной демонстрации и приемки выполненной работы уменьшает ценность критериев приемки, качество выполненной работы.
Выход: Работы команды завершена. Стейкхолдеры решают будет ли вообще следующий спринт.
Демонстрация самим разработчиком выполненной задачи полезнее и понятнее, чем безличное предоставлению нового функционала стейкхолдеру для саморазбора. И стейкхолдер видит, кто сделал для него работу, и разработчики видят для кого они решали проблему.
Сбор отзывов — продолжение Review митинга.
Смысл: наличие в одном месте всех заинтересованных сторон, команды и самого продукта позволяет провести неформальное общение, собрать идеи, предложения и т.п. Получить обратную связь на качество работы команды.
При отсутствии: выделенное формальное время уменьшает ненужные контакты между командой и стейкхолдерами в другое рабочее время.
Выход: новые данные, обратная связь.
Фидбеки вообще полезная штука, даже отзыв от стейкхолдеров на их опыт контактов с разработчиками. Повод для модификации процессов взаимодействия с внешними акторами. Улучшение отношений со стейкхолдерами текущими и будущими всегда можно эксплуатировать — заказы, бюджет, послабления и т.п.
Ретроспектива спринта N — митинг для команды разработки и PM/PO.
Смысл: обсуждение процессов и проблем команды за последний спринт, попытка изменить процессы работы для улучшение команды. Какие процессы были удачные, какие не принесли пользы или повредили, какие новые проблемы возникли и как их можно починить.
Выход: План процессного эксперимента. Процессы модифицируются на следующий спринт, чтобы оценить какие модификации полезны, а от каких стоит отказаться.
При отсутствии: насаждение процессов разработки команды сверху или их отсутствие снижает удобство работы команды, производительность и предсказуемость разработки.
Кроме банального обсуждения проблем и как их стоит решать, хочу обратить внимание на “План процессного эксперимента”. Не стоит относиться к записанным процессам как вырубленным в камне — неизменным и постоянным. Добавляете новое — тестируйте, не понравилось — отсекайте.
Конец спринта N
Спринт N+1. Залить новый инкремент в продакшен
Смысл: по причине частого завершения спринта в конце рабочей недели deploy на продакшен сервер и доступ пользователям происходит уже в следующем спринте, чтобы потенциальные неполадки не вылезли в выходные.