Обзор Feature-Driven Development и Domain-Driven Design
Upcoming SlideShare
Loading in...5
×
 

Обзор Feature-Driven Development и Domain-Driven Design

on

  • 4,848 views

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

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

Statistics

Views

Total Views
4,848
Views on SlideShare
3,477
Embed Views
1,371

Actions

Likes
11
Downloads
133
Comments
0

9 Embeds 1,371

http://lib.custis.ru 962
http://www.happy-pm.com 236
http://2009.agiledays.ru 67
http://agiledays.ru 47
http://www.agiledays.ru 19
http://lj-toys.com 16
http://wiki.office.custis.ru 12
http://www.slideshare.net 11
http://www.netvibes.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Обзор Feature-Driven Development и Domain-Driven Design Обзор Feature-Driven Development и Domain-Driven Design Presentation Transcript

  • FDD & DDD Бибичев Андрей декабрь 2009 г.
  • I. Преамбула Самая ценная часть доклада :)
  • ДЮДЮКИ: Самая известная TDD Test-Driven Development практика Нынче очень модное направление проектирования DDD Сменщик Test-Driven Design BDD TDD Behaviour-Driven Development Одна из самых навороченных FDD Agile-методологий VDD Как затуманить заказчику мозги Feature-Driven Development Value-Driven Development
  • Зачем?
  • Всё дело в том, что удобрение Scrum – это дерьмо а плодородная почва Scrum-команда – это чернозем
  • Scrum-команда
  • Поэтому: внедрив Scrum, мы обычно думаем, что теперь всё будет хорошо само собой цвести и пахнуть
  • Product Owner
  • Но в действительности проблемы только начинаются растет бурьян
  • Архитектор потрудился…
  • И если ничего не делать, то команда разваливается почва истощается
  • Рука HR-а
  • Или всё скатывается к Code-&-Fix копанию в земле по локоть
  • Аналитик Контроль качества Архитектор Менеджер
  • Итак, оказывается еще нужны что выращивать как выращивать идеи и тех. практики и приемы семяна и техника
  • Прибыльный проект Обратите внимание на слоистую архитектуру
  • RUP Шо, опять механизация?
  • Lean Agile Do Итеративные процессы Whatever (0) Code Kanban Scrum XP RUP -&- (3) (9) (13) (120+) Fix (1) 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. FDD Feature-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 Шаблон именования 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 Всегда в терминологии предметной области! Должна быть понятна значимость для бизнеса
  • Очень похоже на 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
  • Схема процесса Разработка Составление Планирование общей модели списка функций Список функций План разработки (Feature list) (A development plan) 1 – 3 недели Design by Build by feature Диаграмма классов feature предметной области Отгрузка!
  • Вау! Здесь есть начальная фаза проекта!!! Чувствуется, что автор из IBM…
  • Процесс по шагам 1: создание общей модели 42  Участвуют:  Главный архитектор  Ведущие разработчики (Chief Developers)  Эксперты в предметной области  Подготовка к созданию:  Выслушивают эксперта в предметной области  По необходимости изучают документы  Обсуждения между собой
  • Наконец-то знакомые роли! Архитектор, ведущий разработчик – и снова здравствуйте 
  • Процесс по шагам 1: создание общей модели 44  Создание модели:  Обязательно разбиваются на небольшие группы  Каждая группа создает свою модель (диаграмму классов)  После этого собираются все вместе, обсуждают различия, выбирают/формируют итоговые решения  В результате:  Диаграмма классов (без детализации)  Комментарии почему выбрано такое решение, альтернативные решения
  • UML и создание «конкурирующих» моделей – мне это определенно нравится!
  • Тоже мне, открыли Америку – всё это известно со времен Model-Driven Development/Architecture (MDD/MDA)
  • Процесс по шагам 2: формирование Feature List 47  Участвуют:  Как и при формировании общей модели  В результате:  Feature List, сгруппированный в наборы (Feature Set), разделенные по областям (Subject Area)
  • Интересно, а как потом учитываются изменения в требованиях и сколько сил на это уходит?
  • Процесс по шагам 3: планирование 49  Основания для планирования:  Наборы функций – итерации  Последовательность итераций определяется исходя из:  взаимосвязи функций с точки зрения реализации  сложности набора функций  наличия рисков при реализации функций  равномерное распределение загрузки разработчиков  Участвуют:  Руководитель проекта  Ведущие разработчики  В результате:  График реализации наборов функций (Набор – дата)  Ведущие программисты, закрепленные за наборами (Набор – ответственный)  Всем классам назначены владельцы (Класс – владелец)
  • Что-то это уже конкретно попахивает водопадом… Да еще персональное владение кодом… Бррр
  • Скажи спасибо, что хоть диаграммы Ганта строить не надо
  • Для тех, кто успел забыть схему процесса: Разработка Составление Планирование общей модели списка функций Список функций План разработки (Feature list) (A development plan) 1 – 3 недели Design by Build by feature Диаграмма классов feature предметной области Отгрузка!
  • Процесс по шагам 4: Design by feature 53  Задачи:  Формирование команд на итерацию  ведущие разработчики динамически формируют команды на итерацию  исходя из того, какие классы затрагивает реализация заданного набора функций (берутся их владельцы)  обычно команды не большие (около 5 человек) (to be continued)
  • Динамическое формирование команд на итерацию – класс! А то: «слаженная команда – это очень ценно»… Так их! 
  • Процесс по шагам 4: Design by feature 55  Задачи: (продолжение)  Обзор затрагиваемой предметной области  Изучение необходимых документов  Составление диаграмм взаимодействия  Уточнение и детализация соответствующей части диаграммы классов  Написание заголовков методов  В результате:  Краткое описание набора функций, дополнительные комментарии  Диаграммы взаимодействия  Объектная модель (уточнения, исправления), заголовки классов  Задания (To Do) в системе ведения дел для каждого участника команды
  • Вот! Спецификация API и персональное назначение задач – сразу чувствуется старая школа! И никаких, понимаешь, соплей про самоорганизацию и кросс- функциональность…
  • Процесс по шагам 5: Build by feature 57  Задачи:  Реализация классов и методов  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-ов: и бизнесам показать не стыдно, и на конфе козырнуть.
  • Уровень процессов Управление проектами SCRUM Индикация прогресса Управление проектом Самоорг. команда, Перечень Daily Meetings требований, Итерации Unit-тесты, FDD Стандарт кодирования, Кодирование XP Cont. Integration Жесткость процессов Анархия Водопад --------- Как некий итог ---------
  • III. DDD Domain-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 been assimilated, and projects are starting to get more ambitious again about business logic.»
  • Еще раз вспомним про FDD: Разработка Составление Планирование общей модели списка функций Список функций План разработки (Feature list) (A development plan) 1 – 3 недели Design by Build by feature Диаграмма классов feature предметной области Отгрузка!
  • Центральная роль в мышлении, проектировании, реализации DDD
  • Пример: есть сайт конференции, надо сделать голосование за доклад
  • О чем вы прежде всего начнете думать? 
  • О чем вы прежде всего начнете думать? votes 
  • О чем вы прежде всего начнете думать? 
  • О чем вы прежде всего начнете думать? 
  • /
  • Три аспекта DDD
  • Внимание! Очень важно! Компоненты нижележащего слоя не должны зависеть от компонентов вышележащего ни при каких обстоятельствах
  • !!!
  • Постоянно себя спрашивайте: можно ли, используя public API доменной модели, нарушить целостность, согласованность и консистентность данных?
  • Хоцца «аналогов» SQL и xxxMyAdmin но для компонентов DomainModel, а не СУБД
  • Этому посвящен значительный объем всех книг, поэтому здесь мы пропустим
  • Используете ORM => У вас DDD !!! http://www.martinfowler.com/bliki/AnemicDomainModel.html Hibernate Ruby on Rails
  • По идее, всё нацелено на достаточно сложные модели: Но на практике эффективно используется и для несложных предметных областей
  • 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.com http://www.google.com/profiles/biBIGone