Ошибки - одно из самых раздражающих и распространенных явлений при разработке программного обеспечения.

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

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

В этой статье мы обсудим стратегии, которые вы можете использовать для эффективного отслеживания и устранения ошибок при работе в среде Agile .

Гибкое мышление над гибкой методологией

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

Сегодня большинство команд приняли Agile-модель в соответствии с их настройками и контекстом.

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

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

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

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

Стратегии гибкого отслеживания ошибок

Четыре стратегии отслеживания ошибок, описанные ниже, основаны на концепциях Agile, которые вы можете вписать в свой собственный процесс разработки, независимо от того, какой методологии вы придерживаетесь.

1. Убедитесь, что все заинтересованные стороны понимают ошибки проекта.

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

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

Как отмечает Джоэл Спольски , генеральный директор Stack Overflow, «ведение базы данных об ошибках - отличительная черта хорошей команды разработчиков».

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

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

2. Расставьте приоритеты в отношении ошибок по их влиянию на вашу систему.

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

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

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

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

3. Обращайте пристальное внимание на ранние отзывы пользователей.

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

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

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

4. Предоставьте разработчикам право собственности на проблемы.

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

Управление продуктами 101

Предоставление разработчикам права собственности на проблему позволяет им быстро решить ее, не теряя времени. Этот метод также способствует более быстрой обработке результатов на основе собранных отзывов и внутренних проверок.

Гибкий и адаптируемый

Agile - это не только более быстрая доставка программного обеспечения. Речь идет о более быстрой доставке качественного программного обеспечения. Для этого командам необходимо иметь необходимые настройки и инструменты, чтобы они могли быстрее менять задачи.

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

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

Мне бы хотелось услышать отзывы от команд на местах: как вы быстро отслеживаете ошибки? Есть ли какие-то методы, которые помогут вашей команде быть гибкой, когда дело доходит до решения проблем? Дай мне знать в комментариях.