Шабанова Елена @easchabanova
Product Lead
Информация
- В рейтинге
- Не участвует
- Откуда
- Москва, Москва и Московская обл., Россия
- Зарегистрирована
- Активность
Специализация
Менеджер проекта, Менеджер продукта
Ведущий
Управление продуктами
Управление проектами
Построение команды
Оптимизация бизнес-процессов
Информационные технологии
Agile
PMBOK
Waterfall
Управление изменениями
Управление людьми
Спасибо, очень интересный подход!
Если бессознательно - не так хорошо)))
Спасибо за ваш комментарий) Это просто отлично, если человек может сознательно включать или выключать те или иные качества в зависимости от того, где он находится)) но, в основном, к сожалению, в схожих ситуациях, какие мы на работе - ровно такие мы и дома))) а на счет руководителя - на нем большая ответственность за свою команду и ее развитие, это же добровольный выбор))
В См Лаб немного другая организация процессов, руководитель продукта не декомпозирует задачи.Вот тут можно послушать более детально: https://habr.com/ru/companies/sportmaster_lab/articles/548620/
Не удалось:)
Сделали;) Как раз хочу написать о том, что получилось. Надеюсь, до НГ найду время. Кажется, выводы могут быть интересны и другим командам:)
Во всем с вами согласна!!! Спасибо за такое интересное сравнение! Возьму на вооружение!)
Спасибо за ваши комментарии!
Эту книгу я как раз читала) Интересно, а в работу вашей команде все user-story одинакового размера поступают? Так бывает?)
Считаю, если пропускную способность оторвать от размера и сложности задач, На графике увидеть ускорение или замедление не получится. В один период реализовано 4 объемных user-story, в следующий - 4 мелкие, а остальное время команда учились, например. Вот на графике без привязки к размеру и в том, и в другом случае будет 4 user-story.
Спасибо за оценку! Самой интересно)
Спасибо за ссылку на книгу! Именно такую не читала, с удовольствием посмотрю)
По поводу вероятностного прозгнозирования - мне оно близко, потому что это объяснимая заказчику математика. Но считаю, что в жизни метод Монте-Карло и пр применимы только если на входе разделять user-story по объему и сложности + собирать данные для похожих user-story + именно на основе этих данных строить вероятностные прогнозы.
Даже в примере из Essential Kanban прогноз звучит как: с 50% вероятностью - 06.05, с 85% вероятностью - 20.05, с 95% вероятностью - 27.06. Разброс дат - 2 месяца, причем, если внимательно посмотреть на график попаданий, то там не 95%, а, скорее, 5%:)
А вот если на входе поделить user-story по размеру и сложности. Например, 1) есть класс user-story, который содержит 1-3 простые понятные задачи 2) есть класс user-story, который содержит 3-10 простые понятные задачи и тд...то для каждого класса user-story диапазон вероятностных дат поставки будет намного уже, при этом он будет таким же правдивым. И так как этот класс надо определять на входе, это снова похоже на относительные оценки - только не задач, а user-story.
Очень интересный вопрос, как раз хочу в него зайти, но не с целью прогнозирования сроков, а поисследовать скорость команды.
Результатами обязательно поделюсь)
Наверное, снова упирается во время( Если собирать оценки - это прям затратно(( а вам хотелось бы участвовать в подготовке прогнозов реализации по задачам своей команды?
Похоже на покер планирования! Думаю, если небольшая команда - очень применимо! А на удаленке - особенно!)) Как говорится, совместить приятное общение с полезным процессом оценки) А вы пробовали?
Потом использовать формулу по 3-м точкам, результат умножить на фокус-фактор, поделить на...))) снова не просто)))
Интересная тема, на какой вид спорта похож процесс разработки:)) Думаю, зависит от уровня специалистов в команде. Иногда на наш футбол, где все мало предсказуемо, а иногда на синхронное плавание:) Я согласна, что любые прогнозы - это всегда не 100% вероятность, поэтому жалко тратить время синхронистов на уборку бассейна:)))