Anatoly Shein

+10
с 2016
0 подписчиков
26 подписок

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

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

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

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

Чтобы Agile подходил для банка, он должен обращать внимание на качество в интегральных средах. Самое простое и самое дорогое решение - гонять все тесты (и ручные и автоматические) сразу же по окончании разработки фичи. Другой способ - сдвинуть влево проверки, которые обычно проводятся в интегральных средах, и подготовить инструменты для программистов, чтобы запускать эти тесты. Такими инструментами являются, например, Cucumber и Vagrant. Еще один из вариантов - Service Virtualization. Можно и все вместе.

1

Действительно, уже давно говорят, что Agile подходит не всем. Однако, например, с 2008 распространение Agile увеличилось в 6 раз и будет увеличиваться дальше.
https://www.fullstackpython.com/web-frameworks.html

Алексей, а что вы подразумеваете, говоря "поставленные не-agile процессы”?

Кстати, Dmitry Dzhafarov действительно прав :-) Строго говоря, "Agile Software Development” не является ни методологией, ни процессом, а простым набором принципов. Однако за почти 20 лет существования понятие Agile превратилось в собирательное, например https://en.wikipedia.org/wiki/Agile_management

4

Родион, спасибо за очень хороший вопрос. Основная проблема именно с количеством проверок, которые необходимо запускать перед релизом. В сложных продуктах полный цикл проверок занимает несколько дней, а то и недель. А если что-то не работает и необходимо починить, так вообще затягивается на более долгие сроки, появляется дефицит проверочных сред и т.д. Даже для тех, кто работает с микросервисами в облаке, типа амазон, поднять необходимое количество сред при скоростях, о которых говорит Agile & DevOps, стоит чересчур дорого.

4

Действительно, менеджеры - "скрам-мастера” и всякие остальные “куры” - отвечают за сроки и содержание. Считается, что качество придёт само собой, стоит только запустить автоматические проверки и, в крайнем случае, благодаря “continuous deployment”, за очень короткие сроки починить в “production” . Этот подход замечательно работает для таких компаний, как Facebook - ну подумаешь, лайк не сработал...