Чтобы при разработке не упустить из виду важное требование, оперативно отреагировать на проблему пользователя, разработчики используют системы, поддерживающие процесс разработки, и чаще всего баг-трекеры. Безусловно, это лучше, чем документировать требования и ставить задачи по электронной почте, однако недостаточно для качественной разработки и кастомизации программных продуктов.
Самими дорогими для разработчика являются ошибки в исходных требованиях, поэтому при разработке и документировании требовний особое внимание уделяют их полноте и непротиворечивости, особенно, если пользователей много, и они не эксперты в постановке задач разработчикам. Разработка основанная на требованиях позволяет более точно оценить стоимость и сроки, устранить разногласия внутри команды и убедить заказчика, что его проблемы понятны разработку, зафиксировать описание системы не в чьей-то голове, а на общедоступном ресурсе.
Чтобы гарантировать качество и стабильность вашего продукта, необходимо организовать процесс тестирования на основе требований и экспертных знаний о работе приложения. Тестовая документация нужна, чтобы знания о продукте не хранились в головах сотрудников, чтобы легче вводить в процесс тестировщиков, незнакомых с функциональностью продукта. Тестовая документация должна опираться на требования, чтобы не возникали разногласия о том, как же действительно должна работать система. Тестовую документацию нужно поддерживать в актуальном состоянии.
С одной стороны, баг-трекер - это просто, с ним легче всего начать наводить порядок, а с другой - требования и тестовая документация записываются в каких-то документах, о которых в команде знают единицы, и об актуальности которых сложно и дорого заботиться. Я это называю проклятьем баг-трекера - повышение зрелости процесса разработки останавливается сразу после его внедрения.
С помощью баг-трекера вам не удастся получить ответы на основные вопросы об эффективности вашей команды:
- Почему пользователи ожидают реализации своих требований по несколько недель, куда уходит время, как повысить скорость работы команды?
- Можно ли повысить эффективность команды так, чтобы еще осталось время на саморазвитие?
- Требуется ли увеличение команды или необходимо оптимизировать процесс, изменить работу с клиентами, внедрить практики, повышающие продуктивность?
Выстраивание процесса
Вряд ли существует универсальный рецепт эффективного процесса разработки, но точно есть путь, как такой процесс выстроить именно в вашей команде или организации. Этот путь называется Kanban и состоит он из нескольких простых шагов.
Сперва вам нужно собрать все требования в общем бэклоге, то есть списке требований, включая заявки, дефекты и доработки по новым требованиям. Поскольку команда у вас одна, таким образом вы сведете все потоки работ к единой системе приоритезации.
Каждый участник команды должен понимать, над чем необходимо работать в первую очередь, а какие работы могут подождать. Система приоритезации может основываться на важности требований для закачзиков, либо на типах запросов, например, дефекты исправляются в первую очередь, затем новые требования, затем уже все остальные хотелки.
Далее необходимо визуализировать процесс разработки на Kanban доске, то есть сделать прозрачными все этапы работ, включая сведения о том, кто чем занят. Это позволит понять на какой стадии находится требование, куда уходит время.
Ключевой момент - ограничить количество незавершенной работы, то есть договориться, что разработчики не смогут брать в работу задач больше, чем смогут выполнить за один день. То же касается и остальных участников процесса: аналитиков, тестировщиков, технических писателей и т.д.
Ограничение незавершенной работы помогает избавиться от переключения контекста, избавляет от ложных ожиданий по срокам, помогает выявить узкие места в процессе. Например, если аналитик готовит требований больше, чем разработчики могут реализовать, то вы сразу заметите, как очередь готовых к разработке требований значительно вырастет.
После выполнения этих шагов команде остается анализировать и выявлять возникающие проблемы, обсуждать их на ретроспективах и совместными усилиями вырабатывать шаги по их устранению. В первую очередь необходимо сфокусироваться на устранении потерь, связанных с лишними действиями, которые не приносят ценности (пользы) заказчику, сокращать количество ручного тестирования и т.п.
Система, поддерживающая ваш процесс, следит за актуальностью документации и автоматически вычисляет среднее время решения заявки или реализации требования и позволяет следить за изменением эффективности вашей команды.
Индивидуальные проектные артефакты
С одной стороны, для организации работы команды нужна общая Kanban-доска, но с другой - каждое внедрение требует индивидуального набора проектных артефактов. Представитель заказчика может оценить важность только тех заявок, которые получены от пользователей его организации, поэтому работает только с бэклогом заявок своей организации.
Команда фиксирует в проекте требования в форме алгоритмов, UML-моделей и макетов форм, специфичные для каждого внедрения в отдельности. Представитель заказчика согласует требования к его проекту по кастомизации.
Тестовая документация тоже специфична для конкретного заказчика, а перед выпуском релиза необходимо выполнить тестирование по его доработкам, а также сделать регрессионное тестирование по ранее реализованным доработкам.
Таким образом, проектные артефакты специфичны для каждого из проектов внедрения, и доступ к ним предоставляется только команде и представителям заказчика.
