FDD & DDD

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

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

ДЮДЮКИ:

TDD

DDDBDD

FDDVDD

Test-Driven Development

Test-Driven Design

Behaviour-Driven Development

Feature-Driven Development

Value-Driven Development

Самая известнаяпрактика

Нынче очень модное направление проектирования

Сменщик TDD

Одна из самых навороченных

Agile-методологий Как затуманить заказчику мозги

Зачем?

Scrum – это

Всё дело в том, что

дерьмоудобрение

а

Scrum-команда – это чернозем

плодороднаяпочва

Scrum-команда

Поэтому:

внедрив Scrum,мы обычно думаем,что теперь всё будет

цвести и пахнутьхорошо само собой

Product Owner

Но

в действительности

растет бурьянпроблемы только начинаются

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

И

если ничего не делать, то

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

Рука HR-а

Или

всё скатывается к

копанию в земле по локоть

Code-&-Fix

Менеджер

Аналитик

Архитектор

Контроль качества

Итак,

оказывается еще нужны

семяна и техника

идеи и тех. практики и приемы

что выращивать как выращивать

Прибыльный проект

Обратите внимание на слоистую архитектуру

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

DoWhatever(0)

RUP(120+)

Итеративные процессы

Code-&-Fix(1)

XP(13)

Scrum(9)

Agile

Kanban(3)

Lean

Pull-загрузка задачами

(с) «Процессная ось» имени Хенрика Книберга

• 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

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

II. FDDFeature-Driven Development

История

1997 год: проект для большого сингапурского банка длительность: 15 месяцев

команда: 50 чел

Jeff De Luca

под влиянием подхода Peter Coad-а к моделированию бизнес-процессов

Интересные факты из биографии:• родился в 1964 году• в 1981 году в возрасте 17-ти лет бросил школу и пошел работать в IBM• быстро стал системным инженером, так и не получив высшего образования (самоучка)• в 1993 ушел из IBM (с должности системного стратега) и организовал собственную компанию• в 1995-1999 гг. выполнил полный реинженирингавтоматизации крупного сингапурского банка

А XP родилось на маленьком in-house

проекте, который кончился fail-ом…

Ну и что! Scrum вообщепредлагает

противоестественноемасштабирование при

помощиScrum-of-Scrum

История

1999 год: книга «Java Modeling in Color With UML» один из соавторов книги – Jeff De Luca (вместе с Peter Coad и Eric

Lefebvre)

в 6-ой главе было дано краткое описание FDD

Всего одна глава!Так – между делом…

По Scrum & XP пришлось написать куда больше книг.

История

2002 год: книга «A Practical Guide To Feature-Driven Development» Stephen Palmer, Mac Felsing

Автор продолжил заниматься делом, а

не исключительноличным PR-ом…

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

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

Шаблон именования Feature (функции):

Всегда в терминологии предметной области!Должна быть понятна значимость для бизнеса

Очень похоже наUser Story,

но нет необходимости изобретать персонажи…

Конечно! Каждый считает своим долгом предложить

свой формат для требований. Ладно хоть

Scrum от этого удержался...

Группировка

Область (Major Feature Set, Subject Area) АРМ Кассира

Набор (Feature Set, Activity) Оплата товара

Функция (Feature) Снять деньги с карточки

Дык, это же полный аналог Themes и Epics

при работе с User Stories

Требования к Feature List

Каждая feature должна быть простой

Каждая feature должна быть ценна(хотя бы понятна) заказчику

Каждая feature должна быть проверяема

Каждый feature set может быть закреплен за ведущим разработчиком(Chief Developer)

Feature List должен быть коротким(на столько, на сколько возможно)

Да-да, узнаю старый добрый INVEST:

Independent, Negotiable, Valuable, Estimable,

Small, Testable

Схема процесса

Разработка общей модели

Составление списка функций

Планирование

Build by featureDesign by feature

Список функций(Feature list)

План разработки(A development plan)

Диаграмма классовпредметной области

Отгрузка!

1 – 3 недели

Вау! Здесь есть начальная фаза

проекта!!!Чувствуется, что автор из

IBM…

Процесс по шагам 1:

создание общей модели42

Участвуют:

Главный архитектор

Ведущие разработчики (Chief Developers)

Эксперты в предметной области

Подготовка к созданию:

Выслушивают эксперта в предметной области

По необходимости изучают документы

Обсуждения между собой

Наконец-тознакомые роли!

Архитектор, ведущий разработчик – и снова

здравствуйте

Процесс по шагам 1:

создание общей модели44

Создание модели:

Обязательно разбиваются на небольшие группы

Каждая группа создает свою модель (диаграмму классов)

После этого собираются все вместе, обсуждают различия, выбирают/формируют итоговые решения

В результате:

Диаграмма классов (без детализации)

Комментарии почему выбрано такое решение,альтернативные решения

UML и создание «конкурирующих» моделей – мне это

определенно нравится!

Тоже мне, открыли Америку – всё это

известно со времен Model-Driven

Development/Architecture(MDD/MDA)

Процесс по шагам 2:

формирование Feature List47

Участвуют:

Как и при формировании общей модели

В результате:

Feature List,сгруппированный в наборы (Feature Set),разделенные по областям (Subject Area)

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

сил на это уходит?

Процесс по шагам 3:

планирование49

Основания для планирования: Наборы функций – итерации

Последовательность итераций определяется исходя из:

взаимосвязи функций с точки зрения реализации

сложности набора функций

наличия рисков при реализации функций

равномерное распределение загрузки разработчиков

Участвуют: Руководитель проекта

