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

Недавно я начал новый проект на работе (было приятно избавиться от хлама старого проекта и взяться за новый), и моя команда и я активно продвигаем более профессиональные методы разработки, которые включают в себя написание модульных тестов. Владелец продукта не очень впечатлен, поскольку, по мнению PO, это приводит к задержке предоставления функций.

PO (который также является начальником моего босса, что создает небольшой конфликт интересов, IMO) очень расстроен из-за проблемы, которая проскользнула в наш релизный продукт. Я подчеркиваю, что хороший набор модульных тестов уловил бы проблему (требуется некоторый дополнительный рефакторинг, чтобы справиться с некоторыми грубыми ошибками архитектуры неопытного кодера), и PO, не теряя времени, предложил, чтобы мы «выяснили, как потратить некоторое количество качественных Тогда ОТ по настройке модульных тестов». Наш график уже заполнен запросами функций и минимальным временем для исправления ошибок и других необходимых задач обслуживания.

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

PS, я не знаю, как пометить это, я тоже был бы признателен за любую помощь.

Я не знаком с термином «Владелец продукта». Это ваш клиент?
Возможно, связано, поскольку решает один из аспектов проблемы: worker.stackexchange.com/questions/7095/…
@DavidK Да! Извините за двусмысленность. Это относится к человеку, которому принадлежит продукт, который разрабатывает моя команда.
@ 404usernotfound Я не подрядчик, я не уверен, что ваша ссылка поможет (хотя это хорошее чтение, спасибо).
@JoeStrazzere Я руководитель группы и говорю за себя. Я бы хотел, чтобы другим тоже не приходилось работать сверхурочно, поскольку защита моей команды является частью моей работы (которая мне даже нравится).
Знает ли ваш владелец продукта, что такое модульные тесты?
@Brandin Я надеюсь на это. Я потратил тридцать минут на подробное описание их на последнем совещании по планированию спринта, надеясь сообщить о тех технических долгах, которые они могли бы помочь сэкономить.
30 минут недостаточно для того, чтобы кто-то понял ценность, которую модульные тесты привносят в процесс разработки. Вы можете попытаться смягчить его/ее страх, объяснив, что вы не собираетесь проверять правильность работы компилятора, среды выполнения или операционной системы.
Какой может быть конфликт интересов, если вы одновременно являетесь владельцем продукта и руководителем своего босса?
У @Hyperbole была та же проблема, моя команда больше не пишет тесты - это просто невозможно, не раздражая босса до такой степени, что вас уволят. Как уже говорили другие, просто не делайте этого, и когда начнет возникать технический долг, поднимите этот вопрос в качестве обсуждения, чтобы оправдать важность модульных тестов.

Ответы (2)

Поскольку вы используете термин «Владелец продукта», я предполагаю, что вы используете Scrum (или родственный метод). Если нет, полностью игнорируйте этот ответ.

Если вы используете scrum, PO не определяет, сколько команда может сделать за спринт, это делает команда. Если вам нужны модульные тесты, чтобы помочь вам соответствовать определению заказа на покупку, включите их в свои балльные оценки. В схватке ваше расписание не должно быть «забитым» — вы можете набрать определенное количество очков за каждый спринт, и это ваше расписание.

PO должен устанавливать приоритет на основе полученной ценности для бизнеса. Если исправления ошибок и технический долг не важны для PO, то они не будут ставить их на первое место в списке приоритетов. Но и ваша команда не должна нести за них ответственность. Если работа соответствовала определению выполненной в ЗП (а тестирование качества должно быть включено в определение выполненной работы), то вы сделали то, что требовалось.

Ваш скрам-мастер должен охранять команду как от вмешательства со стороны PO, так и от вмешательства вышестоящих лиц, так что привлекайте их.

