При работе над пользовательскими историями очень легко допустить ошибки.
Если ошибка не будет выявлена до начала разработки, желаемый результат может быть вообще не получен.
В голове аналитика детали проекта просты и понятны, но на практике их не всегда можно адекватно выразить в виде пользовательской истории.
Сегодня мы поговорим о том, как можно предотвратить возникновение ошибок до или на ранних этапах разработки приложения.
Для достижения этой цели существуют и используются различные методы, помогающие выявить потенциальный недостаток до того, как он проявится.
Многие из этих техник описаны в новой книге Гойко Аджича « Пятьдесят быстрых идей по улучшению ваших тестов С нашей точки зрения, наиболее эффективными оказались два подхода: проведение стартовой встречи и Desk Check (анализ историй «за столом»).
Лучше просмотреть проанализированные истории еще раз, поэтому хорошей идеей будет встреча команды, на которой аналитик (или другой член команды, имеющий представление о проекте) представит предполагаемые истории, опишет их ценность, происхождение и объяснит, почему они нужны.
Это даст команде возможность обсудить технические аспекты и задать вопросы, чтобы прояснить некоторые требования и оценить масштаб истории.
Все замечания и комментарии, полученные в ходе встречи, можно принять во внимание, чтобы разбить историю на несколько частей или, наоборот, добавить к ней больше деталей и примеров, то есть прояснить места, вызвавшие затруднения.
Стартовая встреча
На этом этапе рассматривается список вопросов (состоящий из нескольких пунктов), на которые необходимо ответить перед началом разработки.Вопросы могут быть следующего характера: завершен ли анализ историй и можно ли начинать разработку? На какие технические решения стоит обратить особое внимание при разработке? Достаточно ли информации о визуальном дизайне? Как бороться с сообщениями об ошибках и подсказками?
Эта проблема часто возникает, когда разработчик не делится своими идеями и не согласовывает их с аналитиком (возникает недопонимание).Вот почему перед запуском проводится встреча, на которой команда может пообщаться и поделиться своими мыслями.
Это позволяет учесть все тонкости и важные детали; Каждый член команды играет свою роль и имеет свои собственные идеи для историй.
В идеале на стартовой встрече должны присутствовать бизнес-аналитик, инженер по обеспечению качества и разработчики, тогда они все ознакомятся с разрабатываемым функционалом приложения.
Это сделает обсуждение более продуктивным и полезным.
Вот пример нашего списка вопросов, обсуждавшихся на стартовом совещании:
- Завершен ли анализ истории?
- Была ли история проверена инженером по контролю качества?
- Включены ли все детали истории и вся ли информация верна?
- Насколько очевидна ценность истории?
- Зависит ли история от последующих историй?
- Есть ли технический долг?
- Есть ли макет рассказа?
- Отражаются ли в истории сообщения об ошибках и другие отзывы пользователей?
- Определяются ли подсказки и маркеры историей? Где это отражено?
- Устраивает ли команду длина истории?
Важно помнить (особенно для более крупных историй), что вы можете следить за ходом разработки, чтобы убедиться, что все идет по плану.
Постарайтесь, чтобы комментарии команды не выходили за рамки рассказа, а если это произойдет, то, скорее всего, анализ был проведен не очень тщательно.
Кабинетная проверка
Этот тип анализа проводится только тогда, когда команда разработчиков уверена, что разработка завершена.Приведенный ниже список включает следующие вопросы: Было ли проведено приемочное тестирование? Проведено ли модульное тестирование? Вы приглашали кого-нибудь просмотреть ваш код? Был ли продукт протестирован во всех (популярных) браузерах? Эти вещи важны и помогают избежать проблем в будущем.
Например, тот или иной функционал приложения будет нормально работать в Chrome, но будет отображать ошибки в Internet Explorer, поскольку последний не поддерживает используемые вами библиотеки.
Участники: бизнес-аналитик, разработчики, заинтересованные лица.
- Было ли проведено достаточное количество тестов?
- Проверялся ли код другой командой разработчиков?
- Была ли история проверена «вручную»?
- Влияет ли история на что-нибудь еще?
- Все ли требования клиентов были учтены?
- Нуждается ли история в комментариях или исправлениях?
- Был ли протестирован весь пользовательский опыт?
- Соответствует ли пользовательский интерфейс приложению?
- Приложение работает во всех основных браузерах?
- Соответствует ли текст истории всем меткам и ярлыкам в приложении?
- Была ли проверка на грамматические ошибки?
- Соответствует ли цветовая схема остальным цветам приложения?
Однако мы рекомендуем обратить особое внимание на стартовую встречу, поскольку именно здесь становятся очевидными все разногласия, которые могут привести к далеко не идеальному результату.
Обратите внимание, что приведенные выше примеры являются лишь примерными вопросами, и вы не должны использовать их в качестве справочного материала.
Преимущество этого подхода заключается в том, что можно проверить, что все важные шаги были учтены в процессе разработки.
Еще следует помнить, что все эти списки должны быть персонализированы, поскольку каждый проект имеет свои особенности и цели.
Попробуйте создать свои собственные и посмотрите, как они повлияют на качество вашей разработки.
Сделайте это привычкой, и это станет навыком.
Объявление: 16 сентября 2015 (среда) в 18:30 в Акселераторе ФРИИ пройдет мастер-класс с экс-главой направления мобильных и десктопных продуктов LinguaLeo, основателем AppCraft и гуру метрик — Ильей Красинским.
Тема: «Продуктовая аналитика: как сделать правильные выводы и сфокусироваться на точках многократного роста».
Постановка на учет бесплатно.
Теги: #agile #разработка #Управление проектами #agile #Управление электронной коммерцией
-
«У Меня Есть Все, Что Мне Нужно»
19 Oct, 24 -
Рабочий День За 3 Часа. Инструменты Гтд
19 Oct, 24 -
Какая У Вас Скорость Интернета?
19 Oct, 24
