Что такое итерации спринты

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”. Раз в две недели тимлидер разговаривал с каждым членом команды, где тот мог сказать всё то, что нельзя сказать на ретроспективе.
Были и неофициальные мероприятия за пределами офиса. Например два раза в год мы ездили командой на шашлыки.

Стимулирование

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

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

Схема выглядела вот так:

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

Могу сказать, что идея оказалась провальной. Мы всего один раз смогли заработать эти поощрительные два дня. Оценки на задачи давались очень завышенные и на каждое действие создавался отдельный митинг с участием всей команды, т.к. все боялись не успеть и потерять поощрительные два дня. Завышенные оценки приводили к расслабленности во время реализации этих задач, а куча митингов мешала сосредоточится на программировании и в итоге общая производительность отдела упала. К этому моменту команда уже понимала, что нужно сделать шаг назад и вернуться к прежней системе, но не успела. Отдел закрыли по независящим от команды причинам.

Заключение

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

Источник

В чем разница между спринтом и итерацией в Scrum и длиной каждого спринта? [закрытый]

есть ли разница между спринтом и итерацией или можно иметь итерации в спринте или спринт-это просто терминология, используемая вместо итерации в Scrum? Будет полезно, если кто-то сможет пролить свет на это.

предположим, что есть 4 спринта, и вы решили, что первый спринт будет идти до 10 дней, требуется ли, чтобы другие 3 спринта имели одинаковую длину длины 1-го решенного спринта.

10 ответов

Что касается длины спринта: все идет до тех пор, пока спринт timeboxed, т. е. он завершен в запланированную дату, а не «когда он будет готов». (Или альтернативно, в редких случаях спринт завершается преждевременно, чтобы начать новый спринт в случае изменения некоторых существенных граничных условий.)

Это помогает иметь спринты подобной продолжительности. Меньше нужно помнить о расписании спринта, и ваше планирование становится более точным. Мне нравится держать мой в 2 календарных неделях, которые будут разрешаться в 8..10 рабочих дней вне курортного сезона.

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

держите их последовательными по продолжительности, и вы получите лучшее планирование и доставку. Все будет измеряться тем, сколько 10-дневных спринтов требуется, чтобы закончить серию случаев использования.

держите их последовательными по длине, и вы можете планировать свои поставки,тестирование конечных пользователей и т. д. с большей точностью.

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

важная вещь о спринте заключается в том, что: в спринте функциональность, которая должна быть доставлена, фиксирована.

спринт обычно итерации. Но вы можете, например, иметь 4-недельный спринт, но иметь 4 недельные» внутренние » итерации в этом спринте.

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

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

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

как и фон, скорость-это сумма оценочных баллов, присвоенных элементам отставания или историям, которые были полностью завершены во время этого спринта. Большинство сторонников Agile (например, Майк Кон, Кен Швабер и Джефф Сазерленд) рекомендуют командам использовать «недавнюю погоду», чтобы основывать свои будущие оценки на том, сколько, по их мнению, они могут совершить в спринте. Это означает использование среднего значения из последних нескольких спринтов в качестве основы для оценка в предстоящей сессии планирования sprint.

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

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

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

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

«__ _ в значительной степени является организационной проблемой, вызванной долгими часами, небольшим временем простоя и постоянным наблюдением за коллегами, клиентами и превосходящими»

нет, это не определение scrum, это выдержка Википедии об определении выгорания.

Не делайте слишком много коротких 10 дней спринтов. В конце концов, вы сожжете свою команду. Используйте короткие спринты там, где они вам действительно нужны, и не делайте слишком много подряд. Думай о долгосрочной перспективе. Бегун всегда сами шагов для полная гонка и делает спринты на коротких дистанциях только там, где это имеет значение.

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

итерация-это общий гибкий термин для одного цикла разработки. Это общий термин, используемый в процессах итеративной и инкрементной разработки (IID). Scrum, который является специализированным гибким методом, или мы можем сказать, что специализированный инкрементный процесс разработки использует термин Sprint для своих итераций, то есть один цикл разработки в Scrum называется Sprint. Sprint специфичен для Scrum, поэтому Sprint-это итерация, но не все формы итераций являются спринтами. Другие методы agile могут не использоваться один и тот же термин (Sprint) для определения итерационной работы, но Sprint и Iteration являются двумя наиболее часто используемыми терминами.

спринт, как определено в pure Scrum, имеет продолжительность 30 календарных дней. Однако длина итерации может быть любой, как определено командой.

Источник

Как съесть слона и при чём тут метод управления проектами SCRUM

Как часто проекты в вашей компании не укладываются в заданные временные рамки? Хотя, казалось бы, планирование, графики, отчёты… Организовать работу максимально эффективно можно, для этого нужно знать некоторые инструменты-помощники. Один из них – метод SCRUM.

