что делает спринт в мм2

Грандиозный прорыв Хэмилтона в бразильском спринте. Ферстаппен проиграл Боттасу поул

Начало уик-энда в Сан-Паулу надолго запомнится болельщикам «Формулы-1». Хэмилтон выиграл квалификацию, но стартовал с последнего места в спринте. Его соперник Макс Ферстаппен оказался в центре скандала, а Валттери Боттас вновь извлек из всего наибольшую выгоду.

Удар по чемпионским амбициям Хэмилтона

После столь насыщенных двух дней «Гран-при» Бразилии мало у кого остались эмоции на воскресную гонку. Первые минуты пятничной тренировки задали тон всему уик-энду в Сан-Паулу. В «Мерседес» приняли решение сменить двигатель внутреннего сгорания на болиде Льюиса Хэмилтона, что привело к штрафу британца. Семикратный чемпион мира «Формулы-1» потеряет пять позиций на стартовой решетке воскресной гонки. На субботний спринт наказание не распространялось, однако гонщику «Серебряных стрел» и так не было суждено начать заезд с первых рядов.

Тем не менее пятничная тренировка осталась как раз за британцем. В квалификации к спринту Хэмилтону снова не было равных. Льюис показывал быстрейшие времена в каждом сегменте сессии, а в финале опередил Макса Ферстаппена на 0,438 секунды. Третьим стал Валттери Боттас, а Серхио Перес закончил квалификацию четвертым. Пьер Гасли вновь был лучшим из остальных. Француз, поставив пятое время, обошел «Феррари» Карлоса Сайнса и Шарля Леклера. Ландо Норрис, Даниэл Риккьярдо и Фернандо Алонсо замкнули десятку сессии. Российский гонщик Никита Мазепин оказался худшим в пятницу, а после квалификации во время интервью от досады не смог сдержать слез.

Спустя несколько часов техническая делегация FIA нашла нарушение на заднем антикрыле машины Хэмилтона. FIA постановила, что максимальное расстояние между элементами DRS в открытом положении превысило допустимое значение в 85 мм. Однако вердикт судьям удалось вынести лишь на следующий день, так как в дело вмешался непосредственно лидер сезона Ферстаппен. После квалификации Макс потрогал крыло на болиде соперника, из-за чего сам был вызван к судьям. «Серебряные стрелы» утверждали, что голландец испортил деталь Хэмилтона.

И все же судьи не стали наказывать Ферстаппена, а выписали ему лишь денежный штраф. А Хэмилтону санкций избежать не удалось: британец за техническое нарушение был дисквалифицирован из квалификации, и ему пришлось начинать спринт на одном ряду с Никитой Мазепеным. Таким образом, Ферстаппен переместился на поул спринта, а напарник Льюиса Боттас — на вторую строчку.

Мягкие покрышки помогли Боттасу выиграть старт

События вне трассы немного затмили субботнюю тренировку на «Интерлагосе». Во второй практике лучшим неожиданно стал герой предыдущих спринтов Фернандо Алонсо. Однако сложно было представить испанца победителем спринтерской гонки в Сан-Паулу.

Не все гонщики решились использовать покрышки «софт» на спринт. Лидеры также выбрали разные шинную стратегию на заезд: Ферстаппен, Перес и Леклер взяли «медиум», а Боттас и Сайнс — «софт». Именно мягкие покрышки лучше всех заработали на старте. Валттери Боттас прошел лидера чемпионата на стартовом рывке, а позже голландца обогнал и Карлос Сайнс. Провальный старт не стал помехой для Ферстаппена: Макс быстро отыграл позицию у испанца и погнался за финном.

На старте не обошлось и без столкновений. Напарники по «Альфа Ромео» не смогли вместе войти в первый поворот на втором круге, и Антонио Джовинацци развернул Кими Райкконена.

Агрессивные пилотаж Льюиса Хэмилтона на первых кругах принес свои плоды. Гонщик «Мерседес» сразу же вырвался на 14-ю позицию и не собирался останавливаться. К десятому кругу Хэмилтон прорвался на 11-е место, а обгон на Риккьярдо позволил Льюису войти в десятку.

Боттас и Ферстаппен отъезжали от всего пелотона, а Сайнс, Перес, Норрис и Леклер сражались за подиумное место спринта. За десять кругов до финиша лидер сезона догнал финна и готовился его атаковать. Мягкие шины Боттаса теряли свою скорость, а Макс наконец заставил свой «медиум» правильно работать.

