🦒
System Analyst | Knowledge base
  • Введение
  • Soft skills
    • 📍Продукт
      • Роли в IT продукте
        • Системный аналитик (SA)
        • Бизнес-аналитик (BA)
        • SA vs BA
        • 📎Другие аналитики
      • Жизненный цикл продукта
      • Методологии разработки
        • Waterfall
        • Agile
          • Scrum
          • Kanban
      • 📎Целеполагание
        • SMART
        • Матрица Эйзенхауэра
        • RICE
        • 🔒HADI
    • 📍Требования
      • Классификация требований
        • Уровень: Бизнес
        • Уровень: Пользователь
          • Use case
          • User story
          • 📎Job story
        • Уровень: Продукт
          • Функциональные требования
          • Нефункциональные требования
      • Качества требований
      • Методы сбора требований
      • Техническое задание (ТЗ)
  • Hard skills
    • 📍Базы данных
      • Реляционные
        • Транзакции
          • 🔒CAP
        • Нормальные формы
        • SQL
          • DML
          • DDL/DCL/TCL
          • 📎Представления VIEW
        • Констрейты
        • 📎Типы данных
        • 🔒Middle+
          • Особенности работы с конкертными реляционными БД
      • Нереляционные
        • Примеры использования
        • 🔒Middle+
          • Колоночные
            • Сlickhouse
          • Ключ-значение
          • Матричные
          • Документо-ориентированные
          • Графовые
            • JanusGraph | Neo4j etc
      • Масштабирование БД
      • Оптимизация БД
        • 📎Типы индексов
        • 📎Уникальные индексы
        • 🔒Анатомия плана запроса
      • 📎Какую СУБД выбрать
      • 📎Хранение и анализ данных
        • ETL
        • DWH
          • DWH vs Data Lake vs Data Mart
        • OLAP
          • OLAP vs OLTP
        • BI-аналитика
    • 📍Интеграции
      • Форматы данных
        • JSON + JSON Schema
          • 🔒AVRO
        • JSON vs XML
      • Виды интеграций
        • Синхронное взаимодействие
          • REST
            • RESTful принципы
              • Отсутствие состояния (Авторизация)
                • 🔒OAuth / OpenID Connect
              • Кеширование
              • Единообразие интерфейса (CRUD)
                • Запрос/ответ
              • 🔒Cтепень зрелости REST API
            • Проектирование API
            • 📎Асинхронный REST
          • SOAP
            • XSD
            • WSDL
          • REST vs SOAP
        • Асинхронное взаимодействие
          • Kafka
          • RabbitMQ
          • Kafka vs RabbitMQ
          • ESB
          • gRPC
            • Правила proto-контракта
            • Protobuf vs JSON
            • Сравнительная таблица
          • Другое
          • 🔒WebSocket API
        • Sync vs Async
      • 🔒Middle+
        • Stateful vs Stateless
        • Apache Flink
        • оркестрация и хореография
    • 📍Проектирование
      • Архитектура
        • Монолит
        • Микросервисы
          • Паттерны реализации
        • Монолит vs Микросервисы
        • 🔒Middle+
          • Бессерверная
          • Сервис-ориентированная (SOA)
          • Другое
      • Нотации и диаграммы
        • UML
          • Диаграмма классов
          • Диаграмма последовательности
            • Фреймы
          • Диаграмма прецедентов (use case)
          • 🔒Middle+
            • Диаграмма деятельности/активности
            • Диаграмма состояний
        • BPMN
          • Основные элементы
        • BPMN vs UML
        • ERD
        • 📎IDEF0
      • Прототипирование
        • Figma vs Axure
      • Мониторинг
        • Логирование
        • Метрики
        • Алерты
        • 🔒Инструменты
          • Grafana
          • Prometheus
          • ELK
            • Elasticsearch
            • Logstash
            • Kibana
      • 🔐Системный дизайн
    • 📎DevOps for SA
      • Основы сетей
        • OSI
        • TCP/IP
        • HTTP
        • DNS
      • Git (VCS)
        • GitHub vs GitLab
      • Развертывание приложений
        • CI/CD
        • 🔒Middle+
          • Виртуализация/контеризация
            • ✍️Docker
            • Kubernetes
              • ✍️Openshift
      • Cloud Native
        • Сервисы облачных вычислений
        • Cloud-native app vs Traditional app
      • Командная строка
    • 📎QA for SA
      • Postman | Insomnia
      • Swagger
      • Верификация vs Валидация
      • Идентификация/Аутентификация/Авторизация
    • 📎PM for SA
      • Метрики
        • Метрики привлечения
        • Метрики вовлечённости
          • ARPU
          • LTV
          • NPV
          • ROI
          • NPS
      • Прокси метрики
      • Дерево метрик
      • Фреймворки
      • Юнит-экономика
      • Модель Кано
  • Другое
    • Литература
    • Советы по составлению резюме
    • Общие вопросы на собеседовании
    • Вопросы которые надо задать интервьюеру
  • Контакты
