Дешевая-обувь.рф
ГлавнаяРазноеСпринт что это

Unicloud Business 365. Спринт что это


Планирование спринта: помните, что это спринт, а не марафон

Оригинальная статья Эшли-Кристиан Харди: Sprint Planning: Remember it’s a Sprint, not a Marathon.

Статья переведена с английского Еленой Максимовой.

Планирование спринта - это ограниченная по времени встреча в начале спринта, на которой Команда и Владелец Продукта (ВП) обсуждают и принимают решение о том, какая работа будет завершена в спринте.

Как правило, встреча делится на две части: "Что?" и "Как?".

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

  • Команда обсуждает согласованную работу и план ее завершения
  • Пользовательские истории разбиваются на задачи, уточняются технические детали.

Если команда практикует регулярные встречи по уточнению беклога продукта, то она уже имеет представление, о чем идет речь в истории.

  • Владелец продукта сам определяет и решает, какая работа будет завершена
  • Беклог продукта не актуален, не приоритезирован или не готов к обсуждению
  • В конце планирования все слишком детализировано, и вся работа уже распределена по исполнителям (эту проблему трудно преодолеть)
  • Никто не понимает, что означает статус "Готово"
  • Встреча слишком длинная
  • Встреча не включает участников в процесс
  • Некоторым людям сложно проявляться
  • Неподходящая среда, команда не чувствует поддержки или безопасности
  • Нет доверия или уважения с обеих сторон
  • Команда не понимает, для чего нужна эта встреча

Чек-лист для подготовки к успешному планированию

  • Мотивированная команда
  • Хороший контакт и доверие между ВП и командой.
  • Если ВП не доверяет выводам команды, встреча быстро станет упражнением по избеганию вместо диалога о работе. Команде важно видеть ценность встречи и преимущества планирования. Если есть какие-либо сомнения ‒ процесс рухнет
  • Встреча проходит в установленное время.
  • Она не должна быть слишком длинной и утомительной, потому что тогда теряется ценность
  • Проведена подготовительная работа, часто в формате встреч по уточнению беклога.
  • ВП гарантирует, что существует здоровый, поддерживаемый и приоритезированный беклог
  • Истории в верхней части беклога, которые должны входить в следующий спринт, разбиты на небольшие части, чтобы команда могла их обсудить и запланировать
  • Скрам-мастер убедился, что участвуют все члены команды: Владелец продукта, Скрам-мастер, разработчики, тестировщики, администратор базы данных - каждый, кто является частью команды разработчиков. Другие заинтересованные стороны могут присутствовать только в качестве наблюдателей, не прерывающих процесс.
  • Каждый участник должен чувствовать свою ценность на встрече, иметь возможность поделиться своим видением
  • Решения о работе принимаются командно.
  • Если ВП принимает все решения о работе и ее выполнении, команда будет чувствовать, что это пустая трата времени.
  • Консенсус по поводу метода оценки и разбивки работы. Story Points или Planning Poker - команде нужно договориться о методе оценки, чтобы работать согласованно.

Длительность встречи зависит от длины спринта, чем дольше спринт, тем больше времени нужно для его планирования. Для ориентира:

  • Однонедельный спринт - 2 часа
  • Двухнедельный спринт - 4 часа
  • Спринт длинной в 1 месяц - 8 часов

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

Задача встречи - сформулировать цель спринта. Ее можно представить в форме беклога спринта. Беклог спринта - список приоритезированных задач, которые команда берется завершить до конца спринта. Здесь важно помнить о командных критериях готовности (Definition of Done).

Если вы представили себе конечный результат спринта - согласуйте его с Владельцем продукта, и ваш путь станет гораздо проще. Команду очень мотивирует визуализация и мысленное представление этого результата.

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

Структура встречи нужна в виде предварительного высокоуровневого плана. Пример: рассказ Владельца продукта, команда обсуждает задачи, сессия вопросов и ответов с ВП, беклог спринта уточнен, ретроспектива и встреча закрыты. Эта практика должна быть неизменной для каждой встречи, она поможет команде войти в хороший режим и получить от нее максимальную отдачу.

Производительность команды:

  • Достаточно взять среднее последних 3 спринтов, как руководство
  • Обсудите часы доступности команды, отпуска, режим работы членов команды
  • Помните, что спринты не бывают одинаковыми!
  • Не пытайтесь быть слишком детальными - это бесполезная трата времени, т.к. количество неизвестных слишком велико
  • Команда все равно согласовывает объем работы
  • Оставьте некоторое время для решения пока неизвестных вопросов и проблем.
  • Так команда получает больше свободы действия.
  • Проще добавить работу в спринт, если у вас хорошо проработан беклог, чем убрать ее.