Боттас удержал позади себя Ферстаппена, Хэмилтон прорвался в пятерку

На последних кругах спринта интрига еще оставалась. Ферстаппен прессинговал Боттаса за победу, Перес атаковал Сайнса в борьбе за подиум, а Хэмилтон пролетал мимо соперников на пути к пятерке.

Лидер сезона держался в секунде от Валттери, но подобраться на расстояние атаки никак не мог. В итоге финн удержался на первой позиции и второй раз подряд победил в спринтерской квалификации. Ферстаппен был фаворитом в борьбе за поул, но просчет по шинам и провальный старт лишили голландца первой позиции на гонку в воскресенье.

Серхио Перес также не смог обогнать Сайнса. Это сражение получилось ярким, но развязки придется ждать в завтрашней гонке. Льюис Хэмилтон, легко пройдя Феттеля, Окона, Гасли и Леклера, на последних кругах обогнал субботнего именинника Ландо Норриса и добрался до пятой позиции. Тем не менее пилот «Серебряных стрел» начнет воскресную гонку с десятого места из-за штрафа за смену двигателя.

Никита Мазепин не смог обогнать своего напарника Мика Шумахера в спринте. В воскресенье россиянин будет стартовать с последней строчки.

Выделите ошибку в тексте
и нажмите ctrl + enter

Источник

Спринт в Формуле-1: Что это такое, как будут начисляться очки, зачем он нужен

В 2021-м году в Формуле-1 появится совершенно новый формат гонки – это квалификационный спринт. В апреле руководство «королевских гонок» утвердило, что уже в текущем сезоне будет проведено три спринта, а через год их может стать шесть. Рассказываем о том, что такое квалификационный спринт.

РЕГЛАМЕНТ И ФОРМАТ

Квалификационный спринт – это мини-гонка на 100 километров. Предполагает, что она будет длиться примерно 25-30 минут. По итогу этой гонки победитель получит три очка, два очка – обладатель второго места и одно – финишировавший на третьем месте. При этом во время спринта не будет пит-стопов.

Результаты квалификационного спринта определят стартовую решётку во время основного гран-при.

ЧТО БУДЕТ С КВАЛИФИКАЦИЕЙ И ПРАКТИКАМИ НА ТАКИХ ЭТАПАХ?

Классическая квалификация будет перенесена на пятницу, а вот количество свободных заездов уменьшится на один. Теперь будет две сессии свободных заездов.

Стоит сказать, что на таких этапах квалификации будет изменены правила использования шин. Теперь команды будут использовать только «софт». При этом во время основной гонки пилоты могут самостоятельно выбирать комплект резины, а не тот, на котором они показали лучшее время во втором сегменте.

ГДЕ ПРОЙДУТ СПРИНТЕРСКИЕ ГОНКИ?

На текущий момент точно известно, что первая спринтерская гонка пройдет на гран-при Великобритании в Сильверстоуне. Скорее всего, такая гонка будет и в итальянской Монце. А вот по поводу третьего этапа пока что остаются вопросы – больше всего шансов в бразильского Интерлагоса.

Спортивный директор Формулы-1 Росс Браун считает, что в 2022-м будет как минимум шесть спринтерских гонок.

ЧТО ДУМАЮТ ПИЛОТЫ И БОССЫ КОМАНД?

Мнений относительно нового формата разделились практически пятьдесят на пятьдесят. Приведем лишь несколько цитат.

Жан Тодт, президент ФИА:

— Если честно, мне не нравится идея спринтерских гонок. Мне кажется, что Формуле-1 это не нужно. Тем не менее, мы понимаем, что Формуле-1 нужны новые форматы, все хотят попробовать что-то новое. Давайте попробуем сделать этот эксперимент, посмотрим, как пойдет. Самое главное, чтобы это не навредило воскресной гонке.

Андреас Зайдль, руководитель «Макларена»:

— Мы всегда выступали за спринтерские гонки. Здорово, что уже в этом году мы сможем опробовать данный формат. При этом мы понимаем, что нужно действовать достаточно осторожно. Посмотрим, добавит ли спринт интригу в борьбу в чемпионате.

Себастьян Феттель, пилот «Астон Мартин»:

