Требования
Вредные советы аналитику: как написать непонятные требования
Доклад был на прошедшей конференции Analyst Days 19 и сейчас находится в архиве.
Как часто вы сталкиваетесь с тем, что: Команда неоднократно разворачивает задачу, которую вы ей принесли. Команда взяла задачу в разработку, разработчик сделал одно, тестировщик протестил другое, а выяснилось это на Демо, и Заказчик был совсем не рад. Количество времени, потраченное на объяснение команде больше, чем время, потраченное на описание задачи В своем докладе я поделюсь своими инструментами, которые помогли мне свести к нулю такие кейсы. Вредные советы аналитику: как написать непонятные требования from Vladislav Orlikov
Другие доклады Analyst Days 19
HR, развитие карьеры и профессиональный рост
В чем смысл цели?
Секция A (300 чел.)
Аналитик как часть команды
Баланс интересов: пути разрешения конфликтов при проектировании OpenAPI
Секция B (300 чел.)
Архитектура
Сквозной вопрос. Или как не упустить тот самый АСПЕКТ при проектировании микросервисов
Секция C (200 чел.)
Методологии
Методика перепроектирования приложений с User Story Map и HADI-циклом в подходе Agile
Секция C (200 чел.)
Требования
Зачем так много шаблонов?
Секция D (X5 Tech) (190 чел.)
Специализированные навыки
Мастер-класс: Визуализация данных: убеждает или обманывает
Секция E (мастер-классы) (120 чел.)
Инструменты
Проектировочная документация – практический опыт и проверенные шаблоны
Секция A (300 чел.)
Требования
Декомпозируем истории и создаем User story map для фитнес-аппа
Секция B (300 чел.)
