[Moscow.pm] Potracheno: wasted time tracker

Чт Окт 6 01:07:01 PDT 2016

5 октября 2016 г., 20:26 пользователь Warstone на list.ru
<warstone на list.ru> написал:
> В классическом скраме, насколько я помню, скрам мастер обычно часть -
> команды. То есть он про этот технический долг знает и может его оценить.
>
> Я говорил про то, что если в процессе разработки решения принимает
> технически неграмотный человек, особенно который "любит графики", и/или если
> команда не может объяснить необходимость этих работ, то что-то не так в
> менеджере и, может быть, в команде. В менеджере - так как он такое допустил,
> как минимум.

Вы так говорите, как будто "менеджер - мудак" - это просто невозможная
ситуация в реальном мире :-)

Менеджер может быть безграмотен, не понимать цели рефакторинга, может
лизать зад заказчику, может быть ему лень. Может не понимать реальной
ситуации и насколько все запущено.
В конце концов, вы сами можете оказаться этим менеджером, и вам
придется объяснять заказчику, чем именно занимается команда и за что
заказчик платит деньги. В этом случае такое значение как количество
часов, потраченное впустую, может оказаться очень кстати для оценки
ситуации.

>
> Среда, 5 октября 2016, 20:12 +03:00 от Ilya Chesnokov
> <chesnokov.ilya на gmail.com>:
>
>
> 5 октября 2016 г., 15:02 пользователь Warstone на list.ru
> <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
>>
>>
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
>
>
> --
> Best regards,
> Ilya Chesnokov
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

-- 
Best regards,
Ilya Chesnokov