Методы управления проектами с коротким циклом - agile от...

Методы управления проектами с коротким циклом - Agile от практиков

Презентация

Natalia Reen Ежегодная Всероссийская выставка по

кадровому менеджменту 20–21 марта 2014, Санкт-Петербург,

конгресс-холл Holiday Inn «Московские Ворота»

Жизненный цикл проекта

Бизнес кейс

Альтернативы реализации

E-1

E0

E1 Дизайн Код

Тест «Отгрузка»

E2 E3

E4 E5

Поддержка

Традиционные проекты • до 70% проектов оканчиваются неудачей. • до 45% выходят за рамки бюджета. • до 56% поставляют заказчику меньше, чем тому

нужно. • Из-за неясностей в ТЗ 75% руководителей

проектов не уверены, что проект будет завершен успешно.

* Исследование Оксфордского университета 2012

Изменения в ТЗ ● Результат неопределенности на ранних этапах ● Дорожают от этапа к этапу. ● Заказчик не получает, чего хочет. ● Непонятно как управлять изменениями на

поздней фазе ● Как измерять эффект от изменения

Agile-манифест разработки программного обеспечения

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой

непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

ЛЮДИ И ВЗАИМОДЕЙСТВИЕ важнее процессов и инструментов;

РАБОТАЮЩИЙ ПРОДУКТ важнее исчерпывающей документации; СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ важнее согласования условий

контракта; ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ важнее следования первоначальному

плану;

То есть, не отрицая важности того, что справа, мы всё таки больше ценим то, что слева.

http://agilemanifesto.org/iso/ru/

Основополагающие принципы Agile-манифеста

• Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

• Изменение требований приветствуется, даже на поздних стадиях разработки. o Agile-процессы позволяют использовать изменения для

обеспечения заказчику конкурентного преимущества. • Работающий продукт следует выпускать как можно чаще

o С периодичностью от пары недель до пары месяцев.

Основополагающие принципы Agile-манифеста

• На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

• Над проектом должны работать мотивированные профессионалы. o Чтобы работа была сделана, создайте условия, обеспечьте

поддержку и полностью доверьтесь им. • Непосредственное общение является наиболее практичным и

эффективным способом обмена информацией как с самой командой, так и внутри команды.

Основополагающие принципы Agile-манифеста

• Работающий продукт — основной показатель прогресса. • Инвесторы, разработчики и пользователи должны иметь возможность

поддерживать постоянный ритм бесконечно. o Agile помогает наладить такой устойчивый процесс разработки.

• Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Основополагающие принципы Agile-манифеста

• Простота — искусство минимизации лишней работы — крайне необходима.

• Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

• Команда должна регулярно анализировать возможные способы улучшения эффективности и корректировать стиль своей работы.

1% 1% 1% 2% 2% 2% 2%

7% 9%

11%

54%

4%

Agile-методологии

Организация поддержки и производства

Организация и управление проектами и рабочими группами

Организация разработки и тестирования

Канбан

Скрам

ХР FDD

• Microsoft • Yahoo! • Google • Electronic Arts • Lockheed Martin • Philips • Siemens • Nokia • Samsung • BBC • Time Warner • Turner Broadcasting • Twitter

Скрам / Scrum

Цель Скрама: управление сложными проектами,

неопределенностью и изменениями через наглядность,

анализ и адаптацию.

Скрам в 90 словах

• Скрам – agile процесс, который позволяет фокусироваться на поставке наиважнейших, с точки зрения бизнеса, частей продукта в наикратчайшие сроки.

• Продукт разрабатывается серией итераций (спринтов), каждая не больше месяца.

• Все требования на продукт записываются в виде единого списка, “бэклога продукта”.

• В начале каждого спринта бизнесс-руководство приоритизирует элементы бэклога, чтобы сфокусировать разработку продукта.

• Команды самоорганизуются и определяют лучший способ разработки, чтобы выпустить функции с наивысшим приоритетом.

