Презентация к одноименному докладу, прочитанному на конференции AgileDays'09

1. FDD & DDD
Бибичев Андрей
декабрь 2009 г.

2. I. Преамбула
Самая ценная часть доклада :)

4. ДЮДЮКИ:
Самая известная
TDD
Test-Driven Development
практика
Нынче очень модное
направление проектирования
DDD Сменщик
Test-Driven Design BDD TDD
Behaviour-Driven Development
Одна из самых
навороченных
FDD Agile-методологий
VDD
Как затуманить
заказчику мозги
Feature-Driven Development
Value-Driven Development

5. Зачем?

6. Всё дело в том, что
удобрение
Scrum – это дерьмо
а
плодородная
почва
Scrum-команда – это чернозем

7. Scrum-команда

8. Поэтому:
внедрив Scrum,
мы обычно думаем,
что теперь всё будет
хорошо само собой
цвести и пахнуть

9. Product Owner

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

11. Архитектор
потрудился…

12. И
если ничего не делать, то
команда разваливается
почва истощается

13. Рука HR-а

14. Или
всё скатывается к
Code-&-Fix
копанию в земле по локоть

15. Аналитик
Контроль
качества
Архитектор
Менеджер

16. Итак,
оказывается еще нужны
что выращивать как выращивать
идеи и тех. практики и приемы
семяна и техника

17. Прибыльный проект
Обратите внимание на
слоистую архитектуру

18. RUP
Шо, опять механизация?

19. Lean
Agile
Do Итеративные процессы
Whatever
(0)
Code Kanban Scrum XP RUP
-&- (3) (9) (13) (120+)
Fix
(1)
Pull-загрузка задачами
(с) «Процессная ось» имени Хенрика Книберга

20. • Architecture Reviewer / • Business Designer / • Business-Model Reviewer / • Business-Process Analyst
/ • Capsule Designer / • Change Control Manager / • Code Reviewer / • Configuration Manager / • Course
Developer / • Database Designer / • Deployment Manager / • Design Reviewer / • Designer / • Graphic
Artist / • Implementer / • Integrator / • Process Engineer / • Project Manager / • Project Reviewer / •
Requirements Reviewer / • Requirements Specifier / • Software Architect / • Stakeholder / • System
Administrator / • System Analyst / • Technical Writer / • Test Analyst / • Test Designer / • Test
Manager / • Tester / • Tool Specialist / • User-Interface Designer / • Architectural analysis / • Assess
Viability of architectural proof-of-concept / • Capsule design / • Class design / • Construct architectural
proof-ofconcept / • Database design / • Describe distribution / • Describe the run-time architecture / •
Design test packages and classes / • Develop design guidelines / • Develop programming guidelines / •
Identify design elements / • Identify design mechanisms / • Incorporate design elements / • Prioritize
use cases / • Review the architecture / • Review the design / • Structure the implementation model / •
Subsystem design / • Use-case analysis / • Use-case design / • Analysis model / • Architectural proof-
of-concept / • Bill of materials / • Business architecture document / • Business case / • Business
glossary / • Business modeling guidelines / • Business object model / • Business rules / • Business use
case / • Business use case realization / • Business use-case model / • Business vision / • Change request /
• Configuration audit findings / • Configuration management plan / • Data model / • Deployment model / •
Deployment plan / • Design guidelines / • Design model / • Development case / • Development-
organization assessment / • End-user support material / • Glossary / • Implementation model / •
Installation artifacts / • Integration build plan / • Issues list / • Iteration assessment / • Iteration plan
/ • Manual styleguide / • Programming guidelines / • Quality assurance plan / • Reference architecture /
• Release notes / • Requirements attributes / • Requirements management plan / • Review record / • Risk
list / • Risk management plan / • Software architecture document / • Software development plan / •
Software requirements specification / • Stakeholder requests / • Status assessment / • Supplementary
business specification / • Supplementary specification / • Target organization assessment / • Test
automation architecture / • Test cases / • Test environment configuration / • Test evaluation summary /
• Test guidelines / • Test ideas list / • Test interface specification / • Test plan / • Test suite / • Tool
guidelines / • Training materials / • Use case model / • Use case package / • Use-case modeling
guidelines / • Use-case realization / • Use-case storyboard / • User-interface guidelines / • User-
interface prototype / • Vision / • Work order / • Workload analysis model

