Методология Agile

Alt text

Определение

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

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

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

Разновидности

Scrum, Kanban, Lean и пр.

Процесс

  1. Выберите владельца продукта — это человек, который видит, к какой цели вы идете и что хотите получить в итоге.

  2. Определитесь с командой — от 3 до 10 человек, владеющих навыками, которые позволят получить результат (т.е. работоспособный продукт).

  3. Выберите скрам-мастера — этот человек следит за ходом проекта и помогает команде бороться с трудностями.

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

  5. Запланируйте спринты — отрезки времени, за которые команда выполняет определенный набор задач. Спринты будут регулярными: например, 15 раз по две недели, пока получится готовый продукт.

  6. Проводите ежедневные встречи на 15 минут (и ни минутой больше) — на повестке три вопроса, на которые коротко отвечает каждый: что делал вчера, что буду делать сегодня и какие преграды мешают «взять высоту».

  7. Делайте обзоры — по итогам спринта команда рассказывает, что удалось сделать, и демонстрирует работоспособные части продукта. На обзоры может прийти кто угодно: владелец продукта, главный заказчик или даже потенциальные клиенты.

  8. Проводите ретроспективу — после каждого спринта Agile-команда обсуждает проблемы и ищет решения. Должен получиться план изменений, который команда сразу же и внедрит — на следующем спринте.

Agile от WhiteLabelDevelopers

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

  2. Определяться с размером команды необходимости нет — её диктует проект, точнее его текущее состояние.

  3. Беклог — «нашевсё». Наш внутренний регламент требует обязательного заполнения беклога в любом обращении заказчика. Лучше снять оттуда задачу, чем потерять.

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

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

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

  7. Scrum для разрабоки, Kanban для поддержки.

Источники