2. AGILE ПРИНЦИПЫ - МАНИФЕСТ
• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий
контракта;
• готовность к изменениям важнее следования
первоначальному плану.
3. RICH MIRONOV, AUTHOR OF THE ART OF PRODUCT MANAGEMENT
“For too many teams, product managers and product owners are now
providing development and operational support rather than gathering and
sharing market insights. Contrary to what the Agile movement envisioned,
the product manager or product owner is no longer able to provide up-to-
date market information and strategic vision because they’re immersed in
development activities.”
“Ever larger Agile and Scrum development organizations are pulling
product managers into heads-down product owner roles, crowding
out our time to understand complex markets and determine what our
customer segments really want. As product managers, we have to
avoid orthodoxy and choose the right mix of tools and
methodologies for our unique situations.
4. “I think product managers should take a
step back from the requirements process
and look at the system as a whole – all the
way through from the customer pain you
are trying to solve, to asking which brand
positioning your company has or is
developing, and which story you would like
your customers to say. Then, work
backwards to build that kind of product.”http://thenextweb.com/insider/2015/05/05/the-future-
of-product-management/#gref
5. SCRUM МЕТОДОЛОГИЯ
• Равноправие в команде
• Размер группы
• Артефакты
• Цель - Быстрая реализация
• Равновысокий уровень
• 3 – 9 технарей
• Умения
• Архитектурная слабость
6. ДРУГИЕ МЕТОДИКИ AGILE - RATIONAL UNIFIED PROCESS
на 1000+ человек
> 30 ролей
> 20 активностей
> 70 артифактов
13. ХАРАКТЕРИСТИКИ ПРОЕКТА
• Размер до 10 | до 100 | до 1000| выше 1000 чел/мес
• Бюджет лимитирован | по этапам | не важен
• Сроки несколько месяцев | до 2х лет | неограничен
• Качество прототип | коммерческий продукт | высоконадежный
• Среда ежемесячно | ежегодно | реже конкурентный продукт
• Заказчик финансовый | стратегический партнер | технарь
SCRUM V Model
14. КОМАНДА ПРОЕКТА
• Размер до 10 | до 100 | до 1000| выше 1000 чел/мес
• Бюджет лимитирован | по этапам | не важен
• Сроки несколько месяцев | до 2х лет | неограничен
• Качество прототип | коммерческий продукт | высоконадежный
• Среда ежемесячно | ежегодно | реже конкурентный продукт
• Заказчик финансовый | стратегический партнер | технарь
Juniors Seniors
18. • Проекты разные – уникальные
• Процессы общие – стандартные
• Построение уникального здания из стандартных кирпичей
• Проект для РМ ------ Процессы для команды
Проект
Процессы
19. ПРИНЦИП РАЗРАБОТКИ АДАПТИВНОЙ МОДЕЛИ
• Определить константные параметры проекта
• Определить граничные условия параметров проекта
• Выстроить приоритеты параметров
• Разбить проект на этапы
• Определить критерии прохождения этапа Stage-and-Gate
• Построить модели для каждого этапа
Размер
Бюджет
Сроки
Качество
Среда
Заказчик
ПРОЕКТ
20. Делаем
Планируем
Никто не заходит так далеко, как
тот, кто не знает, куда идет.
Оливер Кромвель
Без совета предприятия
расстроятся, а при множестве
советников они состоятся
Притчи 15:22
21. ОТ ФУНДАМЕНТА К ОТДЕЛКЕ
• Разрабатываем архитектуру до «зоны тумана»
• С помощью методов абстрации создаем независимые модули
• Проверяем архитектуру на каждом витке разработки
• Максимально реализуем принцип Waterfall – планируем
потом делаем.
22. ПРИМЕР V МОДЕЛИ В SCRUM
Solicitation
Grooming
Coding
In Group
Testing
System
Testing
Code
Review
Demo
Product
Owner
Architect
And team
Leads
Team
Team
Developer
Another
Team
Developer
Team
Tester
AQA &
Senior
Tester
PO
And team
Leads
Planning
23. Requirement Analysis
Design
Implementation
Testing
Refactoring
Bug fixing
Evaluation
• Задача руководителя – Requirement Analysis & Dev. Model
• Что делаем – прототип, комерчески продукт, высоконадежный
• Сроки и этапы. Критерии прохождения
• Финансы и график их освоения
• Задача архитектора / тим лида
• Руководство дизайном
• Техническое распределение задач
24. ВЫВОДЫ
• Любая модель разработки подчиняется последовательности
SDLC
• Чем больше ресурсов можно потратить на «фундамент» тем
дешевле в итоге разработка
• Разработку модели управления следует вести от константных
характеристик, граничных условий и приоритетов
• Необходимо переосмысление всей концепции на каждом
витке итерации разработки.
• Использование метода Stage-and-Gate сохранит ресурсы
Размер
Бюджет
Сроки
Качество
Среда
Заказчик