Какая была методология разработки на проекте?

Методология разработки в моем последнем проекте

Контекст проекта

В моем последнем проекте мы использовали Agile методологию (Scrum), что определялось следующими факторами:

• Быстро меняющиеся требования рынка
• Высокая конкуренция в отрасли
• Необходимость получать регулярный фидбек от пользователей
• Стартапное окружение с ограниченными ресурсами

Структура процесса

1. Планирование (Sprint Planning)

Что происходило:

• Встречи 1-2 раза в неделю на 1-2 часа
• Продакт-менеджер представлял приоритизированный бэклог
• Команда оценивала User Stories в Story Points
• Определялась пропускная способность спринта (обычно 40-60 points)
• Разработчики брали на себя задачи, которые они могли выполнить

Мой вклад как BA:

• Уточнял требования перед планированием
• Готовил User Stories с Acceptance Criteria
• Помогал с оценкой сложности
• Отвечал на вопросы о требованиях

2. Дневные Stand-ups

Ежедневные встречи (15 минут):

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

Участники: вся команда (разработчики, тестировщики, менеджер)

Роль BA:

• Слушаю блокеры, связанные с требованиями
• Быстро отвечаю на вопросы
• Выявляю задачи, требующие дополнительного анализа

3. Sprint Review

Демонстрация работы (1-2 часа):

• Разработчики показывали готовые User Stories
• Демонстрировали работающий функционал
• Стейкхолдеры давали фидбек
• Принимали решение о Release

Мой вклад:

• Проверял соответствие Acceptance Criteria
• Отвечал на вопросы пользователей
• Документировал найденные проблемы
• Уточнял требования для следующего спринта

4. Sprint Retrospective

Ретроспектива (1 час):

• Что хорошо сработало на спринте?
• Что нужно улучшить?
• Как мы будем работать по-другому?

Типичные пункты улучшения:

• Требования приходили слишком поздно
• Клиент не был доступен для вопросов
• Ошибки в User Stories приводили к переделкам

Управление требованиями в Agile

Структура бэклога

Хранение: Jira Структура:

• Epic — большая функция
• User Story — отдельная функция
• Task — техническая задача
• Bug — найденная проблема

User Story шаблон

Заголовок: Как [роль], я хочу [действие], чтобы [результат]

Описание: детальное объяснение что и почему

Acceptance Criteria:

• Given пользователь авторизован, When нажимает кнопку Профиль, Then открывается страница профиля
• Given пользователь не авторизован, When нажимает на Профиль, Then перенаправляется на вход

Приоритизация

Методика MoSCoW:

• M (Must have) — критичные требования
• S (Should have) — важные
• C (Could have) — желательные
• W (Wont have) — отложенные

Также использовали Kano Model:

• Базовые требования
• Функциональные требования
• Восхищающие требования

Challenges и решения

Проблема: Быстро меняющиеся требования

Решение: Структурированный бэклог, приоритизация на каждом планировании

Проблема: Непонимание между разработчиками и бизнесом

Решение: Sprint Reviews с реальными пользователями

Проблема: Ошибки в User Stories приводили к переделкам

Решение: Чек-лист для User Story, четкие Acceptance Criteria

Проблема: Поздние открытия в конце спринта

Решение: Больше времени на анализ требований ПЕРЕД спринтом

Ключевые метрики спринта

• Velocity — количество points, завершённых за спринт
• Burn-down chart — график выполнения работы
• Cycle Time — время от начала до завершения задачи
• Defect Rate — процент ошибок

Сравнение с другими методологиями

В этом проекте Agile был идеален, потому что:

• Требования уточнялись в процессе работы
• Нужны были частые демонстрации работающего кода
• Команда была маленькая и могла часто общаться
• Клиент был активно вовлечён

Если бы проект был в регулируемой отрасли или имел фиксированный контракт — я бы порекомендовал Waterfall.

Заключение

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