Метод SCRUM – часть идеологии Agile, представленной в начале этого века группой независимых разработчиков программного обеспечения. Она объединяет несколько гибких методик управления, основанных на эффективной организации труда небольших групп специалистов. Метод оказался настолько эффективным, что теперь применяется и за пределами сферы разработки ПО: везде, где есть проекты, жёсткие сроки, небольшая команда и возможность разбивки проекта на составные, логически завершенные, части. Как съесть слона? По кусочкам.

Весь проект в SCRUM делится на итерации длительностью кратной неделе. Наиболее распространенное время – от 1 до 4 недель. Каждая итерация называется «спринт».

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

Особенность спринтов в том, что одновременно решается только одна задача.

После каждой итерации вы получаете отзыв о том, движетесь ли вы в том направлении, которое нужно. Это и есть главное преимущество SCRUM – гибкость в разработке благодаря постоянной обратной связи.

Если проект делается без спринтов, весь сразу, то есть вероятность, что от него придётся отказаться, если в итоге выяснится, что продукт имеет критические недостатки. Те проблемы, которые можно выявить на ранних стадиях, используя SCRUM, могут быть слишком поздно обнаружены при использовании других методов.

Каждый человек, участвующий в проекте SCRUM, выполняет только отведенную ему роль. Чаще всего этих ролей три: владелец продукта, мастер и команда.

Владелец продукта, он же PO (Product Owner), не является в прямом смысле собственником. Это менеджер, через которого идет связь между клиентом или потребителем и командой, делающей продукт.

Главная задача – коммуникация с заказчиком и оперативное донесение информации до исполнителей.

Мастер является частью команды, но со специфическими обязанностями. Его основная задача – обеспечить рабочий процесс. Также он берет на себя роль модератора во время совещаний, разрешает противоречия в команде и следит за исполнением принципов метода.

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

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

Планируется весь объём работ, который будет выполняться за следующий спринт.

Должны быть чётко поставлены цели и определены методы их достижения.

Также определяется трудоёмкость тех задач, которые запланированы на текущий спринт. Члены команды поясняют PO и мастеру, как они планируют работать, чтобы достичь цели.

Каждый член команды отвечает SCRUM-мастеру на 3 вопроса:

Решение проблем не ищется в рамках ежедневного совещания. Всё общение занимает не более 15 минут.

Презентация законченной части продукта, которая проводится в присутствии всех заинтересованных сторон, включая клиента.

Подведение итогов спринта

Обсуждение того, что удалось достичь и что не получилось.

Здесь должны быть получены ответы на 3 вопроса:

Метод SCRUM применяется в работе над рядом проектов в бизнес-клубе «Атланты». Более 140 мероприятий в год, в том числе открытые и эксклюзивные – только для резидентов – встречи с интересными спикерами, форум-группы, обсуждения, собрания клубов в клубе… Всё это нуждается в чётком планировании. Команда клуба тестирует на себе разные методики и готова делиться наработками.

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

В следующей статье расскажем о распространённых ошибках и трудностях внедрения SCRUM в работу.

Источник

Спринты и ключевые понятия Scrum в Azure Boards

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018–TFS 2013

Эта статья содержит краткий словарь терминов и доступных средств, используемых для отслеживания работы с помощью спринтов и методов Scrum. См. также:

Средства Agile

Набор веб-средств, используемых для мониторинга работы и поддержки гибких методологий. Гибкие инструменты поддерживают базовые гибкие методы — Scrum и Канбан, которые уже сегодня используются группами разработки программного обеспечения. Дополнительные сведения: о гибких средствах и управлении проектами Agile.

Ошибки

Тип рабочего элемента, который записывает потенциальный источник неудовлетворенности продукта. Общее имя типа рабочего элемента для отслеживания дефектов кода. Каждая команда может выбрать способ управления ошибками. Некоторые команды подобны отслеживанию ошибок и требований в невыполненной работе. Другие команды, например, для контроля ошибок по мере выполнения задач, связанных с поддержкой требования. После этого ошибки отобразятся на их taskboard. Дополнительные сведения: Управление ошибками.

Группа и индивидуальная емкость

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

Настроив производительность команды, Группа знает только общее количество рабочих часов или дней, назначенных группе для каждого спринта. С помощью этого средства вы задаете для отдельных участников команды емкость и дни. Настройка емкости для каждого члена команды, работающего во время спринта, приводит к отображению полосы емкости для этого лица. Дополнительные сведения: Настройка емкости спринта.

Шкалы производительности

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

Ежедневные собрания Scrum

Ежедневные собрания по Scrum помогают группам следить за тем, что необходимо сделать, чтобы максимально повысить их способность удовлетворить обязательства по спринтам. Мастер Scrum должен обеспечить структуру собрания и обеспечить ее начало в течение 15 минут или меньше. Дополнительные сведения: рекомендации Scrum, ежедневное совещание Scrum.

Прогноз

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

Пути итерации (спринты)

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

Невыполненная работа по продукту

