Михаил Заборов Руководитель направления «Торговые сети»

AgileDays, Екатеринбург, 2010

Agile в БОЛЬШИХ и ОЧЕНЬ БОЛЬШИХ проектах

проектирование в Agile

Очень большиепроекты

Большие проекты

Текущая работа

Ag

end

a

2/92

Говорим про

корпоративные системы:

3/92

Корпоративные (Enterprise)Системы

ERP / биллинг /банковские / торговые / складские системы

…

Прикладное программное обеспечение предприятий и организаций

Buzzword

4/92

В чем можно мерить размер?

? Объем данных

? Количество транзакций

? Объем изменений

? Длительность проекта

? Количество отчетов?

5/92

Размеры систем

1ТБ

3млн

10млн

270млн

6/92

БОЛЬШИЕ проекты

t

0 4 мес.

1 год

Маленькие Средние Наш размерчик!

= от 10 – 15 чел. лет

Команда 5-10 человек

7/92

Жизнь успешных и востребованных проектовпосле внедрения только

начинается

Высокая динамика требований

8/92

0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60 70

Время (мес.)

Ко

л-в

о м

етад

анн

ых

Изменение Создание

Начало работы

9/92

0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60 70

Время (мес.)

Ко

л-в

о м

етад

анн

ых

Изменение Создание

Начало работы

10/92

Очень большиепроекты

Большие проекты

Текущая работа

Ag

end

a

11/92

ОЧЕНЬ БОЛЬШИЕпроекты t

0 1 год 10 лет

= от 40 – 100 чел. лет

Команда 30-50 человек

12/92

Как сюда впихнуть Agile?

13/92

А зачем нам вообще Agile?

Спросите этих парней

:-)

14/92

Люди и их взаимодействие, чем процессы и средства

Работающее ПО, чем исчерпывающая документация

Сотрудничество с заказчиком, чем обсуждение условий контракта

Реагирование на изменения, чем следование плану

Нам важнее

15/92

Невысокая цена поздних внесенийизменений в начальные требования

Максимальная вовлеченность самих разработчиков в процесс проектирования и дизайна системы.

Отсутствие лишних артефактов, в частности, write-only документации

Работающее и реально использующееся ПО

Удовлетворенность заказчика ранними и периодическими поставками ценного ПО

http://agilemanifesto.org/principles.html

Непосредственное общение разработчиков с пользователями

16/92

Командой в 40 чел управлять очень сложноПотери на коммуникации

Бутылочное горло

Проблемы синхронизации

Оптимальный размер команды 5-7 человек

Про это нам и Agile говорит :-)

17/92

Вывод – нужно делить команды!

18/92

По каким принципам делить?

19/92

Component Team

20/92

Feature Team

21/92

С чисто организационной точки зрения по большому счету — без разницы

22/92

Но кроме организационныхвозникает очень много

других проблем ...

:-(

«Проверено на себе»

23/92

Сложность системы

Не лезет в одну голову«оно так работает…»,почему — никтоне знает. Проблемы обучения (персонал, пользователь).

Непредсказуемые последствия измененийОграничение развития. Поправили в одном месте — отвалилось в совсем другом.

Стихийные внутренние связи«Ничьи» и «общие» данные, коды и проч… невозможно отследить и контролировать.

24/92

Производительность

Объемы данныхПодъем тестового стенда с реальными данными - 3 суток.

Масштабируемость«В следующем году мы планируем увеличить бизнес вдвое»

Асинхронность взаимодействияКритичные приложения ждут не критичные. Лишние блокировки

ЖелезоУвеличение аппаратных мощностей не спасает.«в один прекрасный день оно не уложится в отведенное время»

25/92

Делить нужно не только команды, но и систему!

26/92

Карта приложения

Крупные модули и API между ними

27/92

Структура системы неизбежно повторяет структуру команд

Tom Demarko

Модули продукта инкапсулируются внутри команды

Закон Конвея

28/92

Component Team vs Feature Team

И тут мы солидарны :-)

29/92

А как теперь эти команды синхронизировать?

30/92

Agile предлагаетScrum of Scrum

31/92

Мы пошли другим путем

32/92

Команды максимально независимы и с минимальной синхронизацией

33/92

Критерии деления команд и системы

34/92

Процессы разработки модулей - проектирования, технической поддержки, документирования, выпуска версий, тестирования -

не должны зависеть друг от друга - за исключением изменения API

35/92

Физические границы должны быть просты и понятныпо данным, исполняемым модулям,исходным кодам и т.д.

Нет общих данных владелец данных всегда известен

Нет общих экземпляров исполняемых модулей в том числе библиотек

36/92

Должна быть возможность:

Разместить модули на разные аппаратные мощности

Иметь различные стратегии резервного копирования

Иметь off-line связь между модулями

Выполнить модули в разных технологиях.

37/92

Модуль:

Может быть продан отдельно

Имеет самостоятельную ценность а не только в месте с другими продуктами

Может устанавливаться с продуктами других производителей

38/92

Как делить?

39/92

Гради Буч

«Внутрикомпонентная связь обычно сильнее, чем связь между компонентами»

40/92

Например, по организационной

структуре автоматизируемого объекта

