Причины все равно понять надо.

Я не вижу причин, почему бы скрам команде не отказаться от элемента DoD. Но причины очень важны.

Спасибо за мнение.

Неожиданно )

https://blog.unusual-concepts.ru/2012/12/cynefin/

https://blog.unusual-concepts.ru/2012/12/cynefin/

Ок. Спасибо

А на практике кто-то анализировал свои проекты с позиции Cynefin? Интересует именно свой опыт.

Вопрос к группе: кто использует user persona в работе? не знает, что такое есть, а реально применяет, давая к ним доступ командам.

Мы нет.

Надо у дизанеров спросить. Я правильно понимаю, что это их практики?

Надо у дизанеров спросить. Я правильно понимаю, что это их практики?

Не только. Разработчикам тоже очень полезно понимать, кто пользователь и какие у него есть проблемы.

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

Коллеги, еще вопрос. Кто-то знаком с Cynefin framework? Есть что-то хорошее почитать?

https://hbr.org/2007/11/a-leaders-framework-for-decision-making

https://hbr.org/2007/11/a-leaders-framework-for-decision-making

👍

Кажется, это самая первая статья по киневину

Вопрос к группе: кто использует user persona в работе? не знает, что такое есть, а реально применяет, давая к ним доступ командам.

У нас есть. ПО дал инфу, отрисовали красиво в uxpressio 4х пользователей, повесили на стену. Задумка была в спорных ситуациях подходить к стене, смотреть на портреты, принимать решение на основе того, как это зайдёт пользователям. По факту никто так не делает, потому что: 1. У нас очень мало фронтенда, спорные вопросы в принципе возникают редко. 2. 4 человека это много, никто не понимает как совместить интересы всех. Толкового объяснения что делать в этом случае я не нашёл. Интуитивно - жертвовать кем-то. НО. Был и положительный эффект

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

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

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

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

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

На практике все... интересно.

Ключевое слово должен)

В Долине user-centric design вместе с lean startup прям считается панацеей от всех бед и новой серебрянной пулей :)

В аутсорсе про юикс вообще редко вспоминают

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

А аутсорсовые команды хотят четких требований :)

Ни за чо не отвечать

Не берусь сказать за аутсорс на Россию, но большинство американских и европейских заказчиков приходят с четким понимаем что маркетинг локален и саутсорсить его проблематично . Многие заране приносят толковые исследования, прототипы и дизайн. Очень показательная цифра - у нас в компании около 250 человек (только аутсорс) и всего 1 дизайнер, т.е. загрузки нет. На предыдущем месте работы было тоже самое.

Быть doers

Lean startup же про минимизацию цены провала

В итоге проще объединить аналитиков, UI и UX в команду, убедить в пользе канбана и синхронизиовать со скрам-командами через рейфайнмент и плэннинг.

Минус, конечно, неприятный. А помяните как по-другому?

Я не очень представляю как втиснуть дизайн + аналитику + разработку в один спринт. Сразу возникает проблема оценки - как дать оценку на сторю, где нет ни требований, ни дизайна. А в ДОР, по-хорошему, должна быть оценка.

Я не очень представляю как втиснуть дизайн + аналитику + разработку в один спринт. Сразу возникает проблема оценки - как дать оценку на сторю, где нет ни требований, ни дизайна. А в ДОР, по-хорошему, должна быть оценка.

А нет хорошего универсального решения. Общее - делать аналитику через spike, а дизайн через стандартизацию.

Но это требует наличия многих практик, которым команде надо учиться

А вы каким пользуетесь? Можно два слова (хотя бы чтобы гугл понял) про Спайк и стандартизацию?

Спайк - spike- тип PBI, предназначенный конкретно для исследовательской активности. Не эстимируется, таймбоксится, результат - сугубо знание в той или иной форме, предназначенные для дальнейшей работы команды.

Формальзованный дизайн это весь набор best practices: guidelines, brandbook, color guide, style guide, pattern libraries и т.п.

Т.е. каждый элемент собирается по четким правилам, а не по "креативу".

вот именно поэтому мы возможно временно ушли от дизов+аналитиков+разрабов в одном спринте + плохие требования от РО

Про Диз понятно. Такая стандартизация наверное вообще для любой методологии подойдёт.

Тут тонкая грань, после преодоления которой стандартизация начинает мешать продукту :)

Улучшение ради улучшения?

Стандарты начинают мешать улучшениям.

Т.е. улучшение очевидно нужно, представленное решение очевидно улучшает продукт, но его не имплементят, потмоу что оно не подпадает под стандарт.

Или процесс пересмотра стандартов становится очень забюрократизирован.

Мэйк сэнс

Ну а если девелопмент тим и продакт решили, что хрен с ним. Надо ли в это лезть Скрам-мастеру?

Нет. У нас в энтерпрайзе, дод он в пми прописан и пересмотр, это серьезно. Это вопрос как команде, как к овнеру, так и релиз менеджерам. Но только не к скрам мастеру.

Нет. У нас в энтерпрайзе, дод он в пми прописан и пересмотр, это серьезно. Это вопрос как команде, как к овнеру, так и релиз менеджерам. Но только не к скрам мастеру.

У вас не совсем скрам в таком случае :)

У нас ISO9001:2015 а скрам, бывает, а бывает что и канбан :)

А этот черный квадрат мы для простоты обозначим желтым кружочком. 😉

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

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

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

У нас ISO9001:2015 а скрам, бывает, а бывает что и канбан :)

А одно другому как-то проитворечит?:)

Я не очень представляю как втиснуть дизайн + аналитику + разработку в один спринт. Сразу возникает проблема оценки - как дать оценку на сторю, где нет ни требований, ни дизайна. А в ДОР, по-хорошему, должна быть оценка.