— Я считаю, что новый формат сделает уикенд ещё более напряженным. У нас будет меньше времени на подготовку, сразу нужно будет показывать результат. При этом все будут в равных условиях, так что скоро мы узнаем, понравится ли такой формат зрителям или нет.

Хельмут Марко, консультант «Ред Булл»:

— Я не буду пока делать никаких выводов. Давайте завершатся три экспериментальных спринта, и тогда мы точно скажем, есть ли в них смысл или нет. Мы открыты к тому, чтобы дать спринтерским гонкам шанс закрепиться в календаре чемпионата.

Эрик Булье, руководитель гран-при Франции:

— Мне нравится идея спринтерских гонок, но я считаю, что они должны использоваться или на всех этапах или вообще не использоваться. Условия должны быть одинаковыми для всех.

Источник

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. Решаем проблемы взаимодействия с клиентом и внутри команды

«Мобильное приложение должно быть «живым», пользователь должен видеть, что проект развивается»

Мы в Redmadrobot работаем по гибким методологиям Agile и Scrum. Как известно, они предполагают значительную свободу в том, как организуются спринты по проектам, — каждая компания подбирает удобную для себя модель. Кейсов — информации о том, как организуются команды во время выполнения спиринтов — во внешних источниках крайне мало. Раскрываем свою “кухню”.

Для начала озвучу основные проблемы, которые подсветились в производственном процессе со стороны ВА.

1. Клиент хочет видеть все и сразу на главном экране
Часто компании мыслят категориями и решениями веба и хотят на странице запуска своего мобильного приложения видеть все основные функции, возможности, сервисы (как если бы это была главная страница сайта). Это, мягко говоря, не всегда оправданно, но требует аргументации.
2. Аналитик выдумывает требования, которые не устраивают разработчиков
Разработчиков, которые читают требования, нет. Есть аналитики, которые 10 раз во время написания требований обсуждают их с разработчиками.
3. Требования становятся ничтожными на этапе тестирования
Нужно общаться с тестировщиками — они знают, как сломать. Аналитику полезно получить большой список советов «как должно работать» до начала проектирования.
4. Фантастический дизайн
Макеты должны быть реализуемыми. Поэтому нужны требования к интерфейсами и дизайн-ревью.
5. Приложение должно развиваться, и развиваться оно должно постепенно
Невозможно реализовать сразу все фичи. Поэтому набор задач нужно ограничивать.

«Совершенствоваться не обязательно. Выживание — дело добровольное» (ц) Эдвард Демминг

Рано или поздно любой проект, даже в Agile и Scrum, приходит к стандартизации процессов. Но совершенствование невозможно без пристального фокуса на самом процессе. У нас он выглядит так.

Спринт-пульс

Стандартный спринт в Redmadrobot составляет 4 недели. За это время мы успеваем пройти путь от формализации цели, её реализации в строках кода и тщательного тестирования до заливки новой версии приложения в App Store и Google Play.
Сначала мы готовим требования к дизайну и только потом — к разработке.

— 3 неделя. Подготовка кандидатов в спринт

Участники:
PM — запрашивает набор задач для будущего спринта
РО (Product Owner) со стороны заказчика — формирует набор фич, которые являются потенциальными кандидатами в новый спринт
BA — обрабатывает информацию и проясняет открытые вопросы
Артефакты:
— набор задач-кандидатов в будущий спринт в виде фич
— приоритеты от заказчика
Инструменты: JIRA

Вся процедура является уточнением приоритетов ранее спланированного roadmap.

— 2 неделя. Подготовка кандидатов в спринт и Scope Review

Участники:
BA — фиксирует требования, очищает Impact Map от информации, которая излишне детализирована и не имеет отношения к цели
РО со стороны заказчика — отвечает за цели бизнеса
UX-проектировщик — помогает продумать цели пользователей и методы их достижения
Артефакты:
— Impact Map
— описание пользователей
— User Stories
— топология стейкхолдеров
— спецификация API внешних систем
Инструменты: Xmind, Confluence

Все задачи, которые поступают к нам, можно условно разделить на два вида:
— есть работающие методы API
— методов нет

Scope Review

Участники: DEV, DES, QA, BA, PM, UX-­проектировщик
Артефакты:
— скоуп спринта, согласованный и одобренный заказчиком
Инструменты: Confluence

