Мы планируем принять пользовательские истории, чтобы отразить «намерение» заинтересованных сторон, а не тяжелую SRS (спецификации требований к программному обеспечению). Тем не менее, кажется, что, хотя они понимают ценность историй, все еще есть желание «преобразовать» истории в SRS-подобный язык со всеми атрибутами, приоритетами, входами, выходами, источником, местом назначения и т. Д.
Пользовательские истории «устраняют» необходимость в формальном SRS-подобном артефакте для начала, так какой смысл иметь SRS? Как я должен убедить мою команду (которые, кстати, все они очень квалифицированные сотрудники CS - и по образованию, и по практике), что SRS будет «исключен», если мы примем пользовательские истории для учета функциональных требований системы? (NFR и т. Д. Также могут быть захвачены, но это не цель вопроса).
Итак, вот мой аргумент «рабочего процесса»: собирать начальные требования в виде пользовательских историй, а затем разрабатывать их для сценариев использования (которые необходимо документировать на низком уровне, т. Е. Описывать взаимодействия с прототипами / макетами пользовательского интерфейса и представлять собой готовый к публикации пост). развертывание). Таким образом, переходя от пользовательских историй к сценариям использования, а не от пользовательских историй к SRS к сценариям использования.
Как вы все в настоящее время собираете пользовательские истории на своем рабочем месте (если вообще) и как вы предлагаете мне «обосновать» отсутствие SRS в присутствии пользовательских историй?
источник
Ответы:
Шаги малыша. Продолжайте писать SRS некоторое время. Затем назначьте встречу и обсудите, служат ли они еще цели. Кто-нибудь еще их читает? Оправдано ли потраченное на них время? Есть ли другой промежуточный шаг, который был бы более легким?
Вы никогда не знаете, вы можете обнаружить, что вы не правы. Вспомните манифест Agile, мы находим большую ценность в «Работающем программном обеспечении, а не на исчерпывающей документации», но в последнем все же есть ценность.
Однако я предполагаю, что вы быстро обнаружите, что желание продолжать писать тяжелые документы отпадет, когда они увидят, насколько тесно связаны случаи использования и пользовательские истории.
источник
Эпос заполнители
Практически в любой Agile-методологии концепция Epics будет настолько необходимой, насколько вам нужно для спецификации требований, заполнители - это то, что вам нужно на этом уровне. Эти записи будут располагаться по приоритетам постоянно, любая дополнительная деталь будет потрачена впустую, если требование будет иметь низкий приоритет в течение длительного времени или даже не будет выполнено. Документирование и управление документацией вокруг него было бы пустой тратой времени. YAGNI распространяется как на требования, так и на кодирование.
Инструменты твой друг!
Если вы используете надлежащий инструмент для сбора и управления пользовательскими историями, то вы можете создать из них спецификацию требований. Спецификация требований в любом случае является документом временного артефакта , это не живой документ, это моментальный снимок требований. И никогда не синхронизируется с реальностью.
Автоматически генерировать артефакты
Пользовательские истории, которые можно экспортировать из правильного инструмента, гораздо ценнее любого статического документа артефакта в любое время. Лично я предпочитаю Pivotal Tracker для отслеживания пользовательских историй, я даже написал набор плагинов MoinMoin на Python для публикации всех различных историй и их состояний в вики (которые содержали подробные заметки разработчиков и тому подобное о историях), живые данные всегда лучше, чем статические данные.
Вики стала живым документом обо всех магазинах / требованиях и состоянии их выполнения и приоритете с подробностями, комментариями и другими метаданными.
Это намного лучше, чем огромный документ Word в Sharepoint, который постоянно рассылается по электронной почте и никогда не обновляется, гарантируя, что у всех есть разные версии и они не синхронизированы со всеми остальными!
Пользовательские истории богаче, чем случаи использования
История использования гораздо более ценна, чем сценарий использования, потому что говорят ПОЧЕМУ .
Формат User Story:
As a [ROLE] I [ACTIVITY] so that [WHY]
гораздо более выразителен, чем похожие варианты использованияThe System [shall/shall not/may/must] perform [action]
(где action - блок-схема).С пользовательской историей у вас есть ВОЗ, которая хочет что-то сделать, у вас есть ЧТО они хотят сделать (что может указывать на более подробную диаграмму / документ для сложных задач), и у вас есть самая важная часть, ПОЧЕМУ они хотят выполнять эту деятельность.
Если у вас есть первое, второе полностью избыточно, и в лучшем случае просто шум. Традиционной формальной спецификации требований из методологии Waterfall нет места в Agile-среде.
В конце
Если ваше руководство не стремится измениться, вы не добьетесь успеха с новой методологией. Я работал в компании на 100+ миллиардов долларов в год, они не пошли на шаг в переходе на Agile / SCRUM, они просто сказали, что вся компания движется к этому, вот новый способ сделать это, вот когда начнется ваше обучение новому пути, вот новые инструменты, которые мы будем использовать, вот дата, когда мы начнем действовать таким образом. Это сработало для них менее чем за год. Я работал над внедрением этого в небольших компаниях с таким же успехом.
обязательство
Реализация шагов ребенка , независимо от того, что это за изменение, является рецептом неудачи. Это кодовое слово для менеджмента, которое они спокойно не соглашаются и пассивно агрессивно настраивают вас на неудачу. Они говорят, что я не верю в это достаточно, чтобы совершить это, поэтому я позволю вам сделать достаточно, чтобы потерпеть неудачу / не добиться успеха , таким образом, они могут сказать, что пытались, и это не сработало, и они, как они управляли, работали все в порядке все время. Частичное обязательство в конечном итоге приводит к провалу.
В вашем случае они, вероятно, тихо не верят в пользовательские истории, и через некоторое время, выполнив обе эти задачи, они начнут утверждать, что бесполезны пользовательские истории, а не SRS, и будут настаивать на прекращении написания пользовательских историй. что просто приведет вас назад, а не вперед.
источник
Я бы попробовал использовать юмор.
Начните с http://www.halfarsedagilemanifesto.org/
Поговорите об этом некоторое время ( отвлечение )
и поговорите о том, что на самом деле означают конфликты ( открытое обсуждение ),
затем через некоторое время обратитесь к вашей организации ( сводная таблица )
и изучите SRS и имеет ли это смысл с новой настройкой проекта. ,
Затем я бы завершил (или, возможно, на другой встрече) дискуссией об изменении подхода re: SRS и посмотрел, есть ли у вас больше консенсуса.
В конце дня вы также ограничены бюджетом и обслуживанием деловых людей, так что может быть момент, когда вы будете немного увереннее в том, что привыкнет, но это действительно зависит от отрасли, размера компании, организационных факторов и многих других. другие такие факторы.
источник
Убедить mgmt уйти от SRS и начать использовать пользовательские истории - это то же самое, что убедить mgmt принять Agile. Существуют убедительные статистические данные о преимуществах Agile для производительности. Одним из примеров является презентация VersionOne на конференции 2013 года. Покажите мгмт эти отраслевые данные, и если они относятся к типу прослушивания, у вас есть шанс.
источник