[Moscow.pm] Potracheno: wasted time tracker

[Warstone@list.ru]

А я правильно понимаю, что у вас за техническую часть отвечает менеджер, который не является техническим специалистом и, тем более, не знает что творится в коде, так как не "сопровождает" его? И вы должны доказывать ему что это "надо"?

Если это так, то не кажется-ли вам что в этой схеме что-то сломалось?

>Среда,  5 октября 2016, 13:21 +03:00 от "Konstantin S. Uvarin" <khedin на gmail.com>:
>
>​Приветствую.
>
>Отлично сказано! Очень здравый подход, сам стараюсь так делать и другим советую. А обсуждаемый инструмент просто немного (как мне кажется) должен в этом помочь. 
>
>Вот у Вас
>
>>команда чувствует
>
>у меня считается точно - сколько вешать в граммах. 
>​(Адекватна ли эта оценка - другой вопрос - для того и бета).​
>
>И дальше
>
>>идет борьба бобра с ослом
>
>Менеджер любит отчёты, таблицы и графики - надо дать ему их! Графики, впрочем, у меня будут ещё нескоро. =)
>
>  
>
>2016-10-04 18:30 GMT+03:00  Warstone на list.ru < warstone на list.ru > :
>>Эм... А зачем так страшно?.. У нас, допустим, если техническая команда чувствует что надо сделать рефакторинг где-то она просто вносит время на этот рефакторинг в задачу, которая касается этого места и во все последующие, если текущая снимается. Соотв., если нету задачи, которая касается этих мест, то и рефакторить пока-что незачем. А дальше идет борьба бобра с ослом. Весь вопрос насколько менеджер может ставить раком команду. Но это вопрос не к инструментам, а к подходу к работе.
>>
>>>Вторник,  4 октября 2016, 16:34 +03:00 от "Konstantin S. Uvarin" < khedin на gmail.com >:
>>>
>>>
>>>Приветствую. 
>>>
>>>  Наверное, надо бы описать кейс, который у меня в голове.
>>>
>>>  Допустим, команда ноет, что продукт плохой внутри, что задолбалась 
воевать с багами и надо рефакторинг. Менеджер не видит проблемы: 
тикеты-то кое-как закрываются, а программисты - ну они всегда ноют. Или, если он 
подкован, говорит: хорошо, сделаем рефакторинг, но когда закроем текущие
 задачи. То есть никогда. Конфликт.
>>>
>>>  Я предполагаю, что 
"задолбались" имеет вполне конкретную оценку в человеко-часах (а, 
следственно, и стоимость в деньгах). Также я предполагаю, что есть 
конкретные проблемы у конкретных компонентов, которые если пофиксить - заметная часть этой задолбанности пропадёт. (По аналогии с узкими местами в производительности).
>>>
>>>  Соответственно, если менеджеру 
сказать "мы задолбались" - он ответит "иншалла, пилите Шура, пилите". Если сказать "мы 
протаптываем 20 человеко-часов в месяц из-за проблемы, решаемой за 10" -
 у менеджера в голове закрутятся шестерёнки. 
>>>
>>>  ЕСЛИ предположения верны, ТО обсуждаемый тул позволяет как раз собрать эту статистику. Больше он, собственно, никаких задач и не решает - собрали статистику, презентовали менеджеру, создали задачи на рефакторинг в Редмайне или Жире. Намылись, смыть, повторить.
>>>
>>>  (Замечу в скобках, что технический долг - это ещё и демотивация команды. Но это оценивать в деньгах давайте будем после того, как миелофон изобретут). 
>>>
>>>  Ну как-то так. Надеюсь, стало яснее, что это и зачем это.
>>>
>>>
>>>2016-10-04 11:32 GMT+03:00 KES  < kes-kes на yandex.ru > :
>>>>Вот хорошая штука  https://wakatime.com , чтобы смотреть в каких приложениях потратилось время.
>>>>Как по мне, очень хорошая интеграция с редакторами и браузерами:  https://wakatime.com/editors
>>>>
>>>>03.10.2016, 19:23, "Alexey Shrub" < worldmind на mail.ru >:
>>>>> On Пн, окт 3, 2016 в 4:01 , Konstantin S. Uvarin
>>>>> < khedin на gmail.com > wrote:
>>>>>>    Давно мечтал запилить трекер для
>>>>>>  учёта времени, продолбанного на
>>>>>>  борьбу с техническим долгом. И вот -
>>>>>>  выдалась минутка...
>>>>>
>>>>> Идея шикарная, хотя требует
>>>>> привычки/дисциплины от разработчика.
>>>>> Но не уверен насчёт отдельной тулзы,
>>>>> получается надо и в обычную таску
>>>>> время вписать и в тикет просраченного
>>>>> времени - дублирование, нарушение DRY.
>>>>> В идеале надо конфигурить/плагинить
>>>>> популярные таск-трекеры (redmine какой)
>>>>> так, чтобы можно было при вписывании
>>>>> времени указать тип - просраченное, а
>>>>> потом глядеть в отчёте по затраченному
>>>>> времени сколько полезной активности
>>>>> было, а сколько не очень.
>>>>> Плюс надо привязывать просраченное
>>>>> время к компоненту и виновному
>>>>> разработчику, чтобы потом по
>>>>> статистике видеть кого в первую
>>>>> очередь рефакторить.
>>>>> --
>>>>> Moscow.pm mailing list
>>>>>  moscow-pm на pm.org |  http://moscow.pm.org
>>>>--
>>>>Moscow.pm mailing list
>>>>moscow-pm на pm.org |  http://moscow.pm.org
>>>
>>>
>>>
>>>-- 
>>>Konstantin S. Uvarin
>>>jabber: see <from>
>>>skype: kuvarin
>>>http://github.com/dallaylaen
>>>-- 
>>>Moscow.pm mailing list
>>>moscow-pm на pm.org |  http://moscow.pm.org
>>
>>
>>--
>>Moscow.pm mailing list
>>moscow-pm на pm.org |  http://moscow.pm.org
>>
>
>
>
>-- 
>Konstantin S. Uvarin
>jabber: see <from>
>skype: kuvarin
>http://github.com/dallaylaen
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20161005/ffb92365/attachment-0001.html>