Сбор и анализ требований в Scrum Адаптация процесса ICONIX Вольфсон Борис Руководитель проектов Руководитель регионального отдела веб-разработки Компания.

Презентация:



Advertisements
Похожие презентации
Software Cloud Services Управление проектами в Softline Казарцев Максим, Руководитель отдела веб-разработки в г. Новосибирске
Advertisements

Роль Аналитика в IT- компании Руководитель группы Медведева Наталья.
Agile семейство процессов разработки. Манифест подписали представители следующих методологий Extreme programming, Scrum, DSDM, Adaptive Software Development,
Анализ и Проектирование качественных приложений Презентация по книге Крэга Лармана.
Аналитик и Тестировщик в одном лице – путь к качеству Докладчик: Максим Цепков Software Quality Assurance Days 10-я.
Scrum Выполнил: Сокольников А.М. ПС-41 Руководитель: Нехорошкова Л.Г.
Как не получить «кота в мешке» или поэтапная разработка мобильных приложений Евгений Кузьмин Руководитель отдела разработки.
Разработка объектно- ориентированного ПО Итеративная модель разработки (развитие водопадной модели) анализ проектирование кодирование тестирование.
Учебный курс Модели жизненного цикла и методологии разработки корпоративных систем Лекция 5 Методологии разработки корпоративных систем Лекции читает кандидат.
Культура промышленной разработки программного обеспечения Лекция 1 Воронежцев С.А., Затолокин А.В., Крапивин А.А. ФИВТ МФТИ 2013.
Положение об отделе В.Андреев, Д.Сатин. Штат отдела начальник отдела; бизнес-аналитик; проектировщик пользовательских интерфейсов; специалист по анализу.
Разработка Веб - проектов, от требований заказчика до запуска. Прозрачность разработки как средство формирования ожиданий заказчика.
Степан Василевский менеджер проектов QuartSoft Corp г.
11. Процесс разработки программной системы Последовательный и итеративный процессы разработки Процесс разработки программной системы является бизнес.
Обзор методологий управления интернет-проектами Олег Бунин.
Microsoft Solutions Framework Технологии программирования. Курс на базе Microsoft Solutions Framework Семинар 4. Прохождение фазы выработки концепции в.
Зачем нам нужна VP? Задачи VP взаимодействие между заказчиками и командой разработчиков понимание разрабатываемой системы сокращение расходов упрощение.
Agile Death March Projects Путь ниндзя. Правила ниндзя 1. Никому не рассказывать о ниндзя 2. Никому не рассказывать о ниндзя 3. Все вопросы после завершения.
Agile. Scrum.. Agile Гибкий подход к разработке ПО. Лучшие практики: Scrum XP TDD, etc. "Agility is not a technology, science, or product but a culture"
Транксрипт:

Сбор и анализ требований в Scrum Адаптация процесса ICONIX Вольфсон Борис Руководитель проектов Руководитель регионального отдела веб-разработки Компания Softline

Цели и содержания доклада Среда использования Описание процесса ICONIX Диаграммы и процесс Адаптация процесса ICONIX под Scrum/Agile Потери при производстве Синхронизация диаграмм и кода Соответствие принципам Agile Обсуждение и вопросы

Среда использования Scrum и ICONIX Компания Softline Разработка высоконагруженных коммерческих сайтов: Корпоративные веб-сайты Веб-сайты для электронной коммерции Около 100 основных участников проектов Страны СНГ и дальнего зарубежья Распределенная команда разработки Москва, Новосибирск и Оренбург

Среда использования Scrum и ICONIX: Product Owner ведет много разных проектов у проектов разные предметные области не специалист в области сбора и анализа требований Product Owner является бизнес-менеджером знает приоритеты бизнеса может являться спонсором проекта умеет выстраивать эффективные отношения с заказчиком...но Product Owner

Сбор и анализ требований в Scrum Создание и нормализация видения продукта Выявление и описание персонажей Создание юзер-стори Как «персонаж», я «действие» для «цель» Описания юзер-стори хранятся в виде «знаний» команды Для распределенных команд удобно использовать вики

Сбор и анализ требований в Scrum ПлюсыМинусы Нет общего описания системы Отсутствует моделирование Не очень подходит для распределенных команд Быстрое создание и легкое управление Позднее принятие решений Никаких избыточных артефактов

