Вы активно управляете задолженность по техническим долгам в ваших проектах разработки программного обеспечения, и если да, то как вы это делаете?
Вы активно управляете техническим долгом?
Ответ 1
Одним из аспектов управления техническим долгом является убеждение нетехнических менеджеров в том, что вам нужно время для рефакторинга и исправления ошибок.
Вот статья с конкретными предложениями о том, как это сделать.
Ответ 2
В наших командах мы активно управляем техническим долгом. Мы делаем Scrum, поэтому мы создаем техническую долговую карточку либо для текущей итерации, либо для следующей итерации в зависимости от оценки и оставшейся спринтерской способности, и они становятся приоритетными, как и функции и карты ошибок. Мы также управляем более крупными, кросс-командными долговыми статьями, имея межгрупповое отставание от технического долга, которое мы уделяем приоритетное внимание и вводим в каждую команду Scrum во время планирования спринта.
Ответ 3
Я думаю, что важно запланировать время для решения технического долга, если вы пытаетесь восполнить старые грехи, но я также думаю, что вы не должны делать это привычкой. После того, как вы очистите беспорядок, вы должны избегать привлечения вашего проекта к большему долгу, если у вас нет веских оснований для этого.
Активное управление этим, как предлагает Майк, кажется самым разумным подходом, но я считаю очень важным дать понять (вашей команде), что вы не должны планировать время или планировать рефакторинг в долгосрочной перспективе.
Рефакторинг должен быть естественной частью написания кода и, таким образом, должен быть включен в ваши другие оценки и планы и не рассматриваться как отдельный вид деятельности, если только вам не нужно, то есть по "историческим" причинам или потому, что вы сознательно решили реализовать что-то определенным образом, а затем повторно реализовать его позже.
Ответ 4
Что вы делаете, это создать культуру, где технический долг неприемлем, если только в крайних случаях. Как люди, которые платят наличными и используют кредит только в качестве крайней последней меры.
Ответ 5
Если мне действительно нужно накапливать технический долг, потому что мне нужно что-то выпускать СЕЙЧАС, я делаю критическую ошибку, поэтому он получает наивысший приоритет. Но это только для экстремальных ситуаций (клиент прыгает вверх и вниз, жена ищет дингбат и т.д.).
Ответ 6
Это зависит от продукта. Когда я работал в поле, где наш код должен был проходить аудит, это была запланированная часть нашего спринта. PM просто спросил, в какой области нужен рефакторинг, и он был включен в план. Это не означает, что вы не исправляете код в области, над которой работаете, но вы не посвятили бы день переписыванию искаженного фрагмента кода, который работал. Теперь я работаю в scrum, и разработчики просто делают это, когда они работают. Мое впечатление, что примерно столько же времени идет на рефакторинг, в любом случае.
Ответ 7
Я согласен с Андерсом. Если вам нужно настроить системы для управления техническим долгом, это означает, что вы все еще добавляете его. Прекратите входить в долги в первую очередь, обновив свое определение "сделано".
Это означает, что модули с "задолженностью" будут труднее работать. Разработчики должны знать об этом и присваивать больше сюжетных точек, чтобы они оставляли вещи "сделанные" на своем пути.
Ответ 8
Если вы опаздываете в цикл выпуска, вы не хотите слишком сильно менять базу кода. Это означает, что всегда будет какая-то техническая задолженность. Я обычно пишу FIXME: s для изменений, которые являются субоптимальными, а затем я позабочусь о них, прежде чем я начну реализовывать функции для следующей версии.
Ответ 9
Java Posse недавно рассмотрели управление "Технический долг" , который выглядит очень всеобъемлющим.
Ответ 10
В тех проектах, которые я участвовал до сих пор, некоторые технические долговые обязательства были "оплачены" (управляются) только в начале новых этапов проектов, то есть после "больших выпусков" или этапов.
Очень важный аспект технического долга заключается в том, что он включает не только разработчиков, но и управление. В этом смысле я знаю, что лучший способ справиться с этим - сделать его видимым для "нетехнических участников проекта", которые могут выделять время и ресурсы для управления техническим долгом, как только они поймут его последствия.