По какой методалогии работали на прошлом месте работы

# Методология разработки на предыдущем месте работы

Agile/Scrum фреймворк

Чаще всего современные компании используют Agile с уклоном в Scrum. Вот что обычно под этим понимается:

1. Двухнедельные спринты

• Планирование в начале спринта (Sprint Planning)
• Ежедневные стендапы (Daily Standup) по 15 минут
• Обзор спринта (Sprint Review) в конце
• Ретроспектива (Sprint Retro) для улучшений

# Typical task workflow
# TO DO → IN PROGRESS → REVIEW → DONE
# На доске (Jira, Linear, Azure DevOps)

2. Оценка задач

• Используется Planning Poker (или Fibonacci)
• Story Points вместо часов (1, 2, 3, 5, 8, 13 поинтов)
• Velocity команды (сколько поинтов в спринт)

3. Обязательные практики

Code Review:

# Pull Request → 2 одобрения → Merge
# CI/CD запускается автоматически
# Проверки:
# - Линтинг (ruff, black, flake8)
# - Юнит-тесты (pytest) — coverage > 80%
# - Интеграционные тесты
# - Статический анализ (mypy, bandit)

Test-Driven Development (TDD):

# Red → Green → Refactor
# Сначала пишешь тесты, потом реализацию

# Пример
def test_user_creation():
    user = create_user(name="John", email="john@example.com")
    assert user.id is not None
    assert user.name == "John"
    assert user.is_active == True  # по умолчанию

# Затем реализуешь create_user

Continuous Integration/Continuous Deployment:

# GitHub Actions, GitLab CI, Jenkins
# На каждый commit:
# 1. Запуск всех тестов
# 2. Линтинг и статический анализ
# 3. Сборка (если нужна)
# 4. Deploy на staging (если все ок)
# 5. Deploy на production (если approvesd)

4. Документирование

• README в каждом репо
• ADR (Architecture Decision Records) для важных решений
• Комментарии для сложной бизнес-логики
• API документация (Swagger/OpenAPI)

# Docstrings по Google style
def calculate_discount(price: float, discount_percent: int) -> float:
    """Calculate price with discount applied.
    
    Args:
        price: Original price in USD
        discount_percent: Discount percentage (0-100)
        
    Returns:
        Final price after discount
        
    Raises:
        ValueError: If discount_percent > 100
    """
    if discount_percent > 100:
        raise ValueError("Discount cannot exceed 100%")
    return price * (1 - discount_percent / 100)

5. Версионирование

• Git Flow или GitHub Flow
• Semantic Versioning (MAJOR.MINOR.PATCH)
• Ветки: main (production), develop (staging), feature/* (разработка)

# Git Flow пример
git checkout -b feature/user-authentication
# ... работа ...
git push origin feature/user-authentication
# Pull Request → Review → Merge to develop
# Потом develop → main (релиз)

6. Мониторинг и логирование

• ELK Stack (Elasticsearch, Logstash, Kibana)
• Structured logging (JSON формат)
• Метрики (Prometheus, Grafana)
• Error tracking (Sentry)

import logging
import json

logger = logging.getLogger(__name__)

# Structured logging
logger.info(
    "User login",
    extra={
        "user_id": 123,
        "ip_address": "192.168.1.1",
        "timestamp": datetime.now().isoformat()
    }
)

Метрики успеха

1. Velocity — среднее количество поинтов в спринт
2. Burn Down Chart — прогресс за спринт
3. Cycle Time — время от идеи до production
4. Lead Time — время ожидания features
5. Defect Rate — количество багов после релиза

Чем хороша Agile/Scrum

✅ Быстрая обратная связь от клиентов ✅ Гибкость — легко менять требования ✅ Непрерывная доставка value ✅ Командная синергия через стендапы ✅ Качество через обязательные reviews

Потенциальные проблемы

⚠️ "Agile theatre" — формальное соблюдение без смысла ⚠️ Scope creep — постоянные изменения в спринте ⚠️ Техдолг — спешка ломает архитектуру ⚠️ Выгоранием — излишние митинги

Дополнительные практики

• Pair Programming — работа вдвоём
• Code Ownership — за каждым компонентом ответственность
• Incident Management — процесс реагирования на проблемы
• Roadmap Planning — планирование на квартал

В итоге, методология работает, когда команда понимает её смысл и адаптирует под свои нужды, а не просто следует процессам.