В двух словах Михаил Смирнов

Семейство методологий разработки ПО Наиболее известные представители – XP, Scrum. Есть и другие. Принципы Agile устанавливаются манифестом 2001г.

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

Частый выпуск версий (2-4 недели, чем чаще – тем лучше)-спринт. Объем работ на каждый спринт определяет команда. Требования фиксируются на время спринта. Вносить изменения не допускается. Не допускаются внешние изменения в пределах спринта. Нельзя сдвигать срок спринта (если что-то не успеваем – исключаем из спринта)

Product owner – представитель пользователей, руководства и других заинтересованных сторон Scrum master – следит за соблюдением принципов Scrum (не может быть PO), проводит совещания, разрешает конфликты и т.п. Scrum team – команда разработки, тестирования, аналитики и т.п. Product backlog – список всех запросов на изменение (User story), упорядоченных по приоритету Sprint backlog – список задач для конкретного спринта (уровень ниже, чем User story)

Планирование спринта (Planning Meeting) 4-8 часов Проводится в начале спринта. Оценка и утверждение содержания спринта. Daily Scrum 15 минут. Проводится ежедневно в одно время. Каждый отвечает на три вопроса: Что уже сделано, что будет сделано, какие есть проблемы. Предварительное планирование следующей итерации Демонстрация (Demo Meeting) 4 часа В конце спринта Демонстрация изменений пользователям и пр. Ретроспективное совещание 1-3 часа Проводится командой после спринта. Два вопроса: Что было сделано хорошо и что надо улучшить.

Размер команды 5-9 человек. Отсутствие четкой специализации внутри команды (сегодня ты программист, завтра - тестировщик) Отсутствие технической специализации (сегодня пишешь SQL, завтра - флеш) Самоорганизация – каждый сам себе выбирает задачи (нет назначения задач)

Каждая задача не должна быть длиннее человеко-часов Каждый запрос на изменение обладает некотором кол-вом очков, определяющих ее сложность (Story Points) (имеются разные шкалы очков) Скорость команды = кол-ву Story Points за один спринт. Может использоваться для планирования будущих спринтов.

Номер Название Важность Предварительная оценка в Story Pointах Как продемонстрировать Критерии, определяющие степень готовности

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

Повышаем управляемость Вводим набор мелких управляемых задач Можем планировать скорость команды Снижаем кол-во текущих задач в каждый конкретный момент Быстрая реакция на новые требования

Отдаем продукт на владение команде – повышаем ее вовлеченность и мотивированность Меряем производительность команды в отдаче бизнесу Ориентируемся на продукт, как на сервис (ПО + сопутствующее окружение), а не только как на ПО.