Существуют ли методологии разработки программного обеспечения Agile?

Question

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

Существуют ли какие-либо методологии, которые помогли бы мне перейти от требований к программному обеспечению с учетом гибких целей?

Answer 1

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

Тем не менее, есть несколько шаблонов и методологий, которые, как известно, хорошо работают с гибкой разработкой; Среди них Test-Driven-Design и Acceptance-Test-Driven-Design, которые призваны помочь вам быстро предоставить рабочий код.

Answer 2

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

ACDM состоит из 8 этапов. Цель этого процесса в целом состоит в том, чтобы помочь командам быстро и эффективно перейти от того, что автор называет периодом неопределенности, к периоду определенности в отношении архитектуры архитектуры создаваемой системы.

• Этап 1. Обнаружение архитектурных драйверов -> Автор рекомендует группам сосредоточиться на 4 факторах: технические ограничения, бизнес-ограничения, функциональные требования высокого уровня и атрибуты качества. Конкретные методы извлечения не обсуждаются, и существует большое разнообразие методов.
• Этап 2: установить масштаб проекта -> в основном, создать условный дизайн и убедиться, что он совпадает с обнаруженными драйверами.
• Этап 3: Создание / уточнение архитектуры -> Здесь вы бы применили многие из принципов, которые вы упомянули в своем вопросе, SOLID, использование шаблонов и т. Д.
• Этап 4: Обзор архитектуры -> Анализ проекта на основе сценариев с командой рецензентов в формальном или полуформальном процессе. Основываясь на архитектурных драйверах, это можно рассматривать как вариант TDD для проектирования архитектуры.
• Этап 5: Производство Go / No-Go -> перейдите к шагу 7, если дизайн Go. go/no-go - это не все или ничего для всей системы, что означает, что подмножество элементов может быть "запущено" для производства, в то время как другие элементы должны быть доработаны
• Этап 6: Эксперименты -> Это действительно ядро ​​процесса. Если вы чего-то не понимаете или не уверены, вам часто нужно пачкать руки и писать код, чтобы понять, что нужно делать в дизайне. повторите к шагу 3
• Этап 7: Планирование производства
• Этап 8: Производство -> начинается построение кода, может происходить частично или полностью

Книга обрисовывает в общих чертах почти все, что вам нужно знать. Есть также несколько работ и презентаций, опубликованных автором, которые привели к процессу, опубликованному в книге и после.

Архитектура программного обеспечения Интенсивные системы: Руководство для практиков Энтони Латтанце.

Answer 3

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

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

Помимо книги: eXtreme Programming более техничен и специфичен, чем другие гибкие методологии. Вы должны посмотреть на это также: http://www.extremeprogramming.org/

Нажмите на ссылки там и прочитайте все.

Удачи.

Answer 4

Для того, чтобы быть гибким, вам нужно быстро измениться. Таким образом, ваше программное обеспечение должно быть изменяемым. Достичь этого нелегко, на самом деле это сложно. Я предлагаю вам прочитать эту книгу: http://www.amazon.de/Software-Development-Principles-Patterns-Practices/dp/0135974445 это действительно хорошо.

Вы также можете прочитать мой блог: http://babdev.blogspot.co.at/2013/08/are-you-really-agile.html