Ведущие разработчики

В результате:

График реализации наборов функций (Набор – дата)

Ведущие программисты, закрепленные за наборами (Набор – ответственный)

Всем классам назначены владельцы (Класс – владелец)

Что-то это уже конкретно попахивает

водопадом…Да еще персональное

владение кодом… Бррр

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

Для тех, кто успел забытьсхему процесса:

Разработка общей модели

Составление списка функций

Планирование

Build by featureDesign by feature

Список функций(Feature list)

План разработки(A development plan)

Диаграмма классовпредметной области

Отгрузка!

1 – 3 недели

Процесс по шагам 4:

Design by feature53

Задачи:

Формирование команд на итерацию

ведущие разработчики динамически формируют команды на итерацию

исходя из того, какие классы затрагивает реализация заданного набора функций (берутся их владельцы)

обычно команды не большие (около 5 человек)

(to be continued)

Динамическое формирование команд на

итерацию – класс!А то:

«слаженная команда –это очень ценно»…

Так их!

Процесс по шагам 4:

Design by feature55

Задачи:(продолжение)

Обзор затрагиваемой предметной области

Изучение необходимых документов

Составление диаграмм взаимодействия

Уточнение и детализация соответствующейчасти диаграммы классов

Написание заголовков методов

В результате:

Краткое описание набора функций, дополнительные комментарии

Диаграммы взаимодействия

Объектная модель (уточнения, исправления), заголовки классов

Задания (To Do) в системе ведения дел для каждого участника команды

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

самоорганизацию и кросс-функциональность…

Процесс по шагам 5:

Build by feature57

Задачи: Реализация классов и методов

Code Inspection (Code Review)

до unit-тестирования!

самой командой или даже другой (по решению ведущего программиста)

Unit-тестирование

тесты на класс пишет сам владелец класса

Интеграция (Promote to Build)

Уточнение и детализация соответствующей части диаграммы классов

В результате: Проинспектированные классы и методы

Классы, допущенные в основной ствол проекта

Реализованная функциональность, понятная заказчику (client-valued features)

Супер: вместо парного программирования – Code Inspection/Review; а вместо

мантры «Red-Green-Refactor»– просто написание Unit-

тестов (причем после реализации).

Ну и правильно! Всё равно опросы общественного

мнения показывают, что в парах мало кто кодит, да и

тесты до реализации писать дико – некомпилится ведь!

Важный нюанс

• в FDD нет жесткого time-boxing-а итерации:

– итерация не заканчивается, пока все взятые в неё feature-и не доделают

– т.е. недоделанные feature-и не перетекают в следующую итерацию – их дожимают в текущей, растягивая оную

Разумно, но что они при этом делают со своим

план-графиком?...

Отслеживание хода процесса

62 Стандартная пропорция:

За счет этого ведется графическое отображение хода выполнения:

Обзор

модели

Детализация

модели

(дизайн)

Инспекция

дизайна

Кодирование Инспекция

кода

Интеграция

1% 40% 3% 45% 10% 1%

Отслеживание хода процесса:

для всего проекта63

Области

Наборы функций

Эта штука посильнее будет всяких

Burn-down-ов и –up-ов:и бизнесам показать не

стыдно, и на конфекозырнуть.

--------- Как некий итог ---------

XP

SCRUM

FDD

Уровень процессов

Жесткостьпроцессов

Управлениепроектом

Кодирование

Анархия Водопад

Управлениепроектами

Переченьтребований,Итерации

Unit-тесты,Стандарткодирования,Cont. Integration

Самоорг. команда,Daily Meetings

Индикацияпрогресса

III. DDDDomain-Driven Design

История

2004 годEric Evans

«Domain-Driven Design - Tackling Complexity in the Heart of Software»

Domain (словарь)

• наследственная собственность; имение, поместье; земли; владение

• территория, зона, область, район (отмеченные некоторыми физическими особенностями)

• сфера (интересов), поле (деятельности), область (знаний)

• область определения (мат.)

e.g. DNS

Домен поля таблицы в БД

В данном случае этот смысл

Business Domain

Т.е. это о

и

Business Logic

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

Бизнес-логики

«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 beenassimilated, and projects are starting to get more ambitious again about business logic.»

Еще раз вспомним про FDD:

Разработка общей модели

Составление списка функций

Планирование

Build by featureDesign by feature

Список функций(Feature list)

План разработки(A development plan)

Диаграмма классовпредметной области

Отгрузка!

1 – 3 недели

DDD

Центральная роль в мышлении,

проектировании, реализации

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

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

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

votes

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

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

/

Три аспекта DDD

Внимание! Очень важно!

Компоненты нижележащего слояне должны зависеть от

компонентов вышележащегони при каких обстоятельствах

!!!

Постоянно себя спрашивайте:можно ли, используя public API доменной

модели, нарушить целостность, согласованность и консистентность данных?

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

Этому посвящен значительный объем

всех книг, поэтому здесь мы пропустим

Используете ORM => У вас DDD

!!!

Hibernate Ruby on Rails

http://www.martinfowler.com/bliki/AnemicDomainModel.html

По идее, всё нацелено на достаточно сложные модели:

Но на практике эффективно используетсяи для несложных предметных областей

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

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

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

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

«На кой мне это всё?»

Есть Vision

и feedback

и в проектеориентируюсь

яки рыба в воде

артефакты

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

ВнедрениеScrum

Не подумав вовремя об этом, вы

действуете как кальсонные гномы

Спасибо за внимание!

biBIGone@gmail.comhttp://www.google.com/profiles/biBIGone