список инженерных и процессных практик agile

Что такое DevOps

Алексей Бушманов

28.11.2017

Комментариев нет

DevOps (от английских слов development и operations ) — набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по технической поддержке и взаимную интеграцию их рабочих процессов друг в друга. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения и нацелен на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и услуги.

Методология фокусируется на стандартизации окружений разработки с целью способствования быстрому выпуску релизов. В идеале, системы автоматизации сборки и выпуска должны быть доступны всем разработчикам в любом окружении, у разработчиков должен быть контроль над окружением, а информационно-технологическая инфраструктура должна становиться более сфокусированной на приложении.

Задача DevOps — сделать процесс разработки и поставки программного обеспечения согласованным с эксплуатацией, часто эти задачи решаются при поддержке автоматических средств.

DevOps, согласно модели DevOps Gartner, это:

Начинать изменения необходимо не с внедрения инструментов, а с развития соответствующей культуры.

Типы корпоративной культуры

Культура DevOps это:

Люди

Технологии

Процессы (инженерные и процессные практики)

Цели DevOps

Конкретные цели DevOps охватывают весь процесс поставки программного обеспечения. Они включают:

Источник

Инженерные практики Agile

Время чтения: 6 минут

Отправим вам статью на:

В последнее время в графе «сервисы» у большинства компаний-разработчиков программного обеспечения все чаще и чаще встречаются слова «agile development». Наша компания идет в ногу со временем, и поэтому внедрение методологий agile и waterfall не заставило себя долго ждать. Сегодня мы расскажем об инженерных практиках agile, об их полезности и удобстве использования.

При работе по методологии agile немаловажную роль несут инженерные практики, применяемые для поддержания процесса разработки. Сложно разработать качественный продукт без внедрения этих практик в повседневную работу.

Немаловажным фактором при внедрении практик является понимание преимуществ и возможностей того или иного инструмента, а также сложностей и специфики внедрения.

Нашей командой успешно были внедрены следующие инженерные практики agile:

Code Review

Ревизия кода, систематическая проверка исходного кода программы, позволяющая обнаружить и исправить ошибки, оставшиеся незамеченными. Эта практика позволяет разрабатывать более стабильные и качественные программные продукты. Данная практика была внедрена нами на основе инструмента Review Bord. Этот инструмент позволяет проводить ревизию кода после каждого изменения в версии продукта и предоставляет все необходимые возможности для этого.

Code Review особо хорош в применении, когда в команде работают новички. Более опытные программисты назначаются ревьюверами за остальными участниками команды. Раз в неделю или чаще ревьюверы смотрят код и вносят свои замечания и предложения по его улучшению. Таким образом, исходный код программы становится более структурированным и стабильным, что делает конечный продукт более стабильным и легким в сопровождении.

Until Testing

Code Refactoring

Инструмент по изменению внутренней структуры исходного кода, не влекущий изменений в поведении программы, но упрощающий эту структуру и повышающий скорость работы программного продукта, а также простоту его дальнейшего сопровождения и поддержки.

Build Automation

Необходима для компиляции исходного кода, выполнения тестов и развертывание программы на production или тестовой платформе. Автоматизация позволяет улучшить качество продукта, ускорить процесс компиляции и избавить разработчиков от лишних действий при сборке приложения и предоставлении его клиенту.

Continuous Integration

Данная практика направлена на выполнение частых автоматизированных сборок проекта с целью выявления и решения интеграционных проблем. Ее внедрение производилось на основе Hudson Continuous Integration Server, представляющий собой сервис сервера непрерывной интеграции со всеми необходимыми возможностями.

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

В разработке программного продукта самое важное — взаимодействие с заказчиком. Использование инженерных практик и подходов a gile подразумевает регулярную и довольно тесную связь с ним. Процесс создания продукта становится открытым и обсуждается на каждом этапе, поэтому исключена возможность того, что конечный продукт не будет в полной мере соответствовать ожиданиям клиента. Таким образом, заказчик и исполнитель берут на себя одинаковую ответственность за конечный результат, что свидетельствует о высокой профессиональной культуре обеих сторон.