Powered by GitBook
On this page
  • Scrum роли в команде
  • Scrum события
  • Преимущества
  • Недостатки
  • Где используется

Was this helpful?

  1. Soft skills
  2. Продукт
  3. Методологии разработки
  4. Agile

Scrum

популярно, быстро, эффективно

PreviousAgileNextKanban

Last updated 1 year ago

Was this helpful?

Если Agile – это принципы и философия, то Scrum – это набор конкретных правил и регламентов, которые говорят о том, как именно организовывать работу.

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

Scrum роли в команде

  • Product owner – управляет бэклогом. Backlog – набор требований, которые надо реализовать для того, чтобы продукт был готов. Задачи product owner собрать BackLog, сделать его понятным для команды, выставить приоритеты. Backlog постоянно обновляется в зависимости от текущих целей разработки.

  • Scrum master – координирует команду. Специалист по Scrum, досконально знает этапы, церемонии, артефакты Scrum разработки. Зачастую эту роль выполняет Product owner.

  • Development team – команда разработки (разработчики, аналитики, тестировщики). Люди должны быть кросс-функциональны, т.е. иметь унифицированные компетенции (каждый должен уметь делать все).

Scrum события

  • Sprint – время, за которое создается инкремент продукта — готовый для конечного пользователя продукт. Само часто встречающиеся по длине спринты - это 1 или 2 недели.

  • Планирование Sprint’а – на этой встрече решается, каким будет инкримент, и как организовать работу, чтобы успеть сделать все задачи. Целью планирования является формирование бэклога спринта из бэклога продукта. В планировании спринта участвуют все члены Scrum команды.

  • Ежедневные митинги (daily meeting) – встречи, на которых обсуждается, что сделано за предыдущий день, что будет делаться сегодня, какие проблемы мешают достижению целей спринта.

  • Обзор спринта (Sprint review meeting) — встреча с подведением итогов спринта, демонстрация инкремента продукта для product owner или заказчика. В обзоре спринта участвуют все члены Scrum команды.

  • Ретроспектива – на нем высказываются о прошедшем спринте: что было сделано хорошо, то надо улучшить в следующем спринте. Чаще всего проходит в рамках Sprint review meeting.

  • Груминг (Grooming) – это процесс в разработке ПО, который помогает уточнять и приоритезировать задачи в проекте. Он включает в себя команду участников, которые создают и анализируют задачи или пользовательские истории в беклоге проекта, а затем определяют, какие из них являются наиболее важными или должны быть выполнены первыми.

Преимущества

  • Простота внедрения методологии в команду

  • Эффективное взаимодействие между участниками проекта. Процесс принятия решений полностью зависит только от членов команды. Все внутренние процессы регулируют сами разработчики. Это позволяет всем участникам проекта четко понимать свои функции и задачи.

  • Возможность быстрого запуска проекта с наиболее приоритетными функциями и минимально возможным бюджетом.

  • Ежедневный контроль над ходом работ, и более гибкий контроль над бюджетом проекта.

  • Малую вероятность провала разработки из-за частых совещанием с заказчиком продукта.

  • Возможность вносить коррективы в техническое задание по ходу реализации проекта.

Недостатки

  • Большое количество совещаний. (порядка 15-20% рабочего времени)

  • Необходимость кросс-функциональности команды с высокой квалификацией.

  • Сложности при заключении договоров. Scrum в принципе не подразумевает наличие фиксированного бюджета и фиксированного технического задания, что затрудняет юридическое оформление такого рода договоренностей.

Где используется

Scrum подходит для проектов, где важно быстро предоставлять результаты работы и иметь возможность отреагировать на изменения в процессе разработки. А ещё благодаря многообразию совещаний и способов делегировать задачи эту систему удобно применять, когда некоторые члены команды не знакомы с контекстом продукта.

Источники:

📍
https://vc.ru/u/752307-karina-gorbunova/218436-kanban-agile-scrum-lean-gibkie-metodologii-razrabotki
https://stecpoint.ru/Practices-Methodologies/
https://agaltsovav.ru/docs/development-managment/grooming/
Цикл разработки по Scrum