Какие методики разработки используете Вы?
Добрый день, коллеги.
Хотелось бы узнать как у вас проходит процесс разработки.
Наибольший интерес конечно к разработчикам типовых решений (надеюсь они здесь отпишутся) либо к средним/крупным командам разработки/внедрения. Прошу рассказать про используемые методы проектирования, трекеры/багтрекеры, методы разработки (используется ли модный нынче scrum?). Какие используются стандарты/правила разработки? Как агрегируется информация о различных проектах (допустим несколько внедрений), ошибки?
При ответе, указывайте, пожалуйста сферу деятельности (разработка типовой конфигурации, отраслевого решения, внедренцы, франчайзи).
Для примера опишу нашу ситуацию:
Платформа 8.2 (управляемый интерфейс).
Разрабатываем типовое отраслевое решение, также проводим внедрения своего продукта. Команда чуть более 10 человек. Внедрением занимаются те же исполнители, что и разработчики тиражного решения.
Часть идей, полученных в результате внедрений реализуются и в тиражном решении.
Разделение рабочих обязанностей скорее идет по подсистемам, чем по объектам внедрения (хотя есть и исключения).
Задачи поступают или через трекер или по телефону. Довольно часто поступают "очень срочные" задачи (исправление ошибок, реже новый функционал), которые надо выполнять "прямо сейчас", следовательно приходится откладывать запланированные.
Для регистрации ошибок по каждому из мест внедрения есть отдельный трекер + трекер для тиражного решения (большинство redmine, по трекеру на jira, rt).
По поводу долгосрочного планирования - используется опять же трекер тиражного решения (т.е. просто указываем что необходимо сделать).
В дополнении к этому есть "трекер" в виде excel-таблицы в который поступают задачи с "поля боя" (когда идет общение с заказчиками) - тут как раз задачи, которые надо сделать "прямо сейчас".
Как понимаете, информация по различным внедрениям и тиражному решению никак не агрегируется, задачи для разработчиков тоже (т.е. приходится постоянно просматривать все трекеры, либо читать письма, которые посылаются автоматом при изменении заявок).
По поводу стандартов разработки – стараемся соблюдать 1С-Совместимо, иногда проводится «разбор полетов» с рассмотрением конкретных участков кода и их анализом. Как таковых правил нет.
Хочется улучшить положение дел, поэтому решил поинтересоваться у сообщества - как у Вас происходит разработка?
Хотелось бы узнать как у вас проходит процесс разработки.
Наибольший интерес конечно к разработчикам типовых решений (надеюсь они здесь отпишутся) либо к средним/крупным командам разработки/внедрения. Прошу рассказать про используемые методы проектирования, трекеры/багтрекеры, методы разработки (используется ли модный нынче scrum?). Какие используются стандарты/правила разработки? Как агрегируется информация о различных проектах (допустим несколько внедрений), ошибки?
При ответе, указывайте, пожалуйста сферу деятельности (разработка типовой конфигурации, отраслевого решения, внедренцы, франчайзи).
Для примера опишу нашу ситуацию:
Платформа 8.2 (управляемый интерфейс).
Разрабатываем типовое отраслевое решение, также проводим внедрения своего продукта. Команда чуть более 10 человек. Внедрением занимаются те же исполнители, что и разработчики тиражного решения.
Часть идей, полученных в результате внедрений реализуются и в тиражном решении.
Разделение рабочих обязанностей скорее идет по подсистемам, чем по объектам внедрения (хотя есть и исключения).
Задачи поступают или через трекер или по телефону. Довольно часто поступают "очень срочные" задачи (исправление ошибок, реже новый функционал), которые надо выполнять "прямо сейчас", следовательно приходится откладывать запланированные.
Для регистрации ошибок по каждому из мест внедрения есть отдельный трекер + трекер для тиражного решения (большинство redmine, по трекеру на jira, rt).
По поводу долгосрочного планирования - используется опять же трекер тиражного решения (т.е. просто указываем что необходимо сделать).
В дополнении к этому есть "трекер" в виде excel-таблицы в который поступают задачи с "поля боя" (когда идет общение с заказчиками) - тут как раз задачи, которые надо сделать "прямо сейчас".
Как понимаете, информация по различным внедрениям и тиражному решению никак не агрегируется, задачи для разработчиков тоже (т.е. приходится постоянно просматривать все трекеры, либо читать письма, которые посылаются автоматом при изменении заявок).
По поводу стандартов разработки – стараемся соблюдать 1С-Совместимо, иногда проводится «разбор полетов» с рассмотрением конкретных участков кода и их анализом. Как таковых правил нет.
Хочется улучшить положение дел, поэтому решил поинтересоваться у сообщества - как у Вас происходит разработка?
По теме из базы знаний
- Как заставить разработки работать
- Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST
- Какими критериями стоит руководствоваться при выборе партнера на проект по автоматизации? Часть 1.
- Применение cтандартов и методик разработки конфигураций на практике
- Шаблоны для применения cтандартов и методик разработки конфигураций 1С
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Может я знаю, плохо redmine, но разве проектами нельзя решить проблемы различных версий и инсталяций redmine?
p.s. в своей схеме вы пропустили процесс работы с хранилищем, проверку конфигурации перед релизом, code-review.
p.s. в своей схеме вы пропустили процесс работы с хранилищем, проверку конфигурации перед релизом, code-review.
(2) спасибо за замечания. Действительно можно, но наша проблема состоит в том, что как минимум используется не только redmine.
Хранилище у нас используется только для тиражного решения. Разработка для проектов внедрений ведется напрямую с базами заказчиков (что чаще), либо же в тестовых базах и потом идет перенос в реальную систему. Проверка перед релизом осуществляется в основном путем ручного тестирования, проходит небольшое юнит-тестирование (связанное с заполнением демобазы) и самописная автоматическая проверка требований 1С-совместимо. Code-review как такового не предусмотрено, занимаемся рефакторингом как только "петух ужалит", т.е. если надо изменить логику существующего кода, а там ничего не понять или код реально неоптимален и это заметили мы или клиенты.
Хранилище у нас используется только для тиражного решения. Разработка для проектов внедрений ведется напрямую с базами заказчиков (что чаще), либо же в тестовых базах и потом идет перенос в реальную систему. Проверка перед релизом осуществляется в основном путем ручного тестирования, проходит небольшое юнит-тестирование (связанное с заполнением демобазы) и самописная автоматическая проверка требований 1С-совместимо. Code-review как такового не предусмотрено, занимаемся рефакторингом как только "петух ужалит", т.е. если надо изменить логику существующего кода, а там ничего не понять или код реально неоптимален и это заметили мы или клиенты.
Использую redmine, с иерархией проектов. Для разработки в хранилище как минимуму у меня содержится 3 подпроекта: разработка конфигурации, разработка внешних отчетов/обработок, пользовательская документация, тесты.
Все четыре подпроекта связаны с git соответственно: хранилище 1с -> git->на сервер с redmine, папка с внешними обарботками находится под версионым контролем git, папка с пользовательской документацией тоже, папка с тестами тоже с git.
Каждая задача закрываемая при помещении в хранилище или commit в git привязывается к номеру задачи redmine(автоматически закрывается или если долгоиграющая, просто привязывается refs).
Для каждого заказчика создается новая ветка в git и своя структура подпроектов.
Стабильно используются как минимум 2 хранилища master(он же релизный) и dev - основная активная разработка, при релизе, вся dev переноситься в master с выпуском обновления.
(методика взята с git-flow).
У каждого заказчика всегда используется хранилище(или на наших серверах или у заказчика), если это конечно не 1 раз пришел и потом забыл/забил на полгода/год.
В redmine несколько видов задач, отдельно отделяем, по виду задач определяем что переходит в разработку и что на "подумать" или генераторы идей. Внешние пользователи создают только один вид задачи, для разработчика создается новая задача с детальным описанием и ссылкой на задачу заказчика.
p.s.: тема у вас про методику, а в описании спрашиваете про процесс.
Все четыре подпроекта связаны с git соответственно: хранилище 1с -> git->на сервер с redmine, папка с внешними обарботками находится под версионым контролем git, папка с пользовательской документацией тоже, папка с тестами тоже с git.
Каждая задача закрываемая при помещении в хранилище или commit в git привязывается к номеру задачи redmine(автоматически закрывается или если долгоиграющая, просто привязывается refs).
Для каждого заказчика создается новая ветка в git и своя структура подпроектов.
Стабильно используются как минимум 2 хранилища master(он же релизный) и dev - основная активная разработка, при релизе, вся dev переноситься в master с выпуском обновления.
(методика взята с git-flow).
У каждого заказчика всегда используется хранилище(или на наших серверах или у заказчика), если это конечно не 1 раз пришел и потом забыл/забил на полгода/год.
В redmine несколько видов задач, отдельно отделяем, по виду задач определяем что переходит в разработку и что на "подумать" или генераторы идей. Внешние пользователи создают только один вид задачи, для разработчика создается новая задача с детальным описанием и ссылкой на задачу заказчика.
p.s.: тема у вас про методику, а в описании спрашиваете про процесс.
(4), согласен с Вашим замечанием, но интересно и то и то.
Особенно интересно как реализована связка git-хранилище. У Вас реализованы какая-то регламентная выгрузка в git изменений (допустим по ночам) или что-то другое имелось ввиду? Используется Gitter( или что-то другое или самописное? Можно как-то отследить изменения в макетах и формах или только исходный код модулей? Номер задачи пишите номером или ссылкой на задачу? Для каждого ли коммита пишите номер задачи (это является обязательным требованием)? Если пишете номер всегда, дополняете ли к нему словесное описание?
Как реализовано "задача закрываемая при помещении в хранилище ... привязывается к номеру задачи redmine(автоматически закрывается...)"?
Под тестами подразумеваете юнит-тесты или сценарное тестирование? Что у Вас прижилось?
p.s.: Извиняюсь за столь большое число вопросов, просто связка хранилище 1с-git уж очень заинтересовала.
Особенно интересно как реализована связка git-хранилище. У Вас реализованы какая-то регламентная выгрузка в git изменений (допустим по ночам) или что-то другое имелось ввиду? Используется Gitter( или что-то другое или самописное? Можно как-то отследить изменения в макетах и формах или только исходный код модулей? Номер задачи пишите номером или ссылкой на задачу? Для каждого ли коммита пишите номер задачи (это является обязательным требованием)? Если пишете номер всегда, дополняете ли к нему словесное описание?
Как реализовано "задача закрываемая при помещении в хранилище ... привязывается к номеру задачи redmine(автоматически закрывается...)"?
Под тестами подразумеваете юнит-тесты или сценарное тестирование? Что у Вас прижилось?
p.s.: Извиняюсь за столь большое число вопросов, просто связка хранилище 1с-git уж очень заинтересовала.
(5) ojiojiowka, посмотрите, там есть весь необходимый инструментарий .
номер задачи просто знак диез и номер, примерно можно посмотреть здесь , временной лаг между помещением и привязки 10-20 минут.
Словесное описание - всегда.
Ну и будет интересная тема "Автоматическая сборка и развертывание на платформе 1С ", если вдруг будете на эвенте.
номер задачи просто знак диез и номер, примерно можно посмотреть здесь , временной лаг между помещением и привязки 10-20 минут.
Словесное описание - всегда.
Ну и будет интересная тема "Автоматическая сборка и развертывание на платформе 1С ", если вдруг будете на эвенте.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот