новых фичей?
В контексте всеобщей погони за T2M, job stories, use cases, acceptance criteria все же не являются исчерпывающими конструкциями которые могут хранить знания компании.
Основные вопрос ведётся ли подробная документация всей системы, кем она ведётся т.к это довольно объемная работа и когда( параллельно реализации или сразу после).Интересно послушать опыт и подходы.
Подходы вы сами придумать можете. Собственно, вы их уже перечислили. Вопрос в плюсах, минусах и как выбрать в каждом конкретном случае.
Обычно хранят описания всех требований к системе в некотором систематизированном виде. Каждый продукт изменяющий систему сохраняет свой инкремент. Обычно делает это аналитик/технолог+немного разрабы. Тестовые кейсы - тестировщики
Эти методы подходят что бы сказать что делать сейчас, но не годятся для хранения знаний, они не являются исчерпывающими.
Если говорить про требования, то по большому счету есть два варианта описания требований - императивный и декларативный. Первый вариант очень любят использовать, потому что в нем для инкремента нужно написать только то, что нужно изменить. "Перекрасить кнопку в красный цвет, сдвинуть вправо". По этим требованиям через некоторое время уже не понять, как работает система. Второй - требования сразу описывают все поведение системы, а при каждом инкременте в них вносятся изменения и выделяются. Тогда для каждой поставки видно, какой набор требований, а по сути описание системы ей соответствует.
Согласен, попалась мне команда которой PO перед тем как отдать в реализацию задачу (бизнес идею), провалидировав ее писал исчерпывающее ТЗ , доходило до того что там были описаны структуры данных, их типв , даже формат дат.. У инженеров за годы работы с ним сформировалась вырученная беспомощность и они не могут работать с чем-то более легковесным, что не будет ощутимо растягивать время на реализацию этой инициативы. Сейчас начали движение а сторону job stories + use cases, но вопрос все равно ещё стоит остро и не исключает написания развернутой доки постфактум
Обсуждают сегодня