Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Как вы смогли такого достигнуть? У нас анархия и не знаю как это изменить.
В нашем случае эти штуки сформированы самой командой в ответ на имевшуюся у каждого боль.
Основной посыл для менеджмента при внедрении всего этого: разработчики любят писать код и здоровая команда без лишних отвлечений может делать больше и лучше.
Или у вас анархия в самой команде?
Основной посыл для менеджмента при внедрении всего этого: разработчики любят писать код и здоровая команда без лишних отвлечений может делать больше и лучше.
Или у вас анархия в самой команде?
И в команде и руководстве отделом в целом, ответственный за задачи (замещающий продукт-оунера) не имеет возможности или желания уделять время продукту.
Поэтому спускаются задачи: «поломалось что-то в аналитике», а команда организует работу. Думаю, что проблема в том, что каждый хочет сделать как можно меньше своей работы, договоренности из-за этого нарушаются (н.р. сервер может прислать данные в другом формате).
Пробовал брать на себя роль человека, который организует команду по некоторым задачам. Стало чуть лучше, но пока не смог достигнуть нужного эффекта.
Поэтому спускаются задачи: «поломалось что-то в аналитике», а команда организует работу. Думаю, что проблема в том, что каждый хочет сделать как можно меньше своей работы, договоренности из-за этого нарушаются (н.р. сервер может прислать данные в другом формате).
Пробовал брать на себя роль человека, который организует команду по некоторым задачам. Стало чуть лучше, но пока не смог достигнуть нужного эффекта.
Пару раз по шапке за профуканые сроки получите — и или измените строй, или уволитесь.
Какими системами пользуетесь?
1. Разве определение завершенности задачи это не прерогатива product owner? Не совсем понятно, зачем вся команда должна быть довольна. Доволен должен быть бизнес (овнер и кастомеры).
2. Исправление чужого кода в рамках code review это же дикий overhead по трудозатратам. Влезть со «свежим взглядом» в большую задачу и пытаться ее отрефакторить, вместо того чтобы передать обратно автору, который с головой в контексте и все исправит втрое быстрее? То ли у вас очень мягкие требования по эстимейтам (заложено гораздо больше реально необходимого времени), то ли процедура на практике работает не так, как вы описываете.
2. Исправление чужого кода в рамках code review это же дикий overhead по трудозатратам. Влезть со «свежим взглядом» в большую задачу и пытаться ее отрефакторить, вместо того чтобы передать обратно автору, который с головой в контексте и все исправит втрое быстрее? То ли у вас очень мягкие требования по эстимейтам (заложено гораздо больше реально необходимого времени), то ли процедура на практике работает не так, как вы описываете.
1. Да, все правильно сказали. Но мы сталкивались ситуацией, когда-то кто-то из команды уже после код-фриза или прямо на демонстрации понимал, что в задаче коллеги можно было бы еще что-то важное учесть.
А вся команда должна быть довольна, чтобы ни у кого не было ощущения, что кто-то рядом запилил какую-то фигню (пусть и рабочую), с которой теперь жить :-)
2. Вы правы, погружение в контекст требует времени больше, чем исправление самим автором, поэтому на практике глубина погружения может быть разной (в зависимости от загруженности).
По моим ощущениям, оверхеда не больше, чем при парном программировании, для которого как раз не всегда достаточно времени.
А вся команда должна быть довольна, чтобы ни у кого не было ощущения, что кто-то рядом запилил какую-то фигню (пусть и рабочую), с которой теперь жить :-)
2. Вы правы, погружение в контекст требует времени больше, чем исправление самим автором, поэтому на практике глубина погружения может быть разной (в зависимости от загруженности).
По моим ощущениям, оверхеда не больше, чем при парном программировании, для которого как раз не всегда достаточно времени.
Скажите, пожалуйста, а как происходит процесс ревью? Ревьювер просто берет и молча доделывает/переделывает код или сначало идет обсуждения непосредственно с автором на тему «почему сделано именно так, а не иначе» и уже после достигнутого консенсуса/компромиса начинается рефакторинг?
Если ревьювер вносит какие-то мелочи, то просто берет и вносит. Если у него гениальная идея, как все переписать с нуля, то тут стоит задуматься над целесообразностью.
Изменения «средней тяжести» валидируются с автором. До или после во многом зависит от уровня погружения в код ревьювера и автора. Опытный в этой части кода ревьювер может что-то переделать и потом рассказать автору.
У нас есть нерешенная проблема: нет четкой границы, когда ревью с косметическими правками превращается в полную переработку авторского решения. Нужен какой-то объективный критерий, по которому можно оценить — стоит ли сейчас вносить это изменение или можно выпустить фичу в таком виде в релиз.
Изменения «средней тяжести» валидируются с автором. До или после во многом зависит от уровня погружения в код ревьювера и автора. Опытный в этой части кода ревьювер может что-то переделать и потом рассказать автору.
У нас есть нерешенная проблема: нет четкой границы, когда ревью с косметическими правками превращается в полную переработку авторского решения. Нужен какой-то объективный критерий, по которому можно оценить — стоит ли сейчас вносить это изменение или можно выпустить фичу в таком виде в релиз.
Слишком сложно. Дайте мне 2 выходных, 1 день обсуждений и 4 дня спокойной работы — все, не нужно усложнять.
«Done-консилиум» — это да, тут минусов нет, одни прелести.
«Done-консилиум» — это да, тут минусов нет, одни прелести.
4 дня спокойной работы— вот как раз их и не дадут вам, если не пойти на компромиссы как в статье...(
Я как разработчик хочу творить пока не добил определенный пласт работы, а не болтать. С другой же стороны менеджеры хотят направлять и быть в курсе происходящего. Да и идея с суппортом хороша, хоть и реализуема только в идеальном мире, так как вопросы в тикетах обычно далеко не только о ПО.
Вот и выходит, что в данном случае компромисс, то есть взаимные уступки, это как раз один день.
Вот и выходит, что в данном случае компромисс, то есть взаимные уступки, это как раз один день.
Нам никто не мешает иногда работать по такой схеме с одним днем для обсуждений в неделю или даже без них вообще.
Это дает прирост производительности сейчас, но копит неразгрумленные задачи. Нормальный компромисс, когда PO и команда немного расходятся в понимании, что можно и что нужно успеть в очередном спринте.
У вас, получается, действует правило "кто нашел, тот и сломал"? Качество код-ревью от этого не страдает? Ведь приходится из своей задачи "вынырнуть", чтобы качественно починить чужой код.
Про оверхед, сравнимый с парным программтрованием, интересно замечено.
Как уже писал, глубина погружения на практике может быть разной: кто-то пару проверок добавит, кто-то лишнего уберет, а кто-то обсудит с автором и отрефакторит API.
Мы как раз с классическим код-ревью ощущали проблему с выныриванием и заныриванием: автор запилил фичу и хочет пилить следующую, но остальным некогда поревьювить, потому что у них тоже фичи интересные, но когда они посмотрят, то автор уже начал новую и ему снова переключаться обратно.
Сейчас ревьювер один и он посмотрит тогда, когда ему будет удобно, но при этом не начнет новую задачу, пока не поревьювит. Автор же сразу переключается на новую задачу.
Мы как раз с классическим код-ревью ощущали проблему с выныриванием и заныриванием: автор запилил фичу и хочет пилить следующую, но остальным некогда поревьювить, потому что у них тоже фичи интересные, но когда они посмотрят, то автор уже начал новую и ему снова переключаться обратно.
Сейчас ревьювер один и он посмотрит тогда, когда ему будет удобно, но при этом не начнет новую задачу, пока не поревьювит. Автор же сразу переключается на новую задачу.
7. Передача кода
А бывает, что второй программист, который делает code review, плохо разбирается в коде и ломает то, что работало? У нас исправляет тот, кто написал код, и в моих code review было много комментов, где люди не понимали, как это работает и зачем я добавил этот кусок кода.
6. Done-консилиум. 7. Передача кода.
А почему не наоборот? У нас сначала code review, потом тестировщики проверяют, а потом уже демо. Если окажется, что код кривой и его надо переделать, то вы проводите демо и Done-консилиум ещё раз?
Да, бывает. Как раз в тех местах, где с первого взгляда непонятно, что так специально было сделано и есть какой-то дикий нюанс бизнес-логики, внешнего API, legacy-кода, а не просто продолбали. Специальной защиты от этого нет: явно отразить в коде эту особенность, добавить на нее тест, написать комментарий в конце концов. Никто не запрещает привлечь автора и попросить разъяснить непонятное.
Done-консилиум это еще не итоговое демо по результатам спринта, а внутренняя мини-демонстрация. Автор еще будет вносить изменения после него, поэтому ревьювить код рано. Done-консилиум обеспечивает минимальное погружение в выполненную задачу — без этого нельзя нормально выполнить ревью.
Если по итогам ревью было сделано много изменений, есть смысл провалидировать их с автором, но отдельного Done-консилиума нет.
Done-консилиум это еще не итоговое демо по результатам спринта, а внутренняя мини-демонстрация. Автор еще будет вносить изменения после него, поэтому ревьювить код рано. Done-консилиум обеспечивает минимальное погружение в выполненную задачу — без этого нельзя нормально выполнить ревью.
Если по итогам ревью было сделано много изменений, есть смысл провалидировать их с автором, но отдельного Done-консилиума нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы починили свой процесс и стали меньше отвлекаться