Денис Тучин - Пользовательские истории в Agile-проектахDenis Tuchin
Видеозапись вебинара: https://www.youtube.com/watch?v=YBjbaygwvBM&index=9&list=PLu7pKL8OAoRTTwi3KK2OmVmuX9VllOFwt
1. Что такое пользовательские истории (User Stories)
2. Зачем они нужны в ваших проектах?
3. Как пользовательские истории помогают повысить удовлетворённость заказчика?
4. Как применяются пользовательские истории в Scrum?
Для кого:
Вебинар будет полезен менеджерам продуктов, менеджерам проектов, бизнес-аналитикам, владельцам продуктов, проектировщикам и разработчикам систем, которые хотят начать использовать преимущества разработки требований и создания продуктов в стиле Agile в своих проектах
Истории Пользователей (User Stories) - семинар на AgileUkraine 7, 2009-04-25Timofey (Tim) Yevgrashyn
Семинар на тему Историй Пользователя (User Stories) прошел в рамках седьмой конференции AgileUkraine.
Первоначально задуманный как практическое упражнение для 20 человек, он превратился в захватывающую тематическую дискуссию с аудиторией в 50 человек.
Судя по отзывам, участникам было о чем пообщаться.
Денис Тучин - Пользовательские истории в Agile-проектахDenis Tuchin
Видеозапись вебинара: https://www.youtube.com/watch?v=YBjbaygwvBM&index=9&list=PLu7pKL8OAoRTTwi3KK2OmVmuX9VllOFwt
1. Что такое пользовательские истории (User Stories)
2. Зачем они нужны в ваших проектах?
3. Как пользовательские истории помогают повысить удовлетворённость заказчика?
4. Как применяются пользовательские истории в Scrum?
Для кого:
Вебинар будет полезен менеджерам продуктов, менеджерам проектов, бизнес-аналитикам, владельцам продуктов, проектировщикам и разработчикам систем, которые хотят начать использовать преимущества разработки требований и создания продуктов в стиле Agile в своих проектах
Истории Пользователей (User Stories) - семинар на AgileUkraine 7, 2009-04-25Timofey (Tim) Yevgrashyn
Семинар на тему Историй Пользователя (User Stories) прошел в рамках седьмой конференции AgileUkraine.
Первоначально задуманный как практическое упражнение для 20 человек, он превратился в захватывающую тематическую дискуссию с аудиторией в 50 человек.
Судя по отзывам, участникам было о чем пообщаться.
Итак, вы делает свой проект по Agile методологии. Итерации, планы, Daily Scrum — вроде все это работает.
Один из первых вопросов, с которым сталкиваются команды: «что положить в Бэклог продукта?». Абстрактное слово Требования уже давно известно и в тоже время, Гибкие подходы требуют гибкости мышления во всех областях. Ведь мы договорились, что Требования будут появляться по мере необходимости — мы же AGILE в конце концов. А как же описать всю систему, как построить планы, в конце концов, как оценить сложность?
С одной стороны пользователям не нужны рассказы про архитектуру, базы данных, им нужно «клац-клац, тык-тык». С другой стороны, команда должна знать, что мы вообще строим. Простые инструменты и форматы оказываются более полезными в условиях гибкости и постоянных изменений.
Agile формат записи требований в виде Историй Пользователя уже широко популярен. О нем рассказывают на тренингах, в книгах, статьях и когда хвастаются успехами внедрения Scrum, XP и других методологий.
В тоже время, простота формата хранит много ловушек. Более того, этот формат не единственный
Мы поговорим о том, что же отличает Agile Работу с Требованиями, на чем фокус и какие инструменты нам помогут.
Роман Приходько, Владимир Беспрозванных, «Сбербанк-Технологии» — Платформа ЕФСDev_Party
Роман Приходько, «Сбербанк-Технологии» — Платформа ЕФС — принципы построения и инструменты реализации.
Конференция Dev Party (http://devparty.ru).
Вологда, 02.04.2016.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
Система управления жизненным циклом разработки программного обеспечения Devpr...Evgeny Savitsky
Devprom - российская компания-разработчик инструментов в области управления проектами
Дата образования: июнь 2008
Количество сотрудников: 9 человек
Количество загрузок дистрибутива: 8600
Количество зарегистрированных пользователей: 4800
Цикл выпуска новых версий продукта: 1 месяц
Доклад предназначен для Design Team Leads, которые заинтересованы в развитии своих дизайнеров, настройке процесса обучения; и дизайнеров, которые хотят развиваться и расти в профессиональном плане.
Наш департамент вырос с 20 до 55 дизайнеров в короткие сроки. Стала актуальной задача по определению уровня конкретного дизайнера: чем отличается Middle от Senior, как выровнять эти уровни между СНГ, Британией и США. Как обучить такое количество дизайнеров, выстроить Personal Development Plan.
В докладе мы хотим рассказать, какие инструменты и методы мы разработали для этого, какие результаты это принесло.
Менеджер продукта. Как обрести и развить ключевые навыкиDenis Beskov
Менеджер продукта — это предприниматель и интрапренёр.
К задачам менеджера продукта я отношу необходимость понимать рынок и предметную область, быть в курсе происходящего вокруг, предвидеть будущее, обретать видение продукта, создавать финансовую и экосистемную модели, транслировать видение продукта и корректировать ход развития продукта.
Чтобы делать всё это и приводить продукт к успеху, нужны такие навыки, как умение чувствовать и понимать проблемы людей, настраивать источники информации и оставаться в потоке новостей, мыслить рыночно, а не прецедентно, видеть взаимосвязи, прогнозировать, убеждать, рисковать и рефлексировать.
В основной части мастер-класса мы рассмотрим, как формировать и развивать эти навыки в вашей рабочей среде.
Доклад на конференции SCRUM:open в Харькове 25 июня 2009.
Краткий обзор о том, как гибко управлять требованиями с использованиями Историй Пользователя как наиболее удобного инструмента. Иллюстрация теоретических и практических аспектов.
Основано на работах Майка Кона с его разрешения.
Итак, вы делает свой проект по Agile методологии. Итерации, планы, Daily Scrum — вроде все это работает.
Один из первых вопросов, с которым сталкиваются команды: «что положить в Бэклог продукта?». Абстрактное слово Требования уже давно известно и в тоже время, Гибкие подходы требуют гибкости мышления во всех областях. Ведь мы договорились, что Требования будут появляться по мере необходимости — мы же AGILE в конце концов. А как же описать всю систему, как построить планы, в конце концов, как оценить сложность?
С одной стороны пользователям не нужны рассказы про архитектуру, базы данных, им нужно «клац-клац, тык-тык». С другой стороны, команда должна знать, что мы вообще строим. Простые инструменты и форматы оказываются более полезными в условиях гибкости и постоянных изменений.
Agile формат записи требований в виде Историй Пользователя уже широко популярен. О нем рассказывают на тренингах, в книгах, статьях и когда хвастаются успехами внедрения Scrum, XP и других методологий.
В тоже время, простота формата хранит много ловушек. Более того, этот формат не единственный
Мы поговорим о том, что же отличает Agile Работу с Требованиями, на чем фокус и какие инструменты нам помогут.
Роман Приходько, Владимир Беспрозванных, «Сбербанк-Технологии» — Платформа ЕФСDev_Party
Роман Приходько, «Сбербанк-Технологии» — Платформа ЕФС — принципы построения и инструменты реализации.
Конференция Dev Party (http://devparty.ru).
Вологда, 02.04.2016.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
Система управления жизненным циклом разработки программного обеспечения Devpr...Evgeny Savitsky
Devprom - российская компания-разработчик инструментов в области управления проектами
Дата образования: июнь 2008
Количество сотрудников: 9 человек
Количество загрузок дистрибутива: 8600
Количество зарегистрированных пользователей: 4800
Цикл выпуска новых версий продукта: 1 месяц
Доклад предназначен для Design Team Leads, которые заинтересованы в развитии своих дизайнеров, настройке процесса обучения; и дизайнеров, которые хотят развиваться и расти в профессиональном плане.
Наш департамент вырос с 20 до 55 дизайнеров в короткие сроки. Стала актуальной задача по определению уровня конкретного дизайнера: чем отличается Middle от Senior, как выровнять эти уровни между СНГ, Британией и США. Как обучить такое количество дизайнеров, выстроить Personal Development Plan.
В докладе мы хотим рассказать, какие инструменты и методы мы разработали для этого, какие результаты это принесло.
Менеджер продукта. Как обрести и развить ключевые навыкиDenis Beskov
Менеджер продукта — это предприниматель и интрапренёр.
К задачам менеджера продукта я отношу необходимость понимать рынок и предметную область, быть в курсе происходящего вокруг, предвидеть будущее, обретать видение продукта, создавать финансовую и экосистемную модели, транслировать видение продукта и корректировать ход развития продукта.
Чтобы делать всё это и приводить продукт к успеху, нужны такие навыки, как умение чувствовать и понимать проблемы людей, настраивать источники информации и оставаться в потоке новостей, мыслить рыночно, а не прецедентно, видеть взаимосвязи, прогнозировать, убеждать, рисковать и рефлексировать.
В основной части мастер-класса мы рассмотрим, как формировать и развивать эти навыки в вашей рабочей среде.
Доклад на конференции SCRUM:open в Харькове 25 июня 2009.
Краткий обзор о том, как гибко управлять требованиями с использованиями Историй Пользователя как наиболее удобного инструмента. Иллюстрация теоретических и практических аспектов.
Основано на работах Майка Кона с его разрешения.
Из презентации мы узнаем что такое Omni channel и чем он отличается от других концепций; Какие есть возможности сейчас?; Много сценариев – одно решение (CJM); Как узнать чего хотят пользователи?; -Портреты и сценарии пользователей их значимость; Выводы;
Все проекты начинаются с определения требований к проекту. Однако то, каким образом записаны эти требования, сильно влияет на успех проекта. Что значит управлять требованиями гибко? Как управлять требованиями с помощью историй пользователей? Какие подводные камни могут нас ожидать?
LeSS in the big bank a five-year journey.pdfDenis Tuchin
We will trace the history of LeSS in a large bank from underground to the preferred framework from the perspective of 16 LeSS-like cases.
I will tell how I grew LeSS and got a profit in the hostile organizational structure.
I will share how I sold the LeSS framework to business people who hadn’t heard anything about Agile before and wanted to save their subordinate managers.
How I helped middle managers understand their roles in the new LeSS context and how many of them were fired.
In the end, I will explain 5 years of struggle between the corporate bonus system and the LeSS principle of a single goal for all teams of one product.
LeSS in the big bank a five-year journeyDenis Tuchin
We will trace the history of LeSS in a large bank from underground to the preferred framework from the perspective of 16 LeSS-like cases.
I will tell how I grew LeSS and got a profit in the hostile organizational structure.
I will share how I sold the LeSS framework to business people who hadn’t heard anything about Agile before and wanted to save their subordinate managers.
How I helped middle managers understand their roles in the new LeSS context and how many of them were fired.
In the end, I will explain 5 years of struggle between the corporate bonus system and the LeSS principle of a single goal for all teams of one product.
Прототипирование, как способ исправить клиентский опыт до старта разработки п...Denis Tuchin
Запись выступления: https://www.youtube.com/watch?v=LJ-0nm1UWDg
- Прототип нового продукта или новой функции продукта зачастую можно за считанные часы ещё до выделения бюджета
- Тестирование такого прототипа, как правило тоже обходится достаточно дёшево
- На докладе рассказал, том как быстро создавать и тестировать прототипы, улучшая клиентский опыт ещё до старта разработки
Типовые слайды для тренинга "Agile для лидеров"Denis Tuchin
Тренинг предназначен для руководителей команий, директоров департаментов, начальников отделов, а также вновь назначенных Владелцев Продуктов и бывших руководителей проектов
Видео: https://www.youtube.com/watch?v=I5bI1QTGrRs
Провёл тренинг и kickoff, а команда всё равно не понимает, зачем она повесила доску, и каждый день двигает стикеры? Завёл бэклог и запустил все события Scrum, а Владелец Продукта продолжает себя вести как начальник отдела или руководитель проекта? Провёл воркшоп по 5 порокам команды, а её участники продолжают работать обособленно? Значит ты что-то упустил при внедрении изменений. На докладе рассмотрим, типичные ошибки внедрения изменений на реальных примерах из Agile-кочинга и как их избежать:
- Отсутствие активного участия руководства
- Недостаточное вовлечение сотрудников
- Недостаточное уделение внимания планированию трансформации
- Завышенные ожидания от Agile и отсутствие желания/возможности поменять окружение
Денис Тучин - Как не завалить Ретро: практические советы, как готовится и как...Denis Tuchin
Подготовка к Ретроспективе
1.1. Карта фасилитации
1.2. Нейро-карта фасилитации
1.3. Какие практики выбрать именно для этого ретро?
Что-то пошло не так, что делать?
2.1. Цикл вмешательства (Intervention Cycle)
2.2. Всегда ли применим цикл вмешательства
2.3. Кейсы!
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Денис Тучин - Принципы Agile в управлении требованиямиDenis Tuchin
Этот вебинар для бизнес-аналитиков, архитекторов, руководителей проектов, менеджеров продуктов, которые хотят узнать об особенностях управления требованиями в Agile-проектах.
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Denis Tuchin
Видео выступления: https://www.youtube.com/watch?v=vOMSRSTl1Xo
Хотим мы этого или нет, но часто приходится работать с удалёнными командами, а иногда и с полностью распределёнными, когда все участники сидят в разных местах. На докладе разберём некоторые паттерны организации взаимодействия распределённых Agile команд, какие из них работают лучше, какие хуже и почему, а также посмотрим, что можно изменить, чтобы получился всё же Agile. Рассмотрим такие паттерны как:
- передача изолированных User Story удалённой команде
- Индивидуальные User stories
- Scrum of Remote Scrums
- Функциональные распределённые команды
- Scrum in spite of distributed team
Николай Борисов, Денис Тучин - Основы метода LEGO SERIOUS PLAY, фасилитация, ...Denis Tuchin
4-часовой мастер-класс
Lego Serious Play (LSP) — инновационный и эффективный способ проведения различных встреч, будь то стратегическая сессия, генерация идей нового продукта или ретроспектива. Метод LSP — это не просто метод фасилитации, это своеобразный язык общения.
Он позволяет находить совместные решения, моделировать системы и их взаимосвязи для людей с разным уровнем и порогом входа - "6+". Отличный способ построить любую текущую картину и понять, как достичь планируемой.
Позволяет:
- обеспечить вовлеченность и прозрачность близкую к 100%;
- создать 3D модель, на которую можно смотреть под разным углом, изменять - дополнять и соединять с другими, сравнивать и обсуждать;
- на уровне биохимии мы готовы реализовывать, то что уже построили руками;
- мягко и плавно выводит на очень сокровенные темы и истинные причины проблем и конфликтов, помогаем договориться там, где это казалось не возможным.
На мастер-классе участники узнают о принципах работы метода Lego Serious Play (LSP), где и как можно применить его, а также сами построят индивидуальные и групповые модели.
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
2. Немного о себе
• С 2004 разработка коммерческого ПО
• С 2009 применение инженерных практик Agile
• С 2011 руководитель
• С 2011 Scrum-Мастер
• С 2014 Agile Coach
• Обучил на тренингах более 400 человек
• Запустил более 30 Agile-команд
• Scrum, Kanban, Scrumban, DevOps
• Ака хобби: мотивация взрослых и детей
3. План
1. Коротко про пользовательские истории
2. Практика: пишем User Story в группах
3. Что такое критерии приёмки и с чем их едят?
4. Практика: пишем критерии приёмки
6. Преимущества User story
1. Быстрый способ писать требования клиента, без
необходимости разрабатывать большие
формализованные документы
2. Выше вероятность разработать то, что нужно
пользователю (заказчику)
3. Возможность предложить заказчику более простой и
дешёвый вариант реализации, что повышает доверие
4. Возможность выбрать вариант реализации требующий
минимальных изменений архитектуры
9. F-16: Разговор
«Истребитель должен развивать
2-2,5 скорости звука»
Почему это важно?
Истребитель должен смотаться, если станет
действительно жарко
10. F-16: реализация
• Конструкторы создали истребитель,
превосходящий другие по маневренности
• Прошло более 30 лет, а эти истребители все еще
производят.
• 4400 самолетов продано в 25 стран мира
11. Feature vs User Story
• Как менеджер, я хочу увидеть отчет «утилизация
персонала»
12. Feature vs User Story
• Как менеджер, я хочу увидеть отчет «утилизация
персонала»
13. Feature vs User Story
• Как менеджер, я хочу увидеть отчет «утилизация
персонала»
• Как менеджер, я хочу видеть загрузку своих подчиненных,
чтобы грамотно распределять задачи.
14. Feature vs User Story
• Как менеджер, я хочу увидеть отчет «утилизация
персонала»
• Как менеджер, я хочу видеть загрузку своих подчиненных,
чтобы грамотно распределять задачи.
15. Шаблон пользовательских историй
• Я, как <роль>, хочу <цель/желание> для того,
чтобы <выгода>
• As a <role>, I want <goal/desire> so
that <benefit>
16. Шаблоны пользовательских историй
Наиболее распространённый шаблон (Connextra, 2001):
"As a <role>, I want <goal/desire> so that <benefit>"
Mike Cohn, автор концепции User Stories, иногда опускает
последнюю часть:
"As a <role>, I want <goal/desire>"
Chris Matts предложил больше фокусироваться на ценности для
пользователя:
"In order to <receive benefit> as a <role>, I want <goal/desire>"
Изящный формат основанный на пяти W:
"As <who> <when> <where>, I <what> because <why>."
17. User Story: практика
В группах по 4 человека
Переформулировать требования в формат
пользовательских историй
1. Реализовать вход по логину и паролю на сайт Почты
России
2. Мне как покупателю нужна корзина в онлайн магазине,
чтобы проще сделать заказ
3. Получение баланса по кредитному остатку через
телефонное меню банка
9 минут
19. Приёмочные критерии
Я, как получатель посылки,
хочу видеть статусы всех моих посылки вместе
для того, чтобы сэкономить время на запрос трекинга
каждой
• На одном экране помещается не меньше чем 10 посылок
• В списке посылок видно короткое название посылок,
текущий статус и дату обновления статуса
• Если пользователь просматривает посылки со своего
устройства, то он не должен аутентифицироваться
каждый раз.
20. Приёмочные критерии: практика
В группах по 4 человека
Написать приёмочные критерии для историй
1. Я как клиент интернет-магазина, хочу иметь возможность
формировать заказ из нескольких товаров, чтобы
однократно вводить детали доставки и оплачивать
2. Я, как пользователь кредитной карты, хочу узнавать
остаток по карте, чтобы понимать сколько ещё могу
потратить
5 минут
21. Приёмочные критерии: пример
Я, как пользователь кредитной карты, хочу узнавать
остаток по карте, чтобы понимать сколько ещё могу
потратить
• Остаток должен сообщаться с точностью до копеек
• Чтобы услышать свой остаток клиент не должен
нажимать больше чем 3 раза кнопки в тональном режиме
• Если у пользователя более одной кредитной карты, то
предложить ему выбор с помощью тонального набора
• Если у пользователя более одной кредитной карты,
всегда сохранять порядок кредитных карт, если их состав
не изменился
22. Приёмочные критерии
• Приёмочные критерии (Acceptance Crithirea)
описываются во время реализации или
непосредственно перед самым её началом,
когда уже ясен способ реализации
• Описываются, как правило, не пользователем, но
на основе его пожеланий