Приветствую. Я дико извиняюсь за путаное изложение, вызывающее разногласия.
Давайте уйдём от термина "менеджер", который означает что угодно, и придём к термину "product owner" (или [внутренний] заказчик). ПО - это человек, который принимает конечные решения о том, ЧТО и ЗАЧЕМ мы делаем (но не КАК мы это делаем - это уже должна решать команда). У него нет цели "нагнуть команду". У него есть цель "выпустить как можно больше фич как можно быстрее". Если у него такой цели нет - команда идёт на мороз, вместе с вылизанным и круто сделанным, но никому не нужным продуктом. Вот для этого человека рефакторинг или написание внутренних тулзов - потерянное время (в течение которого можно бы было пилить фичи). Если он нормальный человек, а не погонщик волов, он в принципе понимает, что это тоже нужно делать. Но в принципе. А данная тулза, как мне кажется, могла бы немного облегчить здесь взаимопонимание команды и owner-а. Ну и плюс возможность увековечить свои печали по поводу кода предшественников в полезном для остальной команды виде, а не в качестве гифки на developerslife.ru 2016-10-05 20:26 GMT+03:00 [email protected] <[email protected]>: > В классическом скраме, насколько я помню, скрам мастер обычно часть - > команды. То есть он про этот технический долг знает и может его оценить. > > Я говорил про то, что если в процессе разработки решения принимает > технически неграмотный человек, особенно который "любит графики", и/или > если команда не может объяснить необходимость этих работ, то что-то не так > в менеджере и, может быть, в команде. В менеджере - так как он такое > допустил, как минимум. > > > Среда, 5 октября 2016, 20:12 +03:00 от Ilya Chesnokov < > [email protected]>: > > > 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 > > > > -- > 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
