Как разработчик, что я могу сделать с плохими/отсутствующими требованиями от владельца продукта?

Задавать вопросы.

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

Например, если вы играете в покер с планированием, ваша колода может содержать ?карту. Играйте в нее всякий раз, когда требования недостаточно точны для оценки, и задавайте дополнительные вопросы. Точно так же, если разные люди дают совершенно разные оценки, потому что они по-разному понимают требования, им следует обратиться к PO за разъяснениями.

Вопросы, которые не влияют на усилия по реализации, можно задавать во время спринта (поэтому заказ на покупку должен быть доступен для вопросов).

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

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

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

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

Одна вещь, которую вы можете сделать, это попытаться сократить цикл отказа. Из вашего вопроса не ясно, где возникают проблемы. Но, в качестве конкретного примера, Джейкоб Нильсен ( https://www.nngroup.com/ ) [отказ от ответственности: никакой связи, никакой выгоды для меня] уже более 10 лет публикует информационный бюллетень о тестировании пользовательского опыта и дизайне UX. Он дает конкретные советы о том, как создавать прототипы пользовательских интерфейсов и как проводить UX-тестирование «по дешевке».

Может случиться так, что если вы посидите с кем-нибудь со стороны пользователя и проработаете макет прототипа с бумажным документом и несколькими вырезанными из бумаги кнопками и меню, это может сэкономить вам значительные усилия по проектированию/переделке.

Аналогичные параметры моделирования есть и в других аспектах вашего программного обеспечения. Например, если ваши проблемы возникают из-за проблем с бухгалтерским учетом, может быть, примитивная модель, встроенная в электронную таблицу, могла бы облегчить работу. («О, мы должны применить налог с продаж? Хорошо, давайте добавим это в строку 22».)

Честно говоря, похоже, что вы, ребята, делаете что-то немного неправильно, потому что не должно быть возможности попасть в ситуацию, которую вы описываете. Если владелец вашей системы устанавливает требования, вам нужно отказаться от них и больше работать над пользовательскими историями. Если есть пользовательская история, и кто-то пытается ее изменить, ТОГДА вы бросаете им вызов: как эта пользовательская история могла измениться? Это действительно изменение пользовательской истории или это новая пользовательская история с немного другими обстоятельствами?

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

Прежде всего, вы не одиноки, и в каком-то смысле возможность адаптировать свою работу, когда появляются новые элементы, — это как раз одна из причин, по которой используются такие фреймворки, как Scrum. Тем не менее, у вас есть несколько способов смягчить проблему:

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

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

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

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

PS

Я весьма озадачен забвением некоторых ответов. «Ничего не поделаешь» — худшее проявление профессионализма в таких случаях.

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

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

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

Это скорее проблема, так как предполагает, что у вас нет никого, кто бы хорошо разбирался в системе. Это действительно должно быть поймано на этапе уточнения задач. Если ни у заказчика, ни у PO нет понимания, чтобы следить за этими проблемами, вам следует привлечь разработчиков (или хотя бы одного разработчика с необходимым пониманием, например, «ведущего архитектора») к процессу уточнения. Выделение большего количества времени команды на подготовку бэклога может помочь, если ваша практика в принципе хороша, но вам не хватает времени, чтобы подготовить достаточное количество задач, а затем заполнить оставшуюся часть бэклога спринта несозревшими задачами.

Автоматическое тестирование также может уловить некоторые из этих вещей (если вы уже тестируете для A и B, то при добавлении требования C вы должны получить конфликты, если реализация C отбрасывает A и B)

Требование более широких критериев приемлемости для задачи также может помочь спровоцировать размышления о последствиях задачи.

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

Если владелец продукта сможет ее решить, переходите к совещанию по дизайну и так далее.

В противном случае сообщите о своей ситуации скрам-мастеру на стендап-совещании, чтобы ваша команда узнала о ситуации.

Ожидание ретроспективного собрания, на котором будет поднят этот вопрос, будет пустой тратой денег и ресурсов.

Вы бы не хотели быть причиной снижения скорости спринта.