Содержание
Вернемся к примеру с юридической фирмой и разработкой веб-сайта. Разработчики в меру профессиональны, но сайт именно юридической фирмы делают впервые. Юридическая фирма также в курсе, что такое веб-сайт, но вот выступает в роли его заказчика впервые. Юридическая фирма попросит сделать обязательно “не хуже, чем у тех парней” ну и, разумеется, успеть к их годовщине. Данное упражнение также стоит использовать после приоритезации идей команды. Нужно взять наиболее актуальные темы и обсудить каждую идею последовательно.
- Обсуждение с клиентом, создание мокапов и декомпозиция фичи на пользовательские истории.
- Мы сдвинулись в квадрант Качественный-Внешний и метод предполагает привлечения большего количества участников для оценки.
- Когда участники команды разделяют общую цель, в которую все верят, они находят способ, как ее достичь.
- Затем, в следующем спринте, команда доводит юзерстори до ожидаемого конца и показывает ее еще раз.
- Этот резерв требований и составляет Бэклог продукта.
Основные риски в project-менеджменте — сорвать сроки, не вложиться в бюджет и не набрать нужных специалистов на проект. Например, кандидаты могут оказаться дороже, чем планировалось, специалисты уйдут с проекта в процессе работы или их «захантит» конкурент. “Например, Architect и Tech Lead принимают технические решения, которые касаются архитектуры и технологий продукта. Это люди, которые продумывают, как все будет устроено, и как организовать процесс разработки, чтобы рельсы сошлись в одной точке. По словам CTO ITExpert, в идеальном мире группа программистов с общими интересами могла бы разработать продукт самостоятельно.
Ранее мы уже рассказывали, зачем компании необходимо внедрять гибкие методологии, и с какими проблемами она может столкнуться, если команда работает по классической модели Waterfall. На втором спринте product owner поддался мнению одного из завучей, который считал что «журнал куратора» — крайне важный функционал. Мы взяли эту историю в спринт, потратили на нее усилия. Для нас ретроспектива является вторым по значимости мероприятием в SCRUM после планирования спринта.
Ее суть — каждому участнику процесса планирования дается колода карт с числами Фибоначчи — 1, 2, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. «Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Помните, мы говорим об оценках, а не о жестких планах. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования.
SCRUM — Это важный шаг из GTD, который я добавил в наш Scrum-процесс. У нас есть ежедневные митинги для обновлений статуса друг друга, но они не работают как полноценный обзор. Как например планирование спринта или ежедневный обзор в GTD.
Новости IT компанийОбсуждения, Форум
В конце этого совещания все участники команды должны четко понимать, что им предстоит делать. Согласно методологии скрам требования из бэклога продукта служат основой для проработки задач в спринтах, которые представляют собой временные интервалы для выполнения работ. Перед каждым этапом разработки команда проводит встречу со scrum-мастером, чтобы обсудить план работ и сформировать бэклог спринта. В начале итерации команда разработки анализирует, что она должна сделать. Затем выбирает требования, которые сможет к концу итерации превратить в инкремент готовой к поставке2 функциональности. В ходе итерации команда прилагает для этого все усилия, а любые заинтересованные лица не отвлекают команду до конца итерации.
В итоге мы получили прекрасный инструмент, но его не могли использовать обычные учителя школы, которые не были такими продвинутыми. Это важное мероприятие, позволяющее прояснить, чего мы не знаем, каких компетенций нам не хватает. Так, однажды было решено привлечь стороннего разработчика-консультанта в специфических вопросах, опыта решения которых у нас на тот момент еще не было. Разработчики по очереди демонстрируют новый функционал вживую на реальных данных. Фокус — на том, ЧТО мы сделали, а не на том, КАК мы это делали. Вообще мы постоянно стремимся, чтобы наше демо было бизнес-ориентированным, без упоминаний про технические детали.
«Scrum. Революционный метод управления проектами». Книга за 15 минут
Нужно обязательно знать систему и то, как она работает, чтобы новый функционал корректно ложился на все существующее сейчас. Первый этап работы над фичей — это всегда ответ на вопрос «Почему мы вообще решили это сделать? Как это закрывает бизнес-потребность клиента и какова бизнес-цель? Мы детально бэклог это прорабатываем каждую фичу, и нередко работа над постановкой задачи по ней может занять время, сопоставимое с реализацией. Поэтому для планирования у нас отдельный борд. За каждым типом работ закреплен ответственный специалист, у которого есть своя производительность и своя колонка в бэклоге.
Разбейте историю каждой пользовательской активности на более мелкие Stories – пользовательские задачи. Поместите пользовательские задачи под действия, к которым они относятся, а потом расположите их в том же порядке, что и сами действия, или в таком порядке, который будет понятен для пользователя. Вам необходимо сотрудничать с кем-то, кто использует или будет использовать ваш продукт для поддержки их работы. Каждый может легко понять все приложение — обычно это самая сложная часть разработки программного обеспечения.
Скрам, что это и как пользоваться?
Еще один бэклог, но поменьше и более конкретный. Это список задач на конкретный спринт, который формируется на митинге по его планированию. Он тоже может меняться, если команда столкнулась с затруднениями, и нужно сделать что-то еще, кроме того, https://deveducation.com/ что запланировали. Но его цель, она же цель спринта, остается неизменной. Уточнение Product Backlog – это непрерывный процесс создания функциональных продуктовых бэклогов, позволяющий команде Scrum без подготовки начинать планирование спринта.
Фичи-продукты, которые должны быть в нем обязательно, и пользователи ожидают их там увидеть и очень расстроятся, если их там не будет. Performance – это функции, которые обеспечивают производительность вашего продукта и отличают его от других. Например, если это магазин, то Performance – это wish-list и сравнение. Удовлетворение пользователей зависит от уровня Функциональности, предоставляемой нашим продуктом.
А, ну и будьте готовы, что и вам придется готовиться к этим совещаниям раз в две недели. Новая функция или исправление ошибки, не так важно, как возможность видеть, что работа идет, и идет успешно. Именно за это, кроме возможности менять бэклог, когда им хочется, и любят Scrum владельцы продуктов. Участникам команды это тоже очень важно, так как условно «закрывает гештальт», дает возможность почувствовать удовлетворение от проделанной работы. Это могут быть пользовательские истории, к которым прикреплен имейл от кого-то с конкретными требованиями, фотографии из каких-то сессий.
Agile Retrospective StarterKit
Да и сам бэклог у нас заполняется простым и доступным языком без сложных технических спецификаций для того, чтобы он был понятен каждому в команде. Все элементы в нем сгруппированы в зависимости от их веса для бизнеса. Чем он больше, тем быстрее элемент отправиться в разработку. За создание бэклога отвечает заказчик или product owner, в его обязанности входит составление и тщательное описание всех требований, а также обсуждение этих требований с командой разработки. Безусловно, требования должны быть однозначными и понятными, но если у команды возникнут какие-либо вопросы, вы должны быть в состоянии на них ответить и уточнить любые нюансы. В Scrum процесс планирования происходит в начале каждого нового спринта и так и называется — «планирование спринта».
шага к успешному Sprint Review: советы и лайфхаки
В результате вы будете двигаться итерациями «вслепую», не инспектируя и не адаптируясь. Эти ценности — «протокол» поведения и принятия решений Scrum Team. Без ориентира на них команда не сможет работать с фреймворком эффективно. Это будет набор встреч без ожидаемого результата. Адаптация — изменение курса на основе обратной связи, полученной в процессе инспекции. Благодаря этому не тратите много времени на разработку функционала, который не будет соответствовать реальным потребностям рынка.
Определенный набор навыков зависит от требований продукта. Хотеть следовать принципам Agile и делать это на самом деле — две большие разницы. Знаете, сколько людей способны на самоорганизацию? А сколько готовы согласиться на коллективную ответственность?
Полезно проводить демонстрацию на продуктовой системе с реальными данными и реальными пользователями, которые уже работают в системе. Такой подход возможен когда система находится в стадии альфа-тестирования. Для каждой команды story point — величина индивидуальная, эмпирическая, но каждый член команды чувствует ее. Во-первых, это нужно, чтобы избежать появления ложного чувства точности для больших оценок. Если история оценивается примерно в 17 story points, то нет смысла обсуждать, должна ли она быть 15, или 18, или 21.
Выберите основные функции, которыми должен обладать ваш продукт, определите их приоритетность и запишите в бэклог.