Comments 72
"Сторипоинты — это аналог глубины ямы" ...без учёта неизвестных сюрпризов вроде кабелей, и без учета точности метода изменения этой глубины. "Измеряем индивидуальную производительность" ...с учётом трудности копания.
А итоге получается все та же оценка времени от сложности и объема работ. Верно подмечено, что помогает уменьшить неопределенность декомпозиция на атомарно мелкие задачки, раскладка их в граф, и оценка рисков каждой. Затем граф обсчитывается на минимальное и максимальное время исполнения. И если максимальное выходит за дедлайн, то нужно вернуться назад на этап декомпозиции и повторить. А самое веселое, что есть риски которые в буфер не конвертируются. Например, человеческий фактор обнулит все затраты на планирование. Поэтому что от балды скажи про яму, что пересчитывай копку каждый день, результат может быть тот же самый. Пока не сделаем, не узнаем.
Не говоря уже о том, что
Измеряем индивидуальную производительность (число сторипоинтов в неделю) каждого сотрудника.
зависит от множества факторов типа «внезапно заболел зуб» или «я вам не раб на галере». Которые нужно умножить на среднюю вероятность появления и снова умножить на количество людей в команде. В итоге получаются максимумы и минимумы с разницей в разы.
Я конечно далек от IT, но мне до сих пор не понятна попытки вводить вот эти всякие сторипоинты и прочие меры исчисления, когда есть простые часы и не надо часы конвертировать в часы. По сути только усложнение работы тимлида. Вам установили дедлайн руководство и вместо того чтобы из абстрактных сторипоинтов конвертировать в часы, можно сразу в часах все расписать и понимать сроки и можно не ждать неделю, чтобы примерно понять какая производительность и навыки у человека, а 2-3 дня, видя сколько он тратит часов на те или иные задачи. Единственное полезное что я увидел в статье это декомпелизация задач. Важная штука, не только в айти.
Берём разношорстную команду из сеньоров, джунов и мидлов. Если мы высчитываем производительность команды, то берём усреднённое значение. Условно сеньор выполняет задачу за 2 часа, мидл за 6, а Джун за 12 . Выходит среднее 6 часов 40 минут. И от этой времени и смотрим производительность команды. Среднее время можно как уменьшить, так и увеличить в зависимости от сложности задач, форс мажоров, закладывая в планирование буфер и кому какие задачи выданы. И показывать руководству, клиенту или кому-либо ни было именно фактические часы, а не попытки конвертирования сторипоинтов в часы. Причем тут можно ошибиться. Человеческий фактор никто не отменял и вместо 6 часов 40 минут, показали что выполним за 5 и по итогу у всех жопы горят из-за дедлайна, потому что неверно сроки прикинули. А если сразу показать в часах, то вместо 6 часов 40 минут можно сразу выдать 10 часов и задача будет готова, занося в работу буфер на случай форс-мажора или иных ситуаций. Вы и задачу выполните и будет время в запасе, и планировать проще и прикидывать предварительные сроки тоже будет проще, и от этого отталкиваться к реальному сроку после всего планирования. Или же когда руководство ставит дедлайн идёт ТЗ, срок неделя и н-ое количество задач. Вы прикинули и обсудили спланировали, если по срокам не укладывается вам будет проще либо заново все спланировать либо выявить только важные функционал, объяснить руководству что все что в ТЗ выполнить не получится, но работоспособный продукт без некоторых фич сможем сделать, а остальное добавить позже или если повезёт выбить дополнительное время.
Сроки есть сроки, и как их не вуалируй и не скрывай, когда он начнет поджимать пятая точка будет гореть у всех и будут кранчи, независимо от того какие единицы измерения вы используете и всем будет насрать на сторипоинты, собак, кошек. Всем надо как можно быстрее закончить. А если команда знает когда дедлайн заранее, ей проще вместе с тимлидом составить график и план, какие задачи нужно делать в первую очередь, какие задачи времязатратнее и их нужно выполнять в первую очередь, а какие можно отложить или и вовсе выкинуть и доработать и добавить уже после ввода продукта.
Тот же пример с ямой. Человек без лопаты выроет ее за день, с лопатой за пару часов, с экскаватором за несколько минут. И не нужны танцы с бубнами с переводом одних единиц исчислений в другие, чтобы понимать какая производительность. Все итак наглядно и интуитивно понятно.
Истинно так. Это все названия одной сущности "8человекочасов", "1 человекодень" или сторипоинт - по сути это просто мера. В классике берется эталонная понятная задача, ее нормируют на среднего сотрудника и назначают мерой в 1 сторипоинт. Все остальные задачи с ней сравниваются, и получается эта таска из 7 таких эталонных - ее оценка 7 сторипоинтов. Или человекодней. Или 56 человекочасов.
на практике же у тебя выпуск задачи - это и работа аналитика, часто ux, так же разработчика и тестера. И кто-то из них в отпуске, кто-то заболел, кто-то будет медленнее делать, так как заменяет Серегу, который на таких тасках задачу съел, и так далее. В итоге любые оценки задач и попытки их уместить в единицу релизовремени (спринт) - это все равно планирование конкретных исполнителей на конкретные задачи в конкретные временные отрезки. И как следствие - их оценивать и делать должны или равные по скиллу или те же люди, кто их будет делать. И только с 1 целью - понять и сделать оптимальным инкремент, который выйдет в прод, и запланировать занятость людей и приоритеты.
Так что все эти методологии по сути просто попытка оценки на глаз опытным менеджером переложить на команду, разделить якобы ответственность, и вместо решения проблемы заказчика (либо мы хотим точно знать, что и когда мы получим, либо мы хотим получать больше просто потому что) попытки сделать красивое лицо при плохой игре.
А реальных выхода всегда 2:
сделать процесс планирование с вовлечением заказчика, чтобы заказчик жил с командой и понимал процессы, тогда его ожидания будут совпадать, он не сможет сказать условному Сереге, что он проканал сроки, потому что будет видеть, что Серега сделал все, что мог, и проблема вне команды, и принимать это нормально и с пониманием, и сам отстаивать сроки и снижать ожидания
либо нанимать блин больше людей, если не хватает, и выделять больше бюджета, а не делать мозги, что у Петьки в стартапе в приложении на 15000 строк кода ребята делают 20 задач, а вы в платформе с 3млн пользователей ежедневно и 25 миллионами строк кода и ограничениями в ИБ и кучей интеграций только аналитите 2 месяца.
Вот и вся петрушка. Делать быстро несложно. И оценивать несложно. В маленьких продуктах без зависимостей, выделенной и достаточной командой и разделением на growth и саппорт в рамках итерации, чтобы никто не прибегал с важной таской на зашел и вышел, отвлекая от запланированного времени. В остальных случаях хорошее планирование - лишь цепь случайно сошедшихся обстоятельств, а неудачное - вина команды, все не так, давай менять процессы, но времени и денег на это мы не выделим)))
Сторипоинт Это попытка получить оценку от исполнителей.
хоть в чем, но в во времени по факту.
Просто следом оценка становится ОБЯЗАТЕЛЬСТВОМ.
И вот у вас оценка в 6ч 40 минут в момент как стала ОБЯЗАТЕЛЬСВОМ с ответственностью превратилась магически в 10 часов.
Куда ушли +50% рабочего времени?
А раз они появились. это +50% рабочего времени в момент когда оценка стала обязательством.
То это уже предмет договора вот эти +50% - и вот менеджер пытается вставить максимум задач чтобы за неделю люди больше сдали работы.
И как договоришься.
И вот чтобы люди у станка давали оценки задач СРАВНИМЫЕ , и работали - кодили , а не тратили время на "как договоришься".
- как на рынке: где два дурака один продает другой покупает.
придумали сторипоинты.
Оценка в SP это не оценка времени, это оценка объёма задачи.
Пример с глубиной ямы, которую надо выкопать, является хорошей аналогией.
Нужно понять, какую глубину нужно прорыть, чтобы запланировать, кто будет копать и сколько у них на это уйдёт времени. Землекопа спрашивать за сколько будет вырыта яма не очень правильно, потому что у разных земплекопов на это уйдёт разное время, а глубина - это объективная неизменная величина.
Менеджер берёт оценки в SP не для того, чтобы напихать задач и люди больше работали. Для этого как раз оценки не нужны. Можно по беспределу пихать задач, пока команда берёт и прогибается, грозя увольнением.
А оценки в SP как раз наоборот нужны, чтобы команду оградить от лишнего стресса. Они нужны, чтобы
1. сказать примерные сроки заказчику, не привлекая в этот процесс команду и не нервируя её лишний раз дедлайнами.
2. правильно управлять зависимостями задач друг от друга, понимая где задача жирная, а где нет.
Пример с глубиной ямы, которую надо выкопать, является хорошей аналогией.
Плохой, поскольку на 99% глубина ямы входит в условие задачи - она известна заранее, и определяют её не Джамшуты, которые будут копать.
Заказчик (солидный дядя в пиджаке) не даёт задачу вырыть яму 10 метров. Он говорит, что надо построить красивое здание.
Которое проектирует архитектор, рассчитывает тип и глубину фундамента. Сметчик определяет стоит ли брать экскаватор или дешевле руками вырыть. Прораб пригоняет джамшутов и говорит - копать здесь, глубиной 3 метра. Приду - проверю.
И только в IT перед высокие очи вытаскивают фактически пару чебуреков и начинают:
Вот здесь! Будет! Бизнес-центр!! 8 этажей!!! Какой глубины под него яма?!
Эээ... Бешмельме начальника... Два спринта минимум!
Если мы высчитываем производительность команды, то берём усреднённое значение.
Нет, берём максимальное значение. То есть, время джуна.
Производительность копания измеряется часами на кубометр. Количество времени, которое затрачивается на выкапывание вычисляется как производительность * объём ямы в кубометрах.
То есть, у ямы есть такая характеристика, как объём в кубометрах. А время выкапывания зависит от того, кто будет копать.
Перечень ям вам известен заранее, а чем их будет эффективнее копать, будет решаться позднее с учётом наличия ресурсов и объема ямы. Не целесообразно использовать экскаватор для маленьких ям и ручной труд для больших.
Сторипоинты и задумывались как аналог объема ямы в нашем примере.
Я думаю оценка и сама работа это не одно и тоже, да даже сама оценка это тоже работа (митинги)
Как превратить сторипоинты в сроки?
-------
Все зависит от того, что мы собираемся измерять. Если наш горизонт планирования - это спринт, то и "сроки" понятны: набрали тасков в спринт каким-то способом (пусть через оценку в сторипоинтах), и ладушки.
А вот если нам нужно планировать весь проект, уметь понимать, где мы в проекте, то придется вводить, если угодно, два разных сторипоинта. Один - единый на весь проект, и в нем мы будем измерять скоуп. Второй - на текущий спринт внутри команды, и он нужен для планирования спринта, а к скоупу отношение будет иметь очень косвенное, поскольку велосити команды - вещь нестабильная.
Ну а формулы, которая бы позволила из скоупа в одно действие получить сроки, просто не существует: это разное.
Например, в моих командах мы условились, что подзадача может быть реализована мидлом «за полдня-день»
То есть 1 сторипоинт = 6±2 часа. Двухнедельный спринт в таком случае может вылиться в 7-13 рабочих дней. Городить эти непонятные абстракции в виде велосити и других непонятных метрик ради такого сомнительного результата - это реально того стоит?
Во взрослых бизнесах делается так:
1) типизируются и нормируются ВСЕ работы, которые может выполнять команда. Уже декомпозированные, разумеется. Получается огромный прайс-лист с требуемыми компетенциями и трудозатратами
2) типизируются и нормируются компетенции в команде. Составляется список технологий, которыми владеет каждый сотрудник и уровень его владения этими технологиями
3) Каждая новая задача коллективно оценивается на предмет соответствия прайс-листу и формулируется уровень СКРЫТОЙ неизвестности - когда вроде всё выглядит обычно, но по опыту чувствуется, что что-то может пойти не так
4) Задачи назначаются сотруднику соответственно его грейду и компетенций, полученная длительность работ при этом ложится в график проекта. Для защиты от угрозы добавляются доп.часы (опять же нормированные), доп.ревью сеньором или просто более высокий грейд специалиста
5) Далее на все эти графики надо регулярно смотреть и анализировать их. Если получается, что у вас в них постоянный проёб по срокам и все задачи имеют скрытые проблемы - значит у вас что-то не так с аналитикой или компетенциями разрабов. Если же задачи щёлкаются как орешки - значит можно давать их джунам и экономить моржей. И так далее.
И по итогу эти "взрослые" бизнесы либо проваливают релизы (особенно характерно для game dev) , либо, как сейчас дедает большинство - обновления В СРЕДНЕМ каждые полгода, но из релиза буквально за пару недель до, могут выкинуть н-ое количество фич, которые вроде как были запланированы, но... "Извините, эта функциональность слишком сложная, и мы может быть проработаем ее лучше, но а может и х*й с ней, обойдетесь" 😁 Даже название у этого метода есть: feature driven development...
К чему это я? Когда уже дяди от бизнеса поймут, что создание софта - это ближе к окр. Оно так и есть,т к каждая система создаётся один раз, это не серия. А для большинства разработчиков большинство задач - новые. Как оценить их срок выполнения? - ответ НИКАК! Срок и результаты не предсказуемы до самого дня релиза. Можно назвать только вероятность, да и то это смысла не имеет, т к оценка будет субъективной, а значит не верной. Выход - оставлять двукратный-троекратный запас, причем не от срока, который, вы, бизнес-дяди ставите, а от того что вам технари сказали. Технари слишком оптимистичны, это 100%. И это все еще при условии, что вы сами корректно формализовали свои же требования, а не "два пишем, пять в уме". Как то так. Смиритесь или идите на завод 😁
Когда уже дяди от бизнеса поймут, что создание софта - это ближе к окр
В чём создание 100500 интернет-магазина отличается от 100499 настолько, что "это ближе к окр"?
Оно так и есть,т к каждая система создаётся один раз, это не серия
Строители, внезапно, тоже так умеют. Почему у них сметы есть?
Как оценить их срок выполнения? - ответ НИКАК!
Окей, гугл, нормы продолжительности проектирования объектов строительства. Как они они умудрились это сделать?
Надо упоминать, что проектируют всё, начиная от гаража до целых районов, в разных геологических, климатических и так далее условиях? Равно как и то, что новые материалы, технологии и подходы в строительстве тоже постоянно появляются (не со скоростью появления JS-фреймворков, конечно, но всё же).
Окей, гугл, нормы продолжительности проектирования объектов строительства. Как они они умудрились это сделать?
Вам гугл что то не то отвечает... Строительство - принципиально другая сфера. У меня есть знакомые из этой сферы. Вы вот считаете, что я от балды написал, а я специально их распрашивал. Знакомый прораб объяснил, что время на выполнение работ одинаково, если объекты одинаковые. Примерно тоже самое сказал и проектировщик: типовые проекты ? - да пожалуйста, по всё по нормам. Делают их либо новички, либо вообще стажеры. Он только проверяет. А сам делает не типовые, в основном разные металлоконструкции. По сути все проектирование сейчас сводится к подбору из опыта и интуиции удачной конструкции и симуляции результата в спец ПО. Это может запросто занять до недели времени (c учетом всех требований). А ещё каких-то 20 лет назад было ещё дольше и эта задача не декомпозируется на меньшие. В масштабах всей стройки затраты времени на проектирование не значительны. Это второй фактор, почему ему на эту работу сверху сроки не спускают. Сроки он сам же себе задает из своего опыта и интуиции. Также субъективно, как и в разработке.
С созданием ПО ситуация в корне иная - проектирование сливается с фазой создания (если конечно это не водопад, который остался только в очень ограниченных областях и показал свою полную не гибкость) И разделить эти фазы невозможно. Так же нет практически одинаковых задач (ну если не брать например сферу какого-нибудь 1С, да и то там одинаковыми будут только задачи по его обновлению, да и то если клиент не изменил конфигурацию... А так тоже результат непредсказуем, даже в казалось бы, уже очень однотипной ситуации - одна и та же бизнес-система...)
Более того - сама попытка что-то нормировать и "типизировать" в этой области абсурдна, т к изначально задумывалось, что "зашивают" в электронику программу для того что бы по желанию менять поведение. Но тогда это и должно использоваться именно для не типовых задач... А компьютер - это апогей этой концепции. Универсальное железо для очень разнообразных программ. Если же у вас задачи одинаковые, так зачем вам вообще компьютер ? Зашейте это один раз на аппаратный уровень и всё, и не нужно платить разработчикам постоянно =)
Вам гугл что то не то отвечает...
Так Вы же можете просто ввести тот же запрос и проверить.
Знакомый прораб объяснил, что время на выполнение работ одинаково, если объекты одинаковые
Насколько "одинаковые"? Гараж это "одинаковый" объект? Например, на подвижных грунтах и на скальном. И разница между их "одинаковостью", случайно, не больше, чем между 100500 и 100499 интернет-магазином?
По сути все проектирование сейчас сводится к подбору из опыта и интуиции удачной конструкции и симуляции результата в спец ПО
Ramus, ERWin и далее по списку?
В масштабах всей стройки затраты времени на проектирование не значительны.
В чём принципиальное отличие от написания ПО? Сравните хотя бы время на проектирование БД и её реализацию, подключение в приложение и наполнение начальными данными.
почему ему на эту работу сверху сроки не спускают
Почему не спускают? Cпросите в поисковике, он Вам покажет нормативные документы в которых русским языком написано, что спускают.
Сроки он сам же себе задает из своего опыта и интуиции
А Вы не пробовали опросить хотя бы десяток проектировщиков?
С созданием ПО ситуация в корне иная - проектирование сливается с фазой создания (если конечно это не водопад, который остался только в очень ограниченных областях и показал свою полную не гибкость) И разделить эти фазы невозможно.
Это иллюзии. Вы не сможете одновременно проектировать и реализовывать даже банально базу данных, хотя, казалось бы, инструментов тут более, чем достаточно.
ну если не брать например сферу какого-нибудь 1С, да и то там одинаковыми будут только задачи по его обновлению
Вы же это пишите не имея большого опыта работы с 1С, да?
Более того - сама попытка что-то нормировать и "типизировать" в этой области абсурдна
С точки зрения типичного айтишника, живущего в тепличных условиях, несомненно.
Универсальное железо для очень разнообразных программ
Внезапно, это не означает, что один и тот же экземпляр этого универсального железа будет выполнять все эти очень разнообразные программы. Например, маршрутизатор собран абсолютно на том же железе (плюс-минус с нюансами, но в данном случае это не имеет большого значения), много он "очень разнообразных программ" выполняет?
Аналогично - кирпич. Потенциально из него можно построить кучу разных форм, очень универсальный материал.
Зашейте это один раз на аппаратный уровень и всё, и не нужно платить разработчикам постоянно =)
Можно посмотреть "зашитый на аппаратный уровень" интернет-магазин? Ну хотя бы совершенно типовой WordPress+WooCommerce?
Так Вы же можете просто ввести тот же запрос и проверить.
Пустое. Говорите по существу
Например, на подвижных грунтах и на скальном.
Вы передергиваете. Я вроде достаточно ясно объяснил какие объекты не одинаковые. Те, которые строятся штучно в единственном экземпляре. Для примера - космодром, атомная аэс, либо какой-нибудь уникальный промышленный объект.
А Вы не пробовали опросить хотя бы десяток проектировщиков?
Каких ? Я по-моему доходчиво объяснил, что он занимает позицию старшего проектировщика. Нету смысла опрашивать других, везде так будет. А если сроки старшему начнет ставить менеджер, который в строительстве ноль - будет тоже самое что и в разработке ПО
Это иллюзии. Вы не сможете одновременно проектировать и реализовывать даже банально базу данных, хотя, казалось бы, инструментов тут более, чем достаточно.
Кто "Вы" ? Выражайтесь яснее. Я конкретно ? Может быть, никогда не писал базу данных. Тем более я ее не смогу спроектировать только в уме или в виде UML-диаграмм. Если же вы это скажете тому, кто уже делал базы, то либо он вам сделает тоже самое, что уже есть. Но зачем, если она уже есть ? Либо он окажется в том же положении, что и я. Ну может меньше граблей соберет по дороге. Тем меньше чем больше ваша база будет похожа на уже имеющиеся. Если же она обладает какими-то особенностями, то именно так ее и будут делать - сначала реализуют типовое ядро без всякого проектирования, просто взяв за основу свои же предыдущие наработки, где всё относительно ясно, потом будут проектировать и однровременно писать код этой особенности. (это помимо того что вы можете что-то такое захотеть, что и на первом этапе сразу придется отойти от типового решения) Именно так создается РАБОЧЕЕ ПО которым потом можно пользоваться. Это итеративный процесс. Даже если вы возьмете например процес Rational Unified Process, который сейчас считается "Waterfall", то даже там есть итерации и считается вполне нормальным, что какая-то из итераций может не уложиться в план. И извесно это станет после завершения предыдущих итераций.
Вы же это пишите не имея большого опыта работы с 1С, да?
Вы это зачем написали ? У вас этот опыт есть ? Мне лично достаточно отрицательного опыта, когда одинэсники один за другим разводят руками и говорят "У вас конфигурация не типовая. Мы не знаем сколько нужно денег и времени и даже не знаем получится или нет. Давайте на почасовую оплату" =)
С точки зрения типичного айтишника, живущего в тепличных условиях, несомненно.
Опять передергиваете. Ниже по тексту достаточно нормально объяснено почему я стою на этой позиции.
Например, маршрутизатор собран абсолютно на том же железе (плюс-минус с нюансами, но в данном случае это не имеет большого значения), много он "очень разнообразных программ" выполняет?
Да, много. Как правило как минимум несколько версий своей оригинальной прошивки. Затем прользователь егно может перешить и вообще использовать иначе чем маршрутизатор Помимо этого одну и туже аппаратную платформу используют разные производители, снабжая ее своей прошивкой
Я по-моему ясно сказал что мы говорим о ПО для компьютера. Но даже при создании этого маршрутизатора, когда то его делали впервые. И тот кто это делал был в выше описанной мной ситуации с базами.
Можно посмотреть "зашитый на аппаратный уровень" интернет-магазин? Ну хотя бы совершенно типовой WordPress+WooCommerce?
Так к вам встречный вопрос: Почему нельзя то ? По вашей же логике все магазины на WordPress+WooCommerce одинаковы. Можно взять тот же роутер и зашить... У меня сложилось впечатление, что именно подобными проектами вы и занимаетесь, где всё сводится к установке флажков в конфигурациях. Это вообще не программирование. Впрочем оно тоже плохо планируется, т к вы до конца не знаете всех граблей. В любой день выйдет обновление, которое у половины ваших клиентов начнет вылетать с ошибкой. Это в какой план у вас записано ?
Говорите по существу
Я по существу и ответил. Гугл, первая же ссылка из результатов поиска:
https://docs.cntd.ru/document/456036087
Вы передергиваете. Я вроде достаточно ясно объяснил какие объекты не одинаковые.
Нет, это Вы передёргиваете, я попросил уточнить, какие объекты Вы называете одинаковыми.
Каких ?
Разных.
Нету смысла опрашивать других, везде так будет.
Гарантируете?
А если сроки старшему начнет ставить менеджер, который в строительстве ноль - будет тоже самое что и в разработке ПО
Вы про нормативные документы что-нибудь слышали? Ссылка на один из них в начале этого комментария.
Но зачем, если она уже есть ?
Затем, что от того, что в eCommerce есть таблица типа goods, в WooCommerce она не появляется.
Либо он окажется в том же положении, что и я.
Он окажется ровно в том же положении, что и любой другой. Невозможно одновременно делать даже alter table и insert into. Я уж не говорю о том, чтобы одновременно рисовать ER-диаграмму и делать insert into.
У вас этот опыт есть ?
Да.
Давайте на почасовую оплату
И в описываемом Вами случае как минимум: а) была документация на все нетиповые доработки, а не как обычно: вот конфиг, разбирайтесь сами б) Вы можете гарантировать, что они действительно не знали, а не пытались таким образом выбивать себе более высокие доходы ?
Как правило как минимум несколько версий своей оригинальной прошивки.
Посчитаете, сколько всего программного обеспечения хотя бы просто на гитхабе и какую мизерную долю от этого составляют вообще все версии прошивок на данный маршрутизатор?
Я по-моему ясно сказал что мы говорим о ПО для компьютера
Мне нужно явным образом перечислять все возможные конфигурации компьютеров, которые всё время своей эксплуатации выполняют строго ограниченный набор ПО или Вам достаточно примера в виде маршрутизатора, чтобы задуматься об этом самостоятельно?
Так к вам встречный вопрос: Почему нельзя то ?
Потому что Вы передёргиваете. Утверждение "Если же у вас задачи одинаковые, так зачем вам вообще компьютер ? Зашейте это один раз на аппаратный уровень и всё" Ваше. Вот Вам одинаковая задача: интернет-магазин на WordPress+WooCommerce, которых тысячи по всему интернету. Покажете зашитый на аппаратный уровень?
Это вообще не программирование.
И даже на этом простейшем примере Вы не можете объяснить, почему 100500 интернет-магазин на WordPress+WooCommerce "создаётся один раз, это не серия"?
Это в какой план у вас записано ?
В план работ по установке обновлений в тестовый контур.
Строители, внезапно, тоже так умеют. Почему у них сметы есть?
Строители точно так же регулярно факапятся, даже на серийных объектах. А уж про уникальные и говорить нечего.
Строители точно так же регулярно факапятся, даже на серийных объектах.
И это действительно так.
С одним нюансом - нужно учитывать не то, что они факапятся вообще, а применительно к теме обсуждения, т.е. из-за плохого планирования работ. И тут внезапно окажется, что строители факапят чаще всего по причине недофинансирования, т.е. заказчик банально не дал денег на какой-то этап работ вовремя. Планирование работ к этому имеет околонулевое отношение.
Ага, особенно явно это относится к строительству АЭС, где и с деньгами все нормально и задержки по срокам от плана в два-три раза никого не удивляют.
Это шаблонные многоэтажки из готовых блоков строят более-менее по плану и в срок, хотя и там задержки на четверть срока не редки. Все остальное, от ремонта квартиры и до АЭС - в сроки укладывается довольно редко и, скорее, случайно.
Ага, особенно явно это относится к строительству АЭС, где и с деньгами все нормально и задержки по срокам от плана в два-три раза никого не удивляют.
"Основными причинами задержек в строительстве АЭС является задержки в закупке и доставке материалов и оборудования на проект"
https://energypolicy.ru/voprosy-upravleniyazhiznennym-cziklom-aes/energetika/2023/19/24/
"Сроки ввода в строй всех энергоблоков АЭС «Аккую» требуют уточнения из-за блокировки поставок оборудования компанией Siemens"
https://www.ixbt.com/news/2024/11/25/sankcii-protiv-rossii-srabotali-sroki-zapuska-vseh-jenergoblokov-rossijskotureckoj-ajes-akkuju-trebujut-utochnenija.html
Какое ко всему этому отношение имеет планирование работ?
Это шаблонные многоэтажки из готовых блоков строят более-менее по плану и в срок, хотя и там задержки на четверть срока не редки.
"Это связано с целым рядом факторов: от экономических трудностей и роста цен на строительные материалы до бюрократических проволочек и проблем с подключением коммуникаций."
https://garant-dev.ru/tpost/a0so2l4uv1-problemi-s-zaderzhkami-sdachi-novostroek
Опять же, какое ко всему этому отношение имеет планирование работ?
Все остальное, от ремонта квартиры и до АЭС - в сроки укладывается довольно редко и, скорее, случайно.
"В первом квартале 2025 года более 48% новых жилых комплексов в России были введены в эксплуатацию с отставанием от запланированного графика, что является самым высоким показателем за последние четыре года."
https://vc.ru/id3299780/1906204-zaderzhka-sdachi-novostroek-v-rossii
Т.е. более 50% сдавались в срок (и то это самый худший случай, ранее было лучше). Это как-то очень не похоже на "скорее случайно". Если, конечно, Вы не "динозавровую" случайность имели в виду.
Ты какие-то странные цитаты привел про АЭС. Почитай про https://ru.wikipedia.org/wiki/АЭС_«Олкилуото», например.
Подведение коммуникаций, планирование финансирования - это все часть как раз планирования работ, которое, как ты сам показываешь, даже для серийного строительства одинаковых многоэтажек идет с отставанием в половине случаев.
Т.е. даже шаблонное строительство - не может быть нормально спланировано.
Почитай про https://ru.wikipedia.org/wiki/АЭС_«Олкилуото», например.
"у Areva не было опыта в проектировании станций, проект двигался очень медленно, потому что Areva не была достаточно подготовлена, на некоторые части проекта отсутствовала техническая документация, и не было понятно, сколько необходимо времени на доводку проекта"
Т.е. Вы приводите ссылку на материал, где прямо написано, что никто никаких расчётов сроков не делал и выдаёте это за подтверждение того, что расчёт сроков не работает?
Подведение коммуникаций, <...> - это все часть как раз планирования работ
Вы путаете планирование подведения коммуникаций и фактическое их подведение. Вы можете запланировать по нормам, взять поправочный коэффициент равный Пи и всё равно выйти за сроки. Просто потому, что обычно коммуникации предоставляет естественная монополия и даже если Вы всё сделаете идеально вовремя, средств воздействия на неё у Вас практически нет. Это несколько отличается от типичной ситуации с выполнением задач по разработке ПО, не находите?
планирование финансирования - это все часть как раз планирования работ
Вопрос только чьих. Или Вы сейчас хотите сказать, что тимлид должен расписать сперва план работ программистов, а потом план работ отдела продаж? И потом ещё контролировать как оба этих плана исполняются? А начальник отдела продаж чем у Вас должен заниматься? В потолок смотреть?
Т.е. даже шаблонное строительство - не может быть нормально спланировано
Что Вы подразумеваете под "нормально спланировано"? То, что отдел продаж не заработал обозначенное количество денег в обозначенные временные рамки и производство (стройка, разработка) было заморожено на срок, который вышел за границы критического пути? Какое это имеет отношение к оценке продолжительности работ непосредственных исполнителей (программистов, строителей)?
В строительстве рабочий многократно повторяет одну и ту же работу, поэтому сроки легко посчитать.
Например, укладка плитки занимает 5 минут в среднем. Делим площадь стены на площадь плитки, умножаем на 5 минут и вуаля, готов срок.
В программировании нет никакого смысла повторять одну и ту же работу. Если мы это уже делали, просто берём и используем код повторно. Поэтому каждая работа уникальна. Бывает более-менее похожие, но не такие-же. В любом другом производстве это в принципе невозможно.
Делим площадь стены на площадь плитки, умножаем на 5 минут
"и вуаля" тут трубы торчат, там круглый угол, а здесь электрику нужно вывести сквозь плитку.
Если мы это уже делали, просто берём и используем код повторно. Поэтому каждая работа уникальна.
Это сегодня, когда всерьёз пишут про "перекладывателей JSON'ов" и "CRUDописателей"?
В любом другом производстве это в принципе невозможно.
Здравствуйте, добро пожаловать в XXI век, у нас тут ту же плитку делают на автоматических линиях.
По поводу труб - проделывание отверстия в плитке тоже легко оценивается. Кривые стены легко замерить, и если они не подходят, то добавить в смету штукатурку стены, которая также оценивается банальным замером времени при штукатурке предыдущих объектов.
Вы правы, клепание очередной формы или круд эндпоинта действительно похоже на укладку очередной плитки, и такие задачи примерно также легко оценивать. Хотя вместо клепания каждого круда в отдельности, лучше один раз использовать odata или аналог.
Но, производство следующих 100 плиток на конвейере требует в 100 раз больше ресурсов чем производство каждой одной плитки на этом же конвейере.
Производство ещё 100 новых копий программного продукта после первой копии не стоят практически ничего. Мы не строим новый инстанс программного продукта когда он нужен, мы его просто копируем. В этом разница между производством вещественного продукта, и производством информационного продукта. Также мы поступаем не только с итоговым приложениями, но и с библиотеками и классами внутри приложения. Вот об этом принципиальном отличии я говорил.
Была раньше такая замечательная передача "Grand designs" про строительство нестандартных домов.
Общий вывод из просмотренных двух сезонов - все сроки и все сметы нужно умножать на 2. В смысле - полная глупость этого не делать, даже при том, что всё было просчитано профессионалами высокого класса.
Там ещё была типовая шутка "будет готово к Рождеству". В смысле - без уточнения года.
Работаю в "кровавом энтерпрайзе" (финансовые компании размером >5000 чел) - уж не знаю, считается ли это "взрослым бизнесом". Не видел ни одной удачной попытки качественно нормировать работу разработчика. Повторяющиеся однотипные работы (например, задачи поддержки) нормировать получается. Разработка, выходящая за рамки "набросать типовой отчётик" или "сверстать страничку по макету" обычно содержит слишком много неизвестных как технических, так и по постановке задачи. А люди при этом в своём опыте и производительности могут отличаться в разы даже в рамках одного грейда.
Все усредняют, деваться некуда, все разбираются с аналитикой и компетенциями разработчиков. Вот только оценке, будь то часы или сторипоинты, это мало помогает.
Во взрослых бизнесах сторипойнты. Это статья от МТС, куда уж взрослее.
В крупных IT бизнесах обычно очень, очень фиговые процессы, так как бизнес от качества процессов не зависит, а найти компетентных менеджеров в достаточных количествах не получается.
Статья прекрасная, по ней можно проводить обучение по списку плохих подходов к разработке, собрали чуть ли не полный джекпот.
Вот почему-то всех тянет измерять сложный интеллектуальный труд количеством изготовленных на заводе деталей, которые потом конвертируются во время, оправдывая это тем, что сразу во времени оценить очень сложно. Хотя, это кажется очевидным бредом.
Открою страшную тайну, проблема не нова и уже много лет существует практически в любой отрасли и даже в повседневной жизни. Когда мы измеряем любой процесс в точных единицах времени, мы почти всегда ошибаемся. Но только в ИТ решили придумать защекоины, которые потом все равно приходится переводить во время, вместо того, чтобы использовать готовые решения.
Вы говорите о вреде карго-культа, но сама идея сторипойнтов родилась как решение совершенно другой проблемы. А уже потом карго-культисты под агиле лозунгами использовали эту идею для увеличения собственной значимости.
Это всего лишь магия худу, она работает только когда вы в нее верите. Ничего плохого в ней нет, но ничего хорошего она тоже не приносит, кроме иллюзий. Но, если они вам помогают, почему бы и нет?!
Согласен с вами и еще больше обобщу с помощью поговорки "любой план хорош до его реализации". Как бы мы не оценивали всё равно всплывут какие-то новые подробности, что-то пойдет не так и мы ошибемся.
Но тут дело в том, что отсутствие плана - это еще хуже. То есть вообще не оценивать задачи, не грумить, не декомпозировать их - означает, что делаться они будут дольше, синхронизация в команде будет хуже, случаев, когда человек месяц работает с задачей "да тут дел то на 5 минут" будет больше.
На мой взгляд, как уже говорилось в статье, декомпозиция наше всё. Если задача по примерной оценке занимает больше 2-3 дней, то это плохая задача, её надо декомпозировать, а если столько или меньше, то её и оценивать не нужно :) И второй момент, не надо жадничать при планировании и с той и с другой стороны. Если у вас спринт 10 сторипоинтов вмещает, ну не надо брать задач на 10 сторипоинтов, возьмите на 5, край 7. Нам ведь важно фичу выкатить в срок, а не следить за тем, чтобы не допустить, что разработчик не дай бог где-то не доработает. Да и кроме того, если останется время, оно же не пропадет, его разработчик потратит на несрочные задачи, техдолг тот же.
Если задача по примерной оценке занимает больше 2-3 дней, то это плохая задача
Но тем не менее они нередкие - вот пришло вам от тестировщика что программа (монолит, результат десятилетнего труда 200+ разработчиков) работает нестабильно на некоторых данных...
Я и не предлагал не оценивать задачи и не иметь плана (зато не оценивать задачи предлагал создатель стори пойнтов).
Везде уже научились их оценивать. Поезда вон ходят минута в минуту по расписанию.Многие в ИТ уже тоже научились их оценивать. Мне кажется, что проблемы со сроками только у тех, кто воспринимает фразу "попасть в оценку очень сложно" как аксиому и не пытается сроками управлять. Или у тех, кто пытается использовать бесполезные инструменты, например сторипойнты.
Везде уже научились их оценивать.
Да ладно. Когда там уже термоядерный синтез будет? Или новый космический корабль. Или МС-21, который как-бы не с 2009 года обещают. Только точные сроки.
Конечно можно сказать что УТС или даже авиалайнер это не айти, а гораздо сложнее. Но типовые задачи и в айти в основном нормально оцениваются, как и не в айти типовые задачи периодически факапятся.
Объём работ нигде не измеряют часами, его измеряют в натуральных единицах. Например в площади стены, которую надо оштукатурить, объем ямы, которую надо выкопать.
Зная объём, мы выбираем инструмент исходя из его стоимости и производительности.
Например, на маленькую яму эффективнее использовать человека с лопатой, а на большую экскаватор, потому что производительность экскаватора перекроет разницу в стоимости.
Итого, зачем использовать SP если все равно конечная оценка нужна в часах, что бы назначить дедлайн?
Если делать SP=x часов, то тогда эти SP это не SP. Потому что SP это оценка сложности. Явно конвертировать не стоит, максимум как период от/до, но дедлайн необходимо считать по часам после анализа.
На моей практики SP вкатывается когда менеджеры на основе экспресс аналитики задачи могут оценить ее сложность на примере подобной уже готовой, и запланировать примерно необходимый ресурс человека/часов. А дедлайн все равно рассчитывает исполнитель по часам после полного системного анализа, декомпозиции и тех. анализа.
При этом из 10+ проектов с разными команда не встречался ни один проект где SP легко и понятно работают. А человеко/часы - да, удобно, понятно, просто.
Есть принципиальные отличия от часов. Главные причины, зачем оценивается в SP:
SP даёт команда, а сроки лучше всего руководителю определять самому.
Почему так: во-первых, сроки зависят не только от объёма, но и от много чего ещё, на что влияет именно руководитель, а, во-вторых, потому что сроки - это лишнее психологическое давление на команду, которое совсем не помогает ей работать.Оценка в SP более устойчива к когнитивным искажениям, чем оценка в часах.
Если человек определяет сроки в часах, то он может стесняться дать верную оценку, занижая её, либо может перезакладываться намеренно, чтобы поменьше работать.Оценка в SP не зависит от исполнителя.
Имея такую оценку можно на планировании выбрать исполнителя без переоценки задачи, вычислив сроки.
Пример с ямой в статье показателен. При оценке работ мы ведь не оцениваем глубину ямы в часах. Нужна глубина в метрах, а уже на её основе прораб думает кто будет копать и чем.
потому что сроки - это лишнее психологическое давление на команду, которое совсем не помогает ей работать.
Вот на этот счет есть практика, в которой сроки знает только менеджер (руководитель/лид) и он мягко ведет исполнителей. Работает хорошо, главное менеджера толкового.
Оценка в SP более устойчива к когнитивным искажениям, чем оценка в часах.
Если человек определяет сроки в часах, то он может стесняться дать верную оценку, занижая её, либо может перезакладываться намеренно, чтобы поменьше работать.
С SP аналогично. Не раз встреча такое же искажение в оценке через SP.
Измеряем индивидуальную производительность (число сторипоинтов в неделю) каждого сотрудника.
SP даёт команда, а сроки лучше всего руководителю определять самому.
Если у вас каждого сотрудника (даже не команду) измеряют индивидуально в сторипойнтах в неделю, то сторипойнты это и есть сроки в часах/днях. Если у разработчика Пети производительность 5 сторипойнтов в неделю, то задача на 10 сторипойнтов это две недели. И это всем абсолютно ясно.
сроки - это лишнее психологическое давление на команду, которое совсем не помогает ей работать
В команде работают взрослые люди? Тогда они в курсе, что продукт должен быть готов к определённому сроку. Срок — это всегда стресс, да. Но считать разработчиков какими-то нежными нервными барышнями, которые падают в обморок от стрелки часов, как-то совсем наивно. Если срок нормальный — ничего страшного в нём нет. А чтобы срок был нормальный, тимлид должен выбить этот срок из стейкхолдеров (которые любят нагибать по срокам, работа у них такая).
Свой велосипед с блекджеком и проститутками граблями и квадратными колесами.
Никто не мешает демопозировать задачи перед тем как эстимировать их сторипойнтах или попугаях, и обычно так и делают. Никто не мешает управлять зависимостями задач перед тем ка декомпозировать их. Да, в теории скрама счиатется что команда одинаковой квалификации и любой член команды может безболезненно заменить другого. В реальности это обычно не так, поэтому этот риск митигируют например оверэстимейтом. Ваши попугаи ничем не лучше и не хуже правильноприготовленных сторипойнтов.
Ну а ваще лучше что я читал на эту тему - Стив Макконнелл, Сколько стоит программный проект.
Яма - это хорошо. Плохо то, что в реальной жизни под слоем земли в 10 сантиметров лежит бетонная плита, которую ни руками, ни лопатой не возьмешь. И заранее об этом никто не знает - может быть только догадываются единицы, но их как правило закидывают тапками и криками "не надо нам здесь сеять негатив" :) В IT разработке очень большая доля неопределенности, я об этом.
Есть проекты, где неопределённость - это данность, например, в стартапах или в принципе при запуске нового продукта. Но там и не используются метрики и оценки. Там просто делаем, пока есть инвестиции и силы.
Но если речь идёт не про стартап, то почему должен быть высокий уровень неопределённости? Ведь можно значительно забороть её системным и бизнес анализом или через предварительный RnD, когда разработчик заранее пробует задачу на зуб, но без углубления в детали.
Могу ошибаться, но суть статьи как раз в том, что сторипоинт не временная мерка. У сеньера за спринт выходит 10 СП, у мида 7, у джуна 5, хотя в днях у всех 14.
В такой логике лиду в принципе довольно удобно будет рассчитывать срок выполнения задачи и назначить исполнителя. Оценили задачу в 5 СП, сдать нужно за неделю, понятно что назначить ее можно только на сеньера, только у него в неделю выйдет 5 СП сделать.
Хотя конечно все очень условно и аналогичная задача по горячим следам будет выполнена в 2 раза быстрее. Ну и емкость команды по СП будет сильно меняться от спринта к спринту, нужно постоянно следить за этим.
А на практике да, 1 СП 1 день... Ну у нас на практике вообще весь аджайл не тот что задумывался...
У сеньера за спринт выходит 10 СП, у мида 7, у джуна 5, хотя в днях у всех 14.
Вот этот расчет очень сложный. Был в проектах с такой практикой. Но последние 3 расчет в часах, работает очень легко, понятно и просто.
В такой логике лиду в принципе довольно удобно будет рассчитывать срок выполнения задачи и назначить исполнителя. Оценили задачу в 5 СП, сдать нужно за неделю, понятно что назначить ее можно только на сеньера, только у него в неделю выйдет 5 СП сделать.
У меня не выходит примерить это на свое управление. Обычно считаю сколько влазит часов на исполнителя в часах за спринт, и по ним распределяется.
Выглядит логично и красиво, но:
А что у нас собственно с декомпозицией? А она у нас тоже субъективна. И более того, иногда что бы декомпозироать, нужно смотреть в код, который на совещании совсем не под руками. А иногда еще и пару предварительных рефакторингов выполнить, что бы ПОСЛЕ стало понятно, можно ли вообще сделать эту чертову задачу и сколько еще с ней возиться. А на бумаге, да, красивый графичек конечно нарисуют...
Метод декомпозиции, о котором я рассказал, добавляет прозрачности и объективности в оценку задач. Важно помнить, что она ценна не сама по себе, а только когда на ее основе вычисляются сроки или перформанс сотрудников.
Декомпозиция ценна и сама по себе, имхо, позволяя на ранних этапах выявить подводные камни и недостатки в постановке задачи. Сделать среднюю\большую задачу без декомпозиции как-то не совсем возможно, просто тогда декомпозиция уже будет происходить на этапе выполнения задачи и каждый день будет увлекательным путешествием в Нарнию)
Вот как хочется, чтоб простым разработчикам / тестировщикам / аналитикам можно было просто работать и не ломать из-за этого голову. Но в реальности получается, что нам постоянно приходится подстраиваться под вечно меняющиеся процессы. Где-то ты понимаешь, что они принесут пользу. Но вот изменения способов оценки - если честно, достали, и разницы особой не видно.
Мы то можем оценивать задачи и оценим, если надо. Примерно. Очень примерно. Потому что с опытом понимаешь, что любая фигня может пойти не так, даже если это только что работало, и ты с этим просидишь пол дня, разбираясь. И ты все сильнее хочешь донести, что тут не учтены риски, что в этой задаче много неопределенностей. А иногда вообще из задачи - 2 строчки в Jira, и ни-че-го не известно из того, что там будет. Но оценку давай, придумывай.
Просто эта тема оценок уже настолько надоела. Разные компании, руководство, чего только не было. И что, у кого-то получилось хорошо прогнозировать? Неа.
Сначала был опыт оценки с покером, потом были story points, потом часы, потом снова story points, потом ничего, потом майки и т.д.. И всегда был риск не уложиться в спринт, и часто не укладывались.
И та же декомпозиция. Да, это прекрасная штука. Я ее очень люблю. Особенно когда заранее задачу декомпозирует опытный разработчик, чтоб джуны не кидали MR по 2 тысячи строк. Но и она не решает всех проблем.
Вот только недавно была задача, которую прекрасно разделили на 4 логических пункта. С виду вообще просто. Там чуть-чуть, там чуть-чуть. В итоге из 4 только 1 пошел по плану, а все остальные оказались в разы сложнее.
Так что, как ни крути, но кроме каких-то очень типовых задач, всё это оценивание - пальцем в небо.
В реальности много неизвестных:
Чтобы декомпозировать задачу - надо знать, что нужно сделать
Чтобы знать, что нужно сделать - надо добиться внятных требований и провести анализ
На выходе получим некое техническое решение
(на эти первые пункты уже надо потратить время и оценить его в SP / часах)
(тут начинается статья)
Техническое решение уже можно разбить на мелкие задачи
Конкретный программист кодит, по нему считают индивидуальный коэффициент конвертации SP > часы
(тут статья заканчивается)
Теперь это все надо протестировать - функциональное, регрессионное, нагрузочное и т.п. Если продолжать аналогию - как только яму раскопали, должен прийти отдельный человек и оценить качество - а достигнута ли нужна глубина?
(где учитываются стори поинты на тестирование и где формула конвертации в часы?)
Каким образом программист и тестировщик может оценить свою часть работы в SP, если у него нет анализа, тест кейсов? В итоге все равно приходим к формуле "что сказал программист" умножить на 'пи' и на 'е' ?
ИМХО вся эта видимость демократии, в разработке хороша только пока у людей куча энтузиазма и у бизнеса куча денег. А потом она всегда приводит к боли, обидам, зависти, потере мотивации и выгоранию.
Руководил командой, и пришел к выводу, что оценивать должен лид. В деталях это выглядит так. Есть спринт, команда и бэклог. Тимлид "чувствует" команду и ее возможности из опыта. Он обсуждает кто какие задачи может взять с таким расчетом, чтобы команда уложилась в спринт. Ротация задач приветствуется но не является обычной практикой (специализация по задачам скорее норма). При этом периодически в некоторые спринты лид предельно пессимистичен относительно возможностей команды, исходя из стратегии что лучше взять меньше, но точно сделать. В этом случае все заканчивают раньше, смотрят на следующие задачи и счастливы что превзошли ожидания. После такого спринта лид предлагает быть амбициозные, взять больше задач. Все рвутся в бой, могут не уложиться, но все равно довольны собой - это было амбициозно, мы почти смогли. Дальше опять нужен реалистичный спринт, и так идём к цели.
Минус здесь один - лиду трудно.
Плюсов масса. Во первых, это предсказуемые сроки разработки. Есть один конкретный мозг - мозг лида, ощущающий возможности команды. Он способен взять ответственность за сроки перед менеджментом и берет ее на себя. А девелоперы напротив ду зе бест и не паряться.
Во вторых, лид обсуждает возможность сделать задачу за спринт с каждым отдельно, исходя из текущего предположения кто за нее возмется. В этом случае члены команды хотят произвести впечатление и взять больше, а лид может быть реалистом. В конце лид либо прав, либо приятно удивлен. В обоих случаях девелопер мотивирован, потому что он либо соответствовал ожиданиям, либо превзошел их. Самое важное - члены команды не конкурируют и не завидуют, а сосредоточены на работе которая им досталась в спринт, чтобы впечатлить результатами лида и менеджмент.
Это по сути старая схема с "начальником". Но в ней люди были готовы добровольно работать и вечером и в выходные, чтобы сделать все что запланировано, порадоваться и пойти дальше. А когда я насмотрелся на сторипоинты и "все члены команды равны", это без слез не вспомнишь.
Оценка всегда вопрос непростой. Некоторые люди оценивать работу очень не любят, и часто приходится изрядно поработать, объясняя, что, дав ту или иную оценку, человек не несёт за неё жёсткой ответственности. И некоторым командам в моей практике это было очень непросто объяснить. Если применяется оценка остатка работ для построения burndown, совсем сложно.
Тем не менее, обычно я настаиваю на оценке и на оценке остатка на дейли. Естественно, не микроменеджмента ради (чего некоторые боятся), а для контроля того, успеваем ли, не надо ли что-то неважное выкинуть и т. п. О проблеме всегда комфортнее узнать заранее. То же, как каждый работает, команде обычно видно и так, для этого не надо портить жизнь всем микроменеджментом.
А вот к тому, как объяснять стори-поинты, я в итоге сформировал такой подход, что говорю, что это идеальные человеко-часы. Для расчёта длины спринта при этом вводится некий волшебный коэффициент, равный стоимости стори-поинта в человеко-часах. В качестве стартового значения я рекомендую 1.5, а обычно он в итоге колеблется от 1.3 до 1.8, точному вычислению не подлежит (точные вычисления тут вообще, имхо, утопия), подбирается экспериментально. Ошибок при оценке всегда много, но если оценка не является совсем бредовой, сумма оценок задач в спринте имеет распределение, сильно отличающееся от распределений оценок отдельных задач. Известно, что сумма многих равномерно распределенных случайных величин имеет распределение с острым пиком в середине, и чем этих величин больше, тем больше шансов на получение предсказуемой суммы. Если же исходные величины распределены не совсем равномерно и всё-таки имеют какой-то максимум в районе верной оценки, то с суммой всё обычно совсем хорошо.
Декомпозиция -- неплохой способ, и её в любом случае стоит делать, но всё-таки трудоемкость отдельных задач часто сильно варьируется. После декомпозиции я рекомендую обычно оценивать части.Вот с чем бывает очень много проблем -- это с тем, что даже в кросс-функциональной команде обычно нет такого, что люди кросс-функциональны. Те же тестировщики -- отдельный ресурс. В итоге я часто советую давать не одну оценку задаче, а две (бывает и больше, м но чаще всего две). Тут, правда, надо потратить ещё немало усилий, чтобы загрузить тестировщиков (обычно работающих после разработчиков) равномерно -- это отдельная повесть о куче хитрых трюков, вплоть до впихивания в спринт задач, которые никто не планирует довести до протестированности и деплоя: они должны быть реализованы в этом спринте и загрузить тестировщиков на начало следующего.
В общем, это мир таких плясок с бубном, что даже программирование как таковое бледнеет.
Блин, почему бы не заменить эти все стори поинты на аукцион? Каждый говорит - сделаю за столько $ и столько времени, тимлид/менеджер решает кому отдать. Ставки у друг друга никто не видит. Не успеваешь - кранчуй самостоятельно либо заранее оговоренное уменьшение стоимости. Сюда же можно и про баги добавить.
А так получается игра, где каждый пытается исхитриться чтобы тратить меньше и получать больше.
Есть смутное ощущение что planning pocker не был консенсусом изначально.
А как это в команде должно работать и на пуле задач? Аукцион пока не закончатся свободные разрабы приведет к тому что первые задачи разберут те, кто предложит сделать быстрее. В итоге последний чел может назвать вообще любой срок - задача ему достанется. У других вариантов другие проблемы.
Нету такого понятие последний чел, тут идет от того, что есть бэклог задач и кто быстрее сделает свою - быстрее возьмет следующую (если ему нужны деньги). А если никому неинтересно - значит задачи недооценены.
кто быстрее сделает свою - быстрее возьмет следующую
Получается оценка денег и оценка времени отдельные независимые оценки, правильно? Тут много проблем - что написано в трудовом договоре, как у продажников минимальный оклад и остальное премия по результатам? На такое никто не согласится. А если и найдутся отчаянные, то есть другие проблемы. Сложные и муторные задачи никто брать не будет, возни много, выхлопа мало. Да и банально договориться работникам никто не мешает для завышения цены.
Y2У менеджера наконец появится работа с реальным влияннием на стоимость проекта и дохода - разбить и уточнить задачи так,ятобы они не казались муторными. Деньги и время связаны - если задача закончена за X1 времени - платится y1 денег, если за x2 - y2. Договориться никто не мешает, но так же никто не мешает иметь сустроить конкуренцию
Работать даже в теории сможет только для типовых задач, про которые все понятно. А чинить какой-нибудь мутный баг, который толи день, толи неделю никто не будет. Любая работа связанная с третьей стороной аналогично. Задачи будут сдаваться кое-как, главное закрыть побыстрее, на возможные баги пофиг. Хотя баги даже хорошо - дополнительный доход от их исправления.
У менеджера наконец появится работа с реальным влияннием на стоимость проекта и дохода
Кто ж менеджеру разрешит влиять на стоимость проекта? Не, если он сможет его удешевить, то конечно. А если бюджет придется раздувать, то тут уже будут проблемы)
Все равно всё в итоге держится на мнении опытных разработчиков\аналитиков\тестировщиков. Играйте вы хоть в покер, хоть в подкидного.
Ещё ни разу не видел примера, когда story-points облегчали кому-то работу. Как усложняли, например, вводили дополнительную головоломку лидам, как в это пишете, - видел.
По-моему, достаточно один раз в команде ввести привычку оценивать задачи. Разумеется, единицы измерения надо брать из системы Си. Но дело не поинтах и майках, дело в том, рефлексируют ли разработчики результаты своей работы или нет. А если они начинают это дело, то майки не нужны, это эрзац.
Мы никогда не знаем, сколько времени займёт решение поставленной задачи.
Но мы имеем достаточно неплохое интуитивное представление о том, насколько сложной кажется эта задача судя по её описанию и исходя из практического опыта.
Почему, имея неплохое представление о сложности задачи, мы не можем назвать срок её решения?
А вы откройте ваш трекер и посмотрите, сколько времени НА САМОМ ДЕЛЕ занимало решение задач, изначально оцененных в N попугаев, где N - любое число, не сводящееся в конечном итоге к одному-двум часам. Что вы получите на выходе, неужели цифру? А вот и нет, вы получите диапазон цифр, примерно соответствующий нормальному распределению.
Это по факту будет так, а факты - очень упрямая вещь. Вот и скажите мне - как, прекрасно зная это, вы можете продолжать требовать в качестве ответа ЦИФРУ? Какую именно, блин, цифру? Среднюю? Девяностопроцентный персенталь? Девяностодевятипроцентный персенталь?
И почему вы вообще требуете эту цифру от технических специалистов-то? У Project Manager-а доступа к Jira нет, он сам получить нормальное распределение не может? А ведь это самое распределение и есть - единственно возможный, честный и точный ответ. Всё остальное - ложь.
И для чего эта цифра вообще нужна? Для какого такого планирования? Планирования по одной задаче? А зачем такое планирование нужно-то? Планировать нужно не одну отдельно взятую задачу, а scope этих самых задач. И вот именно для такого планирования вам и нужно честное распределение вероятностей, а не взятые с потолка субъективные цифры сомнительного качества. Потому что именно по такому, качественному набору данных, вы и можете построить свой реальный план с любой требуемой в вашем случае точностью (иными словами - с допустимым в вашем конкретном случае риском срыва планов).
Вроде бы это так просто?
Оценка задач в сторипоинтах по их декомпозиции: метод, который наконец-то работает