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

Question

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

У нас есть один продукт, который закончен и используется несколькими клиентами, но у нас есть 4 дополнительных продукта в работах - и активно продаются, как если бы они были закончены. (Представь себе!)

Мы - очень маленькая компания, работающая очень быстро (и да, временами небрежно) и с жесткими сроками и ограниченным бюджетом, поэтому у нас нет роскоши письменных требований, систематического процесса обеспечения качества и т. Д. В основном владельцы Компания приходит к разработчикам (3 из нас) с идеями, и мы реализуем их. Затем эксперты в данной области тестируют функции, чтобы убедиться, что приложение делает то, что должно.

Я знаю, что последний абзац открывает мне всевозможные отзывы типа "ты не можешь сделать это таким образом", но мне это не нужно. Я понимаю, как неправильно этот подход. В какой-то момент я смог посоветовать владельцам нанять менеджера проекта и сотрудника отдела контроля качества, но через короткое время оба были уволены из-за потери дохода. Мы находимся там, где мы есть, и на этом этапе культура не меняется.

Я пытаюсь управлять ожиданиями. У нас есть список запрашиваемых функций длиной в милю, и вот что я предложил.

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

1) Поместите все выдающиеся функции в будущий выпуск в зависимости от его важности. 2) Работа над этими функциями в течение квартала. 3) Когда запрашиваются новые функции, поместите их в «очередь» для определенного цикла выпуска. 4) Если функция должна войти в текущий выпуск, перенесите другие функции в следующий выпуск. 5) В определенные моменты цикла оцените, какие функции могут не попасть в текущую версию, и внесите соответствующие изменения. 6) Завершить разработку функций не позднее, чем за 30 дней до запланированного запуска в производство и сосредоточиться на тестировании и исправлении ошибок. 7) Направить что-то в производство в назначенную дату, а затем принять тепло, чтобы не закончить все, на что мы согласились вначале (эй, я реалист, а люди, на которых я работаю, нет.)

О, кроме того, если вы планируете сказать мне "получить новую работу", не беспокойтесь об ответах. Это не вариант в данный момент.

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

Заранее спасибо за помощь.

Darvis

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

Выпуск рано и часто.

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

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