В данной статье речь пойдет о процессе добавления новой функциональности в программу. Мы рассмотрим все стадии от зарождения идеи до релиза, включая донесение требований аналитиками до тех, кто собственно всё это дело и должен претворять в жизнь, то есть до наших любимых (без кавычек и иронии) разработчиков. Статья в первую очередь нацелена на передачу практического опыта (в том числе неудачного) построения данного процесса.
КДПВ (эта картинка актуальности не потеряет, наверно, никогда):
Disclaimer: всё нижеприведенное описание процессов основано на личном опыте автора, полученного в конкретной компании и могут не иметь ничего общего с объективной реальностью читателя. Информация о каждой стадии разработки подана в сжатом виде и призвана раскрыть только основные моменты процесса в рамках одной статьи.
Стадии
В начале было слово...
Для себя я выделяю 3 стадии возникновения новой функциональности (aka «фичи»):
1. Есть идея, описанная в общих чертах.
Например: «Добавить в программу поддержку email-уведомлений».
2. Идея прорабатывается с точки зрения пользователя, то есть пишутся сценарии использования.
Например: «При завершении определённых операций в программе будет отсылаться e-mail на указанный пользователем адрес через заранее заданный SMTP-сервер».
3. Идея объясняется разработчикам/тестерам и начинается непосредственно реализация.
Соответственно, для того, чтобы дойти до 3-ей стадии, аналитику требуется досконально изучить предметную область и в первую очередь для себя понять как «оно» будет работать с точки зрения пользователя и в том числе (в меньшей степени) с точки зрения разработки. Недостаточная проработка требований на первом этапе может привести к тому, что реализованная функциональность будет работать совсем не так, как ожидалось аналитиком, а только так, как её понял разработчик (что, к сожалению, в современном мире происходит достаточно часто).
Даже такая, казалось бы, простая «фича» без должной проработки может быть испорчена, если должным образом не проработать детали, такие как:
- Должны ли поддерживаться несколько целевых email-адресов?
- Нужно ли поддерживать SSL/TLS-шифрование?
- В результате каких конкретно операций должны высылаться email-уведомления?
- Нужна ли отсылка уведомлений по расписанию?
- Какой именно текст должен быть в уведомлениях?
- Нужны ли шаблоны при задании темы письма?
- Посылать ли лог операции в уведомлениях? Если да, то в виде текста или в качестве приложенного текстового файла?
- И т.д. и т.п.
Тем не менее, не важно, сколько времени было затрачено на первоначальную проработку требований, практически всегда всплывают неучтённые сценарии использования, особенно, если новая функциональность достаточно объёмная. Именно для этого нужно обсуждение «фичи» с разработчиками и тестировщиками, которые смотрят на новые возможности под совершенно другим углом и могут придумать сценарии, которые простому пользователю и в голову не придут. Подробнее этот процесс раскрыт в следующем отделе статьи.
Ниже приведу пример важности знания собственного продукта при проектировании новой «фичи» из реальной жизни. Предупреждаю, что будет много букв и специфичных терминов. Кому не страшно – могут заглянуть в спойлер:
В своё время была добавлена опция «Replication/cleanup inactivity time», которая по задумке должна ограничивать период, во время которого может выполняться копирование созданных бэкапов, то есть ограничить период активности таска типа «replication»/«cleanup» (например, разрешать данную операцию только с 1 до 3 ночи, чтобы не нагружать сеть в рабочие часы).
Выяснилось, что поведение данной опции отличается от ожиданий пользователей в случае, когда таска бэкапа не успевает завершиться ДО времени указанного в настройках опции «Replication/cleanup inactivity time». Вместо того, чтобы дождаться окончания таски бэкапа и не дать запуститься таску «replication», программа тормозит сам таск бэкапа и ждёт окончания периода «неактивности».
Почему же так произошло? Проблемная опция оказалась «прикручена» не к отдельной активности типа «replication», а ко всему бэкап плану целиком, что и породило данное поведение.
Этой проблемы можно было избежать, если бы было изначально поставлено условие (с учётом знания о структуре бэкап-тасков), что данная опция должна распространяться исключительно на активность типа «replication» и не влиять на другие активности. Соответственно, для постановки такого условия необходимо знание структуры бэкап-плана аналитиком, то есть ему нужно знать не только какое поведение ожидается пользователем, но и представлять в каком месте можно напортачить при реализации функционала.
Обсуждение
После составления первоначального описания (стадия №2) новой «фичи» аналитиком данный текст прочитывается и анализируется как минимум двумя людьми: разработчиком (который будет реализовывать) и тестером (который будет составлять сценарии тестирования).
Обсуждение в нашем случае проводится «на диванчиках»: аналитик и тестер и/или разработчик садятся за чашечкой айриш кофе и проясняют все спорные моменты и неточности в описании «фичи». Все результаты обсуждения документируются и приводят к изменениям в изначальном описании. Подробнее про оформление описания (и не только) читайте в следующей секции.
— Почему это не протестировано?
— А вы сказали, что данный сценарий не валиден и его можно исключить!
— Когда это я такое говорил?!
— Вот, пожалуйста, аудиозапись. У нас все ходы записаны.
Оформление и сопровождение
У себя мы используем JIRA для отслеживания всех активностей (багов, QA-тасков, тикетов от техподдержки и т.д.), ведения статистики, построения метрик. Confluence же используется для описания процессов, внутренней документации, описания функциональных требований и т.д.
Связка JIRA<->Confluence была выбрана за большую гибкость в построении связей между элементами этих двух систем. Например, в Confluence можно построить таблицу по заранее заданным фильтрам из JIRA, построить красивые графики и отслеживать статус нескольких JIRA-проектов на одной странице. К тому же встроенный текстовый редактор Confluence намного более гибок, чем его аналог в JIRA и поэтому лучше подходит для описания функционала.
Жёстких правил в описании нового функционала в Confluence не существует, но есть шаблоны, которым рекомендуется придерживаться. Вот пример нашего шаблона:
Заголовок, привязка к тикету в JIRA, и основные цели:
Информация по маркетингу и инструкция по оформлению требований:
Ссылка на тикеты, в которых выполняется отрисовка пользовательского интерфейса («мокапы»), сценарии использования, функциональные и нефункциональные требования:
Оформление состоит из следующих этапов:
1. Заводится тикет типа «Epic» в JIRA с кратким описанием требуемой функциональности.
2. Принимается решение, в какой версии/апдэйте будет реализована данная «фича».
3. Заводится страница в Confluence по шаблону (пример выше) и заполняется аналитиком с расписыванием всевозможных сценариев в свободной форме.
4. Страница в Confluence показывается тестерам (QA) и разработчикам для изучения и составления тестовых сценариев.
5. В JIRA создаются тикеты вида «dev task» связанные с исходным «Epic»-ом и проставляются оценки.
Далее осуществляется непосредственно разработка, по окончанию которой функциональность передаётся тестерам, чтобы «прогнать» её по заранее созданным сценариям.
При этом между шагами 1 и 2 может пройти значительное время, с учётом того, что новой функциональности много и в первую очередь необходимо реализовывать «фичи» с наивысшим приоритетом зависящим от текущих целей компании.
Разработка
В нашем случае разработка делится на множество итераций (спринтов) длиной 2-4 недели, по окончании которых производится демонстрация. Основная цель демонстраций – убедиться в том, что разрабатываемая функциональность соответствует изначальной задумке и не возникло дополнительных рисков. То есть мы придерживаемся (стараемся во всяком случае) принципов agile-разработки.
Наши разработчики к таким демонстрациям на первых порах относились скептически, считая это пустой тратой времени, но, как показала практика, именно во время демонстраций возникают дополнительные идеи, выявляются упущенные сценарии и можно синхронизировать видение всех участников процесса (аналитиков, тестеров, разработчиков и начальства).
В процессе разработки, особенно если функциональность объёмная, может возникнуть необходимость изменений в первоначальных требованиях (для обеспечения их совместимости с реальностью). Все изменения документируются в Confluence/JIRA и в соответствии с ними корректируются оценки задач.
Релиз
Приемка «фичи» осуществляется в несколько этапов:
1. Разработчик говорит «Готово! Можно посмотреть сборке №XX»
2. Тестер прогоняет новую функциональность по составленным тестовым сценариям и заводит баги.
3. Аналитик смотрит на реализованную «фичу» с точки зрения пользовательских сценариев (по сути это формальный шаг, т.к. то же самое уже выполнялось во время демонстраций).
4. «Фича» отдаётся в другие отделы для внутреннего тестирования:
В первую очередь (после QA) все свои продукты мы тестируем на наших «продакшн-системах». Наши доблестные админы имеют возможность должны первыми вкусить все ужасы прелести новых версий и сообщить о найденных проблемах :)
Только после всех предыдущих этапов продукт считается достойным того, чтобы его увидели наши конечные пользователи.
Публичный релиз продукта сам по себе является отдельным процессом со множеством тонкостей — это больншая тема, достойная отдельной статьи.
Заключение
Просуммировав вышесказанное:
А. Тщательно продумывайте свои идеи и оформляйте их правильно (по крайней мере придерживайтесь одного согласованного стандарта)
Б. Общайтесь с программистами и тестировщиками в течение всего времени разработки
В. Проводите промежуточные демонстрации не дожидаясь окончания срока выделенного на разработку продукта
Г. Пейте айриш кофе :)
Если вы используете схожую методологию при разработке продукта, расскажите, как можно было бы улучшить-ускорить-оптимизировать процесс в комментариях.
Автор: chineek
