В классическом скраме, насколько я помню, скрам мастер обычно часть - команды. То есть он про этот технический долг знает и может его оценить.
Я говорил про то, что если в процессе разработки решения принимает технически неграмотный человек, особенно который "любит графики", и/или если команда не может объяснить необходимость этих работ, то что-то не так в менеджере и, может быть, в команде. В менеджере - так как он такое допустил, как минимум. >Среда, 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
