Пишут ли User Story в больших компаниях

User Stories в больших компаниях

Да, пишут, но часто совсем не так, как рекомендуют в учебниках по Agile. После 10+ лет я видел разные подходы, и реальность сложнее, чем теория.

Что такое User Story в классическом виде

User Story — это простая форма описания требований из перспективы пользователя:

"As a [user type], I want [action], so that [benefit]."

Например: "As a manager, I want to see team reports, so that I can track project progress."

C критериями приемки (Acceptance Criteria):

• When I click the "Reports" button, the page loads within 2 seconds
• The report shows data for the last 30 days
• I can filter by department

User Stories в больших компаниях — реальная практика

1. Используют, но адаптируют под масштаб

В компаниях типа Google, Microsoft, Amazon пишут User Stories, но:

• Они намного более детализированы
• Часто дополняются техническими спецификациями
• Включают нефункциональные требования (performance, scalability, security)
• Ссылаются на архитектурные документы

Пример расширенной User Story в большой компании:

"As a data analyst using our ETL platform, I want to schedule daily pipeline runs with cron expressions, so that I can automate data ingestion.

Acceptance Criteria:

• Support standard cron syntax (5 fields)
• Validate syntax before saving
• Pipeline executes at scheduled time with <5 min deviation
• Failed runs trigger alerts to Slack/Email
• Logs are retained for 90 days
• Can schedule up to 100 pipelines per user

Non-Functional:

• Scheduling must not impact API response time (< 100ms)
• Must scale to 1M+ scheduled pipelines
• Database changes require migration plan

Depends on: Story #123 (user authentication) Conflicts with: Story #456 (batch processing)"

2. Используют в Agile/Scrum проектах, реже в Waterfall

В большинстве крупных компаний при переходе на Agile, User Stories стали стандартом. Но есть исключения:

• В Enterprise Waterfall (финансы, госсектор) пишут подробные требования (Requirements Documents)
• В DevOps/Infra проектах часто используют Issues вместо Stories
• В критичных системах (航空, медицина) требования намного более формальные

3. Комбинируют с другими формами требований

Большие компании редко используют только User Stories. Обычно это комбинация:

• Epics — большие фичи ("User Analytics Platform")
• User Stories — конкретные требования
• Technical Tasks — технические детали
• Bugs — найденные проблемы
• Specifications — документы для сложных систем
• Architecture Decision Records (ADRs) — архитектурные решения

4. Инструменты и системы управления

В большинстве больших компаний используют системы отслеживания задач:

• Jira — самый популярный (есть шаблоны User Story)
• Azure DevOps — в Microsoft и её экосистеме
• Asana/Monday.com — реже, для менее технических команд
• Linear/GitHub Issues — в молодых стартапах и tech-компаниях

Все эти системы имеют встроенные шаблоны для User Stories.

5. Модификации в зависимости от контекста

В большой компании содержимое User Story может кардинально отличаться:

Веб-приложение (фронтенд): "As a user, I want to reset my password, so that I can regain access to my account.

• Display forgot password link
• Send reset link via email
• Link expires in 24 hours
• Password must be minimum 12 characters"

Backend API: "As a microservice, I need to handle 10k req/sec with 99.9% availability, so that the system remains responsive.

• Implement rate limiting with sliding window
• Cache responses with 5-min TTL
• Monitor latency with P99 < 100ms
• Auto-scale when load > 70% capacity"

Infrastructure: "As a DevOps engineer, I want to deploy with canary releases, so that we can catch issues before full rollout.

• Deploy 5% traffic initially
• Monitor error rates and latency
• Auto-rollback if error rate > 1%
• Send notifications to Slack"

6. Отличия от малых компаний

Почему в больших компаниях используют User Stories

1. Agile внедрился везде Power of Agile стал стандартом (хотя часто это "Agile-washing" — внешняя видимость без сути).

2. Простота масштабирования Есть инструменты и системы, которые работают с User Stories как с единицей работы.

3. Трассируемость Когда сотни людей работают параллельно, нужна полная история всех требований.

4. Стандартизация Когда приходят новые люди, они сразу понимают формат.

Red Flags использования User Stories

Деграда я наблюдал в больших компаниях:

• Cargo cult — пишут Stories, но не следят за ними ("write and forget")
• Too much detail — Stories становятся 5-страничными документами вместо краткого требования
• Missing stakeholders — Stories пишут в изоляции, без обсуждения с пользователями
• No prioritization — 100 Stories в бэклоге, неясно, какие первые
• Velocity theater — фокусируются на скорости закрытия Stories, не на качестве

Современный тренд

В последних 5 лет наблюдается тренд отхода от User Stories в больших компаниях:

• Компании типа Netflix, Spotify используют целью (OKRs) вместо требований
• Product-driven компании пишут требования в виде Features с большей фокусировкой на outcomes
• AI-driven компании экспериментируют с автоматическим генерированием требований

Вывод

Да, в больших компаниях пишут User Stories. Но это далеко не простые одностраничные истории из учебников. Это развитая система документирования требований с множеством дополнений, интеграциями в инструменты управления и процессы. Часто это выглядит как излишне сложная бюрократия, но для координации сотен людей это необходимо.

Главное — не забывать, зачем пишут User Stories: общение между людьми, а не документирование ради документирования.