gifts2017

Внедрение типовых конфигураций с тонкой настройкой под заказчика

Опубликовал Евгений Савицкий (saveug) в раздел Управление - Управление проектом

Внедрение типовых продуктов на базе 1С часто приводит к кастомизации, то есть доработке типового продукта под потребности конкретного заказчика. Разработчики постоянно сталкиваются с различиями в процессах, особенностях использования этих продуктов, изменениями в законодательстве. Обычно одна команда работает сразу с несколькими заказчиками и дорабатывает решение удаленно. Для предоставления качественных услуг команде необходимо организовать не только процесс поддержки пользователей, но и процесс разработки, в рамках которого разрабатываются и согласовываются требования и производится тестирование, основанное на требованиях.

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

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

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

С одной стороны, баг-трекер - это просто, с ним легче всего начать наводить порядок, а с другой - требования и тестовая документация записываются в каких-то документах, о которых в команде знают единицы, и об актуальности которых сложно и дорого заботиться. Я это называю проклятьем баг-трекера - повышение зрелости процесса разработки останавливается сразу после его внедрения.

С помощью баг-трекера вам не удастся получить ответы на основные вопросы об эффективности вашей команды:

  1. Почему пользователи ожидают реализации своих требований по несколько недель, куда уходит время, как повысить скорость работы команды?
  2. Можно ли повысить эффективность команды так, чтобы еще осталось время на саморазвитие?
  3. Требуется ли увеличение команды или необходимо оптимизировать процесс, изменить работу с клиентами, внедрить практики, повышающие продуктивность?

Выстраивание процесса

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

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

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

Далее необходимо визуализировать процесс разработки на Kanban доске, то есть сделать прозрачными все этапы работ, включая сведения о том, кто чем занят. Это позволит понять на какой стадии находится требование, куда уходит время.

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

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

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

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

Индивидуальные проектные артефакты

С одной стороны, для организации работы команды нужна общая Kanban-доска, но с другой - каждое внедрение требует индивидуального набора проектных артефактов. Представитель заказчика может оценить важность только тех заявок, которые получены от пользователей его организации, поэтому работает только с бэклогом заявок своей организации.

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

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Дмитрий Воронцов (informa1555) 08.12.15 20:15
А что за софтина? Я для 1Ски на СКД писал канбан деск для пр-ва примерно в таком же виде.
2. Валерий Дяченко (davealone) 09.12.15 09:54
3. Артано Майаров (Артано) 09.12.15 09:56
(1) На скринах видно же - софт от "Devprom", и если мне не изменяет память, автор является участником команды этой компании. Так что можем считать эту статью хорошим прикладным рекламным примером
5. Артур Хасанов (gigabyte_artur) 09.12.15 12:28
В качестве баг-треккеров пользовался указанной программой, СППР (http://v8.1c.ru/model/) и Битрикс-24 (https://www.bitrix24.ru).
Битрикс-24 хорош тем, что он быстрый, лёгкий и достаточно универсальный. Подходит для частной практики и небольших проектов.
СППР - напротив, очень мощный и тяжелый продукт. Мы несколько часов настраивали проект, но силы окупились с лихвой. Преимущество в лёгкой кастомизуемости (1С всё же...) и обширной аналитике на любой вкус.
Указанной программой пользуемся несколько недель. Пока сильно непривычно и хочется вернуться на СППР...
6. ivanov660 ivanov660 (ivanov660) 09.12.15 16:02
Внесу некоторые замечания:
1. Никак не соглашусь что баг-трекер это просто. Возможно Вы не пользовались полным функционалом, или не стали навастривать среду полностью, или просто реклама (правильная фраза - необходим порядок и настройка окружения).
2. Мы используем систему баг трекинга JIRA для которой атласины предоставляют широки функционал и набор плагинов. Для ведения документации необходимо использовать конфлюэнс. Хоть не люблю рекламу, но где-то на этом портале Лустин выкладывал ролик демонстрирующий полноценный вариант подхода к разарботке на 1с с помощью продуктов атласиан и в частности jira.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа