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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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