Как вы отслеживаете документ с требованиями к гибкой команде?

Я понимаю, что пользовательские истории доминируют в гибком мире, но как хранятся эти артефакты, чтобы новые разработчики, присоединившиеся к команде, могли быстрее соответствовать требованиям?

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

Во-первых, почти ничего в ответе @ DXM не соответствует моему опыту с Agile, и особенно с Scrum.

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

Индивидуумы и взаимодействия над процессами и инструментами

Рабочее программное обеспечение над всеобъемлющей документацией

Сотрудничество с клиентом в рамках переговоров по контракту

Реагирование на изменения в соответствии с планом

То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.

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

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

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

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

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

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

В конце концов, это зависит от того, что вам нужно. Если главное, чтобы люди быстро набрали скорость, возможно, для кого-то будет хорошей идеей написать входящий документ, чтобы помочь им. Так пусть кто-нибудь сделает это. Как я уже упоминал, Wiki - отличный инструмент для хранения подобных вещей, поэтому вы можете рассмотреть решения Atlassian, которые могут интегрировать Confluence Wiki с Jira и Greenhopper для отслеживания ваших историй / задач / дефектов и управления вашим проектом в целом. Также есть множество других инструментов на выбор.

[обновление # 1] Как отметил @MatthewFlynn, его опыт работы с agile, а также со многими другими (включая мой собственный) очень отличается от ответа, который я привожу здесь. Ответ здесь основан на моих наблюдениях за тем, что работало и не работало в моей собственной команде в прошлом, в сочетании со многими книгами и блогами, которые я читал на эту тему ...

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

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

• наименее точный
• труднее всего поддерживать
• наименее полезный

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

Однако отставание не следует путать с документом требований:

• В отставании только N количество историй должны быть заполнены. Чем дальше история, тем меньше ее нужно вкладывать (т. Е. Не тратьте свое время, пытаясь определить то, что не произойдет в течение полугода). ).
• Помимо определенного момента, элементы «требований» не следует даже помещать в резерв, если они находятся более чем в 2 циклах выпуска (или, возможно, приращениях при пересылке (PSI)). Даже если вы знаете, что требование является важным и должно быть выполнено в какой-то момент, не поддавайтесь искушению добавить его в очередь. Если это действительно важно, кто-то запомнит это в следующем выпуске. Если никто не помнит это, скорее всего, это потому, что это было не так важно, в конце концов.

Как только история завершена, эта история удаляется из журнала невыполненных работ и убирается ⁽¹⁾ . Опять же, истории не являются требованиями. Они ТОЛЬКО говорят команде, над чем работать дальше; они не для исторического отчета.

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

Тест документирует, как программное обеспечение должно вести себя с учетом определенного набора входных данных и предварительных условий. Он также документирует, как использовать публичные (и внутренние) API вашего кода. Он также служит сетью безопасности, так что, когда новый разработчик входит в команду и непреднамеренно что-то ломает, эта ошибка будет обнаружена, как только она будет возвращена.

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

⁽¹⁾ - Так как я получил несколько ответов на «заброшенную» часть. За 5 лет, прошедших с момента перехода на Agile, моя команда никогда не выбрасывала ни одной истории, даже 30% из тех, которые были запланированы, затем отложены и затем забыты. Мой босс хотел оставить их «для справки», и никто еще никогда не смотрел ни на одну из этих историй.

Люди обычно привязаны к своим данным, и я знаю, что трудно что-то выбросить, когда у вас уже есть это, но хранение инвентаря (физического или электрического) под рукой не бесплатно, и чем больше я об этом думаю, тем больше я согласен с "броском". Это из «Agile Software Requirements: Lean Requirements Practices для команд, программ и предприятия» (стр.190) - «Истории пользователей могут быть безопасно выброшены после внедрения. Это делает их легкими, делает их дружелюбными к команде и способствует переговорам, но приемочные тесты сохраняются в течение всего срока действия приложения ... »

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

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

Это действительно важно? Иногда это может быть. По большей части вы просто хотите просмотреть истории / UML / что угодно вместе с тестами и самим кодом в настоящее время, однако, когда возникают вопросы о том, почему функция была реализована определенным образом, она часто может быть полезно взглянуть на историю, чтобы увидеть , как функция изменилась с течением времени, чтобы нарисовать более четкую картину, почему вариант реализации X был выбран вместо опции Y .

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

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

Это было сказано ранее, но я думаю, что суть этого заключается в следующем:

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

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

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

Рассмотрим легендарный пример зоомагазина онлайн:

• В истории может быть сказано: «Как пользователь, я хочу увидеть НДС, напечатанный на моей квитанции,…». Теперь расчет НДС (налога на добавленную стоимость) может быть сложным делом и, вероятно, требует больше работы, чем предполагает эта история.
• Может быть дополнительная история, которая требует, чтобы расчет НДС был сделан (скажем, умножьте общую сумму продаж на ставку НДС ), но, вероятно, он не будет включать все варианты этого расчета.
• Сначала команда сосредоточится на предоставлении базового модуля, скажем, на основе списка товаров и их продажной цены, а также на возврате суммы НДС. Это то, что команда может сделать за время спринта.
• Вероятно, будет еще много историй, чтобы охватить все возможные случаи для расчета НДС.
• Чтобы сохранить множество различных правил расчета НДС, видимых для отдельных спринтов и за их пределами, имеет смысл хранить отдельный документ с требованиями, в котором перечислены все различные способы расчета НДС. Этот документ может развиваться с течением времени. Фактически, добавление нового раздела к нему может быть частью задачи истории.

Вы можете использовать freemind, чтобы собрать список возможностей. Как это сделать, посмотрите в этот урок (где-то посередине).

Когда у вас есть список возможностей, вы начинаете писать истории пользователей. Это можно сделать с помощью простого текстового файла, или текстового документа, или чего-то более сложного, чем инструмент гибкого управления .

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

Все это можно увидеть, как проектом ac # управляют с самого начала осенью гибкой серии видеороликов .