Мы LeSS используем. Оценка дается на Overall PBR. Это делают представители команд, в том числе занимающиеся дизайном. На нем поверхностное изучение фич и оценка, а потом на командном или многокомандном PBR уже более углубленное изучение. При этом оценка может вырасти. К Спринту задача приходит уже полностью разобранной, но без дизайна. Остальное в Спринте.

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

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

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

Спасибо за объяснение. Допустим разработчик дал оценку в день на фичу. Потом ему пришел дизайн. Неужели он вложится в эту оценку?

очень хочется чтобы так было, но не представляю как такое может работать)

ну и про аппрув диза, расскажите. Или у вас нет такой необходимости?

Спасибо за объяснение. Допустим разработчик дал оценку в день на фичу. Потом ему пришел дизайн. Неужели он вложится в эту оценку?

У нас используется LeSS. Это Скрам. Актуализация и оценка элементов Бэклога происходит до планирования Спринта на мероприятии OverAll PBR https://less.works/ru/less/framework/product-backlog-refinement.html На этом мероприятии присутствуют представители от каждой команды (в том числе дизайнеры и верстальщики - они распределены по командам как их члены). В процессе мероприятия участники (обычно около 15-18) актуализируют элементы на один-два Спринта вперед. Владелец Продукта берет самый приоритетный элемент и представляет его участникам (в том числе дизайнерам). Участники задают вопросы, проясняют его (поверхностно), высказываются эксперты и менторы компонентов. После этого, используя покер планирования с реальными картами (https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BA%D0%B5%D1%80_%D0%BF%D0%BB%D0%B0%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F) , участники оценивают задачи. Голосуют за оценку и поясняют свои почему они так голосовали пока не выдают общий результат оценки. Обычно 1-2 итерации. Максимум три. Если элемент оценили больше пяти стори поинтов (по хорошему - надо все брать) - команды сразу выбирают кто возьмет этот элемент на Командый или Многокомандный PBR - там задачу разбирают дальше уже узким кругом до очередного PBR (их два на две недели). Если элемент оценили больше тринадцати стори поинтов - команда, выбравшая этот элемент разбивает его на своем командном PBR на несколько фич, используя пратику User Story Mapping. Все эти элементы команда уточняет на своих командных (многокомандных ) PBR и формирует Критерии приемки. По сути описание приемочного теста. В результате мы формируем список задач "Sprint Ready" у которых выполняются Defination of Ready - Оценка приоритета от Владельца Продукта, Оценка трудоемкости от команды в стори поинтах не больше 13, Список приемочных критериев для задач на 8 и 13 стори поинтов. И вот уже из этого списка задач на планировании Спринта команды САМИ СЕБЕ выбирают элементы для работы в Спринте в соответствии с приоритетом Владельца Продукта. При этом необязательно команда выберет себе элемент, который они PBRили (В этом отличие Нексус от LeSS). Само планирование (из двух частей) описано тут https://less.works/ru/less/framework/sprint-planning-one.html и тут https://less.works/ru/less/framework/sprint-planning-two.html

ну и про аппрув диза, расскажите. Или у вас нет такой необходимости?

Я правильно понял, что это согласование того, что сделал дизайнер?

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

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

Я правильно понял, что это согласование того, что сделал дизайнер?

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

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

У нас продуктовая разработка https://litebox.ru/ Кассы на Windows и Android, основной функционал системы в облаке, доступен через браузер. Дизайнеры как правило меняют уже имеющиеся интерфейсы, или делают по аналогии я так понимаю. Есть гайды, которые они разработали в сообществе (есть такая практика в LeSS). На них они и ориентируются при оформлении. Я не настолько сильно именно в их работу погружен. Возможно есть какие-то тонкости.

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

Это и есть Скрам :) Масштабируемый Скрам.

Чистый и непознанный ...

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

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

Выходит так.

Вопрос к группе: кто использует user persona в работе? не знает, что такое есть, а реально применяет, давая к ним доступ командам.

У нас есть, считаю это абсолютно безсмысленной хренью.

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

Плюс адын. А если задача сложная технически, не типовая, то еще и различные архитектуры пораждают разные эстимейты (мы тут это обсуждали не так давно)

Ребятаа, хелп, в каком чате можно вакансию кинуть? Фронтендеров ищем оочень срочно на новый проект. У меня чет чаты одни ПМы( Если у вас у кого на примете есть люди или можете помочь, напишите в личку плиз!

Ребятаа, хелп, в каком чате можно вакансию кинуть? Фронтендеров ищем оочень срочно на новый проект. У меня чет чаты одни ПМы( Если у вас у кого на примете есть люди или можете помочь, напишите в личку плиз!

Почему так знакомо)

Ребятаа, хелп, в каком чате можно вакансию кинуть? Фронтендеров ищем оочень срочно на новый проект. У меня чет чаты одни ПМы( Если у вас у кого на примете есть люди или можете помочь, напишите в личку плиз!

https://t.me/agile_jobs

😉

Ребятаа, хелп, в каком чате можно вакансию кинуть? Фронтендеров ищем оочень срочно на новый проект. У меня чет чаты одни ПМы( Если у вас у кого на примете есть люди или можете помочь, напишите в личку плиз!

@javascript_jobs для фронтов

https://t.me/agile_jobs

Не надо сюда программистов

"Очень срочно" - значит будут привлеченны русурсы не проверенные. Скорость/уровень компетенции/сознательность - не извсетные. Дата старта/дедлайны/бюджеты - скорее всего - уже запрувленные. А "Путь камикадзе" как была, так и остается настольной книгой.)

Надо ввести блог или библиотеку знаний "Будни PM-а" или "Типичный PM".))) Чтобы просто ссылки с мануалами бросать в ответ.)

Надо Паше Дурову написать чтобы урезал лимит символов в именах.