« Rev
@agile_ru   127
Fwd »


Anonymous
то есть без четко назначенного ответственного нельзя посчитать трудозатраты?)
Мне приходилось делать расчёт приблизительный без определения конкретного человека на определённый вид работы
Anonymous
Например, аналитика столько дней, тестирование стока и программирование того то того столько
Denis
А технический долг так совсем корнями в банки чешит
Михаил, "технический долг" — это стандартный термин в разработке
Denis
Но как термин в книге, возможно, для нетехнарей — использовано явно неуместно
Dmitry
Например, аналитика столько дней, тестирование стока и программирование того то того столько
или еще лучше "выполнить эту фичу" – столько ибо нам тестирование отдельно ничего не даст)
Anonymous
Михаил, "технический долг" — это стандартный термин в разработке
Денис, не спорю, но в обороте речевом мне ни разу не приходилось применять/слышать
Anonymous
И то, что прилагательное слово технический не означает, что термин сам по себе технический
Denis
Там много мелкой кривизны в словах
Denis
В беклоге не технический долг, а задачи по его устранению, например
Denis
Ну поэтому я её и не написал. Но там в сумме таких мелочей полно, поэтому и непонятно, нафига "научред" взялся пояснять, если только запутал
Anonymous
Рефакторинг, наверное, можно отнести к задачам тех долга
Denis
Михаил, интересная вы личность)
Denis
В чатике про продукты вы не знаете, что такое retention
Denis
В чате про agile — что такое технический долг
Anonymous
Но мне понятие само по себе не нравится тех долг, программная система растёт и развивается, а значит поддерживающий кодинг необходим, потому что так естественно и при чём тут долг
Denis
А рассуждаете с редким рвением
Dmitry
дамы и господа
Dmitry
на сколько правильно и эффективно просить трекать время людей в проекте
Dmitry
?
Anonymous
Ну как же хочу всё знать
Dmitry
мотивируют сверху тем
Dmitry
что якобы хотят замерить сколько какие задачи по времени занимают
Anonymous
ммм.. Зачем?)
Вполне возможно кто то из руководителей желает понимать степень в погрешности оценки трудозатрат
Стас Щетинников
Ну как же хочу всё знать
тратить силы на внедрение, чтобы просто знать - как лихо)
Dmitry
я не троллю, просто надо до первопричины докопаться)
Dmitry
люди не попадают в сроки
Dmitry
видимо хотят прозрачность какую-то
Игорь
что якобы хотят замерить сколько какие задачи по времени занимают
попробовали и отказались от этой идеи, считайте задачи в сторипойнтах, нарабатывайте статистику после каждого релиза и будет вам счастье и сроки не будут просираться
Dmitry
тут строго именно уже логгирование
Dmitry
вот первый день ввели
Dmitry
я читал не раз что это якобы мало эффективно
Dmitry
вот и решил у вас уточнить
Dmitry
Ну, в смысле, если это просто указ свыше, то не понятно чего обсуждать Если это идея по решению проблемы "люди не попадают в сроки", то это мало эффективно, есть другие способы
Dmitry
указ сверху
Dmitry
Для чего это нужно? Наша компания разрослась и мы сейчас одновременно работаем над более чем 60 проектами, связанными с развитием платформы или выполнения кастомизаций тех или иных функций для наших заказчиков.При таком большом объеме работы нам крайне важно понимать, эффективны мы или нет - например, много ли времени мы тратим на исправление дефектов в тех или иных модулях (а значит, возможно, эти модули требуют редизайна, чтобы прекратить постоянно чинить одно и то же) или же насколько трудозатратным является разработка новых функций из-за того, что какая-то часть модулей системы разработана неоптимально, - эта информация могла бы очень помочь нам планировать дальнейшие развитие платформ, продуктов и всей компании.Но сейчас информация о том, сколько и на что инженеры (то есть ключевые сотрудники компании) тратят времени - крайне субъективна и собирается несистемно (иными словами, руководители команд имеют только лишь мнение о том, кто на что потратил время), поэтому - эти знания нам не помогают работать.Поэтому мы приняли решение о том, что нам всем очень важно систематизировать сбор информации о том, на что мы все тратим свое рабочее время и ввести систему его учета.Важные принципы, на которых базируется процесс учета: Цель - не контролировать "с палкой" то, чем занимается каждый разработчик, тестировщик или инженер, а наладить сбор информации о реальных трудозатратах, чтобы выявлять слабые или неэффективные места в компании и устранять их Нет необходимости списывать все с точностью до минуты, степень детализации определяется по договоренности с вашим менеджером Регулярность - рабочее время нужно списывать периодично, не реже раза в неделю Овертаймы и премии будут оплачиваться только при наличии учтенного времени в системе
Dmitry
Ну вот собственно, все ответы на вопросы из "Для чего это нужно?" можно добыть без внедрения логгирования времени В 95% случаев такое внедрение означает лишь степень недоверия между руководством и исполнителями. При этом я знаю случаи, когда логгирование времени было полезно, вот только оно было инициировано самими разработчиками, а это уже совсем другая история)
Dmitry
о чем и речь
Игорь
Для чего это нужно? Наша компания разрослась и мы сейчас одновременно работаем над более чем 60 проектами, связанными с развитием платформы или выполнения кастомизаций тех или иных функций для наших заказчиков.При таком большом объеме работы нам крайне важно понимать, эффективны мы или нет - например, много ли времени мы тратим на исправление дефектов в тех или иных модулях (а значит, возможно, эти модули требуют редизайна, чтобы прекратить постоянно чинить одно и то же) или же насколько трудозатратным является разработка новых функций из-за того, что какая-то часть модулей системы разработана неоптимально, - эта информация могла бы очень помочь нам планировать дальнейшие развитие платформ, продуктов и всей компании.Но сейчас информация о том, сколько и на что инженеры (то есть ключевые сотрудники компании) тратят времени - крайне субъективна и собирается несистемно (иными словами, руководители команд имеют только лишь мнение о том, кто на что потратил время), поэтому - эти знания нам не помогают работать.Поэтому мы приняли решение о том, что нам всем очень важно систематизировать сбор информации о том, на что мы все тратим свое рабочее время и ввести систему его учета.Важные принципы, на которых базируется процесс учета: Цель - не контролировать "с палкой" то, чем занимается каждый разработчик, тестировщик или инженер, а наладить сбор информации о реальных трудозатратах, чтобы выявлять слабые или неэффективные места в компании и устранять их Нет необходимости списывать все с точностью до минуты, степень детализации определяется по договоренности с вашим менеджером Регулярность - рабочее время нужно списывать периодично, не реже раза в неделю Овертаймы и премии будут оплачиваться только при наличии учтенного времени в системе
ой, ну банально же можно в jira навесить эпиклинки на таски и баги и собирать статистику над какими модулями разработчики корпят больше всего, время заменить на очки (оценивайте сложность таска), внедрение сбора времени - худшее, что можно придумать в этом случае
Slava
В бар!
Dmitry
спасибо за ответы) но если кто еще что добавить может - буду рад выслушать мнение
Slava
Если вы трекаете время, вы можете эффективность потока посчитать
Slava
это затраченное время на задачу поделенное на её lead time
Slava
эффективность потока офигительная метрика
Dmitry
Слава, но тут же не про лид-тайм речь)
Slava
"на сколько правильно и эффективно просить трекать время людей в проекте"
Slava
вот вопрос
Dmitry
но смотри, ситуация такая, что кто-то пошел покурил, пообедал итд итп и прочее...а потом таску сделал за 10 мин, но ставит час, потому что тратил на что-то...условно я привожу пример, получается что человеческий фактор, люди добиваются трекания 8 часов, вместо реального объема
Dmitry
Лид-тайм меряется любыми инструментами из коробки
Slava
ой забейте
Slava
это не про agile
Slava
agile про доверие
Dmitry
вот-вот
Slava
Дима эффективность потока не лид таймом мереется
Slava
а затраченным / lead time
Dmitry
вот о чем и речь, все будут врать и скрывать свои посиделки в инете
Dmitry
поэтому я вот думаю мало эффективно это
Dmitry
но решил заручиться и вашим мнением тк одна голова ок, но две лучше
Slava
тут работают всякие штуки типа программы делающие скриншоты, но это уже очень далеко от этого чата
Slava
на практике разработчик либо молодец, либо не молодец
Slava
;)
Dmitry
так вот я привык к доверию)
Dmitry
а это как то так душит меня)
Dmitry
просто по причине того, что это какое-то недоверие
Slava
чтоб не душило, надо вылезать из тасков на бизнес уровень
Slava
и управлять не тасками, а ценностью
Slava
а то так и будете менеджить не молодцов
Dmitry
я эту ценность несу для компании невооруженным взглядом, поэтому как раз я и возмущен
Dmitry
почему я иду extra милю, а в ответ должен трекаться
Anonymous
и управлять не тасками, а ценностью
В смысле управлять ценностью, но не без тасков наверное
Slava
в смысле формулировать бизнес задачи
Slava
и разработчикам говорить про бизнес
Slava
у вас бэклог бэклогом называется?
« Rev
@agile_ru   127
Fwd »