22. погибче
Нам бы чего попроще !

24. II. FDD
Feature-Driven Development

25. История
 1997 год: проект для большого сингапурского банка
 длительность: 15 месяцев
 команда: 50 чел
 Jeff De Luca
 под влиянием подхода Peter Coad-а к моделированию бизнес-процессов
Интересные факты из биографии:
• родился в 1964 году
• в 1981 году в возрасте 17-ти лет бросил школу и пошел
работать в IBM
• быстро стал системным инженером, так и не получив
высшего образования (самоучка)
• в 1993 ушел из IBM (с должности системного стратега)
и организовал собственную компанию
• в 1995-1999 гг. выполнил полный реинжениринг
автоматизации крупного сингапурского банка

26. А XP родилось на
маленьком in-house
проекте, который
кончился fail-ом…

27. Ну и что! Scrum вообще
предлагает
противоестественное
масштабирование при
помощи
Scrum-of-Scrum

28. История
 1999 год: книга «Java Modeling in Color With UML»
 один из соавторов книги – Jeff De Luca (вместе с Peter Coad и Eric
Lefebvre)
 в 6-ой главе было дано краткое описание FDD

29. Всего одна глава!
Так – между делом…
По Scrum & XP
пришлось написать
куда больше книг.

30. История
 2002 год: книга «A Practical Guide To Feature-Driven
Development»
 Stephen Palmer, Mac Felsing

31. Автор продолжил
заниматься делом, а
не исключительно
личным PR-ом…

32. Шикарный подкаст на 40 минут

33. Feature
Шаблон именования Feature (функции):
<действие> <результат> <кем|чем|чего|для|к> <объект>
<action> the <result> <by|for|of|to> a(n) <object>
Примеры:
 Вычислить суммарный объем продаж
 Calculate the total amount of a Sale
 Определить последнее изменение наличных в кассе для кассира
 Determine the most recent Cash Register Assignment for a Cashier
Всегда в терминологии предметной области!
Должна быть понятна значимость для бизнеса

34. Очень похоже на
User Story,
но нет необходимости
изобретать персонажи…

35. Конечно! Каждый считает
своим долгом предложить
свой формат для
требований. Ладно хоть
Scrum от этого
удержался...

36. Группировка
 Область (Major Feature Set, Subject Area) АРМ Кассира
 Набор (Feature Set, Activity) Оплата товара
 Функция (Feature) Снять деньги с карточки

37. Дык, это же полный
аналог Themes и Epics
при работе с User Stories

38. Требования к Feature List
 Каждая feature должна быть простой
 Каждая feature должна быть ценна
(хотя бы понятна) заказчику
 Каждая feature должна быть
проверяема
 Каждый feature set может быть
закреплен за ведущим разработчиком
(Chief Developer)
 Feature List должен быть коротким
(на столько, на сколько возможно)

39. Да-да, узнаю старый
добрый INVEST:
Independent, Negotiable,
Valuable, Estimable,
Small, Testable

40. Схема процесса
Разработка Составление Планирование
общей модели списка функций
Список функций План разработки
(Feature list) (A development plan)
1 – 3 недели
Design by Build by feature
Диаграмма классов feature
предметной области
Отгрузка!

41. Вау! Здесь есть
начальная фаза
проекта!!!
Чувствуется, что автор из
IBM…

42. Процесс по шагам 1:
создание общей модели
42
 Участвуют:
 Главный архитектор
 Ведущие разработчики (Chief Developers)
 Эксперты в предметной области
 Подготовка к созданию:
 Выслушивают эксперта в предметной области
 По необходимости изучают документы
 Обсуждения между собой

43. Наконец-то
знакомые роли!
Архитектор, ведущий
разработчик – и снова
здравствуйте 