Сотрудничайте, вместе планируйте работу над пользовательскими историями, не оценивайте объем ресурсов, не пытайтесь слишком оптимизировать или микроменеджить каждого. Продукты должна делать команда, а не группа людей, работающих над своими задачами.

  • Определите критерии готовности (DoD). Это устраняет конфликты и дает прозрачность процесса. "Готово" должно значить потенциальную поставку продукта.
  • Обсудите все задачи, чтобы получить представление о работе и ее выполнении: создание скриптов, рефакторинг, интеграция кода, тестирование и автоматизация, исправление багов, техническое обслуживание.
  • Не слишком привязывайтесь к процессу оценки, это всего лишь предположение, а не обязательство.
  • Частая ошибка на этом этапе - хождение кругами.
  • Не привлекайте отдельных членов команды к ответственности за оценку. Команда не должна бояться оценивать.
  • Не стоит сравнивать относительные оценки с фактически затраченным временем (если нет существенных различий, но тогда это нужно вынести на командную ретроспективу).
  • Вся команда владеет беклогом спринта, поэтому не распределяйте задачи по исполнителям.По опыту я знаю, что если это происходит, тогда одни и те же люди постоянно получают одну и ту же работу. Это плохо, потому что тогда вы развиваете «специалистов» в своей команде, а обмен знаниями и развитие становятся ограниченными. Совершенно нормально иметь специалистов, пока они обмениваются знаниями с командой, но нет ничего хуже, чем один человек, который несет знания и ответственность за конкретную часть кода, а затем он уходит - забирая эти знания с собой.
  • Цели спринта достигает вся команда. Поскольку у вас есть список приоритетов, то если одна задача выполнена, член команды может предложить помощь другим, если нужно; или перейти к следующей по приоритету задаче.
  • Используйте Story Points как способ относительной оценки. Тут вы сравниваете задачи их по сложности, а не по времени. Разработчику проще сказать «эта задача в 3 раза сложнее, чем та», а не «эта задача займет у меня около 4 дней». Не смешивайте Story Points с часами, тогда люди просто пытаются конвертировать Story Points во время, а затем Story Points вообще теряют свою ценность.
  • Согласовывайте размеры ваших задач. Хороши задачи, которые занимают не более 1 дня; их преимущества:
    • разработчикам проще планировать рабочий день,
    • повышается эффективность, если задачу можно начать и завершить в тот же день,
    • небольшие задачи дают более полное представление об объеме работы,
    • можно сократить "узкие горлышки" процесса,
    • атомарные задачи можно было делать параллельно. Задачи, зависящие друг от друга, - будут вызывать проблемы и провоцировать "узкие горлышки".
  • Создавайте только те задачи, которые требуют выполнения; разработка, тестирование, документация, демо и т. д. ... Не вносите в них работу Владельца продукта или командные встречи.
  • Если вы не уверены в задаче, создайте “зазор”. Он нужен для проведения исследования.
  • Не планируйте 8-часовой рабочий день, даже если команда нанята на это время. В действительности команда не работает 8 часов подряд. «Эффективность» хорошей здоровой команды - около 70% рабочего времени, поэтому я планировал 6 часов в день, т.к. в течение дня происходит много всего: встречи, обеденный перерыв, выяснения деталей с ПО, короткие перерывы.

Среда

Команде важно чувствовать себя в безопасности, понимать, что нормально не знать всего прямо сейчас. Agile весь состоит из адаптации, подстройки и обучения. Должно быть ощущение сотрудничества, поддержки, любопытства и драйва. Команда не должна бояться задавать вопросы, высказываться. Команде важно чувствовать уверенность в том, что они действительно могут поставить и какие взять на себя обязательства; и если у них есть какие-то сомнения или возникают риски, отнеситесь к ним всерьез. Очень важно, что последнее слово о поставке остается за командой, а не Владельцем продукта.

Автономия команды

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

Как Скрам-мастер, вы должны позволить команде ставить собственные цели, коучить и учить команду как взять на себя ответственность, помочь им присвоить план и беклог спринта. Ни в коем случае не сдерживайте команду, помогите им удивляться и изобретать, чтобы превзойти самих себя. Позвольте им думать и пускай в комнате время от времени воцаряется тишина.

Активное слушание

В начале встречи особенно важно вовлечь команду в рассказ ВП, когда он объясняет и рассказывает о приоритетах. Хорошо, если команда активно слушает и задает вопросы на этом этапе.

Взаимное уважение

Я говорил о важности доверия, но уважение не менее важно. Я упомянул, что Владелец продукта должен иметь доверие в команде, и важно, чтобы оно было взаимным. Команда должна уважать ВП и доверять решениям, которые он принимает. Это тот человек, который приоритезирует их работу, им важно знать, что их работа имеет ценность и хорошо продумана.

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

Вопросы

Не успокаивайтесь, если команда не задает никаких вопросов. Если вопросов нет, то кажется, что есть полное понимание, но такое бывает крайне редко. Вы можете договориться, что каждый должен задать хотя бы один вопрос. Обычно, когда возникает один вопрос, за ним появляются и другие.

Процесс