Как мы понимаем Scrum Всё что не приносит ценности для заказчика – потери, которые необходимо устранить Бережливое производство для софтверных проектов Приоритеты выставляет заказчик Короткие итерации и частые релизы Вытягивающее производство Проработка артефактов перед их непосредственным использованием Минимальные запасы готовых артефактов Точно в срок (JIT)

Полная UML Большой входной порог Более 10 видов диаграмм 900-страничное руководство Слишком подробное описание Неявная «Водопадная модель» Избыточность Необходимость постоянной актуализации диаграмм

Потери при производстве: UML Перепроизводство Ожидание Переключение между задачами Лишние этапы обработки Лишние запасы Ненужные перемещения сотрудников Дефекты

Что такое ICONIX? Методология анализа требований, основанная на вариантах использования Описание процесса создания и использования артефактов Используется подмножество UML

ICONIX подмножество UML

Классическая схема процесса ICONIX Протип UI Варианты использования Робастность Последовательность Динамика Сценарии тестирования Статика Предметная область Обновления предметной области Классы Код

Диаграмма предметной области

Диаграмма классов

Диаграмма вариантов использования Марья Васильевна как пользователь читает справку, чтобы понять, как использовать систему

Диаграмма робастности

Зачем нужна диаграмма робастности? Проверка полноты юзкейсов Выявление дополнительных объектов Проверка текста юзкейсов Предварительная проработка архитектуры «Мост» между анализом и архитектурой

Зачем нужна диаграмма робастности? Что? (анализ) Как? (архитектура) Пропасть

Диаграмма последовательности

Практики процесса ICONIX Анализ и уточнение требований Системный аналитик для Product ownerа Уменьшение количества неправильных требований Анализ предметной области Проектирование взаимодействия с системой Префакторинг – рефакторинг модели Синхронизация моделей и кода Агрессивное тестирование на всех уровнях

Проектирование взаимодействия с системой До разработки Во время разработки Usability Вытягивающее производство UI на основе требований Понимание продукта Ранний фидбек

Возвращение к водопадной модели? Классический ICONIX: Близок к водопадной модели Допускает потери при производстве Перепроизводство - проработка лишних требований Лишняя обработка - актуализация диаграмм Лишние запасы – проработка всей модели … но ICONIX отлично адаптируется к Agile

Варианты политик синхронизации диаграмм и кода Актуализация – это потери! Полная или частичная синхронизация «Внешние разработчики» Распределенная команда Поддержка продукта Части продукта для синхронизации Основной функционал Взаимодействие с внешними системами

Различия между моделью и кодом Количество различий Модель Код Время

Спринт 4 Подводное плавание - метафора содержания проекта Размер/рамки проекта Детализация проекта Общее описание системы и архитектура Спринт 1Спринт 2Спринт 3 Спринт 1Спринт 2 Спринт 3Спринт 4

Нулевой спринт – плаваем на поверхности Видение продукта Диаграмма предметной области Диаграмма вариантов использования Роли и персонажи Юзер-стори без описания Проработка юзер-стори для первого спринта Важно ограничить нулевой спринт по времени

Последующие спринты – ныряем на глубину Подробное описание юзер-стори Не больше двух параграфов Баланс текстового и графического описания Диаграмма робастности Диаграмма последовательности Диаграмма классов Обновление диаграммы предметной области и диаграммы юзкейсов

Возможные опасности Неполная осведомленность МП о возможностях продукта Ослабление коммуникаций между МП и командой Преждевременная проработка лишних требований Паралич анализа на нулевой итерации

Agile Manifesto Люди и их взаимодействие важнее процессов и инструментов Готовый продукт важнее полной документации Сотрудничество с заказчиком важнее контрактных ограничений Реакция на изменения важнее следования плану

Инструменты Бумага и карандаш Visio Enterprise Architect Простота Функционал

Плюсы и минусы ICONIX ПлюсыМинусы Подходит для распределенных команд Сочетаемость с Agile- методологиями Подмножество стандартного языка UML Моделирование в виде наглядных диаграмм Нарушение абсолютной кроссфункциональности команды Диаграммы не нужны заказчику Необходимость актуализации моделей

Методологии Scrum ICONIX XP

Литература Agile Development with ICONIX Process: People, Process, and Pragmatism by Doug Rosenberg, Matt Stephens and Mark Collins-Cope Use Case Driven Object Modeling with UML: Theory and Practice by Doug Rosenberg and Matt Stephens Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process Scott W. Ambler

Контакты и вопросы Спасибо за внимание! Вопросы? Мои контакты