Спецификация требований к функциональному программному обеспечению (FSRS) и гибкая разработка
Я нахожусь на пути к тому, чтобы научиться руководить группой разработчиков проектов в RoR, используя гибкую методологию. В Интернете я нашел некоторые инструменты, такие как VersionOne или PivotalTracker, которые могут помочь вам создавать итерации, журналы невыполненных работ, истории и т. Д., Чтобы вы могли разделить работу с фронт-эндом и бэк-эндом, и чтобы ваши разработчики сосредоточились на конкретной задаче.
Мой вопрос касается шага до того, как вы начнете использовать эти гибкие инструменты, создавать истории и итерации, и ваши разработчики начнут увеличивать его на каждом из них. Мои сомнения касаются шага спецификации технических, функциональных и нефункциональных требований к программному обеспечению, поэтому, когда у вас все получится, вы можете начать писать истории:
http://en.wikipedia.org/wiki/Non-functional_requirement.
Существуют ли инструменты, которые помогут вам успешно преобразовать идею веб-приложения (или мобильного приложения) в список историй / итераций? какое-то визуальное представление состояний, функций или функций (и их взаимосвязей), где вы можете указать функциональные, нефункциональные и технические характеристики, так что после этого вы можете создавать истории?
большое спасибо за ваше время и пациента заранее.
1 ответ
Вы должны изменить свой мыслительный процесс здесь.
Пользовательская история - это одно или несколько предложений на повседневном или деловом языке конечного пользователя, в которых отражается то, чего пользователь хочет достичь. Например,
Как представитель стойки регистрации, я бы хотел быстро забронировать номер.
Как вы можете видеть, они
- С точки зрения пользователя / роли (представителя на стойке регистрации)
- Ориентация на цель (быстро забронировать номер)
Но им не хватает деталей, таких как различные потоки (оплата и т. Д.), Критерии приемлемости, специфические нефункциональные требования (что быстро означает, например, в истории?). Вы создаете под-истории, чтобы предоставить больше деталей.
Что делает хорошую историю?
ИНВЕСТИРОВАНИЕ: Независимый, Оборотный, Возможный для рассмотрения, E stimatable, S mall, T estable
Существуют ли инструменты, которые помогут вам успешно преобразовать идею веб-приложения (или мобильного приложения) в список историй / итераций?
Такие инструменты, как Rally и JIRA, позволяют организовывать истории, подтесты, спринты / итерации и т. Д.
Какой-то вид визуального представления состояний, функций или функций (и их взаимосвязей), где вы можете указать функциональные, нефункциональные и технические характеристики, поэтому после этого вы можете создавать истории?
Эти инструменты предоставляют текстовые редакторы, которые помогают нам писать истории. Иногда у вас есть требование, которое не вписывается в историю
- Вариант использования
- Руководство по пользовательскому интерфейсу
- Список бизнес-правил и т. Д.
Тогда напиши что-нибудь еще. Такие инструменты, как JIRA, обеспечивают предоставление вложений.
так после этого вы можете создавать истории?
** Истории должны быть первым действием, которое должно произойти. В этом весь смысл. Это не мысль после. Рассказы - это способ заставить вас думать с точки зрения пользователя и цели, поэтому вы пишете программное обеспечение для достижения целей пользователя. **
Истории представляют собой требования, они не документируют их. - Рэйчел Дэвис
Гибкий подход поощряет достаточно архитектуры с непрерывным рефакторингом.
В состав команды по предоставлению спринта обычно входят все необходимые заинтересованные стороны, такие как бизнес-аналитик, тестировщик, архитектор, разработчик базы данных. Они все вместе отвечают за завершение истории / спринта, и в конце весны у вас будет готовое к развертыванию приложение. Идея состоит в том, чтобы постепенно добавлять функции.
Как вы можете видеть из состава команды, архитектор / лидер также участвуют в каждом спринте. Он, с помощью команды, спроектирует и спроектирует только для историй, которые являются частью текущего спринта / итерации ( Достаточно архитектуры, Emergent Design). Истории, которые они выбирают для первого спринта, являются либо рискованными, либо архитектурно значимыми.
Когда дело доходит до дизайна, в основном это мозговой штурм, основанный на бумаге или доске. Идея состоит в том, чтобы как можно больше использовать код в качестве справочной документации и создавать коллективные знания в команде с помощью парного программирования и т. Д. И т. Д.
Таким образом, вы не получите плохое качество программного обеспечения. На самом деле у вас была бы минимальная кодовая база, которая может использоваться для историй (вы не накапливаете кодовую базу для будущих требований или не хотите иметь функции). Где-то я читал, что только 40% встроенных функций используются клиентами.