Является ли отсутствие функциональных требований гибким?

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

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

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

Поэтому я думаю - действительно ли гибко не иметь никаких бизнес-требований в случае переписывания старой системы?

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

Вы должны сообщить владельцу бизнеса, что не знаете, как работает старая система.

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

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

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

Вы получите одно из следующего:

• Правильные требования и более быстрый цикл разработки
• Время собирать требования и перестраивать программное обеспечение
• Новый проект, который не станет черным пятном в вашей карьере

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

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

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

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

Сбор требований является неотъемлемой частью любого (успешного) программного проекта. Но написание спецификации требований не так.

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

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

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

• Поскольку понимание требований со временем меняется, статическая спецификация требований устареет. Как это можно предотвратить?

  Выражая требования как выполняемые тесты. Оказывается, что «читаемая спецификация» и «выполняемые тесты» не являются исключительными понятиями, но могут в конечном итоге стать одним и тем же документом. Например, огурец и другие идеи из пространства BDD могут быть очень полезны здесь.

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

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

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

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

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

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

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

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

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

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

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

Будут ли постоянно выпускаться, обсуждаться, изучаться, возвращаться и менять программное обеспечение? Вы строите программное обеспечение или оборудование?

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

Выявление дыр в плане - это не поиск ошибок, это просто разработка программного обеспечения.

По этой причине я люблю ответ Гая.