Если вы используете физическую Kanban доску, предложите команде самостоятельно выписать свои стикеры, повесить их на доску и расставить приоритеты, опять же, это хороший способ развивать самоорганизацию. Используйте время встречи для обновления своего инструмента, будь то физическая Kanban доска, Jira или TFS. Во-первых, каждый сможет увидеть план, согласиться на него и начать работу. Во-вторых, хорошо, когда каждый понимает процесс. Тогда, если Скрам-мастер болен, то члену команды несложно подменить его.

Планирование спринта ограничено во времени, заканчивайте его вовремя. Даже если фактически планирование еще не закончено, важно начать работу, продолжение встречи не поможет завершить пользовательские истории. Совершенно нормально не знать всех деталей, это развивает гибкость!

Иногда команде необходима смелость сказать «Ок, этого достаточно, мы не знаем всех деталей, но будем изучать оставшиеся и приспосабливаться по пути». Быть гибким - значит экспериментировать, изобретать, и старт работы дает команде шанс сделать это!

В конце встречи возьмите несколько минут, чтобы снова подумать о том, что получилось хорошо, чего не было в предыдущем спринте и убедитесь, что забираете удачные практики с собой, а все плохое не повторится. Это позволяет бросить последний взгляд на запланированную работу и начать свое путешествие.

Бонус - скрайбинг статьи от Алёны Серпецкой:

www.scrum.ua

sprint - это... Что такое sprint?

  • sprint — [ sprint ] n. m. • 1895; mot angl. « course rapide et brève » ♦ Allure la plus rapide possible, qu un coureur prend à un moment déterminé d une course, et notamment à la fin; ce moment, cette fin de la course. ⇒ emballage, finish, pointe, rush.… …   Encyclopédie Universelle

  • Sprint — Nextel Corporation Год основания 2005 Ключевые фигуры Тимоти Донахью, председатель совета директоров Гари Форси, президент и CEO Тип …   Википедия

  • sprint — SPRINT, sprinturi, s.n. Mărire a vitezei de către un concurent (de obicei în ultima fază a parcursului) la unele întreceri sportive. ♦ Categorie de probe sportive pe distanţă scurtă, caracterizată prin viteză foarte mare. – Din fr., engl. sprint …   Dicționar Român

  • sprint — s.m.inv., s.f.inv. ES ingl. {{wmetafile0}} TS sport 1a. s.m.inv., sforzo breve e intenso di un corridore, ciclista o podista, o di un cavallo, per superare un avversario, spec. nel tratto finale di gara: con un notevole sprint superò tutti gli… …   Dizionario italiano

  • Sprint — [ʃprɪnt], der; s, s: Wettlauf, Wettrennen über eine kurze Strecke: solche Schuhe sind für Sprints am besten geeignet. * * * Sprịnt 〈m. 1〉 Lauf, Rennen mit größtmögl. Geschwindigkeit über eine kurze Strecke [<engl. sprint „schnell rennen“] * * …   Universal-Lexikon

  • Sprint — Sm Kurzstreckenlauf per. Wortschatz fach. (20. Jh.) Entlehnung. Entlehnt aus ne. sprint, zu ne. sprint schnell laufen , das aus einer nordgermanischen Sprache stammt. Verb: sprinten; Nomen agentis: Sprinter.    Ebenso nndl. sprint, nfrz. sprint,… …   Etymologisches Wörterbuch der deutschen sprache

  • šprint — šprȉnt m DEFINICIJA sport reg. sprint, v. ETIMOLOGIJA njem. Sprint ← engl. sprint: v. sprint …   Hrvatski jezični portal

  • sprint´er — sprint «sprihnt», verb, noun. –v.i. to run at full speed, especially for a short distance: »The runners sprinted to the finish line. –n. 1. a short race at full speed: »The first of the added money runs was the $22,725 Autumn Day Handicap, a… …   Useful english dictionary

  • Sprint — Sprint, n. The act of sprinting; a run of a short distance at full speed. [1913 Webster] {Sprint race}, a foot race at the highest running speed; usually limited to distances under a quarter of a mile. [1913 Webster] …   The Collaborative International Dictionary of English

  • Sprint — (spr[i^]nt), v. i. [imp. & p. p. {Sprinted}; p. pr. & vb. n. {Sprinting}.] [Cf. {Sprunt}.] To run very rapidly; to run at full speed. [1913 Webster] A runner [in a quarter mile race] should be able to sprint the whole way. Encyc. Brit. [1913… …   The Collaborative International Dictionary of English

  • Sprint — der; s, s <aus gleichbed. engl. sprint zu to sprint, vgl. ↑sprinten>: 1. kurzer, schneller Lauf. 2. das Sprinten (1; Sport) …   Das große Fremdwörterbuch

    • new_en_ru.academic.ru

    Scrum — реальный опыт работы по методологии / Блог компании Unicloud Business 365 / Хабр

    В данной статье я привожу обзор организации процесса создания программного обеспечения в команде, в которой работаю. Моя цель – это поделиться опытом разработки и управления командой разработчиков.

    Для организации процесса работ над проектом мы решили выбрать популярную методологию 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 Технический директор ООО «Юниклауд Лабс»

    Если интересно что мы делаем — Welcome

    habr.com