От переводчика: это инструкция DIB Guide: Detecting Agile BS (версия 0.4), которую Комитет по инновациям Министерства обороны США (DIB) опубликовал в открытом доступе 9 октября 2018 года.

Agile — модное словечко в разработке ПО, так что все софтверные проекты Минобороны теперь почти по умолчанию объявлены «гибкими». Настоящий документ поможет руководителям программ и специалистам Минобороны отличить софтверные проекты с действительно гибкой методологией от проектов, которые под маской Agile просто используют «водопад» или «спираль» (“agile-scrum-fall”).

Принципы, ценности и инструменты

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

Ценность Agile	Принцип DIB
Индивидуумы и взаимодействия важнее процессов и инструментов	«Компетентность важнее процесса»
Работающий софт важнее полной документации	«Сократить время от начала проекта до развёртывания простейшего базового функционала»
Сотрудничество с клиентом по согласованию контракта	«Внедрение культуры DevSecOps для программных систем»
Реагирование на изменения важнее плана	«Программы должны начинаться с малого, быть итеративными и строиться на успехе — или их быстро сворачивают»

Ключевые признаки, что проект не очень гибкий:

• Никто из команды разработчиков не общается с пользователями и не отслеживает программное обеспечение в действии; мы имеем в виду реальных пользователей реального кода. (Отдел оценки программ не считается реальным пользователем, также как старший офицер, если только он не использует программу в своей работе). Приемлемые альтернативы общению с пользователями: наблюдение за их работой, передача им прототипов для получения отзывов и другие методы исследований, которые не предусматривают большого количества словесного общения.
• Отсутствует постоянная обратная связь от пользователей для команды разработчиков (отчёты об ошибках, оценки). Недостаточно поговорить один раз в начале проекта для проверки требований!
• Соответствие требованиям считается более важным, чем получение минимально полезного результата как можно быстрее.
• Заинтересованные стороны (разработка, тестирование, DevOps, безопасность, подрядчики, конечные пользователи и т. д.) действуют более или менее автономно (например, «это не моё дело»).
• Конечные пользователи не участвуют в разработке; как минимум, они должны присутствовать при планировании релиза и в приёмочном тестировании.
• Недостаточная культура DevSecOps, когда вручную выполняются процессы, которые можно и нужно автоматизировать (например, тестирование, непрерывная интеграция, непрерывная поставка).

Некоторые типичные инструменты для гибкой разработки (они меняются по мере
появления лучших):

• Git, ClearCase или Subversion — система управления версиями для отслеживания изменений в исходном коде. Git является стандартом де-факто в современной разработке.
• BitBucket или GitHub — хостинг репозиториев. Также отслеживает тикеты, имеет «приложения» для непрерывной интеграции и другие инструменты для повышения производительности. Широко используется сообществом open source.
• Jenkins, Circle CI или Travis CI — сервис непрерывной интеграции для сборки и тестирования проектов Bitbucket и GitHub.
• Chef, Ansible или Puppet — програмное обеспечение для создания «рецептов» конфигурации и трансляции задачи по конфигурации ипи поддержке на ряд серверов.
• Docker — компьютерная программа, которая выполняет виртуализацию на уровне операционной системы, также известную как «контейнеризация».
• Kubernetes или Docker Swarm для оркестрации контейнеров.
• Jira или Pivotal Tracker — тикеты, мониторинг и управление.

Графическая версия:

Вопросы для разработчиков

• Как вы тестируете код? (Неправильные ответы: «У нас есть специальная организация для тестирования», «За тестирование отвечает отдел тестирования и оценки продукта»)
  
  • Расширенная версия: какой набор инструментов вы используете для юнит-тестов, регрессивного тестирования, функциональных тестов, сканирования безопасности и сертификация развёртывания?
• Насколько автоматизированы конвейеры разработки, тестирования, безопасности и развёртывания?
  
  • Расширенная версия: какой набор инструментов вы используете для непрерывной интеграции (CI), непрерывной доставки (CD), регрессионного тестирования, документации программы; ваша инфраструктура определяется кодом?
• Кто ваши пользователи и как вы взаимодействуете с ними?
  
  • Расширенная версия: какие механизмы вы используете, чтобы получить прямую обратную связь от пользователей? Какой набор инструментов вы используете для создания отчётов об ошибках и отслеживания тикетов? Как распределяете работу по устарнению багов между командами? Как сообщаете пользователям, что их вопросы решаются и/или уже решены?
• Каков срок по текущему и будущим циклам для релиза?
  
  • Расширенная версия: какие программные платформы вы поддерживаете? Вы используете контейнеры? Какие у вас средства управления конфигурацией?

Вопросы для менеджеров проектов

• Сколько программистов входят в состав организации, которая распределяет бюджет, и каковы основные этапы программы? (Неправильные ответы: «Мы не знаем», «Ноль», «Это зависит от определения программиста»)
• Каковы управленческие метрики для разработки и эксплуатации; как они используются для информирования о приоритетах, выявления проблем; как часто их просматривает и использует руководство?
• Чему вы научились за три последних спринта и как применили новые знания? (Неправильные ответы: «Что такое спринт?», «Мы ждём одобрения руководства»)
• Кто те пользователи, которые извлекают пользу от каждого цикла спринта? Можно поговорить с ними? (Неправильные ответы: «Мы не развёртываем код напрямую для пользователей»)

Вопросы для клиентов и пользователей

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

Вопросы для руководства

• Поставляется ли рабочая версия программного обеспечения хотя бы небольшой выборке реальных пользователей на каждой итерации (включая первую) и собираются ли отзывы? (подсказка: каждые две недели)
• Существует ли устав продукта, в котором изложены миссия и стратегические цели? Понимают ли все члены команды и то, и другое? Видят ли они, как их работа способствует достижению целей?
• Превращаются ли отзывы пользователей в конкретные задания для спринтерских команд со сроком выполнения меньше месяца?
• Уполномочены ли команды изменять требования на основе отзывов пользователей?
• Имеют ли команды право изменять свой процесс на основе того, что они узнали в ходе разработки?
• Является ли гибкой вся экосистема вашего проекта? (Если за гибкой разработкой следует линейная, бюрократическая процедура внедрения — это провал.)

Для команд Agile ответом на все эти вопросы должно быть «да».

Графическая версия:



Более подробная информация о некоторых функциях программ Минобороны содержится в Приложении А («Десять предписаний по программному обеспечению»), Приложении B («Метрики для разработки программного обеспечения») и Приложении C («Ошибки и правила программного обеспечения» [ссылка будет добавлена позже]).