Первый путь DevOps - поток или системное мышление
адаптированный перевод второй главы DevOps Handbook
DevOps (акроним от англ. development & operations) и связанные с ним технические, архитектурные и культурные методики – результат соединения многих философских и управленческих направлений.
DevOps запускает изменения в организациях, преобразуя способы взаимодействия специалистов поддержки (operations), разработчиков, тестировщиков - всех тех, кто участвует в процессе создания и поставки продукта от начала до конца. Основное изменение в том, чтобы создать окружение в котором группы специалистов работают сплоченно и этом главный вызов в корпоративных внедрениях DevOps. И как вы уже догадываетесь, это в основном про изменение культуры в организации, а не в наборе инструментов.
Выделяют принципы DevOps (три пути) и практики которые эти идеи воплощают.
Первый путь: поток или системное мышление
Первый путь DevOps подчеркивает важность производительности всей системы в целом, а не только производительности отдельного “колодца” или отдела (например, отдела разработки или IT-администрирования), будь то крупное подразделение или отдельный исполнитель (например, разработчик, системный администратор).
Основное внимание уделяется всем потокам создания бизнес-ценности, которые обеспечиваются ИТ. Другими словами, процесс начинается с определения требований, превращение требований в программное обеспечение при помощи разработчиков, а затем передачи в IT-администрирование, где ценность затем поставляется клиенту в виде сервиса.
Результаты применения первого принципа включают в себя избегание передачи выявленных дефектов дальше по производственной цепочке, предотвращение локальной оптимизации, ведущей к ухудшению системы в целом, постоянное стремление к увеличению потока и стремление к глубокому пониманию системы (в соответствии с принципами Деминга).
Практики первого пути DevOps
Делайте вашу работу видимой
DevOps вобрал множество практик из бережливого производства, в отличие материального производства на котором создаются физические объекты, то что создаётся при разработке программного обеспечения сложно увидеть - код хранится на жестком диске и его сложно “пощупать”, поэтому визуализация процесса его создания помогает инженерам не только отслеживать текущий прогресс, но и в целом понимать, что входит в процесс создания IT-продукта. Часто используется визуализация при помощи канбан-досок.
Ограничивайте работу в прогрессе (WIP)
Канбан начинает работать когда вы начинаете включать ограничения работы. В любом процессе есть неэффективности и написание большего количества кода не будет приводить к увеличению производительности системы, если фаза тестирования у вас является лимитирующей. Поэтому, если вы заинтересованы в системной оптимизации, нет смысла начинать новую работу, если следующая фаза не готова обработать этот объем работы. Это также называют управлением размером очереди
Уменьшение размера партии
Снижать объем работы можно не только “по вертикали” но и “по горизонтали”. Большие партии работы неизбежно ведут к раздуванию WIP и повышению вариабельности системы - ещё один источник непредсказуемости в системах, что приводит к увеличению общего времени поставки (T2M) и снижению качества продукта - в больших партиях гораздо проще упустить дефекты.
С другой стороны, уменьшение размера партии (задачи или релиза) позволяет повысить качество программного обеспечения - в более мелкой партии дефекты обнаружить гораздо проще. В своем экстремуме такой подход называется однопоточная разработка (single-piece flow) - когда вся команда сфокусирована над одной задачей для пользователя. Это сокращает количество передач работы.
Сокращение количества передач
На время процесса разработки и поставки software-продуктов может повлиять количество передач работы между различными специалистами. В производстве это физическое перемещение деталей. В разработке ПО это передача артефактов: описание требований, архитектурные схемы, схемы баз данных, код, автоматические тесты, документация и тп. Частые передачи между отделами сопровождаются интенсивной коммуникацией и могут привести к искажению информации, её частичной или полной потере. Стоит сокращать количество передач, например, через автоматизацию или реструктуризацию отделов и команд для того, чтобы улучшить поток работы и сократить неэффективное время.
Непрерывное выявление и устранение ограничений
Непрерывно выявляйте и улучшайте ограничения системы для сокращения общего времени выполнения задач и увеличения пропускной способности. Для этого можно применить “пять фокусирующих” шагов Голдрата:
- Выявить ограничения системы
- Определить как можно использовать это ограничение
- Подчинить другие участки системы под ограничение
- Расширить ограничение
- Если ограничение устранено, то вернуться к шагу 1
В DevOps источники ограничений могут исходить из:
- создания окружения
- развертывания кода
- настройки и запуска тестов
- чрезмерно связанной архитектуры
Устранение затруднений и потерь в потоке ценности
Современные интерпретации Lean отмечают, что "устранение потерь" может иметь уничижительный и обесчеловечивающий контекст; вместо этого цель лучше ставить как сокращение трудностей и монотонности в нашей повседневной работе через постоянное обучение для достижения целей организации.
В своей книге Implementing Lean Software Development: From Concept to Cash Мэри и Том Поппендик идентифицируют следующие источники потерь и монотонности:
- частично выполненная работа: любая работа, которая не закончена и находится в “невидимых” очередях
- излишние процессы: любая дополнительная работа, которая не добавляет ценности для пользователя
- излишняя функциональность: функциональность которая существует в сервисе, но не является необходимой для организации или пользователя
- мультитаскинг: переключение между разными задачами создает дополнительную нагрузку и увеличивает время для потока ценности
- ожидание: любые задержки в работе, требующей какие-либо ресурсы для завершения работы
- перемещение: в контексте разработки источником этих потерь может быть неэффективная коммуникации в распределенных командах или передачи между отделами
- дефекты: чем больше времени проходит между внесением и обнаружением дефекта, тем сложнее его устранить
- нестандартная или ручная работа: любые зависимости от эксплуатации должны быть автоматизированы, самообслуживаемы и доступны по требованию
- героизм: сотрудники и команды ставятся в ситуацию, когда им приходится совершать необоснованные поступки, которые могут даже стать частью их повседневной работы
В следующей статье мы с вами разберем Второй путь DevOps: усиление циклов обратной связи.
Published by
Тему DevOps и другие темы профессиональной разработки в Скраме мы разбираем на нашем тренинге Applying Professional Scrum for Software Development (APS-SD)
