x
 
Артур
10 сентября 2020
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Как, по твоему опыту, лучше организовать процесс сдачи задачи и код-ревью в рамках спринта, чтобы определить, кто будет делать ревью, и чтобы при этом задачи, которые были спланированы у ревьюеров, не факапились?


Артур!

Код‑ревью и при­ёмка задачи — это такая же работа, как про­ек­ти­ро­ва­ние или напи­са­ние кода, а зна­чит, на неё точно так же нужно закла­ды­вать время. Если про­грам­мист много и часто делает код‑ревью, зна­чит, в его спринте дол­жен быть запас вре­мени для этого. Мене­джеры и QA, пла­ни­руя своё время, тоже должны пони­мать, что в начале спринта работы будет чуть‑чуть меньше, а ближе к концу им сва­лится много задач на приёмку.

Бывает, что при­ёмку ломают сами испол­ни­тели, сда­вая код за несколько часов до дед­лайна. С такими испол­ни­те­лями стоит пого­во­рить о прин­ци­пах сдачи работы. Дело в том, что код‑ревью, как и руч­ное тести­ро­ва­ние, ничем не отли­ча­ется от обыч­ной сдачи резуль­тата кли­енту, только в роли кли­ента высту­пает кол­лега‑про­грам­мист или мене­джер. А зна­чит, рабо­тает базо­вое правило:

Пройти код‑ревью — ответ­ствен­ность автора кода

Если испол­ни­тель при­нял базо­вое пра­вило, он не затя­нет отправку на код‑ревью, потому что знает, что если задача не сде­ла­ется, вино­ват будет он сам, а не ревьюер, кото­рый не отре­а­ги­ро­вал ночью перед дедлайном.

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Стоит ли менять работу, если уже порядком поднадоело, но есть новые проекты и в целом хоть какой-то прогресс ощутим? Что такое непрерывная доставка? Как написать аккуратный код? Часть четвёртая: ответственность Как и когда зарождающийся стартап в процессе своего развития должен подходить к вопросу имплементации билинга?




Недавно всплыло

6 Что лучше использовать: спинер или прогрессбар? 5 7 2