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