Вход на сайт

Просмотр новости

Найдите то, что Вас интересует

Комментарий к записи Работа над ошибками после использования Agile. Часть 2 (Результаты работы над ошибками после использования Agile)

Дата публикации: 03-03-2026 08:02:58

[…] Это третья, заключительная часть история про продакт-менеджера, который использовал Agile и наломал дров. Часть 1 и Часть 2. […]

Основное содержимое страницы с новостью.

Друзья, всем привет!

Это вторая части истории продакта, который использовал Agile и наломал дров. В ней мы подробно разбираем допущенные ошибки и формулируем гипотезы для их устранения.

И так, допущенные ошибки:

ОшибкаГипотеза для ее устраненияОжидаемый результат
1Груминг проводит аналитик.Груминг проводит продактПродакт вместе с командой вовлечен в груминг задач и понимает, что там нужно сделать. Не сидит, не занимается в фоне другими задачами.
2Работу оцениваем в человеко-часах, но не всю.Всю работу оцениваем в человеко-часах или сторипоинтахНа основе статистики будем понимать капасити спринтов, не перегружать команду, а также давать бизнесу реальные сроки реализации фичи.
3Карту пользовательских историй строит аналитик.Карту пользовательских историй строит продакт менеджер.Продакт менеджер понимает последовательность фичей и может построить работу над продуктом итеративно, постепенно внедряя новые фичи.
4Отказ от обзоров спринта.Вернуть обзоры спринта в конце каждого спринта.Стейкхолдеры понимают, что было сделано, могут задать вопросы по функционалу или дать обратную связь, что хорошо и что улучшить.
5Цель спринта ставится не на какой-то функционал, а прописываются задачи для каждого члена команды, которые нужно закрыть за спринт.Ставить одну цель спринта на конкретный функционал, который нужно сделать за спринт.Фокус на одном функционале вместо списка задач позволит команде достигать цель за спринт.
6Прилетающие баги сразу берутся в спринт, что расширяет его объём. Сделать классы обслуживания для срочных задач, договориться, что берем в текущий спринт, а что оставляем для следующего.Меньше переключений внутри спринта, сохранение капасити спринта, исключение рисков не достичь цели спринта. 
7Задач в спринте раз в 10 больше, чем членов в команде.Пересекается с п.2. Объём задач в спринте должен соответствовать капасити команды.Меньше переключений в спринте между задачами, фокус на завершение начатой работы снижение перегруза в команде.
8На груминге оценивается и обсуждается одна задача и та — пользовательская история. Таски и баги не оцениваются никак.Пересекается с п.1 и п.2. Необходимо сделать еженедельные груминге и оценивать все задачи в бэклоге.Будет проще рассчитать объем спринта, так как все задачи будут оценены, и сопоставить его с капасити комнады.
9Нет понимания капасити команды (как следствие не оцененных задач).Начать измерять капасити команды, начать собирать статистику.Формировать объем спринта в соответствии с капасити команды. Больше завершенных задач в конце спринта. Выполнение цели спринта. 
10Нет понимания скорости команды (как следствие не оцененных задач).Начать измерять пропускную способность команды — сколько взяли в спринт, сколько закрыли.Снизится нагрузка на команду, снизится количество незавершенных задач, появится понимание скорости команды — будет легче выполнять взятые в спринт задачи.
11Я использовал из Канбана подход “no estimate”, но неверно понял его суть.Переход на подход “No estimate” возможен, когда уже накоплена статистика по классам обслуживания.Ускорится планирование спринта и сохранится высокая вероятность реализации задач спринта.
12Отсутствие согласований документации с бизнес-заказчиками. Если не согласовывать готовую документацию, а сразу передавать ее в разработку — это пипец как сокращает лид тайм.Согласовывать с заказчиком документацию перед разработкой. Это сэкономит время на переделку задач по некорректным требованиям.
13Отсутствие приемки на стейдже готового функционала заказчиками. Это капец как сокращает лид тайм.Согласовывать с заказчиком задачи на стейдже перед выкаткой в прод.Это сэкономит время на переделке задач, которые не соответствуют ожиданиям заказчика.

