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