Регламент разработки - когда он нужен и что бывает, если его нет
Лозунг с плаката выше актуален не только на производстве, но и в разработке/внедрении ПО. У «1С», например, есть своя система стандартов и методик разработки конфигураций. А у каждой проектной команды, внедряющей 1С, обычно есть свой регламент разработки. В нем описаны правила внесения изменений в конфигурацию, которых должны придерживаться разработчики.
Я собрал целую коллекцию таких регламентов с проектов 1С, в которых участвовал. 🙂 Но выбрать какой-то из них для работы по своим клиентам никак не мог. В одном, скажем, все слишком жестко. Но в реальности бывают ситуации, когда наилучшее решение требует большей гибкости. Второй слишком короткий, не затрагивает многих важных аспектов разработки. Третий — длинное полотно текста, с которым очень тяжело работать. Да и зачем нам регламент, казалось мне: команда небольшая, вся разработка под моим контролем...
Но не так давно один из клиентов попросил обновить его «Управление торговлей» с 11.4 на 11.5. Таких приключенческих квестов у меня давно не было! За последние шесть лет в конфигурацию вносили доработки разные спецы. Представления о том, «как надо делать правильно», у них сильно отличалось. Как оказалось, оно и у меня менялось за эти годы. 🙂 В итоге похожие доработки сделаны 10-ю разными способами, восемь из которых — неудачные. Разбираться в них, а еще и переделывать под новую версию, очень тяжело.
В общем, пересмотрел свою коллекцию регламентов, припомнил разные казусы из опыта, и написал-таки регламент для нашей небольшой команды. Делюсь с вами. Пользуйтесь, если найдете его подходящим. Буду рад вашей рецензии, замечаниям и предложениям. Делитесь в комментариях!
Соблюдаете регламенты?
👍 — конечно, полностью согласен с лозунгом на плакате.
🤔 — нет, я натура творческая, рамки меня душат.
🔥 — стараюсь, но когда вижу, как их «соблюдают» другие, руки опускаются…
#кейсы