Реализация графика выпуска

Проще говоря, учитывая отсутствие определенного процесса, мало шансов на успешную реализацию четкого графика выпуска. Это не просто пессимизм, хотя я с готовностью признаю, что это так.

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

Опять же, это не означает, что вы не можете достичь того, что вам нужно, делая то, что вы описали выше; честно говоря, если вы находитесь в среде, которая активно враждебна внедрению такого процесса, как описано, вы, вероятно, работаете наилучшим образом для достижения того, что вам нужно. И я не хочу быть полностью пессимистичным; похоже, вы хорошо понимаете, как это сделать; для того, с чем вы должны работать, похоже, что у вас есть разумный процесс. Но я могу практически гарантировать, что вам станет лучше, если вы сможете получить только две вещи; 1) функциональная спецификация от руководства, которая описывает, что они хотят, чтобы программное обеспечение делало, и 2) спецификация дизайна от инженеров, описывающая руководству, как вы собираетесь заставить программное обеспечение делать то, что они хотят в функциональной спецификации. Я думаю, вы могли бы даже вписать это в свой процесс; функциональные спецификации не должны быть сложными; главное в них то, что они записаны, что предотвращает споры о том, что просило руководство; это прямо здесь. Спецификации проекта также не требуют много времени; краткая одностраничная заметка, чтобы сообщить руководству, как (на высоком уровне) вы собираетесь реализовать то, что им нужно, дает им уверенность в том, что вы их услышали, и может помочь им понять всю сложность происходящего (но не переходите слишком глубоко в него, иначе вы рискуете наскучить им и потерять их внимание).

Учитывая отсутствие управления проектами, организации и т. д., я думаю, вы столкнетесь с проблемами, пытаясь заставить себя выйти на ежеквартальный (или любую фиксированную дату) цикл выпуска. Это будет особенно верно, если у вас есть какие-либо «крупные» функции, разработка которых займет более 2 месяцев, которые вы отводите на разработку.

Мое предложение состояло бы в том, чтобы сделать цикл выпуска, основанный на функциях. Просто составьте свою очередь функций, решите, какие из них, по вашему мнению, вы можете разумно реализовать в определенный период времени. Реализуйте эти функции, дайте себе месяц (или сколько угодно) на тестирование, а затем выпустите. Переход к следующей группе функций. Если это займет 2 месяца вместо 3, отлично. Если 4, то тоже нормально.

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

Выпускайте раньше и чаще.

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

Единственная «фишка» — постоянно напоминать заказчику, что тестовая платформа — это не производственная платформа.

Что вы используете для контроля версий?

Мы используем SVN и можем при необходимости создавать различные ветки в зависимости от того, что будет развернуто в следующем выпуске. Если планируется выпуск выпусков a1, a2 и a3, мы можем объединить эти изменения в производственную ветку. Если a2 становится менее приоритетным, мы можем откатить только изменения a2 или, если есть перекрытие, просто создайте новую ветку и объедините только a1 и a3, оставив a2 для более позднего выпуска.

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

Моя компания также увязла в запросах функций.

Что мы сделали, так это рассмотрели все функции и дали оценку времени, которое потребуется для их реализации. Затем мы предоставляем нашему «комитету по изменениям» (нашему генеральному директору, руководителям групп и т. д.) возможность дать нам функции, которые мы будем дорабатывать в течение следующего спринта.

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