5 октября 2016 г., 15:02 пользователь [email protected] <[email protected]> написал: > А я правильно понимаю, что у вас за техническую часть отвечает менеджер, > который не является техническим специалистом и, тем более, не знает что > творится в коде, так как не "сопровождает" его? И вы должны доказывать ему > что это "надо"? > > Если это так, то не кажется-ли вам что в этой схеме что-то сломалось?
А что именно? В Скраме вот, например, вообще нет менеджера. Есть продакт оунер, скрам мастер и команда разработки. И кто из них должен знать что творится в коде и рассказывать о техническом долге? Правильно, сама команда. > Среда, 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 > -- Best regards, Ilya Chesnokov -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
