Комментарии 10
Расскажите, как вы оцениваете трудоемкость задач?
Добрый вечер, в большинстве команд оценка идет по Story Points
Очень плохо, потому что Story Points - это не трудоемкость, а сложность задачи - очень грубая методологическая ошибка.
В этом мире, каждый кто считает Story Points трудоемкостью и приравнивает ее к часам труда, заслуживает смачного леща за элементарную безграмотность.
"Очень интересная" интерпретация методологии оценки. Story Points действительно не выражаются напрямую в человеко-часах, но вот только термин "трудоемкость" – это не синоним "количества потраченных часов"
Трудоемкость – это совокупная оценка усилий, необходимых для выполнения задачи, с учетом сложности, рисков и неопределенности. Это именно то, что измеряют Story Points. Они включают не только сложность, но и объем работы, возможные блокеры, зависимые задачи – то есть всю совокупность факторов, влияющих на выполнение.
Спасибо большое, с интересом почитал (впрочем, я это и раньше знал). Но как вы руководству предоставите информацию, сколько будет стоить фича (или лучше - новая версия)? Не в sp, не в баллах и не в попугаях. В баксах, или в килобаксах. На худой манер, в тысячах рублей. Вот заказчик описывает нужные ему фичи (на уже поставленном им приложении). Там документ на сто пунктов, описанных кривым языком. И нужно решить, какую сумму выкатывать на торге.
Вот в чем драма, понимаете?
Я работал в реальном производстве, и там уже с начала века (прошлого, если не позапрошлого, блджад!) отработаны механизмы экономического планирования и ценообразования.
И уже двадцать пять лет, что я в IT, я хожу и ищу вменяемого человека, который бы рассказал, как можно оценить себестоимость разработки.
Добавлю. Ваше определение противоречит устоявшемуся уже двести лет определению трудоемкости https://ru.wikipedia.org/wiki/Трудоёмкость, давайте не будем сочинять отсебятину. Меряется она в человеко-часах, на определенную операцию и с определенной квалификацией исполнителя.
Меня интересовало трудоемкость именно в экономическом смысле - сколько потребуется разработчиков джунов, мидлов, сеньоров, постановщиков, тестеров, техподдержки для реализации данной версии и соответственно, сколько потребуется бабла и времени при наличии имеющегося количества кадров.
Понимаете, в чем драма. Не имея информации о том, какая трудоемкость (плановая!), скажем тестирования одной фичи, нет смысла говорить о мониторинге производительности (производительность, кстати, обратная величина трудоемкости). Как вы решите, высокая производительность или низкая у данной команды и конкретного человека?
Спасибо за содержательный комментарий!
Вы абсолютно правы, что трудоёмкость исторически измеряется в человеко-часах. И со времен Карла Маркса (1867 г.) это понятие не претерпело изменений и для большой части экономик остается актуальным. Главный вопрос, который стоит задать: "Закладывалась ли туда оценка интеллектуальной работы?". В попытках оценить себестоимость разработки мы стремимся получить тотальный контроль над интеллектуальными ресурсами, постоянно терпим провал, и возникает вопрос: "А это точно нужно?".
Обратите внимание, что в статье цель не оценить производительность человека: все метрики нацелены на то, чтобы понять состояние процессов и вовремя точечно реагировать на отклонение. Стремление управлять процессами, и видеть эффект от изменений - вот главная цель.
И если бы кто-то нашел ту серебряную пулю по которой можно с точностью прогнозировать человеко-часы на получение результата команды разработки, мы бы не знали о существование такого пункта в договоре: "Сроки выполнения работ являются ориентировочными и могут быть изменены при наличии объективных обстоятельств, включая изменения требований Заказчика, технологические риски или иные факторы"
Возможно, что и за следующее 25 лет мы так и не найдем ответа на вопрос как оценить себестоимость разработки. И все подходы, которые были придуманы на границе 00х, станут не актуальными. Придут новые адепты и будут масштабировать свое видение в попытке повысить % точности оценки, но прогнозировать на 100% срок и как следствие стоимость мы все равно не сможем.- Понимаете, в чем драма?
Монументальная статья. Жаль, что мало просмотров и комментариев.
мы строим команды по принципу кроссфункциональности, свои тестировщики есть в каждой из 30+ команд.
Изначально хотел написать, что зачем вам всё это, если у вас кросcфункциональные команды и Agile. Но потом прочитал всю статью и понял, что вы достаточно глубоко зарылись в тему и полученные данные используете для многих бизнес-процессов. Честно, сомневаюсь, что найдётся хотя бы пару компаний, которые смогут повторить то же, что реализовали вы. В общем, молодцы. Респект!
Для тех, кто работает в Jira, можно использовать Kanban DashBoards, чтобы получить информацию по всеми тикетам в нужном проекте. Там будет сразу видна нагрузка на каждого человека, зависшие в workflow задачи, слишком много одновременно выполняемых задач, таски, которые обратно возвращаются к исполнителю и прочее. Jira также поддерживает мощные поисковые фильтры и PowerShell, т.е. можно создавать любые выборки и делать это автоматически. Если вместо Jira используется другой таск трекер, то ситуация сильно усложняется и требуется уже писать свои инструменты для выгрузки и визуализации данные, как это сделал автор статьи.
Например, в случае с одной из наших команд следование рекомендациям позволило сократить скорость выкатки релизов в 15-16 раз.
А точно сокращение скорости выкатки релизов хорошая идея?
А точно сокращение скорости выкатки релизов хорошая идея?
Приветствую.
У меня встречный вопрос: а чего бы этой идее быть плохой?
Теперь постараюсь развернуть, как это выглядит у нас. Как указано в статье, именно "следование рекомендациям позволило сократить скорость выкатки релизов". То есть: мы не урезаем какие-то этапы жизненного цикла задачи, мы не отдаем на откуп командам голые факты по типу "Кажется, у тебя тут проблема. Как хочешь, так ее и решай" и тд. Как только замечаем аномалию, первым делом исследуем вопрос. После того, как мы подтвердили какую-то гипотезу, мы отдаем команде готовую рекомендацию, которая включает в себя либо лучшие практики внутри компании, либо аналогичные решения проблем на основе рыночных решений, либо, если такого не нашлось или нам не подойдет, делаем свой подход, которой способен данную задачу решить.
А следование этим рекомендациям само по себе дает такой эффект. У нас есть аналогичные кейсы, когда мы чинили процесс на ранних этапах, а по итогу получали на его фоне еще и прирост к скорости доставки фич на 2/3, помимо выправления фокусного аспекта. Резюмируя: мы улучшаем процессы органично, не гонясь за формальными показателями, а добиваясь реальных улучшений.
Своим комментарием я хотел отметить, что вы тут ошиблись видимо, а имели в виду увеличение скорости выкатки релизов.
Если бы вместо слова "скорости", использовали слово "времени", то все было бы ок ;)
А так я согласен с вами, подход рациональный к решению данной задачи. Главное есть положительный эффект.
Как видеть всё: внедряем простой мониторинг производительности в командах (на примере QA)