Как Распознать Поддельные Agile-Проекты

От переводчика: это инструкция Руководство 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 — тикеты, мониторинг и управление.

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

Как распознать поддельные Agile-проекты

Вопросы разработчикам
  • Как вы тестируете свой код? (Неправильные ответы: «У нас есть специальная организация для тестирования», «За тестирование отвечает отдел тестирования и оценки продукции»)
    • Расширенная версия.

      Какой набор инструментов вы используете для модульных тестов, регрессионного тестирования, функциональных тестов, сканирования безопасности и сертификации развертывания?

  • Насколько автоматизированы конвейеры разработки, тестирования, безопасности и развертывания?
    • Расширенная версия: какой набор инструментов вы используете для непрерывной интеграции (CI), непрерывной доставки (CD), регрессионного тестирования, программной документации; ваша инфраструктура определяется кодом?
  • Кто ваши пользователи и как вы с ними взаимодействуете?
    • Расширенная версия: какие механизмы вы используете для получения прямой обратной связи от пользователей? Какой набор инструментов вы используете для отчетов об ошибках и отслеживания заявок? Как вы распределяете работу по исправлению ошибок между командами? Как вы информируете пользователей о том, что их проблемы решаются и/или уже решены?
  • Каковы текущие и будущие сроки цикла выпуска?
    • Расширенная версия: Какие программные платформы вы поддерживаете? Вы используете контейнеры? Какие инструменты управления конфигурациями у вас есть?
Вопросы для менеджеров проектов
  • Сколько программистов в организации, распределяющей бюджет, и каковы основные этапы программы? (Неправильные ответы: «Не знаем», «Ноль», «Это зависит от определения программиста»)
  • Каковы управленческие показатели развития и эксплуатации; как они используются для информирования о приоритетах, выявления проблем; Как часто руководство проверяет и использует их?
  • Чему вы научились за последние три спринта и как вы применили свои новые знания? (Неправильные ответы: «Что такое спринтЭ», «Ждем одобрения руководства»)
  • Какие пользователи получают выгоду от каждого цикла спринта? Могу ли я поговорить с ними? (Неправильные ответы: «Мы не развертываем код напрямую пользователям»)
Вопросы для клиентов и пользователей
  • Как вы общаетесь с разработчиками? Наблюдают ли они за вашей работой и задают ли они соответствующие вопросы, демонстрирующие глубокое понимание ваших потребностей? Когда они в последний раз садились вместе и обсуждали функции, которые вы хотите увидеть?
  • Как отправить предложения по функциям или сообщить о проблемах или ошибках в коде? Какую обратную связь вы получаете по своим запросам/отчетам? Вас когда-нибудь просили опробовать прототипы новых функций программного обеспечения и наблюдать, как вы их используете?
  • Сколько времени требуется приложению для реализации запрошенной функции?
Вопросы руководству
  • Предоставляется ли рабочая версия программного обеспечения хотя бы небольшой выборке реальных пользователей на каждой итерации (включая первую) и собирается ли обратная связь? (подсказка: каждые две недели)
  • Существует ли устав продукта, в котором изложены миссия и стратегические цели? Все ли члены команды понимают и то, и другое? Видят ли они, как их работа способствует достижению их целей?
  • Превращается ли обратная связь с пользователем в конкретные задачи для спринтерских команд со сроком выполнения менее месяца?
  • Имеют ли команды право изменять требования на основе отзывов пользователей?
  • Имеют ли команды право менять свой процесс на основании того, чему они научились в ходе разработки?
  • Является ли вся экосистема вашего проекта гибкой? (Если за гибкой разработкой следует линейный, бюрократический процесс внедрения, это провал.

    )

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

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

Как распознать поддельные Agile-проекты

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

Теги: #agile development #git #github #непрерывная интеграция #Управление разработкой #Управление проектами #agile #DevOps

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.