Подпишитесь

Оставьте адрес, и каждый месяц мы будем высылать свежую статью
о новых трендах в разработке програмного обеспечения.

Источник

Чек-лист хороших инженерных практик в компаниях

Разработка программного обеспечения — нетривиальный процесс, который имеет тенденцию значительно усложняться с ростом количества участников. Больше людей в команде — больше коммуникаций и необходимости синхронизироваться (обмениваться знаниями о частях системы и происходящих процессах, следить за бизнесом и его требованиями). Растет цена ошибки, система перестает умещаться в голове одного разработчика, изменения в одном месте влияют на изменения в других местах.

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

Причин такой катастрофической разницы довольно много. Вот некоторые из них:

На некоторые проблемы повлиять либо сложно, либо невозможно (с уровня разработчика). Но другие, особенно относящиеся к инженерным практикам, нужно постоянно улучшать и менять. Программисты должны принимать в этом самое активное участие.

И хотя практик довольно много, в конечном итоге все сводится к тому, как быстро клиенты получают результат вашей работы и насколько они им удовлетворены. Ниже приводится чек-лист, который позволяет понять, используются ли в команде те инженерные практики, которые считаются наиболее удачными.

Соответствие этим практикам не гарантирует того, что в компании нет проблем. Возможно это культ-карго, либо процессы формализованы настолько, что больше мешают, чем помогают. С другой стороны из каждого правила есть исключения и всегда найдется проект, где что-то из списка ниже не применимо. Ну и наконец, некоторые из указанных подходов могут идти вразрез с чьими-то ценностями.

Хорошо

Плохо

Ссылки

Среда разработки

Хорошо

Плохо

Качество

Хорошо

Плохо

Ссылки

Процесс разработки

Хорошо

Test-driven development (TDD). По возможности тесты пишутся до кода. Есть несколько причин, по которым это важно:

Тесты заставляют думать не о реализации, а о том, как тестируемый код будет использоваться. Благодаря такому подходу, программисты видят изъяны в интерфейсах на самых ранних стадиях.

Код в любом случае надо проверять. Если теста не будет, то это придется делать руками.

Плохо

Ссылки

Выкатка новых версий (более актуально для веб-проектов)

Продакшен-среда — инфраструктура (например, сервера), в которой развернут проект. Она обеспечивает доступ к проекту конечным пользователям.

Деплой (выкатка) — процесс, в рамках которого происходит обновление проекта в продакшен среде.

Хорошо

Плохо

Источник

Области гибкости

Перевод статьи Evan Leybourn «Domain of Agility» выполнен Лилией Алексеевой (Agile-евангелист, Сбербанк) с разрешения автора.

Agile не означает Scrum, а Agility нельзя свести только к Agile.

На протяжении нескольких последних месяцев я пытался сформировать простую модель, которая помогла бы раскрыть понятие Agility и взаимодействие между составляющими его элементами. Теперь я хочу представить вам результат этой работы — три различные формы гибкости (Agility) — бизнеса, техническую и процессную. На мой взгляд только наличие всех трех элементов позволяет нам создать Agile-организацию.

Гибкость процессов (Process Agility). Я начну с нее, потому что именно эта область обычно ассоциируется у людей с понятием Agile. Эта область фокусируется на работе команд и проектов, то есть на поставке ценности. Большая часть существующих фреймворков: Scrum, SAFe, LeSS – преимущественно фокусируется на этом уровне (справедливо, впрочем, отметить, что многие фреймворки масштабирования Agile частично охватывают также и область Business Agility).