44. Процесс по шагам 1:
создание общей модели
44
 Создание модели:
 Обязательно разбиваются на небольшие группы
 Каждая группа создает свою модель (диаграмму классов)
 После этого собираются все вместе, обсуждают различия,
выбирают/формируют итоговые решения
 В результате:
 Диаграмма классов (без детализации)
 Комментарии почему выбрано такое решение,
альтернативные решения

45. UML и создание
«конкурирующих»
моделей – мне это
определенно нравится!

46. Тоже мне, открыли
Америку – всё это
известно со времен
Model-Driven
Development/Architecture
(MDD/MDA)

47. Процесс по шагам 2:
формирование Feature List
47
 Участвуют:
 Как и при формировании общей модели
 В результате:
 Feature List,
сгруппированный в наборы (Feature Set),
разделенные по областям (Subject Area)

48. Интересно, а как потом
учитываются изменения
в требованиях и сколько
сил на это уходит?

49. Процесс по шагам 3:
планирование
49
 Основания для планирования:
 Наборы функций – итерации
 Последовательность итераций определяется исходя из:
 взаимосвязи функций с точки зрения реализации
 сложности набора функций
 наличия рисков при реализации функций
 равномерное распределение загрузки разработчиков
 Участвуют:
 Руководитель проекта
 Ведущие разработчики
 В результате:
 График реализации наборов функций (Набор – дата)
 Ведущие программисты, закрепленные за наборами (Набор – ответственный)
 Всем классам назначены владельцы (Класс – владелец)

50. Что-то это уже
конкретно попахивает
водопадом…
Да еще персональное
владение кодом… Бррр

51. Скажи спасибо, что хоть
диаграммы Ганта
строить не надо

52. Для тех, кто успел забыть
схему процесса:
Разработка Составление Планирование
общей модели списка функций
Список функций План разработки
(Feature list) (A development plan)
1 – 3 недели
Design by Build by feature
Диаграмма классов feature
предметной области
Отгрузка!

53. Процесс по шагам 4:
Design by feature
53
 Задачи:
 Формирование команд на итерацию
 ведущие разработчики динамически формируют команды на итерацию
 исходя из того, какие классы затрагивает реализация заданного набора функций
(берутся их владельцы)
 обычно команды не большие (около 5 человек)
(to be continued)

54. Динамическое
формирование команд на
итерацию – класс!
А то:
«слаженная команда –
это очень ценно»…
Так их! 

55. Процесс по шагам 4:
Design by feature
55
 Задачи:
(продолжение)
 Обзор затрагиваемой предметной области
 Изучение необходимых документов
 Составление диаграмм взаимодействия
 Уточнение и детализация соответствующей
части диаграммы классов
 Написание заголовков методов
 В результате:
 Краткое описание набора функций, дополнительные комментарии
 Диаграммы взаимодействия
 Объектная модель (уточнения, исправления), заголовки классов
 Задания (To Do) в системе ведения дел для каждого участника команды

56. Вот! Спецификация API и
персональное назначение
задач – сразу чувствуется
старая школа! И никаких,
понимаешь, соплей про
самоорганизацию и кросс-
функциональность…

57. Процесс по шагам 5:
Build by feature
57
 Задачи:
 Реализация классов и методов
 Code Inspection (Code Review)
 до unit-тестирования!
 самой командой или даже другой (по решению ведущего программиста)
 Unit-тестирование
 тесты на класс пишет сам владелец класса
 Интеграция (Promote to Build)
 Уточнение и детализация соответствующей части диаграммы классов
 В результате:
 Проинспектированные классы и методы
 Классы, допущенные в основной ствол проекта
 Реализованная функциональность, понятная заказчику (client-valued features)

58. Супер: вместо парного
программирования – Code
Inspection/Review; а вместо
мантры «Red-Green-Refactor»
– просто написание Unit-
тестов (причем после
реализации).

59. Ну и правильно! Всё равно
опросы общественного
мнения показывают, что в
парах мало кто кодит, да и
тесты до реализации писать
дико – некомпилится ведь!

60. Важный нюанс
• в FDD нет жесткого time-boxing-а итерации:
– итерация не заканчивается, пока все взятые в
неё feature-и не доделают
– т.е. недоделанные feature-и не перетекают в
следующую итерацию – их дожимают в
текущей, растягивая оную

