Опишите задачу пользователя
Возьмём учебный каталог из трёх записей: Мир растений, История города и Мир животных. Пользователь вводит часть названия, чтобы найти нужную запись. Уже здесь следует уточнить, ищется ли совпадение в любом месте названия, учитывается ли регистр и что происходит при пустом запросе. В нашем примере поиск выполняется по любой части названия без различения регистра, а пустой запрос показывает все записи. Это выбранные условия учебной задачи, а не обязательное устройство любого поиска. Главное, что они сформулированы до реализации.
Пример связывает слова с результатом
По запросу мир ожидаются две записи, по запросу города одна. Запрос море не должен давать ни одной записи и сопровождается понятным сообщением об отсутствии результатов. Такие случаи помогают заметить расхождение раньше, чем субъективное обсуждение удобства. Если реализация показывает только названия, начинающиеся с запроса, случай города выявит ошибку относительно нашей договорённости. При этом примеры не заменяют всех требований. Нужно отдельно обозначить границы: например, исправление опечаток и поиск по описанию в текущую небольшую задачу не входят.
Несколько заказчиков нуждаются в общем решении
При совместном заказе каждый участник может добавлять пожелания, которые противоречат друг другу. Полезно назначить понятный способ согласования и хранить одну актуальную версию требований. Важно отделять обязательное поведение от дополнительных идей на будущее. Если один человек просит поиск с учётом регистра, а другой без него, нельзя передавать оба требования как одновременно согласованные. Сначала нужно выбрать правило и обновить примеры. Иначе программист получает не техническую задачу, а необходимость самостоятельно решать спор между заказчиками.
Приёмка проверяет поведение, а не впечатление от демонстрации
Во время проверки используют заранее подготовленные данные и повторяют описанные действия. Если результат отличается, сообщение о проблеме должно содержать условия, шаги, ожидаемый и фактический ответ. Фраза поиск сломан не позволяет воспроизвести ситуацию так же надёжно. Проверку лучше выполнять на тестовом наборе, не передавая реальные личные данные без необходимости. Новое пожелание также следует отличать от ошибки: если теперь нужен поиск с исправлением опечаток, это изменение задачи, а не автоматически доказанный дефект первоначальной реализации. Такое различие помогает обсуждать объём работы предметно.
Попробуйте на практике
Составьте короткое задание и проверку для учебного каталога из трёх названий: Мир растений, История города и Мир животных. Реальную разработку заказывать не требуется.
- Запишите цель пользователя и два правила поиска: совпадение в любой части названия и отсутствие различия регистра. Укажите поведение пустого запроса.
- Для запросов мир, города и море перечислите ожидаемые результаты. Добавьте понятное сообщение для отсутствия совпадений.
- Назовите одну функцию, которая не входит в текущую задачу, например исправление опечаток, чтобы не оставлять скрытого ожидания.
- Опишите вымышленную ошибку, при которой города ничего не находит. Укажите шаги, ожидаемую запись и фактический результат без общей оценки качества исполнителя.
Как проверить результат. Поиск мир даёт две записи, города одну, море ни одной, пустой запрос все три. В задании есть границы, а сообщение об ошибке позволяет воспроизвести конкретное расхождение.
Частые вопросы
Нужно ли заказчику самому писать программный код?
Для такого задания достаточно понятно описать цель и наблюдаемое поведение. Техническую реализацию обсуждают отдельно, когда это необходимо для ограничений проекта.
Можно ли менять требования после начала работы?
Изменения возможны, но их нужно явно согласовать и обновить критерии проверки. Новая идея не должна незаметно превращаться в старое обязательство исполнителя.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.