Ad
More Related Content
What's hot (9)
Viewers also liked (13)
Ad
Similar to Scrum в управлении проектами (20)
Ad
Scrum в управлении проектами
- 1. 1 SCRUM В УПРАВЛЕНИЕ ПРОЕКТАМИ Дашкин Руслан Валерьевич arslandv@gmail.com
- 2. СТРУКТУРА ПРЕЗЕНТАЦИИ • ОСНОВНЫЕ КРИТЕРИИ ВЫБОРА • ПРИЧИНЫ ВОЗНИКНОВЕНИЯ • СРАВНЕНИЕ МЕТОДОЛОГИЙ • ОСНОВНЫЕ ПОНЯТИЯ, ПРИНЦИПЫ И АРТЕФАКТЫ ПО SCRUM
- 3. ИСТОРИЯ В ФЕВРАЛЕ 2001 В ШТАТЕ ЮТА США БЫЛ ВЫПУЩЕН «МАНИФЕСТ ГИБКОЙ МЕТОДОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ». ОН ЯВЛЯЛСЯ АЛЬТЕРНАТИВОЙ УПРАВЛЯЕМЫМ ДОКУМЕНТАЦИЕЙ, «ТЯЖЕЛОВЕСНЫМ» ПРАКТИКАМ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ТАКИМ КАК «МЕТОД ВОДОПАДА», ЯВЛЯВШИМСЯ ЗОЛОТЫМ СТАНДАРТОМ РАЗРАБОТКИ В ТО ВРЕМЯ. ДАННЫЙ МАНИФЕСТ БЫЛ ОДОБРЕН И ПОДПИСАН ПРЕДСТАВИТЕЛЯМИ МЕТОДОЛОГИЙ ЭКСТРЕМАЛЬНОГО ПРОГРАММИРОВАНИЯ, CRYSTAL CLEAR, DSDM, FEATURE DRIVEN DEVELOPMENT, SCRUM, ADAPTIVE SOFTWARE DEVELOPMENT, PRAGMATIC PROGRAMMING.
- 4. ЧТО ТАКОЕ AGILE? • ГИБКАЯ МЕТОДОЛОГИЯ РАЗРАБОТКИ (АНГЛ. AGILE SOFTWARE DEVELOPMENT) — ЭТО КОНЦЕПТУАЛЬНЫЙ ПОДХОД, В РАМКАХ КОТОРОГО ВЫПОЛНЯЕТСЯ РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. СУЩЕСТВУЕТ НЕСКОЛЬКО ПОДОБНЫХ МЕТОДИК. • ЦЕЛЬ: МИНИМИЗАЦИЯ РИСКОВ • ЗА СЧЕТ ЧЕГО: РАЗРАБОТКА КОРОТКИМИ ИТЕРАЦИЯМИ
- 5. ТРАДИЦИОННЫЙ ПОДХОДТех.задание Проектирование Разработка Опытная эксплуатация Промышленная эксплуатация 100 000 р. 150 000 руб. 200 000 руб. 192 000 руб.
- 8. ОСНОВНЫЕ ПРИНЦИПЫ AGILE • УДОВЛЕТВОРЕНИЕ КЛИЕНТА ЗА СЧЁТ РАННЕЙ И БЕСПЕРЕБОЙНОЙ ПОСТАВКИ ЦЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ; • ПРИВЕТСТВИЕ ИЗМЕНЕНИЙ ТРЕБОВАНИЙ ДАЖЕ В КОНЦЕ РАЗРАБОТКИ (ЭТО МОЖЕТ ПОВЫСИТЬ КОНКУРЕНТОСПОСОБНОСТЬ ПОЛУЧЕННОГО ПРОДУКТА); • ЧАСТАЯ ПОСТАВКА РАБОЧЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (КАЖДЫЙ МЕСЯЦ ИЛИ НЕДЕЛЮ ИЛИ ЕЩЁ ЧАЩЕ);
- 9. ОСНОВНЫЕ ПРИНЦИПЫ AGILE • ПРОЕКТОМ ЗАНИМАЮТСЯ МОТИВИРОВАННЫЕ ЛИЧНОСТИ, КОТОРЫЕ ОБЕСПЕЧЕНЫ НУЖНЫМИ УСЛОВИЯМИ РАБОТЫ, ПОДДЕРЖКОЙ И ДОВЕРИЕМ; • РЕКОМЕНДУЕМЫЙ МЕТОД ПЕРЕДАЧИ ИНФОРМАЦИИ — ЛИЧНЫЙ РАЗГОВОР (ЛИЦОМ К ЛИЦУ); • ТЕСНОЕ, ЕЖЕДНЕВНОЕ ОБЩЕНИЕ ЗАКАЗЧИКА С РАЗРАБОТЧИКАМИ НА ПРОТЯЖЕНИИ ВСЕГО ПРОЕКТА;
- 10. ОСНОВНЫЕ ПРИНЦИПЫ AGILE • РАБОЧЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ – ГЛАВНАЯ МЕРА ПРОГРЕССА ПРОЕКТА • ГИБКИЕ ПРОЦЕССЫ СПОСОБСТВУЮТ НЕПРЕРЫВНОМУ РАЗВИТИЮ. ВСЕ УЧАСТНИКИ ПРОЕКТА ДОЛЖНЫ УМЕТЬ ВЫДЕРЖИВАТЬ ТАКОЙ ПОСТОЯННЫЙ ТЕМП. • ПОСТОЯННОЕ ВНИМАНИЕ К ТЕХНИЧЕСКОМУ СОВЕРШЕНСТВУ И КАЧЕСТВЕННОЙ АРХИТЕКТУРЕ СПОСОБСТВУЮТ ГИБКОСТИ.
- 11. ОСНОВНЫЕ ПРИНЦИПЫ AGILE • ПРОСТОТА НЕОБХОДИМА, КАК ИСКУССТВО МАКСИМИЗАЦИИ РАБОТЫ, КОТОРУЮ НЕ СЛЕДУЕТ ДЕЛАТЬ. • ЛУЧШАЯ АРХИТЕКТУРА, ТРЕБОВАНИЯ, ДИЗАЙН СОЗДАЕТСЯ В САМООРГАНИЗУЮЩИХСЯ КОМАНДАХ. • КОМАНДА ПОСТОЯННО ИЩЕТ СПОСОБЫ СТАТЬ БОЛЕЕ ЭФФЕКТИВНОЙ, ПУТЕМ НАСТРОЙКИ И АДАПТАЦИИ СВОИХ ПРОЦЕССОВ.
- 12. ПРОЦЕНТНОЕ СООТНОШЕНИЕ УСПЕШНОГО ЗАВЕРШЕНИЯ ИТ ПРОЕКТОВ 43 63 63 72 Offshoring Data Warehouse Traditional Agile
- 13. ПРЕИМУЩЕСТВА Традиционный подход Agile •Легок для понимания и использования; •Детально структурирован, что облегчает его применение к малоопытным командам; •Задает стабильные требования к проекту/продукту с самого старта; •Проекты легко контролируются, отслеживаются ресурсы, риски, время; •Качество имеет первоочередной приоритет по сравнению со стоимостью и •Итеративная разработка; •Использование временные рамки(time boxes); •Конечный пользователь вовлечен в процесс с самого начала; •Быстрое получение первой/пробной версии продукта для тестирования; •Легко воспринимаются корректировки и изменения в процессе разработки.
- 14. НЕДОСТАТКИ Традиционный подход Agile •Все требования должны быть определены и детально описаны до начала разработки; •Дорого и медленно; •Чувствителен к изменениям; •Мало возможностей для конечного пользователя повлиять на цели проекта и требования к продукту; •Зачастую проблемы выявляются на этапе тестирования; •Много документации, много технической документации, которая не понятна конечному •Может привести к низкому качеству продукта; •Риск никогда не достигнуть закрытия/завершения проекта; •Могут возникнуть проблемы с расширяемостью продукта.
- 15. КРИТЕРИИ ВЫБОРА Традиционный подход Agile •Требования к продукту предельно ясны и стабильны; •Известны используемые технологии и инструменты; •Продукт четко формализован •Архитектура продукта строго регламентирована и детализована; •Требования внешних нормативных документов. •Команда с высоким уровнем профессионализма; •Тесная связь заказчика и разработчиков; •вовлечен в проект со старта; •Четко определены бизнес- цели проекта/продукта; •Состав команды стабильный; •Технические требования приемлемые, коллериются с технологиями, которые собираются быть использованными для разработки; •Система может быть модульной.
- 16. ГРАФИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СРАВНЕНИЯ МЕТОДОЛОГИЙ Наглядное представление Риски Ценность для заказчика - Гибкие методологии - Традиционные методологии
- 18. АРТЕФАКТЫ • СПИСОК ЗАДАЧ ПО ПРОДУКТУ -PRODUCT BACKLOG • СПИСОК ЗАДАЧ ИТЕРАЦИИ -SPRINT BACKLOG • ГРАФИК ВЫПОЛНЕНИЯ ЗАДАЧ BURNDOWN CHART • СПИСОК ПРОБЛЕМ -IMPEDIMENTS LISTРЕЛИЗ
- 19. КОММУНИКАЦИИ • ПЛАНЕРКА ИТЕРАЦИИ -SPRINT PLANNING • ЕЖЕДНЕВНАЯ ПЛАНЕРКА - DALLY SCRUM • ПОДВЕДЕНИЕ ИТОГОВ - SPRINT REVIEW • РАЗБОР ПОЛЕТОВ -SPRINT RETROSPECTIVE
- 20. РОЛИ • МЕНЕДЖЕР ПРОДУКТА -PRODUCT OWNER • ЛИДЕР КОМАНДЫ -SCRUM MASTER • КОМАНДА – TEAM (7±2 ЧЕЛОВЕК, САМООРГАНИЗУЮЩАЯСЯ, КРОССФУНКЦИОНАЛЬНАЯ)
- 21. СОБЫТИЯ • РЕЛИЗ • ИТЕРАЦИИ -SPRINT
- 23. ОБЛАСТИ ЗНАНИЙ