Эффективное управление бэклогом

Когда команда планирует спринт, часто звучит тревожное: – «Это же не видно пользователю…» – «А давайте просто сделаем как подзадачу...» – «Сначала фичу, а инфраструктуру – потом доделаем…» Так технические истории оказываются в тени. Хотя именно они делают продукт стабильным, масштабируемым и готовым к росту. Пора перестать бояться называть вещи своими именами: Техническая история – это не долг. Это вклад в ценность продукта. Техническая история – это задача, необходимая для реализации или поддержки пользовательской истории, но не содержащая интерфейсной части...

Всё больше команд и руководителей за пределами IT начинают задаваться вопросом: Можно ли использовать инструменты Agile, если мы не пишем код? Можно – и нужно. Один из таких инструментов – User Story Map, или Карта пользовательских историй. Несмотря на своё "айтишное" происхождение, этот инструмент давно вышел за рамки разработки. Сегодня его применяют маркетологи, HR-руководители, логисты, строители, производственники – и даже операционные команды. Давайте честно: в любой сфере мы работаем ради результата, а не ради задач...

Буквально на днях на корпоративном обучении участники задали очень практичный вопрос: Как и когда заносить всю информацию в трекер (будь то Yandex Tracker, YouGile, Kaiten и др.), если в этих системах нет встроенной поддержки User Story Map? 🧩 Да, в Jira такой плагин есть, но в большинстве систем этого визуального слоя нет. ⛓️‍💥 В итоге – одна картина в Miro или Holst, а бэклог продукта живёт в трекере. Получается круговая порука: всё вроде бы есть, но всё врозь. ⁉️ Это действительно частая боль у Agile-команд...

Меня часто спрашивают: можно ли заменить человека искусственным интеллектом при написании пользовательских историй? На первый взгляд – конечно. Алгоритм прекрасно распознаёт шаблон: «Я как [кто-то], хочу [что-то], чтобы [ценность]» и вот уже перед вами стройная конструкция, подходящая под любую задачу. ‼️ Но в этом и кроется главная ловушка. User Story – это не фрейм. Это не шаблон. Это не артефакт. Это – приглашение к разговору. 💡 История не в форме, а в смысле Когда Джефф Паттон говорил о пользовательских историях, он приводил метафору фотографии...

Это картина целиком, которую можно рассмотреть как сверху, так и в деталях. Когда мы начинаем строить карту с командами, почти всегда случается удивление: 🤪 Так это не просто путь пользователя? 🤪 А почему здесь есть шаги от лица компании? 🤪 А что, баги и технический долг тоже можно сюда положить? Можно. Более того – нужно. User Story Map – это не только про то, что делает пользователь, но и про то, что должно произойти внутри компании, чтобы он действительно получил ценность. В ней мы отмечаем:...

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