Интерактивный список рабочих элементов, которые соответствуют плану проекта команды или плану, по которому Группа планируется доставлять. Невыполненная работа по продукту поддерживает приоритеты работы, прогнозирования работы по спринтам и быстрое связывание работы с элементами невыполненной работы портфеля. Вы можете определить элементы невыполненной работы, а затем управлять их состоянием с помощью доски Канбан.

Каждая невыполненная работа по продукту может быть настроена командой. Дополнительные сведения: Создание невыполненной работы.

Элемент невыполненной работы по продукту

Тип рабочего элемента, определяющий приложения, требования и элементы, которые группы планирует создать. Владельцы продуктов обычно определяют и блокируют элементы невыполненной работы по продукту, которые определены в процессе Scrum. Дополнительные сведения: Scrum процесс типы рабочих элементов и рабочий процесс.

Роль владельца продукта

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

Роль мастера Scrum

Шаблоны Scrum помогают создавать и обслуживать работоспособные команды, применяя процессы Scrum. Они посвящены, обучению, обучение и помощь командам Scrum в правильном опыте методов Scrum. Образцы Scrum также действуют как агенты изменения, чтобы помочь командам преодолеть препятствия и повысить производительность группы. Дополнительные сведения: рекомендации по Scrum, роль главной роли Scrum.

Спринты (также называемые итерациями)

Спринт — это период времени, который обычно составляет от двух до трех недель, которые используются для группирования рабочих элементов, которые должны быть завершены в течение этого периода времени. Спринты используются в методах Scrum для поддержки планирования спринта, выработки спринта и других процессов Scrum. Спринты определяются с помощью путей итерации. Дополнительные сведения см. в разделе Общие сведения о путях к областям и итерациям (спринты).

Невыполненная работа спринта

Интерактивный список рабочих элементов, назначенных одному и тому же пути спринта или итерации для команды. Невыполненная работа спринта поддерживает команды, использующие методологии Scrum. Дополнительные сведения: Планирование спринта.

Диаграмма сгорания для спринта

Диаграмма «выработка спринта» отражает ход выполнения всей работы, которая была оценена во время совещания по планированию спринта. Команда следит за ИТ, чтобы снизить риски и проанализировать отработку на протяжении всего цикла спринта. Идеальная линия тренда всегда указывает на устойчивую выработку. Синяя область, как показано на следующей диаграмме, представляет то, что происходит на самом деле. Он показывает накрутки работы по мере того, как члены команды добавляют задачи и сокращают работу по мере выполнения задач членами команды. Дополнительные сведения: мониторинг выработки спринта.

Цели спринта

Цели спринта используются для фокусировки действий спринта. Цель состоит в краткой информации о том, что группа хочет выполнить в конце спринта. Дополнительные сведения: рекомендации по Scrum, Установка целей спринта.

Планирование спринтов

Собрание по планированию спринта выполняется в начале спринта, а также в том случае, если владелец и Группа продукта согласны с набором целей спринта и работы. Дополнительные сведения: рекомендации по Scrum, собрания по планированию спринта.

Совещания с ретроспективой спринта

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

Задача

Задача — это тип рабочего элемента, используемый для мониторинга предполагаемой и оставшейся работы. В Scrum задача определяется в диапазоне от 4 до двенадцати часов. Определение задач является необходимым для мониторинга выработки спринта, работы с производительностью команды и использования taskboard. Задачи связаны с родительскими элементами невыполненной работы по продукту или пользовательскими историями. Дополнительные сведения: Добавление задач в элементы невыполненной работы.

Доска задач

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

Teams

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

Участник команды

Член, добавленный в проект или организацию, который был добавлен в конкретную группу. Project участники могут быть добавлены в несколько команд. Несколько средств гибкой разработки, таких как планирование ресурсов, групповые оповещения и мини-приложения панели мониторинга, ограничены группой. То есть они автоматически ссылаются на пользователей, которые были добавлены в качестве членов группы для поддержки действий планирования или отправки оповещений.

Сведения о добавлении пользователей в команду см. в разделе Добавление пользователей в проект или конкретную команду.

Технический долг

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

Собрания по рассмотрению

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

Пользовательская история

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

Диаграмма скорости и скорости

Скорость — это мера объема работы, которую может выполнить команда в зависимости от их периодичности спринта. Встроенная диаграмма скорости измеряет скорость, суммируя баллы истории (Agile), трудозатраты (Scrum) или size (CMMI), определенные для спринта.

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

Кроме встроенной диаграммы скорости, Мини-приложение скорости можно добавить на панель мониторинга команды. Это мини-приложение можно настроить для суммирования количества рабочих элементов или суммы усилий. Дополнительные сведения: Настройка мини-приложения скорости.

Каждая команда связана с одной и только одной диаграммой скорости. Скорость зависит от производительности команды, спринта по спринту. Однако со временем скорость должна указывать на надежное среднее значение, которое можно использовать для прогнозирования всей невыполненной работы. Свести к минимуму вариативность размера элемента невыполненной работы — усилия или баллы истории — вы получаете более надежные метрики скорости. Дополнительные сведения: Добавление задач в элементы невыполненной работы.

Источник