SCRUM — как аналитики и остальная команда работают на проекте
Раньше была популярна "водопадная" (waterfall) модель разработки.
Это когда фазы разработки переходят одна в другую поочередно:
- Встреча с заказчиком.
- Анализ его требований.
- ТЗ, ПЗ, SRS — большие документы, которые писали аналитики несколько месяцев и даже больше года с информацией о том, что нужно сделать.
- Разработка — такая же продолжительная.
- Тестирование — тестирование этого всего.
- Сдача заказчику.
- Осознание, что сделано не то, не так, это уже не актуально.
Теперь большинство компаний работают по итеративной (iteration — повторение) модели разработки ("гибкие" методологии).
Это когда небольшие фазы зацикливаются/повторяются. Тогда продукт делается небольшими частями:
- Встреча с заказчиком.
- Определение списка задач.
- Выборка из списка задач на 1 итерацию.
- Написание требований на 1 итерацию.
- Разработка функций в 1 итерацию.
- Тестирование функций в 1 итерацию.
- Сдача заказчику функций 1 итерации.
- Выборка из списка задач на 2 итерацию.
- Написание требования на 2 итерацию.
- Разработка функций во 2 итерацию.
- Тестирование функций во 2 итерацию.
- Сдача заказчику функций 2 итерации.
- Выборка из списка задач на 3 итерацию...
На стажировке разработка идет по SCRUM (Agile — метология, SCRUM — её реализация), подробнее о методологии можно почитать в конце статьи по ссылкам.
Единицей периода разработки является спринт, его нет смысла делать длинным, чаще всего он занимает 1-2-3 недели. Рекомендуется 2 недели.
- Менеджеры и аналитики определяют перечень задач на весь период стажировки и согласовывают с заказчиком.
- Менеджеры вместе с аналитиками выбирают задачи, которые требуется сделать в первую очередь в 1 итерацию.
- Аналитики пишут требования на 1 итерацию.
- Стартует планирование спринта.
- Стартует спринт, разработчики выполняют задачи 1 спринта.
- В это время аналитики пишут требования на 2 итерацию.
- Заканчивается спринт, разработчики выкатывают результат 1 спринта.
- Тестировщики тестируют функции, которые были выполнены в 1 спринте.
- Результат показывается заказчику.
При итеративной разработке нормально, что по итогам встречи с заказчиком сделанное нужно дорабатывать. Это одна из главных проблем, которая решается гибкой методологией, — делать то, что нужно заказчику.
Необходимые доработки оформляются через аналитиков требованиями (добавить полей на форму и т. д.), если они не касаются технических вещей, которые делают разработчики.
