Роман Ивлиев romas1982

Мы фул-стек не практикуем. Точнее как, ребята могут, но на работе ты или фронт или бэк. Не совсем понял про образование. Ты пришёл верстаком, умел хтмл и цсс, потом поработал, поучился, стал уметь Джаваскрипт. Почему косо будут смотреть?

Мы взяли по одному на команду и учим. Так что «никто» — спорный тезис. Верстаков в фронтов переучиваем вполне успешно.

Звучит так, что вас не повезло с руководителем и, возможно, компанией.

Я готов открыто признаться — я хочу получать максимум пользы при минимуме затрат. Чтобы кроме проектов можно было позаниматься развитием технологического стека, поработать с техдолгом и всем тем, что не приносит прибыль в явном виде, не работать сверх положенного, или в выходные, когда внезапно выяснится, что проект просрали, а никто не в курсе.

И выжимать при этом я никого не хочу, пооому что разбегутся или начнут хачить систему по закону, который коллега привёл ниже.

Работник вообще ничего не знает про бОльшую часть метрик. Они нужны для калибровки процесса. И комит в код это лишь одна из метрик для оценки!!! процесса!!.. Если у вас в этот конкретный модуль идут комиты сотнями, значит важность тестов возрастает. Если у вас Вася делает следующим комитом откат предыдущего с завидным постоянством — это повод понять, откуда растут ноги. Может ему требования меняют регулярно и надо дать по голове тому, кто требования носит, а может он тупо не может с первого раза прочитать корректно и его надо научить читать правильно. А может от затрахался и ему надо в отпуск.

Откуда такое маниакальное стремление во всем увидеть желание работодателя выжать все соки??? Инженер без соков больше ошибается и приносит меньше пользы. Если руководит адекватный менеджер, который умеет адекватно читать результаты измерений — все хорошо и все счастливы. А сдуру, как известно, можно сломать что-угодно.

Due date — инструмент планирования. В скраме инструмент планирования — велосити и капасити, что само по себе чистейшей воды метрики. А выход фич из спринта — метрика для ПМ, по ним он ориентируется на завершение проекта. ПМ в код вообще не должен смотреть. Для него важны проектные и процессные метрики, а не инструментальные. Инструментальные метрики важны для того, кто отвечает за разработку, для СТО, например. Точность и адекватность метрик — это сложный процесс, которым надо заниматься постоянно и калибровать, например, в случае, если сильно изменилась команда. Если подходить к процессу с умом, то кучу пользы можно извлечь от измерений. Причём для всех, а не только для кровавого бизнеса.

Мы на конференции про измерения говорили очень много именно для того, чтобы показать пользу, а не разрекламировать очередной инструмент для пыток.

некоторые — ничто иное как способ давление, способ заставить девелоперов работать больше, быстрее но при этом ещё и без потери качества.

Я бы сказал так: очень зависит от команды и периода ее становления. На начальном этапе можно тратить на коммуникации до 100%, а можно 50%. Все очень зависит. Я ориентируюсь по ситуациии в проекте и по ситуации в команде и варьирую процент времени на коммуникации. Бывает так, что команда уже устоялась и работает вместе давно, но в моменте может потребовать снова 100%. А бывают сложные проекты, там и 146% бывает. Среднее в этом вопросе очень стремная характеристика.

Вероятно, это все-таки не бесполезная ересь, да и контора тоже не такая уж паршивая. Многие стремятся там работать. Мне для понимания — какие конторы вы считаете не паршивыми? Попросим их рассказать, как и что устроено

Спасибо!

Автостопом по галактике

Ефрейтор никогда не был командой должностью, даже самой низшей. Может! временно! исполнять роль командира отделения. А так это лишь способ выделить хорошего солдата над плохими… Капрал — командная должность. Ближайший аналог — сержант. Только это.

Всегда есть место неинтересной и порой ненужной работе. Согласен с вами, что для спецов высокого уровня на интересных проектах наверняка это не нужно, но таких случаев куда меньше, чем других.

