1. Scrum
2. роли
3. процессы
4. канбан
5. XP (Экстремальное программирование)

Agile - это манифест разработки программного обеспечения, или, проще говоря, идея, подход к созданию продуктов путем непрерывного быстрого поставки ценного рабочего функционала.

Agile реализуется методологиями:

• Scrum - управленческий фреймворк;
• XP - инженерные практики;
• Канбан - организация Поддержка.

Также есть множество других методологий, которые не столь популярны но все еще используются в определенных ситуациях. Можно назвать несколько из них: Crystal Clear, Dynamic Systems Development Method (DSDM), Agile Unidied Process, Future-driven development, ICONIX.

Ценности Agile:

• Люди и их взаимодействие важнее процессов и инструментов;
• Готовый продукт важнее документации по нему;
• Сотрудничество с заказчиком важнее жестких контрактных ограничений;
• Реакция на изменения важнее следованию плану.

принципы Agile

1. Наш высокий приоритет - это удовольствие заказчика с помощью частых и непрерывных поставок продукта, ценного для него.
2. Мы принимаем изменения к требованиям, даже на поздних этапах реализации проекта.
3. Гибкие процессы приветствуют изменения, является конкурентным преимуществом для заказчика.
4. Поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае, каждые несколько месяцев. Чем чаще, тем лучше.
5. Представители бизнеса и команда разработки должны работать вместе над проектом.
6. Успешные проекты строятся мотивированными людьми. Дайте им соответствующее окружающую среду, обеспечите всем необходимым и доверьте сделать свою работу.
7. Самый эффективный метод взаимодействия и обмена информацией - это личная беседа.
8. Рабочее программное обеспечение - главная мера прогресса проекта.
9. Гибкие процессы способствуют непрерывному развитию. Все участники проекта должны уметь выдерживать такой постоянный темп.
10. Постоянное внимание к техническому совершенству и качественной архитектуре способствуют гибкости.
11. Простота необходима, как искусство максимизации работы, которую не следует делать.
12. Лучшая архитектура, требования, дизайн создается в самоорганизующихся командах.
13. Команда постоянно ищет способы стать более эффективной, путем настройки и адаптации своих процессов.

Scrum

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

Требования разбейте на небольшие, ориентированные на пользователей, функциональные части, которые максимально независимы друг от друга, в результате чего получите беклог продукта. Затем упорядочение элементы беклога по их важности и сделайте относительную оценку объемов каждой истории. Выделите отдельного человека - владельца продукта (product owner), который будет отвечать за требования и их приоритеты, замыкая на себя всех заинтересованных лиц.

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

В конце каждого спринта проводите осмотр спринта (demo), чтобы получить обратную связь от владельца продукта, и ретроспективу спринта (retro), чтобы оптимизировать ваши процессы. После этого владелец продукта может изменить требования и их приоритеты и запустить новый спринт.

роли

• В Scrum принято выделять три основных роли: владелец продукта, скрам-мастер и команда.
  Владелец продукта (Product owner Менеджер продукта) - это человек, ответственный за приоритезацию требований и часто за их создание.
• Скрам-мастер - член команды, который дополнительно отвечает за процессы, координацию работы команды и поддержания социальной атмосферы в команде.
• Команда - 7 ± 2 человек, которые реализуют требования владельца продукта.

артефакты

Беклог продукта (Product Backlog) - приоритезировать список требований по оценке трудозатрат. Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-ценность и называются элементы беклога (User stories).

Беклог спринта (Sprint Backlog) - часть беклога продукта, с высокой важностью и суммарной оценке, не превышает скорость команды, отобранная для спринта.

Инкремент продукта - новая функциональность продукта, созданная во время спринта.

процессы

Большинство процессов Scrum носят характер встреч, так как данная методология основана на качественных коммуникациях.

Скрам-митинг

Скрам-митинг (Scrum meeting, скрам, ежедневный скрам, планерка) - собрание членов команды (с возможностью приглашению владельца продукта) для синхронизации деятельности команды и информированием о проблемах. Каждый член команды отвечает на три вопроса:

1. Что было сделано с предварительного скрам-митинга?
2. Какие проблемы?
3. Что будет сделано к следующему скрам митинга?