Техническая гибкость (Technical Agility). Техническая зрелость изначально считается краеугольным камнем гибкости. Один из самых ранних и основополагающих фреймворков Agile — Экстремальное программирование (XP) — почти полностью посвящен технической гибкости. Большинство современных инженерных практик таких как Test-Driven Development (разработка через тестирование), парное программирование и даже рефакторинг берут свои корни из XP. Но техническая гибкость не ограничивается инженерными практиками из отрасли разработки программного обеспечения. Любая область работы может и должна стать «технически» гибкой. В первую очередь это касается всех поддерживающих процессов, например, таких как финансирование, функционирование хозяйственных служб и прочих. Что значит для них гибкость? Это их собственный внутренний Time-to-Market. Пример, знакомый любому руководителю отдела любой крупной компании: план по подбору новых сотрудников подается в отдел по персоналу и утверждается с ними на год вперед. А если в середине года неожиданно стартовал новый проект, и требуются люди, то ставок на них нет, и подбор можно будет начать только в новом году. (Примечание переводчика). Изменение таких процессов поддерживаются новыми Agile-практиками: Beyond Budgeting и прочими.

Гибкость бизнеса в целом (Business Agility). Это самая молодая область. По большому счету организации только сейчас начинают думать о гибкости бизнеса как об отдельной области. На протяжении последних двадцати лет пока отдельные команды становились гибкими, основным сдерживающим фактором, как правило, было взаимодействие с соседними командами в пределах одного подразделения. Сегодня же, когда целые подразделения и части компаний становятся гибкими, ключевым ограничивающим фактором становится вся остальная организация. По моему опыту, такие подразделения как финансы, HR и проектный офис становятся основными источниками ограничений на пути к гибкости организации в целом.

Гибкость бизнеса (Business Agility) в целом находится на стадии становления. В отличие от двух других областей здесь почти нет формальных методов и подходов, описанных в рамках каких-либо фреймворков. Beyond Budgeting, Холакратия и Лидерство как служение (Servant Leadership) — вероятно, три наиболее сформировавшихся и ставших узнаваемыми концепции из области Business Agility. Лично я считаю, что в течение следующих 5-10 лет мы увидим взрывной рост различных методов, инструментов и подходов к обеспечению гибкости бизнеса, которые консолидируются в стройные фреймворки.

PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.

Источник

Agile: что это такое и где используется, принципы и методология

В больших проектах, где работает много участников, организовать работу сложно без подготовки и единой системы. Чтобы повысить показатели при ведении проектов, научиться управлять командой, стоит присмотреться к системе гибкого управления Agile.

Что такое Agile

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

Чем отличается от других методологий

Она не похожа на предыдущие подходы, описывающие создание продукта в деталях. Agile краток, в нем 4 ценности и 12 принципов. RUP в отличие от Agile – менее гибкая методология, при этом более объемная, описывает процесс работы на десятках страниц. RUP не подходит для небольших задач, состоит из итераций с продолжительностью от 2 до 6 недель.

OpenUP – преемница RUP. В этой методологии проект делится на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Методология недостаточно гибкая в сравнении с Agile, применима больше в IT-сфере.

Где используется Agile

Методика применялась в IT-индустрии и использовалась для разработки ПО. Суть сводилась к внедрению адаптивных методов, которые ускоряют создание продуктов через микропланирование и короткие производственные циклы. Однако впоследствии Agile стала использоваться и в других прикладных областях. Agile сейчас применяют компании: Netflix, Spotify, Magna International, General Electric, Accenture, М.Видео.

Подобные технологии стали достоянием команд, работающих над созданием клиентских продуктов.

Плюсы и минусы Agile

Манифест Agile

Идеи Agile

Ценности Agile говорят, что:

Гибкость методологии

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

Принципы методологии

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

Работа над мини-блоками

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

Маленькие кросс-функциональные команды

Сотрудники работают в небольших командах. Задача каждой в реализации одной из функций, которая важна для клиента. Численность и состав команд отличаются в зависимости от их задач. Число сотрудников в одной команде до 12 человек.

Ограничение объема незавершенной работы