Все зависит от представления. В точных цифрах конечно не про уровень руководителя всей сотни, это не надо, но может быть полезно лиду, например. А в относительных цифрах и в виде динамики при наличие хорошего инструмента все видно замечательно и очень полезно. Гитлин по сути это и делает. Собирает кучу данных — хочешь — смотри детали, хочешь смотри динамику.

Баг багу рознь. Баг с прода меряют очень многие. Число зафейденых ревью коммитов также очень частая метрика.

Тут важно с умом подходить к измерениям и к выбору метрик. Если метрика будет «точность попадания в оценку», например, то с рестом уже не будет такой ситуации. То, что люди разные, ещё Дедушка Брукс доказал и показал, когда деревья были сильно меньше. Это факт. Принимать решения только на основе цифр, которые тебе дала спец.тулза или экселька — путь в ад. Но мерять однозначно нужно и анализировать результаты тоже.

Все так. Но с определенного момента такой метод перестаёт давать ответы на интересующие вопросы, либо даёт большую погрешность. И вот здесь уже приходится подбирать измерения под себя и свою команду.

Здесь акцент стоит сделать на «целый квартал» и «почти 100%». Для небольших проектов — это и правда часто страшилка из книжек, а для больших — суровая правда жизни.

Не совсем понял суть вопроса. Если говорить про конференции Бунина, то Евгений несколько раз выступал и является членом одного из программных комитетов. Так что вполне себе знаком участникам.

Согласен, но если начать интерпретировать и выравнивать кривые фразы, всегда есть шанс подменить смысл. В любом случае учту на будущее.

1. По опыту в большинстве проектов фиг кто даст выделить время и отдать часть итерации под техдолг. Почему-то считается, что это вообще не проблемы бизнеса. Мы пробовали разные сценарии: парко-хозяйственный день, когда 20% итерации идёт на техдолг (не очень работает), технологические итерации, когда команда между проектами целую итерацию делает только техдолг и инженерные задачи ( реально работает, но крайне непросто убедить бизнес пойти на это). Аджайл в идеальном мире действительно не про это, но в реальном мире часто все идёт именно по пути замены требований по пути. Тоже самое касается внесения новых задач в уже стартанувшую итерацию. Интересен именно нехороший сценарий.
2. Выходит, что признание долгом долга вещь сугубо субъективная, я верно понял? Т.е. в задах системы живет пачка овнокода, но поскольку она работает и жить не мешает — она признается нормой?
3. Вспомнилось «highly likely”:))) Документация часто сама является техдолгом, потому как написать-написали, а поддерживать забыли:))

Про аджайл спорить не буду, до не тот топик.

В п.2 меняющийся, вместо «отменяющийся». Прошу прощения.

Спасибо за материал, тема, безусловно необъятная, и в одну статью не влезет, есть пара вопросов:

1. Вот вы пишете, что аджайл помогает решать проблему техдолга за счёт итераций и дробления скоупа. Но ведь тот же аджайл допускает изменения по ходу дела в пользу лучшего продукта здесь и сейчас. Как быть в такой ситуации? Ведь изменяющиеся постоянно требования в угоду рынку и есть причина отсутствия чёткой реализации и обилия костылей.
2. Мне кажется, что часто отменяющийся код хорош тем, что его часто читают разные скорее всего люди. Ведь тот код, который запилили на скорую руку с костылем или без и ушли из него надолго, закопав стюардессу, есть имхо основной источник техдолга и неожиданных эффектов в будущем, наряду с изменяющимися требованиями и нехорошей архитектурой кода, которую почему-то не упомянули. Вы каким-то образом решаете задачу отслеживания долга в таких случаях?
3. Куда-то подевалась мать всех костылей — плохая архитектура самого приложения и отдельно взятых модулей. Когда любое расширение несёт за собой боль и страдания. Но при этом вы указали документацию и отсутствие комментариев в коде, что само по себе не является маркером технического долга. Не могли бы вы прокомментировать, как предложенные методы помогут решить вопрос плохой архитектуры?

Спасибо!