Это промежуточный чекпойнт между появлением спецификации требований и требований к интерфейсу. Определяется, сколько времени потребуется команде, чтобы выполнить данную задачу, есть ли стоп­факторы, которые не позволяют взять задачу в спринт, оцениваются трудозатраты. Скоуп отправляется PM на согласование с Product Owner. После этого спринт фиксируется, и добавление новых фич становиться невозможным.«Приложение должно развиваться, и развиваться оно должно постепенно» — разбираемся с проблемой №5

— 1 неделя. Разработка требований к интерфейсу и Design Review

Участники: BA, UX-проектировщик
Артефакты:
— Use Cases
— контентные ограничения
— нефункциональные требования
Инструменты: Confluence

В практике подготовки требований мы используем стандартные подходы для их описания: Use Cases (шаблон, предложенный Алистером Коберном). Сценарии хорошо взаимодействуют с подготовленными ранее User Stories и покрывают их. Разработка сценариев идет совместно с UX-проектировщиком и описывает будущее поведение системы, которое нужно отразить дизайнеру. Выход за эти рамки порождает изменения в требованиях: контентные ограничения, которые выявляются на основании спецификации API и общения с заказчиком, а также нефункциональные требования.

NB! После подготовки требований к интерфейсу мы проводим заочное ревью с остальными участниками команды. Сбор комментариев на раннем этапе позволяет не рисовать нереализуемый дизайн.

Design Review

Кейс “Мой Билайн”
Когда в приложении реализовывалась услуга “Номер на выбор”, нам в ВА упал уже готовый дизайн (как наследство с тех времен, когда в проекте не было полноценной аналитики). Проведя анализ, я выявил, что дизайн сложен для реализации + наше API не поддерживало такую реализацию + был нарисован лишний набор экранов, которые не применялись в приложении. Неверно был определен scope на дизайне.
Нам пришлось все перерисовывать.

1 неделя спринта. Покрытие макетов требованиям и Requirement Review

Участники: BA, UX-проектировщик
Артефакты:
— Impact Map
— описание пользователей
— User Stories
— Use Cases
— нефункциональные требования
— контентные ограничения
— cпецификация API внешних систем
— функциональные требования

Requirement Review

Участники: DEV,DES,QA,BA,PM, UX-проектировщик
Артефакты:
— Impact map
— описание пользователей
— User Stories
— Use Cases
— нефункциональные требования
— контентные ограничения
— cпецификация API внешних систем
— функциональные требования
Инструменты: Confluence

Задачи на данном этапе — удостовериться, зафиксирован ли необходимый набор требований для разработки, понятны ли они всем участникам команды и истолковываются ли одинаково. При появлении замечаний и комментариев требования изменяются и проходят процедуру повторного ревью, после чего согласовываются с заказчиком.

Кейс “Мой Билайн”
Приложение реализуется на двух платформах — Android и iOS; у каждой платформы и команды разработки — свой тим-лид. Бывает, эти команды выдают какие-то решения, которые друг с другом не синхронизированы. Я фиксирую их в требованиях.

2 неделя спринта. Поддержка команды на этапе разработки и проработка требований по крупным задачам

Участники: BA, DEV, UX-проектировщик
Артефакты:
— скоуп спринта, согласованный заказчиком
— спецификация API внешних систем (при наличии)
Инструменты: Confluence

Задачи тут делятся на два типа. В первом случае отсутствует спецификация API — аналитик совместно с разработкой готовит спецификацию требований к Backend. Она становится основной для будущей карты экранов и учитывается в контентных ограничениях. Во втором случае есть спецификация API внешних систем, но задача слишком большая, чтобы полностью пройти весь цикл от анализа до тестирования. Тогда процесс проходит по стандартной процедуре, описанной в пункте “Разработка требований к интерфейсу и Design Review”. Затем она отправляется в следующий спринт, где будет покрыта требованиями к мобильному приложению и разработана, либо откладывает в Backlog до появления методов API.

NB! Естественно, периодически приходится работать с задачами, которые из-за своего размера не могут попасть в спринт. Тогда в ход идет следующая схема:

— Бизнес-анализ в отдельном спринте
— Проектирование интерфейса
— Передача в разработку

Такая схема может растягиваться на три четырехнедельных спринта.

Вывод

Идеального процесса не бывает, процесс бывает хорошим на текущий момент. Наш процесс на текущий момент позволяет эффективно решать задачи бизнеса заказчика. Естественно, организация спринтов по проектам не покрывают озвученные в начале текста проблемы полностью. О том, как побороть их окончательно — в следующей статье.

Источник