планирование спринта

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

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

обзор спринта

Обзор спринта (также часто используется термин «демонстрация» или сокращенно «демо») - показ владельцу продукта (и заинтересованным лицам) работающий функционал продукта, сделанного по спринт. Основная задача проведения осмотра спринта состоит в получении обратной связи.

ретроспектива

В долгосрочном плане ретроспективы (или сокращенно «ретро») является важнейшим практикой Scrum: ведь именно они позволяют адаптировать и кастомизировать Scrum, делая из него по-настоящему гибкий фреймворк для управления проектами.

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

1. Что было сделано хорошо?
2. Что можно улучшить?
3. ���Яки улучшения будем делать (Action items)?

канбан

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

Таким образом, канбан - это высоко адаптивный инструмент, который требует от команды, которая решила использовать его, соответствующего уровня самоорганизации и дисциплины:

1. Визуализируйте производственный процесс - для этого обычно используют доску, размеченную по этапам работы над задачей. Конечно, более продвинутым вариантом будет использовать плазму / проектор, и выводить туда состояние трекера.
2. Ограничивайте количество незавершенной работы (WIP, Work In Progress) - у каждого столбца-состояния команда указывает максимальное количество задач, которые могут в нем находиться. Таким образом, минимизируется переключения между задачами и связанные с этим потери при производстве.
3. Оптимизируйте процесс - основа оптимизации производства в рамках канбана. Необходимо отслеживать среднее время задачи и уменьшать его.

XP (Экстремальное программирование)

Инженерные практики является проверенные временем решения, связанные непосредственно с реализацией требований заказчика.

Основные практики:

• Непрерывная интеграция (Continuous Integration) - использование специального программного обеспечения, которое получает свежую версию исходного кода проекта, и выполняет построение ПО. В случае наличие проблем выводится и рассылается соответствующее сообщение. В сборник проекта обязательно входит запуск автоматических тестов.
• Разработка через тестирование (Test Driven Development) - сначала пишем автоматические тесты, а затем функционал который обеспечивает прохождение этих тестов. О TDD я писал уже много и можно прочитать статью Unit tests - начало. Часть 1.
• Парное программирование (Pair programming) - код пишется двумя разработчиками за одним компьютером, причем один из разработчиков играет роль «пилота», а второй роль «штурмана». Это существенно поднимает качество кода.
• Коллективное владение кодом (Collective code ownership) - обеспечивает кроссфункциональнисть самих участников команды и позволяет реализовывать эту важное свойство Scrum. Важным преимуществом такого подхода является быстрое распространение знаний между участниками команды. Для реализации этой практики необходимо использовать стандарты кодирования , Чтобы код, написанный разными участниками команды, был одинаков с точки зрения оформления. Проверку на соответствие стандартам лучше осуществлять на этапе построения проекта в автоматическом режиме. Также процедура Code review помогает достичь этой практики XP.
• Стандарт кодирования (Coding standard or Coding conventions) - набор правил написания кода. Каждый разработчик в команде должен им следовать.
• 40-часовая рабочая неделя (Sustainable pace, Forty hour week) - это гарантия для команды от перегрузок, одного из вида потерь в экономном производстве. Надо очень четко понимать, что количество отработанных часов не равно количеству сделанного функционала, как и в любой интеллектуальной и инженерной деятельности.
• Рефакторинг (Design Improvement, Refactor) - это изменения исходного кода без изменения функциональности для улучшения внутреннего качества (простота кода, гибкость архитектуры и т.д.). рекомендую прочитать Что такое "Чистый код"?

В XP есть еще несколько важных практик которые повседневно используются в работе по Agile / Scrum: Игра в планирование (Planning game), Заказчик всегда рядом (Whole team, Onsite customer), Частые небольшие релизы (Small Releases), простота (Simple design), метафора системы (System metaphor).

В Википедии описанных данные практики - экстремальное программирование .

Более теории Agile можно посмотреть в презентации Бориса Вольфсона.

Также рекомендую прочитать "Гибкие методологии разработки" Вольфсон Борис

Если вы заметили ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl + Enter.