<HTML><BODY>В классическом скраме, насколько я помню, скрам мастер обычно часть - команды. То есть он про этот технический долг знает и может его оценить.<br><br>Я говорил про то, что если в процессе разработки решения принимает технически неграмотный человек, особенно который "любит графики", и/или если команда не может объяснить необходимость этих работ, то что-то не так в менеджере и, может быть, в команде. В менеджере - так как он такое допустил, как минимум.<br><br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
Среда, 5 октября 2016, 20:12 +03:00 от Ilya Chesnokov <chesnokov.ilya@gmail.com>:<br>
<br>
<div id="">
<div class="js-helper js-readmsg-msg">
<style type="text/css"></style>
<div>
<base target="_self" href="https://e.mail.ru/">
<div id="style_14756875770000000885_BODY">5 октября 2016 г., 15:02 пользователь <a href="mailto:Warstone@list.ru">Warstone@list.ru</a><br>
<<a href="mailto:warstone@list.ru">warstone@list.ru</a>> написал:<br>
> А я правильно понимаю, что у вас за техническую часть отвечает менеджер,<br>
> который не является техническим специалистом и, тем более, не знает что<br>
> творится в коде, так как не "сопровождает" его? И вы должны доказывать ему<br>
> что это "надо"?<br>
><br>
> Если это так, то не кажется-ли вам что в этой схеме что-то сломалось?<br>
<br>
А что именно? В Скраме вот, например, вообще нет менеджера. Есть<br>
продакт оунер, скрам мастер и команда разработки. И кто из них должен<br>
знать что творится в коде и рассказывать о техническом долге?<br>
Правильно, сама команда.<br>
<br>
> Среда, 5 октября 2016, 13:21 +03:00 от "Konstantin S. Uvarin"<br>
> <<a href="mailto:khedin@gmail.com">khedin@gmail.com</a>>:<br>
><br>
><br>
> Приветствую.<br>
><br>
> Отлично сказано! Очень здравый подход, сам стараюсь так делать и другим<br>
> советую. А обсуждаемый инструмент просто немного (как мне кажется) должен в<br>
> этом помочь.<br>
><br>
> Вот у Вас<br>
><br>
>>команда чувствует<br>
><br>
> у меня считается точно - сколько вешать в граммах.<br>
> (Адекватна ли эта оценка - другой вопрос - для того и бета).<br>
><br>
><br>
> И дальше<br>
><br>
>>идет борьба бобра с ослом<br>
><br>
> Менеджер любит отчёты, таблицы и графики - надо дать ему их! Графики,<br>
> впрочем, у меня будут ещё нескоро. =)<br>
><br>
><br>
><br>
> 2016-10-04 18:30 GMT+03:00 <a href="mailto:Warstone@list.ru">Warstone@list.ru</a> <<a href="mailto:warstone@list.ru">warstone@list.ru</a>>:<br>
><br>
> Эм... А зачем так страшно?.. У нас, допустим, если техническая команда<br>
> чувствует что надо сделать рефакторинг где-то она просто вносит время на<br>
> этот рефакторинг в задачу, которая касается этого места и во все<br>
> последующие, если текущая снимается. Соотв., если нету задачи, которая<br>
> касается этих мест, то и рефакторить пока-что незачем. А дальше идет борьба<br>
> бобра с ослом. Весь вопрос насколько менеджер может ставить раком команду.<br>
> Но это вопрос не к инструментам, а к подходу к работе.<br>
><br>
> Вторник, 4 октября 2016, 16:34 +03:00 от "Konstantin S. Uvarin"<br>
> <<a href="mailto:khedin@gmail.com">khedin@gmail.com</a>>:<br>
><br>
><br>
> Приветствую.<br>
><br>
> Наверное, надо бы описать кейс, который у меня в голове.<br>
><br>
> Допустим, команда ноет, что продукт плохой внутри, что задолбалась воевать<br>
> с багами и надо рефакторинг. Менеджер не видит проблемы: тикеты-то кое-как<br>
> закрываются, а программисты - ну они всегда ноют. Или, если он подкован,<br>
> говорит: хорошо, сделаем рефакторинг, но когда закроем текущие задачи. То<br>
> есть никогда. Конфликт.<br>
><br>
> Я предполагаю, что "задолбались" имеет вполне конкретную оценку в<br>
> человеко-часах (а, следственно, и стоимость в деньгах). Также я предполагаю,<br>
> что есть конкретные проблемы у конкретных компонентов, которые если<br>
> пофиксить - заметная часть этой задолбанности пропадёт. (По аналогии с<br>
> узкими местами в производительности).<br>
><br>
> Соответственно, если менеджеру сказать "мы задолбались" - он ответит<br>
> "иншалла, пилите Шура, пилите". Если сказать "мы протаптываем 20<br>
> человеко-часов в месяц из-за проблемы, решаемой за 10" - у менеджера в<br>
> голове закрутятся шестерёнки.<br>
><br>
> ЕСЛИ предположения верны, ТО обсуждаемый тул позволяет как раз собрать эту<br>
> статистику. Больше он, собственно, никаких задач и не решает - собрали<br>
> статистику, презентовали менеджеру, создали задачи на рефакторинг в Редмайне<br>
> или Жире. Намылись, смыть, повторить.<br>
><br>
> (Замечу в скобках, что технический долг - это ещё и демотивация команды.<br>
> Но это оценивать в деньгах давайте будем после того, как миелофон<br>
> изобретут).<br>
><br>
> Ну как-то так. Надеюсь, стало яснее, что это и зачем это.<br>
><br>
><br>
> 2016-10-04 11:32 GMT+03:00 KES <<a href="mailto:kes-kes@yandex.ru">kes-kes@yandex.ru</a>>:<br>
><br>
> Вот хорошая штука <a href="https://wakatime.com" target="_blank">https://wakatime.com</a> , чтобы смотреть в каких приложениях<br>
> потратилось время.<br>
> Как по мне, очень хорошая интеграция с редакторами и браузерами:<br>
> <a href="https://wakatime.com/editors" target="_blank">https://wakatime.com/editors</a><br>
><br>
> 03.10.2016, 19:23, "Alexey Shrub" <<a href="mailto:worldmind@mail.ru">worldmind@mail.ru</a>>:<br>
>> On Пн, окт 3, 2016 в 4:01 , Konstantin S. Uvarin<br>
>> <<a href="mailto:khedin@gmail.com">khedin@gmail.com</a>> wrote:<br>
>>> Давно мечтал запилить трекер для<br>
>>> учёта времени, продолбанного на<br>
>>> борьбу с техническим долгом. И вот -<br>
>>> выдалась минутка...<br>
>><br>
>> Идея шикарная, хотя требует<br>
>> привычки/дисциплины от разработчика.<br>
>> Но не уверен насчёт отдельной тулзы,<br>
>> получается надо и в обычную таску<br>
>> время вписать и в тикет просраченного<br>
>> времени - дублирование, нарушение DRY.<br>
>> В идеале надо конфигурить/плагинить<br>
>> популярные таск-трекеры (redmine какой)<br>
>> так, чтобы можно было при вписывании<br>
>> времени указать тип - просраченное, а<br>
>> потом глядеть в отчёте по затраченному<br>
>> времени сколько полезной активности<br>
>> было, а сколько не очень.<br>
>> Плюс надо привязывать просраченное<br>
>> время к компоненту и виновному<br>
>> разработчику, чтобы потом по<br>
>> статистике видеть кого в первую<br>
>> очередь рефакторить.<br>
>> --<br>
>> Moscow.pm mailing list<br>
>> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
> --<br>
> Moscow.pm mailing list<br>
> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Konstantin S. Uvarin<br>
> jabber: see <from><br>
> skype: kuvarin<br>
> <a href="http://github.com/dallaylaen" target="_blank">http://github.com/dallaylaen</a><br>
> --<br>
> Moscow.pm mailing list<br>
> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
><br>
><br>
><br>
> --<br>
> Moscow.pm mailing list<br>
> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Konstantin S. Uvarin<br>
> jabber: see <from><br>
> skype: kuvarin<br>
> <a href="http://github.com/dallaylaen" target="_blank">http://github.com/dallaylaen</a><br>
> --<br>
> Moscow.pm mailing list<br>
> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
><br>
><br>
><br>
> --<br>
> Moscow.pm mailing list<br>
> <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
><br>
<br>
<br>
<br>
-- <br>
Best regards,<br>
Ilya Chesnokov<br>
-- <br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div>
<base target="_self" href="https://e.mail.ru/">
</div>
</div>
</div>
</blockquote>
<br></BODY></HTML>