стори поинт относительная оценка и вот относительно чего она, если не времени? если прилетела задача на 60 стори поинтов, а мы закрываем 30 в неделю, то сделаем задачу за 2 недели. В чем сложность сразу высчитать эти 2 недели, если по факту, это поинты ты потом и превращаешь в время? все видео будто бы с википедии текст брали...
Интересное видео, но тут не рассмотрен вопрос, а как оценивать эти стори поинты. Понятно, что в днях неделях часах их оценивать не надо. Так как это будет одно и то же, а вот в деньгах, как их оценивать.? Предположим задачу оценили в 1- стори поинт, какой сумме для клиента это будет равно.? Как вариант найти типовую задачу прайс, на которую известен на рынке и оценить её в стори поинта, и вот таким образом получить результат стоимости 1 балла?
Я бы советовал рассматривать оценку в сторипоинтах как объем работы. И уже от этого становится ясно, почему один специалист сделает одну и туже задачу за 1 час, а другому будет мало целого дня. Вот пример, задача - нужно выкопать 1 куб земли. Джун будет исходить из того, что будет копать в одиночку и лопатой. А сеньер знает, где можно дёшево взять эсковатор вместе с эксковаторщиком. Вот и получается оценка в сторипоинтах одинаковая, но во времени - разная. У Джуна низкая производительность в сторипоинтах/неделю, у сеньера - высокая. Легко отслеживать статистику профессионального роста и многое другое, важное для бизнеса. А многие не понимают этой разницы, предполагая что оценка в сторипоинтах это абстрактная величина оценки времени...
@@moreamoreesp речь не про оценку сложности, а про объем работ (он одинаков). Немного другой пример приведу. 1км это 1000 метров как для Джуна, так и для Сеньора. Одинаково понятная дистанция, ее можно вписать в поле задачи как "объем работ". Если идти "вслепую" - да, сложная задача и по времени будет дольше, чем бежать или ехать на велосипеде. Это очевидный факт. Какой смысл оценивать эту задачу по времени движения Джуна "вслепую", если эту задачу поручить выполнять сеньеру на велике или мидлу-бегуну? Да даже по среднему времени это оценка будет уже далеко от реальности дел в конце спринта. Вот и сторипоинт - это в системе измерений как единица объема работы, а не сложность или время. Условно, сделать окно с 2--мя кнопками в проекте - это 1 сторипоинт. Сделать 2 таких окна это будет уже 2 сторипоинта. Вот это оценка объективная как для сеньора, так и для Джуна. И она не будет меняться от исполнителя. Для менеджера открывается больший контроль над планированием при использовании сторипоинтов. Например, менеджер знает, что его команда-разработчиков за неделю может закрыть задач на 12 сторипоинтов. Вот он и набирает задач столько в недельный спринт, чтобы не уйти в овертайм. Набирает задачи с учетом последовательности выполнения, зависимостей и т.д. У каждого разработчика своя производительность в сторипоинтах\в неделю. Поэтому, там где Джун будет делать одну задачу, сеньор сделает таких же больше. Так в итоге и получается, что Джун закроет меньше сторипоинтов в неделю, чем сеньор. Удобно планировать отпуска\дейоффы. Вылетает, например, на неделю разработчик Вася. У него производительность 4 сторипоинта в неделю. Таким образом на неделю, где не будет Васи, менеджер набирает задач на 8 сторипоинтов (12 - 4 = 8), а не на 12 как при полной команде. Как итог, чтобы узнать - сколько времени нужно тому или другому разработчику на выполнение задачи, не нужно брать его конкретную оценку в часах ( это вероятность попадания 50 на 50 ). Всего лишь нужно знать его производительность (собирается статистически за весь срок работы его на проекте) + иметь обоснованную оценку у задачи в сторипоинтах (не пальцем в небо, а через декомпозицию и оценку по составляющим всей командой). Чтобы проще было делать оценки, нужно вести стату по задачам и делать проработку "неправильных оценок" (можно оценить как в большую сторону, так и меньшую). В итоге должен получится список задач по типам с реальными оценками в сторипоинтах, куда можно будет заглядывать при оценки новых задач.
Спасибо за видео! Вот волнуюший меня вопрос: если команда только будет работать с новым проектом, то есть еще динамики никто не знает, возможно ли наперед говорить о сроках сдачи проекта? Или в любом случае не угадаешь, пока не нырнешь хотя бы в первый спринт?
Даже если был опыт похожий проектов, то все равно будут нюансы. Новый проект - новые люди (как со стороны заказчика, так и исполнителя). Поэтому по моему опыту можно назвать приблизительные сроки с сильной погрешностью: мы закончим через год +- 2 года. А по ходу закрытия спринтов уже можно срок уточнять.
Типовые задачи есть всегда. Нет же такого, что сегодня задача - полететь на Марс, а завтра сделать бэкэнд под мобильное приложение. Сделать кнопку, сделать печатную форму, сделать отчёт, сделать сложный Отчет, разработать архитектуру нового приложения и тд. Конечно кнопка кнопке рознь, и архитектура одного приложения отличается от архитектуры другого, но порядок оценки будет одинаковый +-
@@shilov_games да, но мне кажется это на много более приблизительно будет чем если оценит в часах. + Не факт что это разработчик уже делал подобное фичу ранее!
Вот ещё какой пример. В команде есть начинающий и опытный разработчик. Оценили задачу в 4 часа. Эти 4 часа джуновские или опытного разработчика? Если оценивать в стори поинтах, то все норм. 2 стори поинта. И не важно кто сделает задачу.
За первые месяцы нужно постараться собрать оценочную таблицу задач ( эталон ). И, относительно которой, потом будете вести оценку новых задач. Как это делается? Команда методом тыка оценивает задачи (индивидуально) в условных сторипоинтах, потом менеджер подбивает коэффициент для каждого члена команды и приводит оценки к диопазонам в нормализованных сторипоинтах. Формируя восходящий список задач по числу в сторипоинтах. Ещё раз индивидуально каждый член команды проводит черту над задачей, которую на его взгляд можно вытянуть в спринт, при условии что задача будет выполненна командой до конца спринта. Менеджер в конце каждого спринта разбирает каждый кейс в каждой задаче ( удачное выполнение или нет) Если удача и всех все устраивает, то выполненная задача попадает в эталон. Но бывает так, что может измениться оценка у задачи в сторипоинтах, если команда была не внимательна при изучении нюансов задачи во время прошлой оценки или коммуникация между членам команды оказалось сложнее, чем все думали. Таким образом нужно набить эталон всеми типами задач. Пока команда сильно не меняет состав, этот эталон будет работать на любых проектах. Как только сильно изменилась команда, нужно собирать новый эталон. Так проще и быстрее собрать единую СИ в сторипоинтах, чем ломать большинство команды под старые устои. Пример, у старой команды может оказаться, что сделать GDPR скрин можно в 1 сторипоинт, а новая команда решила эту задачу оценивать как 2 сторипоинта. И от этого все становится не актуальным в старых задачах.
Ни о чем.... Где конкретный пример? Одна теория... Бла бла бла, ну и что знасить 8 стори поинтов? Все эти ваши оценки гадание на кофейной гуще, они подходят только если есть идеальная аналитика, а ее как ппавило нет
Классное видео) хотела скинуть своей команде, но увидев обложку испугалась, что вызовет неприятие 😅 поменяйте обложку если это возможно))
стори поинт относительная оценка и вот относительно чего она, если не времени? если прилетела задача на 60 стори поинтов, а мы закрываем 30 в неделю, то сделаем задачу за 2 недели. В чем сложность сразу высчитать эти 2 недели, если по факту, это поинты ты потом и превращаешь в время? все видео будто бы с википедии текст брали...
Вставка с Ивлеевой просто класс! А вообще спасибо за видео очень познавательно! Подпишусь
Спасибо 🙏
Интересное видео, но тут не рассмотрен вопрос, а как оценивать эти стори поинты. Понятно, что в днях неделях часах их оценивать не надо. Так как это будет одно и то же, а вот в деньгах, как их оценивать.? Предположим задачу оценили в 1- стори поинт, какой сумме для клиента это будет равно.? Как вариант найти типовую задачу прайс, на которую известен на рынке и оценить её в стори поинта, и вот таким образом получить результат стоимости 1 балла?
Даёшь agile+scrum в массы!💪
Agile - супер тема
Добрый день!
А если у меня команда не фул стек? Есть QA, FE, BE, то как тут быть? Интересны реальные кейсы. Спасибо!
Я бы советовал рассматривать оценку в сторипоинтах как объем работы. И уже от этого становится ясно, почему один специалист сделает одну и туже задачу за 1 час, а другому будет мало целого дня. Вот пример, задача - нужно выкопать 1 куб земли. Джун будет исходить из того, что будет копать в одиночку и лопатой. А сеньер знает, где можно дёшево взять эсковатор вместе с эксковаторщиком. Вот и получается оценка в сторипоинтах одинаковая, но во времени - разная. У Джуна низкая производительность в сторипоинтах/неделю, у сеньера - высокая. Легко отслеживать статистику профессионального роста и многое другое, важное для бизнеса.
А многие не понимают этой разницы, предполагая что оценка в сторипоинтах это абстрактная величина оценки времени...
а почему джун и сеньор оценят задачу одинаково? Сеньор оценит ее как менее сложную, чем джун.
@@moreamoreesp речь не про оценку сложности, а про объем работ (он одинаков).
Немного другой пример приведу.
1км это 1000 метров как для Джуна, так и для Сеньора. Одинаково понятная дистанция, ее можно вписать в поле задачи как "объем работ".
Если идти "вслепую" - да, сложная задача и по времени будет дольше, чем бежать или ехать на велосипеде.
Это очевидный факт.
Какой смысл оценивать эту задачу по времени движения Джуна "вслепую", если эту задачу поручить выполнять сеньеру на велике или мидлу-бегуну?
Да даже по среднему времени это оценка будет уже далеко от реальности дел в конце спринта.
Вот и сторипоинт - это в системе измерений как единица объема работы, а не сложность или время.
Условно, сделать окно с 2--мя кнопками в проекте - это 1 сторипоинт.
Сделать 2 таких окна это будет уже 2 сторипоинта.
Вот это оценка объективная как для сеньора, так и для Джуна.
И она не будет меняться от исполнителя.
Для менеджера открывается больший контроль над планированием при использовании сторипоинтов.
Например, менеджер знает, что его команда-разработчиков за неделю может закрыть задач на 12 сторипоинтов.
Вот он и набирает задач столько в недельный спринт, чтобы не уйти в овертайм.
Набирает задачи с учетом последовательности выполнения, зависимостей и т.д.
У каждого разработчика своя производительность в сторипоинтах\в неделю.
Поэтому, там где Джун будет делать одну задачу, сеньор сделает таких же больше.
Так в итоге и получается, что Джун закроет меньше сторипоинтов в неделю, чем сеньор.
Удобно планировать отпуска\дейоффы.
Вылетает, например, на неделю разработчик Вася. У него производительность 4 сторипоинта в неделю.
Таким образом на неделю, где не будет Васи, менеджер набирает задач на 8 сторипоинтов (12 - 4 = 8), а не на 12 как при полной команде.
Как итог, чтобы узнать - сколько времени нужно тому или другому разработчику на выполнение задачи, не нужно брать его конкретную оценку в часах ( это вероятность попадания 50 на 50 ).
Всего лишь нужно знать его производительность (собирается статистически за весь срок работы его на проекте) + иметь обоснованную оценку у задачи в сторипоинтах (не пальцем в небо, а через декомпозицию и оценку по составляющим всей командой).
Чтобы проще было делать оценки, нужно вести стату по задачам и делать проработку "неправильных оценок" (можно оценить как в большую сторону, так и меньшую).
В итоге должен получится список задач по типам с реальными оценками в сторипоинтах, куда можно будет заглядывать при оценки новых задач.
очень приятное видео
Потому что полный кадр)
Спасибо за видео! Вот волнуюший меня вопрос: если команда только будет работать с новым проектом, то есть еще динамики никто не знает, возможно ли наперед говорить о сроках сдачи проекта? Или в любом случае не угадаешь, пока не нырнешь хотя бы в первый спринт?
Даже если был опыт похожий проектов, то все равно будут нюансы. Новый проект - новые люди (как со стороны заказчика, так и исполнителя).
Поэтому по моему опыту можно назвать приблизительные сроки с сильной погрешностью: мы закончим через год +- 2 года.
А по ходу закрытия спринтов уже можно срок уточнять.
супер-понятно!
так как же найти эталон относительно чего мы будем мерит?
задача масса, подобных нет. Чем мерит?
Типовые задачи есть всегда. Нет же такого, что сегодня задача - полететь на Марс, а завтра сделать бэкэнд под мобильное приложение.
Сделать кнопку, сделать печатную форму, сделать отчёт, сделать сложный Отчет, разработать архитектуру нового приложения и тд.
Конечно кнопка кнопке рознь, и архитектура одного приложения отличается от архитектуры другого, но порядок оценки будет одинаковый +-
@@shilov_games да, но мне кажется это на много более приблизительно будет чем если оценит в часах. + Не факт что это разработчик уже делал подобное фичу ранее!
Возможно
Вот ещё какой пример. В команде есть начинающий и опытный разработчик. Оценили задачу в 4 часа. Эти 4 часа джуновские или опытного разработчика?
Если оценивать в стори поинтах, то все норм. 2 стори поинта. И не важно кто сделает задачу.
За первые месяцы нужно постараться собрать оценочную таблицу задач ( эталон ). И, относительно которой, потом будете вести оценку новых задач. Как это делается? Команда методом тыка оценивает задачи (индивидуально) в условных сторипоинтах, потом менеджер подбивает коэффициент для каждого члена команды и приводит оценки к диопазонам в нормализованных сторипоинтах. Формируя восходящий список задач по числу в сторипоинтах. Ещё раз индивидуально каждый член команды проводит черту над задачей, которую на его взгляд можно вытянуть в спринт, при условии что задача будет выполненна командой до конца спринта. Менеджер в конце каждого спринта разбирает каждый кейс в каждой задаче ( удачное выполнение или нет) Если удача и всех все устраивает, то выполненная задача попадает в эталон. Но бывает так, что может измениться оценка у задачи в сторипоинтах, если команда была не внимательна при изучении нюансов задачи во время прошлой оценки или коммуникация между членам команды оказалось сложнее, чем все думали. Таким образом нужно набить эталон всеми типами задач. Пока команда сильно не меняет состав, этот эталон будет работать на любых проектах. Как только сильно изменилась команда, нужно собирать новый эталон. Так проще и быстрее собрать единую СИ в сторипоинтах, чем ломать большинство команды под старые устои. Пример, у старой команды может оказаться, что сделать GDPR скрин можно в 1 сторипоинт, а новая команда решила эту задачу оценивать как 2 сторипоинта. И от этого все становится не актуальным в старых задачах.
Лол, это же пересказ видоса Джерри Халприна 😅
А если вы открываете список задач, когда клиент решил использовать story points вдруг, и у вас там 10 разных бутылок и одно большн меньше другой...
Какую-то бутылку выбрали за эталон и остальные оценили относителен неё.
Не не.. Стори поинт не часы. В конце: делим 60 на две недели....30стори принтов неделя)))) получается неделя 5 дней, 6поинтов = 8 часов.
Так получается только при текущей скорости команды. Скорость изменится и часы тоже изменятся. А стори поинты останутся
Такое часто бывает...
Да, планировать сложно
@@shilov_games безумно сложно...
👍👍👍
Какие еще темы интересны?
Ни о чем.... Где конкретный пример? Одна теория... Бла бла бла, ну и что знасить 8 стори поинтов? Все эти ваши оценки гадание на кофейной гуще, они подходят только если есть идеальная аналитика, а ее как ппавило нет