Правила работы в системе

Начало работы

• Работа начинается с регистрации в системе управления требованиями через вступительное тестирование.
• После регистрации вы получаете сообщение с логином и паролем для входа в систему. В этот момент пользователь находится в роли «Кандидат».
• При успешном прохождении вступительного тестирования пользователю назначается роль сотрудник». В этот момент после авторизации в системе становится доступен список задач, открытых для предложения концепции решения.

Работа в системе управления требованиями, получение задач

Разработчики предлагают концепции решения задач в открытых задачах (разработки, анализа, тестирования — по желанию). Из предложенных сотрудниками концепций руководитель выбирает наиболее подходящую, руководствуясь следующими соображениями в порядке убывания важности:

• содержание концепции — отражает степень понимания специалистом условия задачи;
• планируемый срок сдачи — планируется очередь фиксирования результатов;
• планируемые времязатраты к оплате — оценивается, насколько указанные трудозатраты соответствуют концепции решения, сроку выполнения и реальной трудоемкости задачи: исходя из этих соотношений руководитель делает вывод — правильно сотрудник оценивает задачу или недооценивает/переоценивает ее трудоемкость.

Переданная на выполнение задача становится доступна разработчику в списке «Мои задачи».

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

Производит компиляцию файла конфигурации 1cv8new.cf для платформы 8.х, 1cv7.new.md для платформы 7.7 производится с помощью команды -c (compile) средства сборки/разборки конфигураций v8parser.exe для платформы 8.х, gcomp.exe для платформы 7.7

Конфигурирование, внесение изменений

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

• Загружает собранную в п. 4 конфигурацию в пустую базу 1С («база для разработки») (команда «Загрузить конфигурацию из файла»)
• Вносит изменения требуемые для решения задачи в конфигурацию «базы для разработки».
• Готовит изменения для отправки в центральный репозиторий:
  • Сохраняет файл конфигурации из своей «базы для разработки». (команда «Сохранить конфигурацию в файл»)
  • Обновляет свою локальную копию репозитория (каталог п. 3) для получения доработок, внесенных другими разработчиками за время его работы.
  • Собирает актуальный файл конфигурации с учетом доработок других разработчиков, загружает в пустую базу, отличную от базы п. 5.1. («дизайн-копия»).
  • Переносит свои изменения в актуальную конфигурацию из репозитория (команда «Сравнить/Объединить с конфигурацией из файла», где в качестве файла конфигурации указывает свою конфигурацию из «базы для разработки»)
  • Сохраняет полученную в итоге слияния конфигурацию в файл.
  • Разбирает (декомпилирует) конфигурацию п. 5.3.5 с помощью команды -d (decompile) средства сборки/разборки v8parser.exe или gcomp.exe в каталоге, отличном от п. 3 — локальной копии репозитория
  • Каталоги конфигураций п. 5.3.6 (с доработками) и п. 3 (локальная копия репозитория) сравниваются при помощи внешнего средства сравнения (KDiff, Araxis Merge): выдается список измененных, добавленных и удаленных файлов.
  • Изменения п. 5.3.7 фиксируются в локальной копии репозитория (каталог п. 3). На этом подготовка к отправке заканчивается:изменения готовы к отправке.
• Изменения файлов п. 5.3.8 фиксируются в центральном репозитории проекта в CVS (команда Commit). В этот момент в RMS автоматически добавляется сообщение с комментарием коммиту (он должен быть содержательным и отражать суть внесенных изменений), времязатратами к оплате и флагом решения задачи.

Учет рабочего времени и оплата

Время к оплате суммируется по всем решенным разработчиком задачам.

Выплату мы производим по запросу разработчика при условии достижения границы фактически отработанного времени в 20 и более часов.

В случае, если разработчик не планирует продолжать работу в системе и все взятые им в разработку задачи решены — мы произведем выплату, даже если фактически отработанное время меньше 20 часов.

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

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