От переводчика: это инструкция Руководство DIB: обнаружение Agile BS (версия 0.4) , который Совет по оборонным инновациям (DIB) опубликовал публично 9 октября 2018 года.
Agile — модное слово в разработке программного обеспечения, поэтому все программные проекты Министерства обороны теперь почти по умолчанию объявляются «гибкими».
Этот документ поможет менеджерам программ и специалистам Министерства обороны отличить проекты программного обеспечения с действительно гибкой методологией от проектов, которые под видом Agile просто используют «agile-scrum-fall».
Принципы, ценности и инструменты Эксперты и энтузиасты Agile определяют ключевые показатели, характеризующие эту культуру и подход к гибкой разработке.
В своей работе DIB разработал собственные руководящие принципы, примерно отражающие истинные ценности Agile:
Ценность Agile | Принцип ДИБ |
---|---|
Люди и взаимодействия важнее процессов и инструментов | «Компетентность важнее процесса» |
Работающее программное обеспечение важнее полной документации | «Сократите время от старта проекта до развертывания простейшего базового функционала» |
Сотрудничество с клиентом для согласования договора | «Внедрение культуры DevSecOps для программных систем» |
Реагировать на изменения важнее, чем планировать | «Программы должны начинаться с малого, быть итеративными и опираться на успех, иначе они будут быстро свернуты».
|
- Никто из команды разработчиков не общается с пользователями и не следит за программным обеспечением в действии; Мы имеем в виду настоящий пользователи настоящий код. (Отдел оценки программы не считается реальным пользователем, равно как и старший офицер, если только он не использует программу в своей работе).
Приемлемые альтернативы общению с пользователями включают наблюдение за их работой, обмен с ними прототипами для обратной связи и другие методы исследования, не требующие большого количества устного общения.
- Отсутствие постоянной обратной связи от пользователи для команды разработчиков (отчеты об ошибках, оценки).
Недостаточно провести один разговор в начале проекта, чтобы проверить требования!
- Соблюдение требований считается более важным, чем максимально быстрое получение минимально полезных результатов.
- Заинтересованные стороны (разработчики, тестирование, DevOps, безопасность, подрядчики, конечные пользователи и т. д.) действуют более или менее автономно (например, «это не мое дело»).
- Конечные пользователи не участвуют в разработке; как минимум, они должны присутствовать при планировании выпуска и приемочном тестировании.
- Недостаточная культура DevSecOps, когда вручную выполняются процессы, которые можно и нужно автоматизировать (например, тестирование, непрерывная интеграция, непрерывная доставка).
- Git, ClearCase или Subversion — это система контроля версий для отслеживания изменений в исходном коде.
Git — это стандарт де-факто в современном развитии.
- BitBucket или GitHub — хостинг репозитория.
Также отслеживает билеты, имеет «приложения» непрерывной интеграции и другие инструменты повышения производительности.
Широко используется сообществом открытого исходного кода.
- Jenkins, Circle CI или Travis CI — это служба непрерывной интеграции для создания и тестирования проектов Bitbucket и GitHub.
- Chef, Ansible или Puppet — программное обеспечение для создания «рецептов» конфигурации и трансляции задач настройки и поддержки на ряд серверов.
- Docker — это компьютерная программа, выполняющая виртуализацию на уровне операционной системы, также известную как контейнеризация.
- Kubernetes или Docker Swarm для оркестровки контейнеров.
- Jira или Pivotal Tracker — тикеты, мониторинг и управление.
Вопросы разработчикам
- Как вы тестируете свой код? (Неправильные ответы: «У нас есть специальная организация для тестирования», «За тестирование отвечает отдел тестирования и оценки продукции»)
- Расширенная версия.
Какой набор инструментов вы используете для модульных тестов, регрессионного тестирования, функциональных тестов, сканирования безопасности и сертификации развертывания?
- Расширенная версия.
- Насколько автоматизированы конвейеры разработки, тестирования, безопасности и развертывания?
- Расширенная версия: какой набор инструментов вы используете для непрерывной интеграции (CI), непрерывной доставки (CD), регрессионного тестирования, программной документации; ваша инфраструктура определяется кодом?
- Кто ваши пользователи и как вы с ними взаимодействуете?
- Расширенная версия: какие механизмы вы используете для получения прямой обратной связи от пользователей? Какой набор инструментов вы используете для отчетов об ошибках и отслеживания заявок? Как вы распределяете работу по исправлению ошибок между командами? Как вы информируете пользователей о том, что их проблемы решаются и/или уже решены?
- Каковы текущие и будущие сроки цикла выпуска?
- Расширенная версия: Какие программные платформы вы поддерживаете? Вы используете контейнеры? Какие инструменты управления конфигурациями у вас есть?
- Сколько программистов в организации, распределяющей бюджет, и каковы основные этапы программы? (Неправильные ответы: «Не знаем», «Ноль», «Это зависит от определения программиста»)
- Каковы управленческие показатели развития и эксплуатации; как они используются для информирования о приоритетах, выявления проблем; Как часто руководство проверяет и использует их?
- Чему вы научились за последние три спринта и как вы применили свои новые знания? (Неправильные ответы: «Что такое спринтЭ», «Ждем одобрения руководства»)
- Какие пользователи получают выгоду от каждого цикла спринта? Могу ли я поговорить с ними? (Неправильные ответы: «Мы не развертываем код напрямую пользователям»)
- Как вы общаетесь с разработчиками? Наблюдают ли они за вашей работой и задают ли они соответствующие вопросы, демонстрирующие глубокое понимание ваших потребностей? Когда они в последний раз садились вместе и обсуждали функции, которые вы хотите увидеть?
- Как отправить предложения по функциям или сообщить о проблемах или ошибках в коде? Какую обратную связь вы получаете по своим запросам/отчетам? Вас когда-нибудь просили опробовать прототипы новых функций программного обеспечения и наблюдать, как вы их используете?
- Сколько времени требуется приложению для реализации запрошенной функции?
- Предоставляется ли рабочая версия программного обеспечения хотя бы небольшой выборке реальных пользователей на каждой итерации (включая первую) и собирается ли обратная связь? (подсказка: каждые две недели)
- Существует ли устав продукта, в котором изложены миссия и стратегические цели? Все ли члены команды понимают и то, и другое? Видят ли они, как их работа способствует достижению их целей?
- Превращается ли обратная связь с пользователем в конкретные задачи для спринтерских команд со сроком выполнения менее месяца?
- Имеют ли команды право изменять требования на основе отзывов пользователей?
- Имеют ли команды право менять свой процесс на основании того, чему они научились в ходе разработки?
- Является ли вся экосистема вашего проекта гибкой? (Если за гибкой разработкой следует линейный, бюрократический процесс внедрения, это провал.
)
Графическая версия:
Более подробная информация о некоторых функциях программ DoD содержится в Приложении А ( «Десять рецептов программного обеспечения» ), Приложение Б ( «Метрики разработки программного обеспечения» ) и Приложение C («Программные ошибки и правила» [ссылка будет добавлена позже]).
Теги: #agile development #git #github #непрерывная интеграция #Управление разработкой #Управление проектами #agile #DevOps
-
Подготовка Приложения Для Istio
19 Oct, 24 -
Повышение Градиента С Помощью Catboost
19 Oct, 24 -
Яндекс Врёт
19 Oct, 24 -
Русские В Португалии
19 Oct, 24 -
Почему Ваш Сайт Могут Заблокировать?
19 Oct, 24