Совет директоров

Розница Опт Закупки Логистика Финансы

41/92

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

проще договариваться

Замкнутая предметная областьПроще обучать сотрудников, осуществлять тестирование и поддержку

Проще внедрятьЛокализованное внедрение

Проще общаться с «верхним» руководством заказчикапонятно, с какой областью идет работа. Общее руководство у всех пользователей

42/92

Этого достаточно?

Agile

Agile

Agile

Agile

43/92

К сожалению, нет :-(

44/92

Деление накрупные модули

Большие проекты

Текущая работаAg

end

a

45/92

Дело в том, каждый модуль –

это все еще БОЛЬШОЙ проект

t

0 4 мес.

1 год

Маленькие Средние Наш размерчик!

= от 10 – 15 чел. лет

Команда 5-10 человек

46/92

Как получить то, что действительно нужно

пользователю ?

47/92

Agile предлагаетинкрементальный

дизайн:

48/92

49/92

В реальности задачи в

разных итерациях сильно

связаны между собой

Приходится переделывать ранее

сделанное

50/92

Алистер Коберн

вводит различие между

итеративной и

инкрементальной

разработкой

http://alistair.cockburn.us/Incremental+versus+iterative+developmenthttp://alistair.cockburn.us/Incremental+means+adding%2c+iterative+means+reworking

51/92

52/92

53/92

Основное отличие

Инкрементальная разработка – добавление нового (add onto)

Итеративная — переделывание (rework) ранее сделанного

54/92

Для действительно БОЛЬШИХ[*] СИСТЕМ

большой разницы нет:-(

[*] Время итерации 2-3 недели, время проекта 7-8 лет

55/92

Как из этого:

Путем постоянного

переделывания

Получить вот это: ?

56/92

http://lobasev.ru/2008/01/blog-post.html

Для этого и этого этапа

Опять инкремент

А иногда и для этого57/92

При разработке короткими итерациями мы работаем с небольшим

куском системы

58/92

59/92

Где гарантия, что мы получим то,

что нужно?

60/92

61/92

62/92

В народном творчестве

это находит

свое отражение:

63/92

http://thekonst.net/ru/propaganda/291

64/92

Нужна общая картина

65/92

66/92

При проектировании ИС такая картина —

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

aka Domain MоdelНа самом деле конечно модель

системы

67/92

Признаки качественной модели

Простая

Лаконичнаяобозримая

Понятная заказчикуключевому пользователю

Понятная разработчикувсем членам команды

68/92

Признаки качественной моделиЧто на картинке, то и в системе…

Достаточно формальная

Эскиз, а не детальная спецификация

69/92

Признаки качественной модели

Отражает действительность(близка к предметной области)

Зависит от контекста

70/92

Модель предметной области –

составляет существенную часть Vision

Назначение и границы модуля

Основные пользователиОсновные функции

71/92

Можно оценить реализуемость проекта

Можно оценить объем работ

Bonus

72/92

На этом проектирование

закончено?

73/92

Практически…

74/92

Деление накрупные модули

Модель предметной

области

Текущая работа

Ag

end

a

75/92

Мы часто пишем детальные постановки на кусок

системы

76/92

Пишем непосредственно перед стартом разработки

Выясняем детальные требования

Пишем и согласуем постановку

Разрабатываем, тестируем, отгружаем

ПротоколПостановка

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

77/92

Согласуем с заказчиком

Заказчику понятно, что для него будетсделано

78/92

Постановка не содержит технических деталей

не спецификация

В терминах пользователей

79/92

Не успевает «протухать»

через год

Ситуация не успела поменятьсяЗаказчик и разработчики все еще в

контексте80/92

Проектирование методом «Набегающей волны»

По аналогии с планированием методом набегающей волны (Rolling Wave Planning)

Питер Хрущка

Snorkeling&

Scuba Diving

81/92

И это Agile?

82/92

Невысокая цена поздних внесенийизменений в начальные требования

Максимальная вовлеченность самих разработчиков в процесс проектирования и дизайна системы.

Отсутствие лишних артефактов, в частности, write-only документации

Работающее и реально использующееся ПО

Удовлетворенность заказчика ранними и периодическими поставками ценного ПО

Непосредственное общение разработчиков с пользователями

Да, конечно! 83/92

Легче вводить новых людей в проект

Есть история принятых решений

Возможность выявить недопонимание,

до начала разработки

Заказчик вовлекается в принятие решений

Bonus

84/92

А как иначе?

85/92

Скотт Адамс (Scott Adams)Источник: http://dilbertru.blogspot.com/2007/11/20071166.html

Мы собираемся попробовать кое-что

под названием «Agile

программирование».

Это значит, больше никакого

планирования, никакой

документации. Просто начинайте

писать код и жаловаться.

Так вот как это

называется.

Твоя школа.

86/92

Деление накрупные модули

Модель предметной

области

Детальнаяпостановка

87/92

Про это мы уже рассказывали

88/92

http://www.custis.ru/docs/publishing/secr-2008/2008-10-22-analyst-in-agile-show.pdf

89/92

Базовая методология-Планы счетов

90/92

91/92

Спасибо!

team.custis.ru

92/92