Please enable JavaScript.

Coggle requires JavaScript to display documents.

Методологии AGIL - Coggle Diagram

- - - - Команда
        
        ► Слаженный организм профессионалов:
        • автономный, в котором участники сами решают, как выполнять задачу
        • многофункциональный — знаний и навыков членов команды хватает для решения задачи
        Состав 7+-2 человек
        (иначе тратят много ресурсов на коммуникации)
        
        Роли
        
        ВЛАДЕЛЕЦ ПРОДУКТА (Product Owner)
        — человек, который отвечает за функциональность конечного продукта, составляет список пользовательских историй (бэклог проекта) и ведет его по ходу проекта.
        Зона ответственности — что делать в рамках проекта и связь с заказчиком
        
        Обязанности
        
        • Отвечает за формирование концепции продукта (product vision)
        • Управляет ROI (возврат вложенных средств)
        • Управляет ожиданиями заказчиков и всех заинтересованных лиц
        • Координирует и приоритизирует баклог продукта (Product backlog)
        • Предоставляет понятные и тестируемые требования команде
        • Взаимодействует с командой и заказчиком
        • Отвечает за приемку кода в конце каждой итерации
        
        СКРАМ-МАСТЕР (Scrum Master) - самая важная роль в методологии, отвечает за успех Scrum в проекте. Обязательно один из членов команды. Как правило, он совмещает работу скрам-мастером с проектной ролью (разработчик, тестировщик, аналитик и т.д.)
        Зона ответственности - отвечает за соблюдение командой практик гибкой разработки и помогает команде придерживаться принятых ею решений.
        
        Обязанности
        
        • Создает атмосферу доверия
        • Делает проблемы и открытые вопросы видимыми
        • Участвует в митингах в качестве модератора
        • Устраняет внешние препятствия
        • Отвечает за соблюдение практик и процесса в команде
        
        КОМАНДА (TEAM) - является самоорганизующейся и самоуправляемой.
        ! В SCRUM ВКЛАД ОТДЕЛЬНЫХ ЧЛЕНОВ ПРОЕКТНОЙ КОМАНДЫ НЕ ОЦЕНИВАЕТСЯ, ТАК КАК ЭТО РАЗВАЛИВАЕТ САМООРГАНИЗАЦИЮ КОМАНДЫ !
        Зона ответственности - выполнение объема работ на спринт перед Владельцем продукта.
        
        Обязанности
        
        • Отвечает за оценку элементов баклога
        • Формирует план спринта (Sprint Backlog)
        • Принимает решения по дизайну и имплементации
        • Разрабатывает софт и предоставляет его заказчику
        • Отслеживает собственный прогресс (вместе со скрам-мастером)
        • Отвечает за результат перед Владельцем продукта
      - Артефакты
        
        БАКЛОГ ПРОДУКТА (PRODUCT BACKLOG)
        
        Приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе (use cases, defects, enhancements, т.д. )
        Ответственный: Владелец
        
        ЕЖЕДНЕВНЫЙ СТЕНДАП-МИТИНГ
        
        ► проходит каждое утро в начале дня и предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте
        ► Длительность этого митинга строго ограничена и не должна превышать 15 минут
        ► Совещание проводится стоя, что важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу
        Ответственный: Скрам Мастер
        
        СПРИНТ
        
        Спринт (или итерации) является основной единицей разработки в SCRUM и представляет собой определенный таймбокс, то есть ограничение определенной продолжительности. Продолжительность фиксируется заранее для каждого спринта и обычно составляет от одной недели до одного месяца, двухнедельный спринт является наиболее распространенным.
        Результатом спринта является готовый продукт (build), который можно передавать заказчику
        
        Планирование
        
        Определение той функциональности, которая будет разработана (Sprint Backlog) при участии заказчиков, пользователей, владельца продукта, скрам-мастера и команды
        
        Для каждого элемента Баклога спринта команда определяет список задач и оценивает их продолжительность и определяется исполнитель
        
        ДЕМО И РЕВЬЮ СПРИНТА
        
        В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта. На этом этапе заказчик высказывает свое мнение, вносит коррективы, запрашивает дополнительный функционал и т.д.
        Используются: Отчеты за соответствующий промежуток времени, «клиентский доступ» к проектам (виден прогресс, не видна внутренняя кухня), комментарии и эмоции.
        
        В конце спринта происходит спринт-ревью (sprint review, обзор спринта) - команда рассказывает о поставленных задачах, как они были решены, какие препятствия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными.
        На основании ревью принимающая сторона может сделать выводы о том, как должна дальше развиваться система
        
        БАКЛОГ СПРИНТА (BACKLOG) BACKLOG)
        
        Список задач на спринт — отсортированный список идей, которые команда решила сделать за ближайший спринт
    - - Выберите владельца продукта, который четко определит, что должно быть сделано
        
        Сформируйте скрам-команду
        
        Назначьте скрам-мастера
        
        Создайте бэклог проекта в виде списка пользовательских историй. Включите в него все задачи, которые команда могла бы сделать для проекта, и расставьте их по приоритету
        
        Оцените задачи из бэклога, используя относительные величины, например, размеры футболок или числа из последовательности Фибоначчи: 0, 1, 1, 2, 3, 5, 8, 13 и т.д. Оценивайте задачи всей командой с помощью покера планирования (planning poker): используйте колоду карт или приложение на смартфон.
        
        Проведите планирование спринта: выберите задачи и распределите их между исполнителями
        
        Заведите скрам-доску, поделите ее на три части: нужно сделать, в работе, сделано. Перемещайте стикеры с задачами, чтобы видеть динамику работы. Используйте реальную или виртуальную доску.
        
        Не забывайте о ежедневных собраниях
        
        В конце спринта проведите демонстрацию
        
        Соберитесь на ретроспективу, обсудите, как улучшить работу, какие препятствия устранить. Это может быть неработающая кофемашина, тормозящий компьютер, некомфортная температура воздуха, вспыльчивость коллеги, недобросовестный подрядчик. Когда команда начинает работать по скраму, решаются проблемы, которые месяцами откладывались в долгий ящик.
        
        Начинайте следующий спринт с планирования (пункт 6).
    - - Если Scrum не работает, или работает хуже, чем ожидалось:
        • Scrum применяется неверно или неполностью.
        • Недооценена важность работы по обеспечению мотивации команды
        • Scrum применяется для продукта, требования к которому противоречат идеологии Scrum (fixed-cost/fixed-time проектах).
    - - • Не все проекты можно выполнять по такой методологии. Для госзаказов, к примеру, Scrum многие специалисты считают неприменимой
        • Отсутствие фиксированных бюджета и срока проекта в целом осложняет заключение юридических договоров
        • Немотивированная или низкоквалифицированная команда не сможет работать эффективно. А далеко не все сотрудники отличаются самоорганизованностью. Это же может повысить затраты на подбор и отбор кадров
        • С некомпетентностью можно столкнуться и при подборе специалистов на роль Scrum-мастера. Сейчас очень много людей, имеющих на руках сертификат о том, что они прошли обучение. При этом далеко не всегда эти люди действительно являются профессионалами и могут организовывать деятельность команды
    - - • Быстрое удовлетворение большинства требований заказчика или клиентов
        • Высокая конкурентоспособность продукта за счёт его постоянной оптимизации
        • Большая эффективность рабочей команды: каждый сотрудник постоянно занят своим делом, не тратит время на лишние разговоры, при этом постоянно взаимодействует с коллегами и через Product Owner с заказчиками
        • Готовый продукт производится в быстрые сроки
        • Экономия на менеджерах, так как команда управляется изнутри только Scrum-мастером, а извне лишь получает требования к продукту от заказчика
        
        Целесообразность применения Scrum
        • При создании инновационных продуктов. В тех случаях, когда заказчик имеет лишь общие представления о том, что продукт будет из себя представлять. Поэтому часто Scrum используется для разработки нового ПО.
        
        • В случаях, когда продукт нуждается в постоянных обновлениях, чтобы быть удобным и конкурентоспособным.