Agile помогает командам концентрироваться на задачах, которые можно решить за небольшой промежуток времени. Уменьшение объема работы помогает быстрее справиться с мини-задачами, что сказывается на общей продуктивности.

Автономность команд

Перед началом работы над задачей составляют план. Затем каждая команда решает, как приступить к его выполнению. Задача руководителя ― определить базовые правила, сотрудники самостоятельно выбирают темп работы, условия, координируют действия.

Достижение стадии готовности

Проверка методологии – завершение задачи, итоги которой подводятся в конце каждого цикла. Благодаря разделению на небольшие блоки команды могут полностью завершить задачу, а не отмечать ее как «практически законченную». Причина медлительности в крупных проектах – задания, которые завершены частично, но в них еще ряд проблем. В результате они тянут время, ресурсы, внимание и отвлекают сотрудников от обязательств.

Беспрерывная работа

Задачи, поделенные на короткие циклы, имеют приоритеты, к которым нужно стремиться на каждом этапе. Благодаря чему работа беспрерывна, и сотрудники не отвлекаются на смежные задачи.

А чтобы не отвлекаться на рутинные отчеты, подключите сквозную аналитику Calltouch для вашего бизнеса и уделяйте время важным стратегическим задачам.

Полная прозрачность и использование досок со стикерами

Это помогает кратко, но емко описать работу, зафиксировать актуальную стадию, на которой находится команда, посмотреть на процесс глазами сотрудников, при необходимости определить источник проблем.

Обратная связь от пользователей на каждом цикле

Команды получают обратную связь от клиентов в конце каждого цикла. На основе сведений оценивают достижения, реализацию задачи. Информация учитывается в дальнейшем для планирования.

Ключевые моменты в применении

Методы Agile используются для решения разных бизнес-процессов. Поэтому перед их внедрением важно разобраться, как выглядит методология на практике.

Какие существуют роли по Agile

Иерархия компетенции в Agile

Структура команды горизонтальна, но в ней есть иерархия. Руководитель задает вектор, по которому сотрудники реализуют задачи. Особенность системы – иерархия построена на компетенции, а не власти, что определяет взаимодействие сотрудников с начальством.

Что такое пропускная способность

Пропускная способность – реализованное количество «пользовательских историй». Это пожелания клиентов, которые формируются в задачи. Например, установка фильтров поиска в приложении, улучшение обратной связи с клиентами, работа над службой техподдержки. Пропускная способность измеряется количеством отработанных пользовательских историй в неделю.

Как определить последовательность и приоритетность задач

Приоритетность задач зависит от направления компании. Например:

Как составить график решения задач

Для составления графика используют приложения с шаблонами для планирования проектов. Например, GanttPRO – сервис для постановки задач и их контроля. Он содержит шаблоны графиков, отслеживает цели по степени продвижения, отмечает слабые места.

Внедрение Agile

Для внедрения методологии выполняют комплекс мероприятий. Он основан на выборе главного метода в системе, после чего устанавливаются задачи, цели, сроки, численность команды. Сотрудники должны быть обучены применению методов на практике, а руководство должно понимать, что внедрение системы станет новым поворотом в развитии бизнеса.

Важно использовать опыт специалистов, которые уже работали с системой и знают, как реализовать ее. Их опыт помогает в формировании команды, подборе инструментов, аналитике.

Распространенные проблемы при реализации

Основные проблемы при внедрении Agile:

Популярные методы и средства управления проектами

Scrum

Здесь упор на контроль рабочего процесса, что разделяет разработку проекта на стадии. Эти стадии длятся от 2 до 4 недель. Процесс начинается с оценки масштабов работы, предполагает корректировку действий и планов с учетом промежуточных итогов. Скрам повышает производительность и ориентируется на сокращение времени для достижения цели.

Kanban

Метод основан на прозрачности процесса. Он функционально распределяет нагрузку на сотрудников, мотивирует членов команды на сотрудничество и обучение. Принципы строятся на:

Заключение

Источник