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

Если вы все же решились попробовать новое. В этой статье я поэтапно расскажу как плавно перейти от Waterfall к Agile без потерь, рисков и нарушения основных налаженых процесов работы.

Выбор проекта для перехода

При выборе проекта нужно учесть несколько важных факторов. А именно:

• Размер
• Риски
• Вовлечение Заинтересованых лиц

Размер — Проект должен быть не меньше 4х недель. Это оптимальное время для формирования полноценной обратной связи и понимания самой методологии. Оптимальный максимальный размер проекта — 12 недель.

Риски — проект должен быть важный но не критический. На проекте должно отсутствовать давление со стороны времени и со стороны клиента. Так как этот проект пилотный — очень важно быть сконцентрированным именно на внедрении методологии а не на тушении пожаров.

Вовлечение стейкхолдеров. Важно что бы в проект были вовлечено как можно больше участников. ПМ, Дизайнеры, Разработчики, Тестировщики, Аналитики… Так же проект должен проходить через все стадии разработки. Концепция, Дизайн, Анализ, Разработка… Очень важно понять все аспекты внедряемой методологии и полностью окунуться в нее. Здесь важно получить обратную связь от каждого участника и на каждом этапе.

Выбор Команды.

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

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

Формирование ролей

Следующим этапом будет формирование ролей в команде. Ключевые роли в любой Agile команде:

• Product Owner
• Scrum Master
• Development Team
• Business Analyst или Клиент (Не совсем часть команды но важная часть процесса)

Эти роли разделяются на 2 группы. Клиентская сторона и Техническая.
Клиентская сторона, а именно Product Owner и BA, отвечают за создание требований к проекту и формируют их в форме пользовательских историй или user stores. Задача владельца продукта предоставить “Just enough” информации для команды разработки, что бы последние могли начать работу над продуктом.

“Управление требованиями — отдельная очень крупная тема, которая требует более глубокого и детального рассмотрения”

Планирование и оценка

На раннем этапе происходит планирование “Road Map”. Необходимо спланировать задачи с примерным указанием когда каждая пользовательская история будет закончена. Так как это первый проект в agile — точность не тоб на что стоит делать акцент. Главное — аккуратность.

Итак, что же должно включать в себя планирование. Планирование состоит из частей функционала которые разбиты на пользовательские истории, и каждая из пользовательских историй включает в себя определенный набор критерий для принятия функционала. Каждая из этих частей является определенным “Defenition of Done”. Рассмотрим кадую из них по ближе.

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

Я, как _________ хочу _________ для того, что бы _______

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

Scenario: Логин

Given: Я на странице логина
And: логин поле имеет валидные данные
And: пароль поле имеет валидные данные
When: Я нажимаю на кнопку “Login”
Then: Я логинюсь как пользователь
And: Стартовая страница открывается

Теперь подойдем к оценке. Части функционала оцениваются в размерах. XS, S, M, L, XL. Но оценка Пользовательские истории же оцениваются в сравнении с другими пользовательскими историями. Выбирается одна пользовательская история к которой определяется время на разработку. Эта ПИ принимается за один поинт и каждая следующая пользовательская история оценивается в пунктах. Тоесть соотношение более крупной задачи к мелкой.

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

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

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

Планирование спринта. Так как все User Stories написаны, оценены и релиз план составлен, настало время для планирования спринта. На планировании обсуждаются любые новые User Stories, которые были добавлены но не были оценены. Далее все истории быдут разбиты на задачи, соответствующие Acceptance criterea и все AC будут оценены. Оценены в часах.

Velocity. Это среднее количество стори поинтов которое команда способна заделиверит в течение спринта. На первом спринте у команды velocity отсутствует. По этому команда обсуждает и решает что она сможет закончить на 100% в течение спринта и подтверждается командой.

Спринт беклог фиксируется и не изменяется.

Оценка и успех спринта. Ключевые элементы влияющие на успех спринта — это Стенд АП, Взаимодействие и Измерения.

Ежедневное планирование — 15 минутное мероприятие проводимое командой каждый день в одном и том же месте и отвечающее на основные вопросы.

• Что я делал вчера
• Что я буду делать сегодня
• Есть ли у меня какие либо проблемы

Взаимодействие — Один из найболее важных факторов это командная работа и взаимодействие каждого чоена команды с каждым. Как гласит одна часть Agile манифеста: “Люди и взаимодействие важнее процессов и инструментов…"

Обзор Спринта и Демо

В конце каждого спринта имеют место быть 2 мероприятия.

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

По окончании этих 2х мероприятий проходит Ретроспектива. Это мероприятия проводится для команды и покрывает такие моменты как:

• Что за время спринта мы сделали хорошо?
• Что мы могли бы улучшить?
• Что мы улучшим в следующем спринте?

И что же дальше? Когда спринты завершены и продукт закончен. Ретроспектива всего проекта и мнение команды по поводу новых процесов — одни из важнейших элементов принятия решения.

Автор:

Источник