Pull to refresh

Как распознать липовые проекты Agile

Reading time 5 min
Views 13K
Original author: Комитет по инновациям Министерства обороны США
От переводчика: это инструкция 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 («Ошибки и правила программного обеспечения» [ссылка будет добавлена позже]).
Tags:
Hubs:
+13
Comments 5
Comments Comments 5

Articles