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

9

Мы планируем принять пользовательские истории, чтобы отразить «намерение» заинтересованных сторон, а не тяжелую SRS (спецификации требований к программному обеспечению). Тем не менее, кажется, что, хотя они понимают ценность историй, все еще есть желание «преобразовать» истории в SRS-подобный язык со всеми атрибутами, приоритетами, входами, выходами, источником, местом назначения и т. Д.

Пользовательские истории «устраняют» необходимость в формальном SRS-подобном артефакте для начала, так какой смысл иметь SRS? Как я должен убедить мою команду (которые, кстати, все они очень квалифицированные сотрудники CS - и по образованию, и по практике), что SRS будет «исключен», если мы примем пользовательские истории для учета функциональных требований системы? (NFR и т. Д. Также могут быть захвачены, но это не цель вопроса).

Итак, вот мой аргумент «рабочего процесса»: собирать начальные требования в виде пользовательских историй, а затем разрабатывать их для сценариев использования (которые необходимо документировать на низком уровне, т. Е. Описывать взаимодействия с прототипами / макетами пользовательского интерфейса и представлять собой готовый к публикации пост). развертывание). Таким образом, переходя от пользовательских историй к сценариям использования, а не от пользовательских историй к SRS к сценариям использования.

Как вы все в настоящее время собираете пользовательские истории на своем рабочем месте (если вообще) и как вы предлагаете мне «обосновать» отсутствие SRS в присутствии пользовательских историй?

— кандидат наук
источник

этого не произойдет за день, подходи легко

— Юсубов

Если вы работаете на поставщика услуг программного обеспечения, то SRS, возможно, не понадобится для реализации, а для проведения «игры обвинения», когда клиент хочет уменьшить стоимость или аргументы поставщика услуг о том, что нужно больше денег, или оба будут судиться.

— k3b

14

Шаги малыша. Продолжайте писать SRS некоторое время. Затем назначьте встречу и обсудите, служат ли они еще цели. Кто-нибудь еще их читает? Оправдано ли потраченное на них время? Есть ли другой промежуточный шаг, который был бы более легким?

Вы никогда не знаете, вы можете обнаружить, что вы не правы. Вспомните манифест Agile, мы находим большую ценность в «Работающем программном обеспечении, а не на исчерпывающей документации», но в последнем все же есть ценность.

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

— прецизионный самописец
источник

2

@PhD: ты прав. Это почти изначально. И именно поэтому вы не выиграете эту битву с какой-либо логикой, только с доказательствами. Шаги малыша.

— фунтовые

2

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

2

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

1

@JarrodRoberson Я просто хочу добавить, что мой опыт более точно отражает ваш опыт. Есть два типа людей, и, следовательно, два типа менеджеров, консерваторов и риск-людей. Консерваторы, естественно, не склонны к изменениям и риску. Когда они находят модель, которая работает, даже плохо, они придерживаются ее. Когда на них принуждают или нажимают на изменения, они подсознательно саботируют их, пытаясь сделать шаги ребенка . Вот почему я когда-либо видел настоящую гибкую работу по усыновлению, когда ее возглавляют люди, рискующие.

— maple_shaft

2

@maple_shaft: хитрость в том, чтобы продолжать двигаться вперед. Если постепенное изменение не работает, не обязательно делать тот же шаг назад, подумайте, почему оно не сработало ... как, может быть, вы все еще тратите слишком много времени на написание бессмысленного документа. Теперь я признаю, что для того, чтобы думать так, нужен хороший менеджер, и большинство из них вернется в свою зону комфорта. Но, по той же причине, это не означает, что единственный другой вариант - радикальные изменения. Плохой менеджер все испортит.

— фунтовые

6

Эпос заполнители

Практически в любой 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, и будут настаивать на прекращении написания пользовательских историй. что просто приведет вас назад, а не вперед.

— kmote
источник

Вы будете весьма удивлены, что пользовательские истории управляются инструментом, который может (и делает) экспортировать их как требования. Тем не менее, похоже, что проблема заключается в «переводе» пользовательских историй на язык SRS «система должна ...» и т. Д., А не в качестве пользовательских историй.

— PhD

1

Что ж, если повесить трубку - это терминология "должен / должен / может", вы, вероятно, плюете в ветер с этими людьми. Пользовательские истории рассказывают ВОЗ / ЧТО и, что важнее всего, ПОЧЕМУ нужно что-то делать, гораздо полезнее, чем те случаи статического использования, которые в большинстве случаев неверны и корректны.

2

-1: Совсем не согласен с большинством ответов, однако заявляет, что SRS - это «Спецификация требований - это документ временного артефакта, так или иначе, это не живой документ», настолько ошибочный, что показывает тревожное отсутствие понимания того, что SRS для или как она используется, когда сделано правильно - обычно только в устаревших моделях программного обеспечения модели водопада сегодня.

— Mattnz

5

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

3

@JarrodRoberson +1 для тебя. Действительно, mattnz также прав, что SRS должен быть живым документом, но затем вы берете на себя пару критических производственных проблем, которые должны быть изменены требованиями заказчика, работая над одним или несколькими разветвленными выпусками базы кода, неправильно истолковав требования бизнес-аналитики, разработчики и QA ... то, что у вас осталось - это документ, который не является истинным отражением системы на данный момент, но также не является истинным отражением потребностей пользователя. Пользовательские истории действительно принимаются компаниями, которые больше заботятся о клиенте, чем о системе.

— maple_shaft

0

Я бы попробовал использовать юмор.

Начните с http://www.halfarsedagilemanifesto.org/

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

Затем я бы завершил (или, возможно, на другой встрече) дискуссией об изменении подхода re: SRS и посмотрел, есть ли у вас больше консенсуса.

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

— Майкл Даррант
источник

5

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

— MarkJ

-1

Убедить mgmt уйти от SRS и начать использовать пользовательские истории - это то же самое, что убедить mgmt принять Agile. Существуют убедительные статистические данные о преимуществах Agile для производительности. Одним из примеров является презентация VersionOne на конференции 2013 года. Покажите мгмт эти отраслевые данные, и если они относятся к типу прослушивания, у вас есть шанс.

— Джо
источник

1

Извините, это не очень хороший ответ. Вы говорите «показать статистику» и даже не предоставляете ссылки.

— Ян Догген

и действительно напишите полные слова и предложения ...

— jwenting