Top Banner
Михаил Заборов Руководитель направления «Торговые сети» AgileDays, Екатеринбург, 2010 Agile в БОЛЬШИХ и ОЧЕНЬ БОЛЬШИХ проектах проектирование в Agile
92

Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Jan 24, 2015

Download

Technology

CUSTIS

 
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

Page 2: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

Ag

end

a

2/92

Page 3: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Говорим про

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

3/92

Page 4: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

Buzzword

4/92

Page 5: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

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

5/92

Page 6: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

1ТБ

3млн

10млн

270млн

6/92

Page 7: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

t

0 4 мес.

1 год

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

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

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

7/92

Page 8: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

начинается

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

8/92

Page 9: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60 70

Время (мес.)

Ко

л-в

о м

етад

анн

ых

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

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

9/92

Page 10: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60 70

Время (мес.)

Ко

л-в

о м

етад

анн

ых

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

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

10/92

Page 11: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

Ag

end

a

11/92

Page 12: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

0 1 год 10 лет

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

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

12/92

Page 13: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

13/92

Page 14: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

:-)

14/92

Page 15: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

Нам важнее

15/92

Page 16: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

http://agilemanifesto.org/principles.html

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

16/92

Page 17: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

17/92

Page 18: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

18/92

Page 19: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

19/92

Page 20: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Component Team

20/92

Page 21: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Feature Team

21/92

Page 22: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

22/92

Page 23: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

:-(

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

23/92

Page 24: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

24/92

Page 25: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

25/92

Page 26: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

26/92

Page 27: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

27/92

Page 28: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

Tom Demarko

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

Закон Конвея

28/92

Page 29: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Component Team vs Feature Team

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

29/92

Page 30: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

30/92

Page 31: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

31/92

Page 32: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

32/92

Page 33: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

33/92

Page 34: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

34/92

Page 35: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

35/92

Page 36: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

36/92

Page 37: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

37/92

Page 38: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Модуль:

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

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

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

38/92

Page 39: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Как делить?

39/92

Page 40: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Гради Буч

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

40/92

Page 41: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

41/92

Page 42: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

42/92

Page 43: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

Agile

Agile

Agile

Agile

43/92

Page 44: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

44/92

Page 45: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

end

a

45/92

Page 46: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

t

0 4 мес.

1 год

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

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

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

46/92

Page 47: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

47/92

Page 48: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

дизайн:

48/92

Page 49: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

49/92

Page 50: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

сделанное

50/92

Page 51: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

разработкой

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

51/92

Page 52: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

52/92

Page 53: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

53/92

Page 54: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

54/92

Page 55: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

55/92

Page 56: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Как из этого:

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

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

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

56/92

Page 57: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

Page 58: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

58/92

Page 59: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

59/92

Page 60: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

что нужно?

60/92

Page 61: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

61/92

Page 62: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

62/92

Page 63: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

это находит

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

63/92

Page 64: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

64/92

Page 65: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

65/92

Page 66: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

66/92

Page 67: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

системы

67/92

Page 68: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

Простая

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

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

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

68/92

Page 69: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

69/92

Page 70: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

70/92

Page 71: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

71/92

Page 72: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

Bonus

72/92

Page 73: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

закончено?

73/92

Page 74: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

74/92

Page 75: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

области

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

Ag

end

a

75/92

Page 76: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

системы

76/92

Page 77: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

77/92

Page 78: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

78/92

Page 79: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

79/92

Page 80: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

через год

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

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

Page 81: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

Питер Хрущка

Snorkeling&

Scuba Diving

81/92

Page 82: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

И это Agile?

82/92

Page 83: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

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

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

Page 84: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

Bonus

84/92

Page 85: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

А как иначе?

85/92

Page 86: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

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

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

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

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

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

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

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

называется.

Твоя школа.

86/92

Page 87: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

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

области

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

87/92

Page 88: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

88/92

Page 89: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

89/92

Page 90: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

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

90/92

Page 91: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

91/92

Page 92: Agile в очень больших проектах (Михаил Заборов, Agile Days 2010)

Спасибо!

team.custis.ru

92/92