Автор: Диана Пурцеладзе.
Статистика проектов в США на 1994 год была практически провальная. 16,2% проектов — успешны, 31,1% — аннулированы, 52,7% — превысили срок и бюджет. Появилась реальная потребность в развитии моделей разработки digital-проектов.
Расскажу об основных из них.
Гибкая модель
В проекте требования до конца непонятны, они могут меняться по ходу разработки. Это всегда большой проект с длительным жизненным циклом.
RAD-model
Rapid application development — быстрая разработка приложений. Много аналитиков с очень высокой квалификацией. Когда есть уверенное знание всех нюансов бизнеса.
Инкрементная модель
В инкрементной модели возможна разработка проекта по версиям. Требования известны и четко зафиксированы. Данный продукт нужно выводить на рынок быстро. Есть несколько рискованных целей.
V-Model
Улучшенная версия классического водопада. Крайне высока стоимость ошибки. Требования четко зафиксированы. Есть много тестировщиков, и они в пределах шаговой доступности.
Водопад
Требования четко зафиксированы. Нет противоречий. Проект относительно небольшой, несложный.
Гибкие методологии:
Приведу пример статистики проектов, проведенных по методу Водопада и гибкому Scrum.
Существуют некоторые правила, которые можно назвать составляющими agile-манифеста:
- Люди и взаимодействие важнее процессов и инструментов;
- Работающий продукт важнее исчерпывающей документации;
- Сотрудничество с заказчиком важнее согласования условий контракта;
- Готовность к изменениям важнее следования первоначальному плану;
Если следовать простым вышеописанным правилам можно надеяться не только на итоговую успешность проекта, но и на продолжительное плодотворное сотрудничество.
Какие роли выделяются в Scrum.
Product Owner (PO) — связующее звено между командой разработки и заказчиком. Знает цели разработки продукта.
Команда разработки — люди, непосредственно руками и головой работающие над проектом.
Scrum Master — член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды.
Как работает Scrum.
В целом, происходит декомпозиция проекта на короткие блоки (версии), по завершению проводится стендап — ежедневная короткая планерка в скраме (участвуют члены команды, проводит Scrum Master), составляется бэклог — список функций, пользовательских историй, требований к системе, отсортированный по приоритетам. Исходя из этого составляется план работ на следующую версию.
Бэклог должен быть только в одном экземпляре. Приоритеты задач определяет Product Owner. Чем важнее задача — тем выше приоритет, при этом приоритеты не должны совпадать. Бэклог должен подразумевать предварительную оценку задач (например в часах). Он обязательно содержит пользовательские истории и/или бизнес-фичи, но не технические задачи.
Существуют некоторые сервисы для Scrum:
Google Docs
Scrumban (вложенные задачи, подзадачи, разные доски)
Trello (подходит для маленьких проектов)
Jira (есть версионность, эпик-задачи)
Подробнее с каждым из сервисов можно ознакомиться в поисковиках.
Стендап должен включать в себя обсуждение всего трех вопросов. Что было сделано вчера? Что будет сделано сегодня? Какие есть проблемы?
Команда.
Тестировщики, дизайнеры, аналитики должны присутствовать на стендапах между версиями. Скрам на удаленке возможен, но обязательно нужен эффект присутствия. Важно также понимать, что формирование команды требует экспериментов и времени, а минусом постоянных команд является сопротивление добавлению новых людей или удалению людей старых.
Scrum Master. Роль менеджера в скраме
В начале спринта менеджер фиксирует начало и дедлайн, добавляет оценки, оповещает заинтересованных лиц. Далее каждый день следит за распорядком, что все начинается и заканчивается вовремя, за изменениями в спринте и их влиянием на график, сообщает собственнику продукта об изменениях, решает неизбежно возникающие проблемы. Пинает ответственных. В конце каждого спринта проводит его демонстрацию, фиксирует основные тезисы прошедшей ретроспективы и следит за их выполнением, вносит значение реальной производительности, проводит ретроспективу с командой (возможно, позовет туда Product Owner'а).
Scrum выделяет очень большую роль стратегии тестирования. Должно быть ежедневное тестирование во время спринта и полное тестирование спринта по окончании.
Ретроспектива — это командный пересмотр последнего этапа работы (спринта) с целью улучшения процесса в целом.
Цель ретроспективы — именно улучшить процесс, а не наказать виноватых, например.
Скрам — это некий фреймворк. Его нужно настраивать под себя. Важно понимать, что ни один фреймворк не заменяет голову, и ей надо работать. Адаптируйте данный инструмент с умом. Успехов!
Что почитать на тему:
Хенрик Книберг. Scrum и XP: заметки с передовой
Джефф Сазерленд. Scrum. Революционный метод управления проектами
Асхат Уразбаев, Никита Филиппов. Ag;)e Checklist
