Какие методологии разработки вы знаете? Чем Scrum отличается от Kanban?

Методологии разработки: Scrum vs Kanban

Методология разработки — это структурированный подход и набор практик для управления проектом, организации работы команды и доставки результатов. Выбор методологии критичен для успеха проекта и скорости разработки.

Основные методологии разработки

Agile — семейство методологий, основанных на итеративной разработке

• Scrum
• Kanban
• XP (Extreme Programming)
• Lean
• Crystal

Waterfall — последовательная разработка (планирование → разработка → тестирование → деплой)

DevOps — интеграция разработки и операций

SAFe — Scaled Agile Framework для больших организаций

Hybrid — смешивание Waterfall и Agile

Agile Манифест

Все современные методологии базируются на Agile принципах:

• Индивидуумы и взаимодействие > процессы и инструменты
• Работающий продукт > исчерпывающая документация
• Сотрудничество с клиентом > контрактные переговоры
• Отклик на изменения > следование плану

Scrum методология

Определение

Scrum — это фреймворк для управления проектами, основанный на итерациях (спринтах), ясных ролях и церемониях. Фокусируется на доставке готового функционала каждый спринт.

Роли в Scrum

Product Owner (PO)

• Отвечает за Product Backlog (список всех требований)
• Приоритизирует требования
• Общается с stakeholders
• Принимает готовый функционал

Scrum Master (SM)

• Фасилитатор и coach команды
• Убирает blockers
• Проводит Scrum церемонии
• Защищает команду от внешних помех
• НЕ технический лидер (это разница от PM)

Developers

• Разработчики, тестировщики, дизайнеры
• Самоорганизующаяся команда
• Оценивают и выполняют work items
• Несут ответственность за качество

Спринт — итерация, обычно 2 недели

Timo line спринта (2 недели):

Day 1: Sprint Planning (4 часа)
├─ PO объясняет requirements
├─ Team оценивает
└─ Team коммитится на спринт

Days 2-9: Development
├─ Daily Standup (15 минут каждый день)
│  - Что сделал вчера?
│  - Что делаю сегодня?
│  - Есть ли blockers?
└─ Development work

Day 10:
Spring Review (2 часа)
├─ Demo готового функционала
├─ PO приемлет или отклоняет
└─ Feedback от stakeholders

Retro (1.5 часа)
├─ Что хорошо?
├─ Что плохо?
├─ Что улучшить?
└─ Action items на следующий спринт

Артефакты Scrum

Product Backlog — список всех требований приоритизированный

1. User Authentication (PO приоритет высокий)
2. Payment Integration (PO приоритет высокий)
3. Analytics Dashboard (PO приоритет средний)
4. Dark Mode (PO приоритет низкий)

Sprint Backlog — требования выбранные для спринта

Selected для Sprint 5 (14 points velocity):
- User Authentication (8 points) ✓
- Payment test cases (6 points) ✓
Оставить для следующего спринта:
- Payment Integration
- Analytics Dashboard

Increment — готовый функционал в конце спринта

• Должен быть Done (готов для production)
• Включает код, тесты, документацию
• Может быть released или holdится для следующего release

Плюсы Scrum

Структурированность — четкие роли, события, артефакты

• Знаем кто за что отвечает
• Знаем когда встречаемся
• Есть регулярная feedback

Предсказуемость — спринты позволяют планировать

• Velocity (сколько points в спринт)
• Можем оценить сроки
• Regular releases

Адаптируемость — быстро respond на изменения

• Backlog можно пересортировать
• Каждый спринт можно изменить prioritize
• Regular demos для feedback

Accountabilty — каждый спринт team коммитится

• Видно что задачи completed
• Burn-down chart показывает progress

Минусы Scrum

Требует дисциплины — много meetings

• Planning, Daily, Review, Retro
• ~5 часов в неделю meetings
• Для маленькой team это overhead

Fixed sprint — сложнее с interrupt-driven work

• Urgent issues середине спринта
• Нужно решить: прерывать ли спринт?
• Может быть disruptive

Estimation сложна — оценить в points не просто

• Team может переоценить или недооценить
• Velocity может варьироваться
• "What is 3 points?" вопрос

Не scalable для маленьких teams — overhead большой

• 2-3 человека: 5 часов meetings из 40 часов работы = 12.5% overhead
• Может быть не эффективно

Kanban методология

Определение

Kanban — это методология управления потоком работы, основанная на визуализации work items, ограничении WIP (Work In Progress) и непрерывном улучшении.

Принципы Kanban

1. Визуализация — все work items видны на доске

Kanban Board:
┌──────────────┬──────────────┬──────────────┬──────────────┐
│  To Do       │  In Progress │  In Review   │  Done        │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ Task 1       │ Task 3       │ Task 5       │ Task 7       │
│ Task 2       │ Task 4       │ Task 6       │ Task 8       │
│ Task 9       │              │              │              │
│ Task 10      │              │              │              │
└──────────────┴──────────────┴──────────────┴──────────────┘
Limit: 2       Limit: 3       Limit: 2       No limit