После разбора ошибок мы договорились, что в течение следующего полугодия (квартал — минимум) продакт претворяет в жизнь гипотезы, чтобы устранить выявленные ошибки и фиксирует результат, что изменилось.

После этого мы еще раз встречаемся и смотрим, что и как сработало, что осталось без изменений и что стало хуже.

Завершение истории. Часть 3.

Навигация по записям

Схожие новости

#Наименование новостиТональностьИнформативностьДата публикации
1 Комментарий к записи Как продакт использовал Agile и наделал ошибок. Часть 1 (Результаты работы над ошибками после использования Agile) 031.9103-03-2026
2 Комментарий к записи Результаты работы над ошибками в Agile. Часть 3 (Работа над ошибками после использования Agile) 025.8303-03-2026
3“Scrum didn’t work for us.”08.130-07-2026
4Великая иллюзия Agile: как индустрия променяла инженерную науку на средневековый эмпиризм-6727-06-2026
5How to Avoid AI Debt by Borrowing from Agile Artifacts04.9427-07-2026
6Der heimliche Feind jedes Product-Owners: 5 Mythen, die Karrieren ruinieren015.2327-07-2026
7Cognitive Trap: Velocity Misinterpretation07.3720-07-2026
8Clean out the Product Backlog0524-06-2026
9Developers who move fast still need to do it together​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌​‌‍​‌‌‍‍‌‍‍‌‌‌​‌‍‌​‍‍‌‍‍‌‌‍​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍‌‍‍​‌‌​‌‌​‌​​‌​​‍‍​‍​‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‍‌‌‍‍‌‌​‌‍‌‌‌‍‍‌‌​​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​​‍‌‍‌‌‍‌‍‌​‌‍‌‌​‌‌​​‌​‍‌‍‌‌‌​‌‍‌‌‌‍‍‌‌​‌‍​‌‌‌​‌‍‍‌‌‍‌‍‍​‍‌‍‍‌‌‍‌​​‌​‍​​‍​‌‍‌‍​‌‌​​‍‌‍‌​​‌‌‍​‍​‍‌‌‍‌‌‌‍‌​​​​‌‌​‍‌​‌​‌‍‌​​​‍​​​‍‌​‍‌​​​​‌​‌‍‌‌​‍‌‌‍‌‌​​‌‌‍​​​​​​​‌‍​‍​​‌‌​​‍‌‍‌‌​‌​‌​‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌‍​‍‌‍​‌‍‌‍‌‌‌​​‌‍‌​‌‌​​‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‌​‌‍‍‌‌‌​‌‍​‌‍‌‌​‌‍​‍‌‍​‌‌​‌‍‌‌‌‌‌‌‌​‍‌‍​​‌‌‍‍​‌‌​‌‌​‌​​‌​​‍‌‌​​‌​​‌​‍‌‌​​‍‌​‌‍​‍‌‌​​‍‌​‌‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‌‍‍‌‌‍‌​​‌​‍​​‍​‌‍‌‍​‌‌​​‍‌‍‌​​‌‌‍​‍​‍‌‌‍‌‌‌‍‌​​​​‌‌​‍‌​‌​‌‍‌​​​‍​​​‍‌​‍‌​​​​‌​‌‍‌‌​‍‌‌‍‌‌​​‌‌‍​​​​​​​‌‍​‍​​‌‌​​‍‌‍‌‌​‌​‌​‍‌‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌‍​‍‌‍​‌‍‌‍‌‌‌​​‌‍‌​‌‌​​‍‌‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‌​‌‍‍‌‌‌​‌‍​‌‍‌‌​‍‌‍‌​​‌‍‌‌‌​‍‌​‌​​‌‍‌‌‌‍​‌‌​‌‍‍‌‌‌‍‌‍‌‌​‌‌​​‌‌‌‌‍​‍‌‍​‌‍‍‌‌​‌‍‍​‌‍‌‌‌‍‌​​‍​‍‌‌08.2917-07-2026
10Stehen sich Scrum Master selbst im Weg? 5 hausgemachte Probleme, die du überwinden musst0629-06-2026

Классификация: Мнения. Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 42.27. Источник: filipyev.ru.