Определение «Готово» в заказе на поставку было согласовано, чтобы указать «разработка завершена, но с контролем качества», вопреки моему лучшему суждению.
Затем ваш скрам-мастер должен убедиться, что именно PO, а не команда, несет ответственность за это решение.
@Kathy имеет правильную идею. ОП, вы должны объяснить своему боссу, почему модульное тестирование важно для него, чтобы он согласился. Прямо сейчас он, кажется, не понимает ценности этого, лучший способ сделать это — использовать его подход, и когда накапливается технический долг, упомяните ему, что это потому, что вы, ребята, не проводите модульное тестирование. Тогда он будет более склонен слушать.

Когда вы определяете объем или размер своих функций, вы разбиваете модульное тестирование как часть этого или это отдельная позиция? Я бы посоветовал вам сделать модульное тестирование частью вашего процесса разработки, а затем соответствующим образом масштабировать задачи, не разбивая их на код, который тестирует эту функцию. Просто предположим, что усилия по «кодированию» функции включают в себя написание тестовых случаев.

Если вас спросят, почему объем работ увеличивается, просто укажите, что проект растет, и чем больше проект, тем больше затрат на добавление функций. Вы могли бы рассказать ему о TDD (разработка через тестирование), но я не думаю, что это будет иметь большое значение. С другой стороны, если TDD является частью вашего процесса разработки, то он просто полностью интегрирован и не является отдельной вещью, это просто то, как вы добиваетесь своей цели.

Если вы используете agile/scrum, то PO в любом случае не должен диктовать расписание, он/она должен просто расставлять приоритеты и определять функции. Это работа вашей команды, чтобы дать ему сроки. Если вам нужно вернуться и сделать некоторую очистку, то есть некоторый аргумент в пользу собственного времени, но вы можете договориться об определенном количестве «инженерного» времени. Там, где я сейчас работаю, мы договорились, что 15% нашего времени посвящается инженерным работам. Это вещи, которые мы внутренне определили как нуждающиеся в исправлении. Это может быть производительность, которая сейчас не слишком заметна, но скоро будет, или это может быть тот модуль, который не был сделан правильно с первого раза и нуждается в доработке.

Выделение UT в качестве элемента задачи — это практический риск, PO крайне устойчив ко всему, что не дает немедленной ощутимой выгоды для бизнеса. Даже после этого серьезного дефекта в опубликованном продукте PO не хочет слышать о преимуществах UT.
Вы сказали, что «разработка завершена» была частью вашего определения готовности. UT является частью разработки, это тестовые примеры, написанные разработчиком, и они должны быть частью вашего определения разработки, при условии, что у вас есть определение для этого. Возможно, вам придется нажать это, если вы хотите, чтобы это было включено, поэтому оно не будет сделано или даже не будет готово для обеспечения качества, пока не будут пройдены все модульные тесты. Это тоже код, ваш PO явно не разбирается в разработке ПО, так что удачи.
@Hyperbole Обычно лучше вообще не упоминать модульное тестирование, но иметь в команде общее правило, согласно которому весь новый или измененный код должен иметь достаточное количество модульных тестов для любого уровня уверенности, который вам нужен, а затем переоценивать все на основе этого. Да, некоторые истории или задачи, которые выглядят простыми, внезапно станут намного дороже, если вам придется писать модульные тесты, которые должны были быть написаны ранее (или даже дороже, если вам придется переписать сам код, чтобы его можно было тестировать).
Но эти дополнительные расходы теперь являются ценой выхода из этого и погашения технического долга. Если это действительно неприятно, вы можете немного схитрить, недостаточно протестировав наихудшие случаи сейчас, оставив добавление лучших тестов на потом, но вам нужно продолжать двигаться вперед в проведении тестов. ¶ Важно избегать переговоров с нетехническими людьми о том, как писать код; Принцип XP, согласно которому только люди, пишущие код, могут принимать решения о том, как писать код, специально предназначен для решения этой проблемы. И это включает в себя то, сколько модульных тестов вы проводите.
Владелец продукта требует сверхурочной работы для написания модульных тестов. Как я могу решить эту проблему?
СпросиСетьПолитика конфиденциальности1y, 0v