2. WIP Limiting — ограничиваем работы в процессе

• In Progress max 3 items
• Если кто-то свободен но limit не превышен, может взять новую
• Если все работают на WIP limit, нужно что-то завершить перед новой работой
• Результат: focus, быстрее completion

3. Flow Management — управляем потоком работы

• Items движутся слева направо по доске
• Стараемся минимизировать время в каждой колоне
• Pull система (берём работу когда готовы, не push)

4. Explicit Policies — ясные правила

• Что значит "Done"?
• Как items попадают из To Do в In Progress?
• Когда выполняется deployment?

5. Continuous Improvement — постоянно улучшаемся

• Metrics tracking (cycle time, lead time, throughput)
• Regular retros
• Экспериментируем с процессом

Артефакты Kanban

Kanban Board — визуализация workflow

• Physical board (картечки) или digital (Jira, Trello)
• Columns = workflow stages
• WIP limits на каждую column

Metrics

Lead Time — время от request до delivery

Client request → Feature delivered = 30 дней lead time

Cycle Time — время от start работы до finished

Developer начал → feature готов = 5 дней cycle time

Throughput — сколько items завершено за период

За неделю: 10 items completed
Throughput = 10 items/week

Cumulative Flow Diagram (CFD) — визуализирует flow

      Done
      ▄▄▄▄▄
     ╱     ╲
Review
     ▄▄▄▄▄
    ╱     ╲
In Progress
     ▄▄▄▄▄
    ╱     ╲
To Do
___________|___
 Time →

Плюсы Kanban

Простота — нет много meetings

• Нет sprint planning
• Нет sprint estimation
• Нет sprint boundaries
• Minimal overhead

Гибкость — легко меняется

• Новая urgent task? Добавь в To Do
• Не нарушает спринт
• Continuous delivery

Фокус на efficiency — WIP limiting улучшает flow

• Меньше context switching
• Быстрее completion
• Лучше качество (не спешим)

Scalable для маленьких teams — minimal overhead

• 2-3 человека: можно use Kanban
• Простой board
• Основной focus на работу, не на meetings

Metrics driven — основано на data

• Lead time, cycle time tracking
• Видим improvements
• Data-driven decisions

Минусы Kanban

Неструктурированность — меньше жёсткости

• Нет четких iterations
• Сложнее predict сроки
• Нет commitment ceremonies

Требует дисциплины — WIP limits нужно enforce

• Если не соблюдать limits, теряется смысл
• Requires культура discomfort (not taking more work когда можешь)

Сложнее с большими releases — continuous vs batch

• Kanban designed для continuous delivery
• Если need big coordinated release (v2.0), сложнее

Estimation не явная — story points не обязательны

• Сложнее understand complexity
• Сложнее compare tasks

Scrum vs Kanban сравнение

Когда использовать Scrum?

✓ Well-defined requirements — знаем что будем делать ✓ Stable team — люди не уходят ✓ Enough people — минимум 5-7 developers ✓ Predictable work — не много interrupts ✓ Product iterations — want batch releases ✓ Large projects — много work нужно organize ✓ Enterprise требует structure — defined roles и processes

Когда использовать Kanban?

✓ Interrupt-driven work — support, bug fixes, urgent issues ✓ Small team (1-3 people) — overhead не приемлем ✓ Continuous delivery — want release всегда готовой ✓ Variable complexity — tasks сильно различаются ✓ Focus на efficiency — WIP limiting поможет ✓ Flexibility important — need easily prioritize ✓ Junior team — learning curve меньше

Hybrid: Scrumban

Scrumban — комбинация Scrum и Kanban

• Scrum iterations для structure
• Kanban WIP limiting для efficiency
• Scrum ceremonies но lighter
• Kanban metrics для tracking

Популярен в teams которые:

• Нужна структура Scrum
• Но нужна гибкость Kanban
• Interrupt-driven work есть

XP (Extreme Programming)

Дополняет Scrum/Kanban с engineering practices:

• Pair programming
• TDD (Test-Driven Development)
• Continuous Integration
• Refactoring
• Simple design

Хорошо combined с Scrum.

Waterfall

Когда использовать:

• Hardware projects (нельзя change mid-way)
• Regulated industries (GDPR, HIPAA)
• Requirements полностью clear
• Low risk изменений

Минусы: сложнее adapt, долгий feedback cycle

Выбор методологии

Questions to ask:

1. How much requirements change? → Agile
2. How much structure needed? → Scrum
3. How much flexibility? → Kanban
4. How interrupt-driven? → Kanban
5. How predictability important? → Scrum
6. Team size? → Small = Kanban, Large = Scrum
7. Release frequency? → Continuous = Kanban, Batch = Scrum

Рекомендация: большинство teams успешны с Scrum или Scrumban.

Системный аналитик должен понимать все методологии и рекомендовать оптимальную для проекта.