Содержание
Product Manager больше работает с маркетингом и клиентами, определяет потребности рынка. Владеет vision, roadmap, высокоуровневым бэклогом, ценовой политикой, политикой лицензирования, отвечает за ROI. Приоритизирует фичи и большие технические задачи, определяет критерии приемки для них. Это не имет отношения к подходу управления требованиями и написания пользовательских историй. Чем опытней команда и каждый сотрудник в отдельности, тем слажаней работа и планирование. Я всегда выступал в роли визионера для команд, в которых я был.
В результате вы будете двигаться итерациями «вслепую», не инспектируя и не адаптируясь. Адаптация — изменение курса на основе обратной связи, полученной в процессе инспекции. Благодаря этому не тратите много времени на разработку функционала, который не будет соответствовать реальным потребностям рынка. И даже если ошибетесь, то цена просчета будет небольшой.
Основные роли в команде разработчиков
Следующим шагом необходимо создать истории пользователей, описать кто, что и зачем будет делать в вашем программном продукте. Здесь важно учесть абсолютно все нюансы и ситуации, которые могут возникнуть. Далее важно определить то, какие функции будут выполняться продуктом, а также какие задачи он будет решать.
Команда разработчиков — +/- 5 специалистов, которые будут заниматься работой над проектом. Команд этих может быть любое нужное вашему проекту количество, но они должны состоять из специалистов в определенных технологиях и быть небольшими, чтобы избежать проблем с коммуникацией. В общем, для работы в командах Scrum мало быть хорошим техническим специалистом, нужны еще и soft skills https://deveducation.com/ выше среднего. Это могут быть пользовательские истории, к которым прикреплен имейл от кого-то с конкретными требованиями, фотографии из каких-то сессий. Может быть просто большой текст с рассказом о том, чего бы хотелось, или список. BA in Progress (более детальное видео)В этой секции находятся пользовательские истории, над которыми идет активная работа клиента и вендора.
Часто задаваемые вопросы
Разбейте историю каждой пользовательской активности на более мелкие Stories – пользовательские задачи. Поместите пользовательские задачи под действия, к которым они относятся, а потом расположите их в том же порядке, что и сами действия, или в таком порядке, который будет понятен для пользователя. Story Mapping позволяет легко выбирать User Stories из разных функций, которые вместе обеспечивают значимую ценность. Это означает, что вы можете уверенно определить объем и создать MVP или полезный релиз. SCRUM – Мы записываем каждый запрос от заказчика и каждую проблему или ошибку в нашей системе TFS. Интересно, что из-за того, что я, будучи руководителем программы, выгружаю вещи из головы, иногда возникают проблемы!
Product Owner больше работает с технологиями и командой, обычно находится вместе с ними. Помогает создать Vision, но отвечает больше за бэклог команды и его реализацию. Определяет и приоритизирует цели итерации и User Stories, которые будут входить в нее. Определяет критерии приемки User Stories и в конце итерации их проверяет. Расскажите людям, как будет идти сбор требований, уточнение требований, за что отвечает клиент, а за что отвечаете вы. Очень важно предоставить клиенту доступ к программному обеспечению, которое вы будете использовать для управления требованиями.
- Участники формируют перечень задач в начале каждого этапа работы.
- В нашем примере с Fun Events Club подзадачи уже расположены в порядке важности.
- В таких случаях команда добавляет себе работы или сокращает ее количество во время спринта.
- Но SCRUM — это не только о взаимодействии, но и о правильном и точном планировании.
Наш продукт имеет широкий спектр применения — это и CRM, и аналитическая система, и телефония, и колл-центр. Поэтому существует множество векторов его развития. В то же время ресурсы не бесконечны, выбор приоритетов критически важен.
Основой для бэклога могут быть либо истории пользователей, либо дорожная карта, это зависит от особенностей компании и продукта. Product Backlog – это артефакт, в котором собраны и упорядочены все требования к будущему программному продукту. В этом документе описано все, что необходимо реализовать в процессе разработки, а его созданием занимается собственник самого будущего продукта. Документ, который отображает цели, общее видение продукта, направление его развития и основные этапы разработки. Зачастую в нем нет деталей, но указаны сроки выполнения задач, что позволяет установить дедлайны и рассчитать время работы. Важно ещё отметить, что при внедрении любого функционала большое количество новых кейсов и идей к нам приходят уже в процессе работы.
Как распределяются роли в команде
По этому не скупитесь на специалистов, которые делают такую работу. Есть отчеты, но в отчетах вы можете посмотреть в определенном виде, а дальше вам надо идти в джиру и менять все руками или использовать массовые изменения. Самый большой плюс данного подхода — это визуальное понимание того, что твориться с бэклогом. Пишу это, так как планирую работу команды на5-6 спринтов вперед и понимаю, что если на доске кроме основных спринтов будут ещё другие стори, но не в беклоге, это будет ту мач. Клиент так или иначе получит то что он хотел и в той последовательности в которой договорились.
После чего их нужно согласовать внутри команды и с людьми заказчика. Теги — это ключевые слова, по которым можно легко сгруппировать/находить определенную информацию. Например, в своих проектах, я часто использую теги типа Web, APP, Integration.
Как работать с бэклогом и приоритизацией фич в зрелом продукте
Легкая и доступная в использовании, но сложная в освоении, если верить официальному описанию. На практике вся сложность сводится к тому, чтобы научить разработчиков и других специалистов следовать этой самой методологии в работе. Ну это не совсем про настройку самого программного обеспечения — это больше про настройку организационных вопросов и процессов. Допустим, Фикс прайс проект состоит из 5 фич, оценили High level estimation 2,5 месяца (каждая фича по спринту (по 2 недели)).
шага к успешному Sprint Review: советы и лайфхаки
Еще одна причина успешной работы скрама заключается в том, что он раскрывает интеллектуальный потенциал сотрудников. Зачастую, когда что-то идет не так, вокруг есть люди, которые знали о потенциальной проблеме, но почему-то их идеи не были учтены. Ретроспектива— периодически пересмотр того, что работает, а что — нет. Могут быть приглашены Product Owner, заказчики или менеджмент компании. Оба этапа взаимосвязаны друг с другом единой целью – выявить сильные и слабые стороны. Но если в случае с ретроспективой речь идет об анализе работы команды, то Sprint Review направлен на анализ продукта.
Каждый из команды в нашем случае добавил что-то свое. Защита фичи перед командой — одна из важнейших частей процесса, так как здесь уже знающие о сути функционала люди презентуют идею коллегам со свежим взглядом, которые и будут ее реализовывать. На данном этапе разработчики смотрят на новый функционал с точки зрения возможных реализаций в коде, поэтому иногда могут придумать такой вариант, что сократит планируемые сроки едва ли не вдвое. Участники семинара должны иметь практический опыт работы в проектах с использованием одной или нескольких гибких методологий разработки.
Его работа — точно знать, что должен делать готовый проект и каждая его часть, а заодно вникать в то, как идет разработка. Планирование самого спринта — обсуждение самой приоритетной задачи командой и скрам-мастером. На этом этапе выбираются истории из бэклога, бэклог это которые нужно сделать для выполнения цели спринта. В конце этого совещания все участники команды должны четко понимать, что им предстоит делать. Это как раз тот, полученный результат работы над каждой подзадачей, что обладает ценностью для заказчика.
Один из главных плюсов гибких методологий — возможность влиять на процесс. В случае со Scrum вы можете договориться с владельцем продукта о производительности команды в каждый спринт (ее легко отследить по диаграмме сгорания задач). Оставайтесь вовлеченными, делитесь оперативно обратной связью, объясняйте свои ожидания и фиксируйте их “на бумаге”. Еще одна цель Sprint Review – получить обратную связь всех причастных к процессу разработки.
Story Mapping: нарисуйте общую картину User Stories вашего продукта
Скрам превращает участников небольших команд в менеджеров своей судьбы. Мы знаем, что несем ответственность за собственный выбор и обязательно найдем способ добраться в Бостон, если будем самостоятельно выбирать маршрут. Мы станем объезжать ремонтные работы и избегать пробок в часы пик, принимать решения на лету, адаптируясь к независимым решениям других водителей.
Я знаю, что там все есть, но иногда меня застают врасплох бизнес-стейкхолдеры, спрашивающие меня о чем-то, наиболее важном для них, а у меня этого нет в голове! Ну да ладно, обычно я отвечаю, что посмотрю все детали и вернусь к ним, но это один из тех случаев, когда я почти чувствую, что мне нужно что-то держать в голове, хотя я предпочитаю этого не делать. Как Agile-практика и программного менеджера для сложного ПО, меня всегда привлекали инструменты и системы, которые делают мою жизнь менее напряженной и более продуктивной. Для обеспечения доставки на следующий день достаточно центральной системы диспетчеризации, которая планирует маршрут водителя единожды в начале дня.
No products in the cart.