• В конце спринта команда представляет часть продукта, готовую к поставке заказчику. Руководство решает принять его или продолжить улучшения в следующем спринте.

• Инженерные практики не являются частью скрама.

Процесс

“бэклог продукта”

“бэклог спринта”

Другая модель разработки

Техничекое задание

Проектирование, дизайн

Разработка

Тестирование

Поставка, внедрение

Традиционные проекты

Техничекое задание

Проектирование, дизайн

Разработка

Тестирование

Поставка, внедрение

Agile проекты

Другая модель разработки

Техничекое задание

Проектирование, дизайн

Разработка

Тестирование

Поставка, внедрение

Традиционные проекты

Техничекое задание

Проектирование, дизайн

Разработка

Тестирование

Поставка, внедрение

Agile проекты

50%

50%

Роли: • Владелец продукта • Скрам-мастер • Команда

Структура Скрама

Ритуалы: • Планирование спринта • Ежедневный скрам • Обзор спринта • Анализ спринта

Артефакты:

• Бэклог продукта • Диаграммы burndown

Структура Скрама

Ритуалы: • Планирование спринта • Ежедневный скрам • Обзор спринта • Анализ спринта

Артефакты:

• Бэклог продукта • Диаграммы burndown

Роли: • Владелец продукта • Скрам-мастер • Команда

Владелец продукта • Один человек! • Следит, чтобы проект достиг цели. • Определяет требования к ПО. • Приоритизирует требования. • Определяет даты релизов. • Работает с совладельцами проекта. • Принимает или отвергает реализованные требования. • Корректирует приоритеты для каждого спринта. • Совместно с командой вырабатывает Критерии Готовности.

Совладельцы

Скрам-мастер

Владелец продукта

Команда

Скрам-мастер

Совладельцы

Скрам-мастер

Владелец продукта

Команда

• Представляет руководство проекта. • Ответственен за внедрение ценностей и практик скрама. • Не раздает задания! • Устраняет препятствия. • Ответственен за эффективность работы команды. • Обеспечивает видимость и прозрачность ситуации в команде. • Защищает команду от внешних воздействий.

Команда • 5-9 человек. • Кросс-функциональная. • Самоорганизующаяся - нет специальных ролей. • Работает на проекте 100%. • Определяет задачи в рамках спринта. • Производит оценку усилий на реализацию требований. • Разрабатывает продукт. • Заботится о качестве продукта. • Анализирует и адаптирует процесс.

Совладельцы

Скрам-мастер

Владелец продукта

Команда

Совладельцы

Скрам-мастер

Владелец

продукта Команда

Совладельцы Скрам-мастер

Владелец

продукта

Команда Руководство

Пользователи, клиенты,

продавцы, консультанты

и т.д.

Структура Скрама

Артефакты: • Бэклог продукта • Диаграммы burndown

Роли: • Владелец продукта • Скрам-мастер • Команда

Ритуалы: • Планирование спринта • Ежедневный скрам • Обзор спринта • Анализ спринта

Владелец продукта

Планирование спринта

Совладельцы

Скрам-мастер Команда

Приоритеты бизнеса Технологии Состояние

продукта

Определение цели

спринта

Приоритизация бэклога

продукта

Анализ бэклога

продукта

Как достичь цели спринта

(дизайн)?

Выбор требований

для реализации

Разбивка требований на задачи

(бэклог спринта)

Оценка задач в часах

Планирование спринта • Команда выбирает из Бэклога

Продукта требования, которые они могут реализовать за спринт.

• Создается Бэклог Спринта o Задачи идентифицируются и

оцениваются в часах. o Все делается командой, а не

Скрам-мастером. • Учитывается высокоуровневая

архитектура приложения.

Ежедневный скрам • В одно и то же время. • 15 минут. Все участники

стоят. • Говорить могут только

члены команды. • Не для отчета, а для

информирования коллег. • Не для разрешения

проблем.

Доска скрама