61. Разумно, но что они при
этом делают со своим
план-графиком?...

62. Отслеживание хода процесса
62 Стандартная пропорция:
Обзор Детализация Инспекция Кодирование Инспекция Интеграция
модели модели дизайна кода
(дизайн)
1% 40% 3% 45% 10% 1%
 За счет этого ведется графическое отображение хода выполнения:

63. Отслеживание хода процесса:
для всего проекта
63
Области
Наборы
функций

64. Эта штука посильнее
будет всяких
Burn-down-ов и –up-ов:
и бизнесам показать не
стыдно, и на конфе
козырнуть.

65. Уровень процессов
Управление
проектами SCRUM Индикация
прогресса
Управление
проектом Самоорг. команда, Перечень
Daily Meetings требований,
Итерации
Unit-тесты, FDD
Стандарт
кодирования,
Кодирование XP Cont. Integration
Жесткость
процессов
Анархия Водопад
--------- Как некий итог ---------

66. III. DDD
Domain-Driven Design

67. История
2004 год
Eric Evans
«Domain-Driven Design - Tackling Complexity in the Heart of Software»

71. Domain (словарь)
• наследственная собственность; имение,
поместье; земли; владение e.g. DNS
• территория, зона, область, район
(отмеченные некоторыми физическими
особенностями)
• сфера (интересов), поле (деятельности),
область (знаний) В данном случае
этот смысл
• область определения (мат.)
Домен поля
таблицы в БД

72. Т.е. это о
Business Domain
Предметной области
и
Business Logic
Бизнес-логики

73. «Attention was diverted away
from rich logic and deep solutions,
because there was so much value
in just getting data onto the web,
along with very simple behavior.
But now that basic level of web
usage has largely been
assimilated, and projects are
starting to get more ambitious
again about business logic.»

74. Еще раз вспомним про FDD:
Разработка Составление Планирование
общей модели списка функций
Список функций План разработки
(Feature list) (A development plan)
1 – 3 недели
Design by Build by feature
Диаграмма классов feature
предметной области
Отгрузка!

75. Центральная роль в
мышлении,
проектировании,
реализации
DDD

76. Пример: есть сайт конференции,
надо сделать голосование за доклад

77. О чем вы прежде всего
начнете думать?


78. О чем вы прежде всего
начнете думать?
votes


79. О чем вы прежде всего
начнете думать?


80. О чем вы прежде всего
начнете думать?


81. /

82. Три аспекта DDD

86. Внимание! Очень важно!
Компоненты нижележащего слоя
не должны зависеть от
компонентов вышележащего
ни при каких обстоятельствах

87. !!!

89. Постоянно себя спрашивайте:
можно ли, используя public API доменной
модели, нарушить целостность,
согласованность и консистентность данных?

91. Хоцца «аналогов» SQL и xxxMyAdmin
но для компонентов DomainModel, а не СУБД

92. Этому посвящен
значительный объем
всех книг, поэтому
здесь мы пропустим

93. Используете ORM => У вас DDD
!!!
http://www.martinfowler.com/bliki/AnemicDomainModel.html
Hibernate Ruby on Rails

94. По идее, всё нацелено на достаточно сложные модели:
Но на практике эффективно используется
и для несложных предметных областей

95. http://www.infoq.com/
presentations/rebuild-guardian-ddd-wills

96. http://www.infoq.com/
presentations/rebuild-guardian-ddd-wills

97. http://www.infoq.com/
presentations/rebuild-guardian-ddd-wills

99. IV. Заключение
В стиле «Демотиваторы»

100. «На кой мне это всё?»
Есть Vision
и feedback
и в проекте
ориентируюсь
яки рыба в
воде
артефакты

101. На одном Scrum-е далеко не уедешь

102. Внедрение
Scrum
Не подумав вовремя
об этом, вы
действуете как
кальсонные гномы

103. Спасибо за
внимание!
biBIGone@gmail.com
http://www.google.com/profiles/biBIGone