Проблемы с итеративной моделью разработки

Если у вас есть хороший контроль версий, вы сможете каскадировать исправление ошибок с версии 7.3 по всем выпускам до текущего. Должно быть немного необходимости выяснять, как исправлять будущие выпуски. Если у вас есть хорошие инструменты автоматизированного тестирования, вам просто нужно убедиться, что ошибка существует в каждом выпуске, патче и проверить исправление.

Для такого релиза я бы разрабатывал на стволе, а ветку — на релизе. Ветвление как можно раньше и как можно позже. Я видел проекты, где каждый релиз — это отдельный островок кода. Это имеет тенденцию создавать проблемы, с которыми вы сталкиваетесь.

Я бы разделил работу над ошибками в предыдущих выпусках на отдельный поток обслуживания. В потоке обслуживания должны быть старшие разработчики, иначе вы можете внести больше ошибок, чем исправляете. Эта группа должна иметь возможность объединять исправления ошибок с текущим выпуском.

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

Документирование причины ошибки (как она появилась) может помочь уменьшить скорость, с которой вы создаете новые проблемы.

Сокращение числа поддерживаемых версий также может помочь. Рассмотрите как график обслуживания что-то вроде:

• Каждый выпуск поддерживается до тех пор, пока не будут выпущены два ежеквартальных выпуска.
• Квартальные выпуски поддерживаются в течение года.
• Годовые выпуски поддерживаются в течение двух лет.

Обязательно ли иметь столько версий? Есть ли способ перейти на один трек ? (Одна дорожка означает, что у вас есть одна основная или главная ветка в зависимости от вашей системы управления версиями, и каждое изменение входит в эту основную или главную ветку, а версий нет)

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

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

По моему опыту, 90% клиентов устраивают одну дорожку. Остальные 10% потеряли доверие и решили из-за этого не брать новые патчи. Но, это другая ситуация.

Сократите объем, интегрируйте тестирование в цикл выпуска (например, не делайте этого, пока не протестируете и не исправите его) и выпускайте чаще.

Чтобы итерационный цикл работал хорошо, вам необходимо:

1. Увеличивайте частоту выпусков и
2. Всегда двигаться вперед

Идея в том, что:

1. Клиентам не придется долго ждать устранения неполадок
2. Клиенты могут быть уверены, что новая версия будет лучше старой .

Это нормально, когда клиент остается с более старой версией, но непродуктивно ожидать, что она будет поддерживаться или исправляться в течение длительного времени.

Кроме того, чтобы не расстраивать ваших основных клиентов, создайте группу «опытных пользователей» , которые получат новую версию раньше всех и помогут устранить основные проблемы.

По пункту 1

Ваш спрос превышает предложение, вызывая отставание в работе, которое будет стремиться к бесконечности. Трудно дать конкретный совет, чтобы помочь исправить это, но я бы начал с:

Измерьте, как часто возникают запросы на новые функции/изменения. Как часто возникает ошибка в рабочей версии. Обратите внимание на уровни спроса на ценность (новые вещи, которые хотят клиенты, которые будут стимулировать новый бизнес или увеличивать расходы) и спрос на отказ (те запросы, вызванные ошибкой с вашей стороны (например, ошибки)

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

Для получения дополнительной информации ознакомьтесь с теорией очередей. Там много материала, но я особенно рекомендую взять «Управление фабрикой дизайна» Дона Рейнертсена, в которой есть действительно хороший раздел об очередях (а также в целом потрясающая книга).