Статьи компании «АКСИОМА-СОФТ»

Козий Сергей, генеральный директор ООО «Аксиома-Софт»

Общие принципы коллективной разработки

В начале проекта необходимо определиться с регламентом разработки

У каждого проекта и у каждого архитектора свои методы управления разработки, однако, существуют общие принципы, которые нужно соблюдать:

• Использование хранилища — все более менее опытные разработчики умеют им пользоваться, но мало кто использует все возможности хранилища для организации наиболее комфортного управления разработкой
• Использование системы учета разработок или, как часто её называют, «тикетной» системы. Таких систем много как на платформе 1С, так и на других платформах
• Все разработки должны быть документированы хотя бы в части комментариев к закладкам в хранилище и комментариев в коде.

Требования к закладкам в хранилище: обязательно должны быть указаны код задачи и её краткое описание. «Краткое описание», для того чтобы можно было быстро понять, что правилось и чтобы это было понятно в отчете о хранилище; «код задачи» для того чтобы можно было открыть задачу в базе и более детально понять, что и как должен был сделать разработчик.

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

Организация процесса разработки

Архитектор назначает ответственного специалиста на проекте, в обязанности которого входит:

• проверка и регистрация технических заданий в среде учета разработок;
• выдача заданий разработчикам;
• контроль загрузки разработчиков;
• поддержка актуальности информации в среде учета разработок;
• проверка наличия и полноты заполнения документации по готовым разработкам;
• проверка соответствия объектов разработки требованиям, описанным в данном регламенте;
• сборка релизов.

Ответственный специалист на проекте может назначать специалистов контроля качества, которым делегируется часть полномочий ответственного специалиста на проекте:

• проверка соответствия объектов разработки требованиям, описанным в данном регламенте;
• сборка релизов.

Проверка объектов разработки производится специалистом контроля качества перед сборкой релиза. При обнаружении расхождений в объектах разработки с требованиями, специалист контроля качества формирует список замечаний в системе учета разработок.

Цикл управления разработкой

Планирование, установление целей и процессов, необходимых для реализации проекта:

1. Действие — выполнение задач по разработки.
2. Контроль — контроль выполнения задач, тестирование.
3. Воздействие или (управление, корректировка) — устранение замечаний.

Планирование

Весь проект нужно разбивать на как можно более низкий уровень задач и подзадач.

Рабочий день сотрудника на проекте должен начинаться с просмотра своих задач.

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

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

Рабочий процесс выполнения задач и исправления ошибок

1. Каждая задача или ошибка должна быть рассмотрена консультантом, либо тим-лидером — ответственным за подсистему.
2. После рассмотрения задача подробно описывается и отправляется на выполнение программисту.
3. После выполнения задачи программист отправляет задачу консультанту или тим-лидеру.
4. Консультант проверяет задачу и если задача выполнена без ошибок и в точном соответствии с постановкой, то далее задача отправляется на проверку Заказчику, если есть ошибки, то задача отправляется на доработку программисту.
5. После проверки задачи заказчиком, задачу закрывает руководитель проекта со стороны Заказчика или со стороны Исполнителя.

Трехсистемный ландшафт

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

На наших проектах мы используем, трехсистемный ландшафт, который состоит из:

1. Среды разработки — DEV
2. Среды тестирования — TEST
3. Продуктивной среды — PROD

Каждый из разработчиков кодирует в хранилище, и отлаживает на собственной базе.

В назначенное время разработка останавливается — накладывается мораторий на развитие функционала и исправление старых ошибок. Во время моратория правятся только ошибки, привнесенные в этой сборке, и происходит обновление общей базы всех разработчиков — DEV.

После обновления базы DEV консультанты начинают тестирование заявленного нового функционала и прогон сквозных тестов на базе DEV

После того, как по мнению команды Подрядчика тестирование завершено успешно, обновляется база TEST, на которой происходит тестирование совместными силами команды Заказчика и Подрядчика.

И только после того как тестирование силами Заказчика закончится успешно, можно обновлять рабочую базу PROD.

Стоит отметить, что организация трехсистемного ландшафта зачастую ещё связана и с внутренней политикой безопасности компании Заказчика — обычно Заказчик не допускает подрядчика к своим продуктивным базам, поэтому приходится проводить тестирование на тестовых данных.

Корректировка

Теперь рассмотрим, какие бывают отклонения от методологии и как с ними бороться.

Как правило, из того, что запланировали к релизу не все успевают реализовать, что делать в данном случае:

• Провести анализ на критичность для Заказчика задач, которые не успели сделать, возможно, часть из этих задач можно перенести на следующий релиз.
• Провести анализ возможности переноса срока выпуска релиза.
• Понять почему не успели: недооценили задачу, недооценили количество требуемых ресурсов, переоценили качество выделенных на задачу ресурсов и т.д.

Что делать с нарушителями регламента?

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

Что делать с новыми ошибками, которые пропустили в результате тестирования?

1. Проанализировать их критичность
2. Попытаться найти способ их обхода
3. Проанализировать трудоемкость их исправления. Возможно, все ошибки несложно поправить и можно оперативно выпустить новый релиз

Резюме

• Каждый участник должен отвечать за свой кусок в проекте и у каждой задачи должен быть один ответственный на каждом этапе
• Перед началом кодирования все участники проекта должны договориться о правилах коллективной разработки — согласовать регламент разработки
• Обязательно используйте трехсистемный ландшафт
• Не экономьте время и деньги на тестировании