Вот прямо сейчас проверил наши "технологические карты": с момента, как разработчик ознакомился с заданием, должно пройти как минимум 5 важнейших этапов перед тем, как я могу попросить его оценить объем работ и его ответ будет иметь смысл.
Я понятия не имею, зачем спрашивать разработчика, который только что прочитал текст задания, о том, что он думает о его сложности и как долго он будет его делать. И тем более - зачем об этом спрашивать его коллегу.
Команды разные и контексты разные. В нашей команде ребята понимают в каком компоненте и какую примерно работу делать, т.к. погружены в проект и его домен. Поэтому и такой метод командой оценки работает и оправдан.
На мой взгляд, вариант, когда разработчик по хорошо оформленному тикету не может дать оценку, свидетельствует либо о том, что проекты и домен часто меняются (аутсорс разработка), и тут действительно Story Points не подойдут; либо о плохом бас-факторе в команде. Когда инженер не знает, чем вообще занимаются коллеги. И это другая проблема, которая за скоупом статьи.
Мне раньше было интересно: когда я нанимал человека из бигтеха, я спрашивал - "а что ты им отвечал на вопрос о стори-поинтах, в момент, когда очевидно, что ответа еще не существует?" Все как один: "Просто говорил разную чепуху, чтобы они отстали и успокоились. Главное - чтобы совпало с коллегой". Ужас…
Прискорбно о таком слышать. Тут лучше честность, чем "чепуха". Это еще один флажок о плохом бас-факторе или просто об особенностях проекта, где применяют Story Points без необходимости.
Я искренне надеюсь, что вы просто неудачно выразились, опустили важные моменты, и на самом деле не делаете "буквально" то, что описано в статье. Иначе - "да прибудет с вашими разработчиками сила", она им понадобится...
Не знаю, откуда в вас столько токсичности. Мы это применяем, потому что у нас это работает. Я нигде в статье не говорил, что это универсальный "швейцарский нож". Для таких практик и команда, и проект, и, возможно, компания должны быть достаточно зрелыми.
Спринты обычно в днях, и совместить эту шкалу со стори поинтами - чистый рандом
В днях тоже — "чистый рандом", потому что разные исполнители в команде сделают задачи за разное число дней. Story Points это просто еще один способ оценки в условиях неопределенности без привязки к людям.
В начале упомянули про то, что программист отвлекается. Да и чисто психологически программист оценивает время и сложность разработки. А где аналитика, тест кейсы, тестирование, код ревью / мержи / релизы / хотфиксы?
При оценки таким методом вспомогательные активности учитываются за счет Velocity. Мы просто работаем командой какое-то время, а далее смотрим сколько реальных продуктовых Story Points удалось закрыть за это время. Учитывая, что при этом команда тестировала, релизила, ревьювила и прочее.
А если в процессе выяснилось, что промахнулись с оценкой то что тогда? Повышаем и выкидываем другие менее приоритетные задачи из спринта?
Да, если эта задача более приоритетная, то добиваем ее. После окончания спринта ретроспективно смотрим: был продолб в оценке или слишком много взяли на команду и нужно понизить целевое Velocity. 100% точности в планировании никогда не получится достичь на долгом промежутке времени. Какой бы способ для оценки вы не использовали.
Я в настоящий момент участвую в двух спринтах. По четным дням я начинаю делать спринт номер раз до забора или до обеда конца дня. Если остается время переключаюсь на другой спринт. А по нечетным - наоборот, начинаю со спринта номер два. Я все сказал.
На мой взгляд такая особенность также может быть учтена за счет Velocity. Кто ответственен за процесс планирования просто смотрит, сколько команда может закрыть. И планируется под такой же капасити. Ну а для вас, если вы каждый день чередуетесь, вклад в обе команды как будто равнозначный.
В любом случае Story Points — это всего лишь инструмент. Он где-то может подходить, где-то нет. И как у любого инструмента, есть свои плюсы и минусы.
Story Points хорошо работают для краткосрочного планирования. Можно пробовать применять для долгосрочного. Общий алгоритм примерно такой: ты знаешь Velocity своей команды. Тебе залетает проект. И тут либо распланированный беклог, либо грубая прикидка диапазона SP, сколько нужно на проект. Делишь одно на другое и получаешь спринты.
Как указывал в статье, долгосрочное планирование — отдельная тема, на раскрытие которой нужна отдельная статья :)
Я немного изучил этот вопрос. Ранее функция поиска по картинкам действительно была доступна, вот, например, доклад с Highload: https://youtu.be/AVNeOgT1ms0?t=418. Однако сейчас она, к сожалению, недоступна по внутренним причинам. Возможно, лучше обратиться через официальные каналы коммуникации, но, к сожалению, я не могу подсказать конкретные. В любом случае ваши комментарии в блоге компании — хороший способ поделиться своей потребностью, и, возможно, кто-то из команды обратит на них внимание!
Да, вы совершенно правы. Такое решение подходит не для каждой компании, а только для крупных, где менеджить нужно тысячи инстансов. Для наших DBA мы стараемся упрощать жизнь как можем: пилим отдельные CLI-утилиты, которые уходят от абстракций k8s; предоставляем более понятый API, согласованный с DBA, чтобы базами можно было управлять напрямую через платформу и т.д. И вообще держим тесный контакт с ними как с основными стейкхолдерами. Но даже с такими подходами ребятам все равно необходимо знать какой-никакой минимум по k8s, хотя бы на уровне чтения логов контейнеров Pod-a.
Мы скорее пытаемся автоматизировать жизненный цикл БД для множества микросервисов для обеспечения polyglot persistence. Если какой-то микросервис упирается по ресурсам, то применяем шардирование для горизонтального масштабирования как раз, чтобы конкретные инстансы не распухали.
Ну и в целом не понимаю, что мешает засетапить подобную базу в Kubernetes, если есть соответствующие ноды в кластере.
Спасибо за набросы! Постараюсь ответить.
Команды разные и контексты разные. В нашей команде ребята понимают в каком компоненте и какую примерно работу делать, т.к. погружены в проект и его домен. Поэтому и такой метод командой оценки работает и оправдан.
На мой взгляд, вариант, когда разработчик по хорошо оформленному тикету не может дать оценку, свидетельствует либо о том, что проекты и домен часто меняются (аутсорс разработка), и тут действительно Story Points не подойдут; либо о плохом бас-факторе в команде. Когда инженер не знает, чем вообще занимаются коллеги. И это другая проблема, которая за скоупом статьи.
Прискорбно о таком слышать. Тут лучше честность, чем "чепуха". Это еще один флажок о плохом бас-факторе или просто об особенностях проекта, где применяют Story Points без необходимости.
Не знаю, откуда в вас столько токсичности. Мы это применяем, потому что у нас это работает. Я нигде в статье не говорил, что это универсальный "швейцарский нож". Для таких практик и команда, и проект, и, возможно, компания должны быть достаточно зрелыми.
Спасибо за классные вопросы!
В днях тоже — "чистый рандом", потому что разные исполнители в команде сделают задачи за разное число дней. Story Points это просто еще один способ оценки в условиях неопределенности без привязки к людям.
При оценки таким методом вспомогательные активности учитываются за счет Velocity. Мы просто работаем командой какое-то время, а далее смотрим сколько реальных продуктовых Story Points удалось закрыть за это время. Учитывая, что при этом команда тестировала, релизила, ревьювила и прочее.
Да, если эта задача более приоритетная, то добиваем ее. После окончания спринта ретроспективно смотрим: был продолб в оценке или слишком много взяли на команду и нужно понизить целевое Velocity. 100% точности в планировании никогда не получится достичь на долгом промежутке времени. Какой бы способ для оценки вы не использовали.
На мой взгляд такая особенность также может быть учтена за счет Velocity. Кто ответственен за процесс планирования просто смотрит, сколько команда может закрыть. И планируется под такой же капасити. Ну а для вас, если вы каждый день чередуетесь, вклад в обе команды как будто равнозначный.
В любом случае Story Points — это всего лишь инструмент. Он где-то может подходить, где-то нет. И как у любого инструмента, есть свои плюсы и минусы.
Story Points хорошо работают для краткосрочного планирования. Можно пробовать применять для долгосрочного. Общий алгоритм примерно такой: ты знаешь Velocity своей команды. Тебе залетает проект. И тут либо распланированный беклог, либо грубая прикидка диапазона SP, сколько нужно на проект. Делишь одно на другое и получаешь спринты.
Как указывал в статье, долгосрочное планирование — отдельная тема, на раскрытие которой нужна отдельная статья :)
Я немного изучил этот вопрос. Ранее функция поиска по картинкам действительно была доступна, вот, например, доклад с Highload: https://youtu.be/AVNeOgT1ms0?t=418. Однако сейчас она, к сожалению, недоступна по внутренним причинам. Возможно, лучше обратиться через официальные каналы коммуникации, но, к сожалению, я не могу подсказать конкретные. В любом случае ваши комментарии в блоге компании — хороший способ поделиться своей потребностью, и, возможно, кто-то из команды обратит на них внимание!
Да, вы совершенно правы. Такое решение подходит не для каждой компании, а только для крупных, где менеджить нужно тысячи инстансов. Для наших DBA мы стараемся упрощать жизнь как можем: пилим отдельные CLI-утилиты, которые уходят от абстракций k8s; предоставляем более понятый API, согласованный с DBA, чтобы базами можно было управлять напрямую через платформу и т.д. И вообще держим тесный контакт с ними как с основными стейкхолдерами. Но даже с такими подходами ребятам все равно необходимо знать какой-никакой минимум по k8s, хотя бы на уровне чтения логов контейнеров Pod-a.
Добрый день!
К сожалению, не могу ответить, т.к. сильно далеко от разработки самого продукта. Наша команда пилит платформенную автоматику :)
Мы скорее пытаемся автоматизировать жизненный цикл БД для множества микросервисов для обеспечения polyglot persistence. Если какой-то микросервис упирается по ресурсам, то применяем шардирование для горизонтального масштабирования как раз, чтобы конкретные инстансы не распухали.
Ну и в целом не понимаю, что мешает засетапить подобную базу в Kubernetes, если есть соответствующие ноды в кластере.