Гибкий подход к разработке OSS для крупного заказчика

1. Гибкий подход к разработке OSS для крупного заказчика Уживутся ли Agile и крупный традиционный телекоммуникационный бизнес Александр Атцик, руководитель отдела развития

2. Как мы предлагаем заказчику наше ПО? Коробочное решение Кастомизация готового продукта Заказная разработка Облачное решение (SaaSи т.п.)

3. Заказная разработка и кастомизация Кастомизация готового продукта Требования заказчика Как мы организуем свою работу по выполнению требований? Заказная разработка

4. Крупный заказчик Традиционный подход – «Водопад» Тендер (предложение) Анализ Формирование требований Согласование ТЗ Разработка Тестирование Опытная эксплуатация Доработка Развертывание и промышленная эксплуатация

5. Минусы традиционного подхода • Решение принимается: • На верхнем уровне • Отсутствует/искажено мнение специалистов Старт проекта Окончание проекта

6. Принятие решений Обсуждение требований Представитель разработчика Компания заказчика Компания разработчика

7. Минусы традиционного подхода • Решение принимается: • На верхнем уровне • Отсутствует/искажено мнение специалистов Жесткие требования Старт проекта Окончание проекта

8. Требования $ $ V V t t Жесткие требования Нежесткие требования

9. Минусы традиционного подхода • Решение принимается: • На верхнем уровне • Отсутствует/искажено мнение специалистов Жесткие требования Обратная связь – только в конце проекта (спустя длительный срок после анализа) Старт проекта Окончание проекта Нивелировать эти минусы можно лишь точечно и не всегда эффективно

10. Семейство Agile Регулярная обратная связь от всех заинтересованных лиц Документация не жесткая: определяет цели и границы Требования гибко меняются на протяжении проекта Старт проекта Окончание проекта Итеративная разработка(периодами по 2-4 недели) Промышленная поставка функций по мере готовности + есть другие принципы (команда, роли, …)

11. Гибкая разработка & ГодовойБюджет Полноценное применениеAgile Крупный заказчик Минимальное количество документации Гибкие изменения решений Итерации Прямое взаимодействие с заинтересованными лицами Сложная система бюджетирования Иерархическая система принятия решений Множество заинтересованных лиц Разветвленная область компетенций

12. Наш Эксперимент Заказчик: МРФ «Юг» Разработка системы контроля ключевых показателей Цель: Разработка системы интеллектуальных выборок Цель:

13. Решенные задачи $ V Определили заинтересованных лиц Предварительнособрали требования t Интервью с заинтересованными лицами,объяснение, выбор функций для 1-го спринта Определилиграницы и объем

14. Решенные задачи Написали гибкое ТЗ, определили объем работ, допустимые изменения 3x-недельные спринты Детальное интервью по возникшимвопросам, коррекция планов разработки Получилиобратную связь

15. Результаты Разработчик Заказчик Показы результатов разработки Более четкое формулирование требований Пересмотр приоритетов функций Уточнение понимания трудозатрат Первые итерации Информирование о возможности разделения функций и их отдельной поставки Коррекциятребований ИзменениеIT-окружения Минимумдокументации Все заинтересованные лица проектав курсе его хода и состояния

16. Дискуссия