Onboardind developer - webkoth/style-guide-php-laravel GitHub Wiki

  1. Разработчики отделов распределены по командам согласно направлениям. Текущее распределение по командам закреплено в документе.

  2. Задачи разработки размещаются в Jira.

  3. Разработчик берет в работу задачи своей команды согласно приоритетам в текущем спринте. В случае отсутствия у команды задач к разработке разработчик может по согласованию со SM команды подключаться к задачам других направлений.

  4. Недопустимо переназначать на себя задачу, назначенную на другого разработчика, без уведомления этого разработчика.

  5. Типы задач в спринте, назначаемые на разработчика:

  • Задачи развития:

    • История – декомпозированная задача на разработку функциональности;
    • Enabler Story – декомпозированная задача на рефакторинг, оптимизацию функциональности и т.п.;
    • NoDevTask – задачи, на консультации и совещания, разработка в них не проводится;
    • Запрос на изменение – запросы на продуктовые доработки, разработчики участвуют для оценки задачи, разработка в них не проводится;
    • Подзадача разработки – любая подзадача на разработку;
    • Подзадача дефект – дефекты и ошибки, найденные внутри производства (устаревший тип, новые задачи по нему не создаются);
    • Дефект – дефекты и ошибки, найденные внутри производства;
    • Задача на перенос доработок – задача на перенос доработок, если перенос требуется отдельно от основной задачи.

  • Задачи сопровождения:

    • Инцидент – задача на ошибку в работе готовой функциональности;
    • NoDevTask – задачи, на консультации и совещания, разработка в них не проводится;
    • Запрос на изменение – запросы на доработки тиражирования функциональности, разработчики участвуют для оценки задачи, разработка в них не проводится;
    • Подзадача разработки – любая подзадача на разработку;
    • Подзадача дефект – дефекты и ошибки, найденные внутри производства (устаревший тип, новые задачи по нему не создаются);
    • Дефект – дефекты и ошибки, найденные внутри производства;
    • Задача на перенос доработок – задача на перенос доработок, если перенос требуется отдельно от основной задачи.
  1. В зависимости от типа задачи может отличаться workflow (последовательность смены статусов) работы над ней.
  2. Разработчики берут в работу задачи со статусами: "К разработке", "Разработка", "К переносу", "Перенос", "Code Review", "На оценку".

Разработка задач

  1. При приеме задачи в разработку разработчик меняет статус задачи на "Разработка" и заполняет у нее поля Разработчик WEB и/или Разработчик БД. В один момент времени у разработчика в статусе «Разработка» может быть только одна задача.

  2. При необходимости переключиться на другую задачу (например, неотложная задача), разработчик переводит статус текущей задачи на статус "К разработке", а статус новой задачи – "Разработка". В предыдущей задаче оставляется комментарий со ссылкой на задачу, куда переключился разработчик.

  3. Разработка ведется строго на тестовом стенде МИС.

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

  5. В случае внесения изменений по вебу, разработчик обязан комментарием к задачи приложить ссылку на pull request с подробным комментарием о проделанной работе, по БД – ссылку на коммит в dd_store, скрипт внесения правок или сформированный патч (см. правила проведения Code Review) также комментируя внесенные изменения (см. пункт Фиксация изменений и результатов).

  6. В случае проведения разработчиком настроек композиций, методов показа или других настроек стенда необходимо отписать в задаче их изменение.

  7. Если правки по вебу вносятся в БП (базовую поставку), разработчик обязан проанализировать имеющиеся у формы ЮФ (юзер формы), и в случае если правки БП приведут к неработоспособности функционала на ЮФ – подсветить информацию об этом в задаче со списком проблемных ЮФ. Если правки вносятся на ЮФ одного из регионов, разработчик должен проанализировать БП и ЮФ других регионов на наличие в них аналогичных ошибок и также подсветить эту информацию в задаче для принятия решения аналитиком о доработке.

  8. Если правки по задаче могут повлиять на функциональность, явно в ней не затронутую, включая модули других команд, информация об этом фиксируется комментарием в задаче и доносится до назначенного за проверку доработки тестировщика. Если они могут повлиять на общесистемную функциональность, информация об этом должна быть донесена до Teach Lead разработчика и PO направления, также с размещением комментария в задаче.

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

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

  11. В случае, если анализ задачи повлек корректировку постановки задачи, доработку ТЗ или описания Confluence, задачу необходимо отправить на доработку аналитику через кнопки "Вернуть на анализ" или "Анализ", и назначить на аналитика из поля "Аналитик" или, если значение не заполнено, на аналитика отписывавшего задачу к разработке.