FDD & DDD
 Бибичев Андрей
   декабрь 2009 г.
I. Преамбула
Самая ценная часть доклада :)
ДЮДЮКИ:
                     Самая известная


TDD
Test-Driven Development
                        практика




          ...
Зачем?
Всё дело в том, что

                    удобрение
Scrum – это дерьмо
                а
                        плодородна...
Scrum-команда
Поэтому:


  внедрив Scrum,
мы обычно думаем,
что теперь всё будет
 хорошо само собой
 цвести и пахнуть
Product Owner
Но



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

проблемы только начинаются
     растет бурьян
Архитектор
потрудился…
И



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

 команда разваливается
   почва истощается
Рука HR-а
Или



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

       Code-&-Fix
копанию в земле по локоть
Аналитик
Контроль
качества
                      Архитектор
           Менеджер
Итак,



      оказывается еще нужны
что выращивать       как выращивать



 идеи и тех. практики и приемы
            сем...
Прибыльный проект


Обратите внимание на
слоистую архитектуру
RUP
Шо, опять механизация?
Lean


                              Agile


Do                          Итеративные процессы
Whatever
(0)

   Code    Kan...
• Architecture Reviewer / • Business Designer / • Business-Model Reviewer / • Business-Process Analyst
 / • Capsule Design...
погибче
Нам бы чего попроще !
II. FDD
Feature-Driven Development
История
   1997 год: проект для большого сингапурского банка
       длительность: 15 месяцев
       команда: 50 чел
   ...
А XP родилось на
маленьком in-house
 проекте, который
 кончился fail-ом…
Ну и что! Scrum вообще
      предлагает
 противоестественное
масштабирование при
        помощи
    Scrum-of-Scrum
История
   1999 год: книга «Java Modeling in Color With UML»
       один из соавторов книги – Jeff De Luca (вместе с Pet...
Всего одна глава!
Так – между делом…
    По Scrum & XP
 пришлось написать
  куда больше книг.
История
   2002 год: книга «A Practical Guide To Feature-Driven
    Development»
       Stephen Palmer, Mac Felsing
Автор продолжил
заниматься делом, а
 не исключительно
   личным PR-ом…
Шикарный подкаст на 40 минут
Feature
Шаблон именования Feature (функции):
<действие> <результат> <кем|чем|чего|для|к> <объект>
            <action> the...
Очень похоже на
      User Story,
 но нет необходимости
изобретать персонажи…
Конечно! Каждый считает
своим долгом предложить
    свой формат для
 требований. Ладно хоть
     Scrum от этого
      удер...
Группировка
   Область (Major Feature Set, Subject Area) АРМ Кассира
      Набор (Feature Set, Activity)          Оплата...
Дык, это же полный
 аналог Themes и Epics
при работе с User Stories
Требования к Feature List
 Каждая   feature должна быть простой
 Каждая feature должна быть ценна
  (хотя бы понятна) за...
Да-да, узнаю старый
    добрый INVEST:
Independent, Negotiable,
   Valuable, Estimable,
     Small, Testable
Схема процесса
 Разработка            Составление              Планирование
 общей модели          списка функций



     ...
Вау! Здесь есть
    начальная фаза
       проекта!!!
Чувствуется, что автор из
         IBM…
Процесс по шагам 1:
                          создание общей модели
42

    Участвуют:
        Главный архитектор
     ...
Наконец-то
  знакомые роли!
Архитектор, ведущий
разработчик – и снова
   здравствуйте 
Процесс по шагам 1:
                         создание общей модели
44

    Создание модели:
        Обязательно разбиваю...
UML и создание
  «конкурирующих»
  моделей – мне это
определенно нравится!
Тоже мне, открыли
    Америку – всё это
  известно со времен
      Model-Driven
Development/Architecture
      (MDD/MDA)
Процесс по шагам 2:
                  формирование Feature List
47


    Участвуют:
        Как и при формировании общей...
Интересно, а как потом
учитываются изменения
в требованиях и сколько
   сил на это уходит?
Процесс по шагам 3:
                                 планирование
49

    Основания для планирования:
        Наборы фун...
Что-то это уже
 конкретно попахивает
      водопадом…
 Да еще персональное
владение кодом… Бррр
Скажи спасибо, что хоть
   диаграммы Ганта
    строить не надо
Для тех, кто успел забыть
                  схему процесса:
 Разработка          Составление             Планирование
 общ...
Процесс по шагам 4:
                                 Design by feature
53

    Задачи:
        Формирование команд на ит...
Динамическое
формирование команд на
   итерацию – класс!
          А то:
 «слаженная команда –
   это очень ценно»…
      ...
Процесс по шагам 4:
                            Design by feature
55
    Задачи:
     (продолжение)
        Обзор затраг...
Вот! Спецификация API и
персональное назначение
 задач – сразу чувствуется
 старая школа! И никаких,
  понимаешь, соплей п...
Процесс по шагам 5:
                                 Build by feature
57

    Задачи:
        Реализация классов и метод...
Супер: вместо парного
  программирования – Code
 Inspection/Review; а вместо
мантры «Red-Green-Refactor»
   – просто напис...
Ну и правильно! Всё равно
  опросы общественного
 мнения показывают, что в
 парах мало кто кодит, да и
тесты до реализации...
Важный нюанс
• в FDD нет жесткого time-boxing-а итерации:
  – итерация не заканчивается, пока все взятые в
    неё feature...
Разумно, но что они при
 этом делают со своим
   план-графиком?...
Отслеживание хода процесса
62   Стандартная пропорция:
 Обзор         Детализация   Инспекция   Кодирование   Инспекция  ...
Отслеживание хода процесса:
                       для всего проекта
63


     Области




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

Управление
проектами        SCRUM             Индикация
                                   прогресса

У...
III. DDD
Domain-Driven Design
История
                            2004 год
                            Eric Evans
«Domain-Driven Design - Tackling Compl...
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...
Еще раз вспомним про FDD:

Разработка           Составление             Планирование
общей модели         списка функций

...
Центральная роль в
   мышлении,
 проектировании,
   реализации
                     DDD
Пример: есть сайт конференции,
надо сделать голосование за доклад
О чем вы прежде всего
   начнете думать?




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




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




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




                        
/
Три аспекта DDD
Внимание! Очень важно!

Компоненты нижележащего слоя
     не должны зависеть от
  компонентов вышележащего
  ни при каких ...
!!!
Постоянно себя спрашивайте:
 можно ли, используя public API доменной
      модели, нарушить целостность,
согласованность и...
Хоцца «аналогов» SQL и xxxMyAdmin
но для компонентов DomainModel, а не СУБД
Этому посвящен
значительный объем
 всех книг, поэтому
здесь мы пропустим
Используете ORM                 =>        У вас DDD
                               !!!
          http://www.martinfowler.c...
По идее, всё нацелено на достаточно сложные модели:




     Но на практике эффективно используется
      и для несложных ...
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
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Обзор Feature-Driven Development и Domain-Driven Design
Upcoming SlideShare
Loading in …5
×

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

4,712 views

Published on

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

Published in: Technology
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,712
On SlideShare
0
From Embeds
0
Number of Embeds
1,461
Actions
Shares
0
Downloads
152
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide

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

  1. 1. FDD & DDD Бибичев Андрей декабрь 2009 г.
  2. 2. I. Преамбула Самая ценная часть доклада :)
  3. 3. ДЮДЮКИ: Самая известная TDD Test-Driven Development практика Нынче очень модное направление проектирования DDD Сменщик Test-Driven Design BDD TDD Behaviour-Driven Development Одна из самых навороченных FDD Agile-методологий VDD Как затуманить заказчику мозги Feature-Driven Development Value-Driven Development
  4. 4. Зачем?
  5. 5. Всё дело в том, что удобрение Scrum – это дерьмо а плодородная почва Scrum-команда – это чернозем
  6. 6. Scrum-команда
  7. 7. Поэтому: внедрив Scrum, мы обычно думаем, что теперь всё будет хорошо само собой цвести и пахнуть
  8. 8. Product Owner
  9. 9. Но в действительности проблемы только начинаются растет бурьян
  10. 10. Архитектор потрудился…
  11. 11. И если ничего не делать, то команда разваливается почва истощается
  12. 12. Рука HR-а
  13. 13. Или всё скатывается к Code-&-Fix копанию в земле по локоть
  14. 14. Аналитик Контроль качества Архитектор Менеджер
  15. 15. Итак, оказывается еще нужны что выращивать как выращивать идеи и тех. практики и приемы семяна и техника
  16. 16. Прибыльный проект Обратите внимание на слоистую архитектуру
  17. 17. RUP Шо, опять механизация?
  18. 18. Lean Agile Do Итеративные процессы Whatever (0) Code Kanban Scrum XP RUP -&- (3) (9) (13) (120+) Fix (1) Pull-загрузка задачами (с) «Процессная ось» имени Хенрика Книберга
  19. 19. • 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
  20. 20. погибче Нам бы чего попроще !
  21. 21. II. FDD Feature-Driven Development
  22. 22. История  1997 год: проект для большого сингапурского банка  длительность: 15 месяцев  команда: 50 чел  Jeff De Luca  под влиянием подхода Peter Coad-а к моделированию бизнес-процессов Интересные факты из биографии: • родился в 1964 году • в 1981 году в возрасте 17-ти лет бросил школу и пошел работать в IBM • быстро стал системным инженером, так и не получив высшего образования (самоучка) • в 1993 ушел из IBM (с должности системного стратега) и организовал собственную компанию • в 1995-1999 гг. выполнил полный реинжениринг автоматизации крупного сингапурского банка
  23. 23. А XP родилось на маленьком in-house проекте, который кончился fail-ом…
  24. 24. Ну и что! Scrum вообще предлагает противоестественное масштабирование при помощи Scrum-of-Scrum
  25. 25. История  1999 год: книга «Java Modeling in Color With UML»  один из соавторов книги – Jeff De Luca (вместе с Peter Coad и Eric Lefebvre)  в 6-ой главе было дано краткое описание FDD
  26. 26. Всего одна глава! Так – между делом… По Scrum & XP пришлось написать куда больше книг.
  27. 27. История  2002 год: книга «A Practical Guide To Feature-Driven Development»  Stephen Palmer, Mac Felsing
  28. 28. Автор продолжил заниматься делом, а не исключительно личным PR-ом…
  29. 29. Шикарный подкаст на 40 минут
  30. 30. 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 Всегда в терминологии предметной области! Должна быть понятна значимость для бизнеса
  31. 31. Очень похоже на User Story, но нет необходимости изобретать персонажи…
  32. 32. Конечно! Каждый считает своим долгом предложить свой формат для требований. Ладно хоть Scrum от этого удержался...
  33. 33. Группировка  Область (Major Feature Set, Subject Area) АРМ Кассира  Набор (Feature Set, Activity) Оплата товара  Функция (Feature) Снять деньги с карточки
  34. 34. Дык, это же полный аналог Themes и Epics при работе с User Stories
  35. 35. Требования к Feature List  Каждая feature должна быть простой  Каждая feature должна быть ценна (хотя бы понятна) заказчику  Каждая feature должна быть проверяема  Каждый feature set может быть закреплен за ведущим разработчиком (Chief Developer)  Feature List должен быть коротким (на столько, на сколько возможно)
  36. 36. Да-да, узнаю старый добрый INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
  37. 37. Схема процесса Разработка Составление Планирование общей модели списка функций Список функций План разработки (Feature list) (A development plan) 1 – 3 недели Design by Build by feature Диаграмма классов feature предметной области Отгрузка!
  38. 38. Вау! Здесь есть начальная фаза проекта!!! Чувствуется, что автор из IBM…
  39. 39. Процесс по шагам 1: создание общей модели 42  Участвуют:  Главный архитектор  Ведущие разработчики (Chief Developers)  Эксперты в предметной области  Подготовка к созданию:  Выслушивают эксперта в предметной области  По необходимости изучают документы  Обсуждения между собой
  40. 40. Наконец-то знакомые роли! Архитектор, ведущий разработчик – и снова здравствуйте 
  41. 41. Процесс по шагам 1: создание общей модели 44  Создание модели:  Обязательно разбиваются на небольшие группы  Каждая группа создает свою модель (диаграмму классов)  После этого собираются все вместе, обсуждают различия, выбирают/формируют итоговые решения  В результате:  Диаграмма классов (без детализации)  Комментарии почему выбрано такое решение, альтернативные решения
  42. 42. UML и создание «конкурирующих» моделей – мне это определенно нравится!
  43. 43. Тоже мне, открыли Америку – всё это известно со времен Model-Driven Development/Architecture (MDD/MDA)
  44. 44. Процесс по шагам 2: формирование Feature List 47  Участвуют:  Как и при формировании общей модели  В результате:  Feature List, сгруппированный в наборы (Feature Set), разделенные по областям (Subject Area)
  45. 45. Интересно, а как потом учитываются изменения в требованиях и сколько сил на это уходит?
  46. 46. Процесс по шагам 3: планирование 49  Основания для планирования:  Наборы функций – итерации  Последовательность итераций определяется исходя из:  взаимосвязи функций с точки зрения реализации  сложности набора функций  наличия рисков при реализации функций  равномерное распределение загрузки разработчиков  Участвуют:  Руководитель проекта  Ведущие разработчики  В результате:  График реализации наборов функций (Набор – дата)  Ведущие программисты, закрепленные за наборами (Набор – ответственный)  Всем классам назначены владельцы (Класс – владелец)
  47. 47. Что-то это уже конкретно попахивает водопадом… Да еще персональное владение кодом… Бррр
  48. 48. Скажи спасибо, что хоть диаграммы Ганта строить не надо
  49. 49. Для тех, кто успел забыть схему процесса: Разработка Составление Планирование общей модели списка функций Список функций План разработки (Feature list) (A development plan) 1 – 3 недели Design by Build by feature Диаграмма классов feature предметной области Отгрузка!
  50. 50. Процесс по шагам 4: Design by feature 53  Задачи:  Формирование команд на итерацию  ведущие разработчики динамически формируют команды на итерацию  исходя из того, какие классы затрагивает реализация заданного набора функций (берутся их владельцы)  обычно команды не большие (около 5 человек) (to be continued)
  51. 51. Динамическое формирование команд на итерацию – класс! А то: «слаженная команда – это очень ценно»… Так их! 
  52. 52. Процесс по шагам 4: Design by feature 55  Задачи: (продолжение)  Обзор затрагиваемой предметной области  Изучение необходимых документов  Составление диаграмм взаимодействия  Уточнение и детализация соответствующей части диаграммы классов  Написание заголовков методов  В результате:  Краткое описание набора функций, дополнительные комментарии  Диаграммы взаимодействия  Объектная модель (уточнения, исправления), заголовки классов  Задания (To Do) в системе ведения дел для каждого участника команды
  53. 53. Вот! Спецификация API и персональное назначение задач – сразу чувствуется старая школа! И никаких, понимаешь, соплей про самоорганизацию и кросс- функциональность…
  54. 54. Процесс по шагам 5: Build by feature 57  Задачи:  Реализация классов и методов  Code Inspection (Code Review)  до unit-тестирования!  самой командой или даже другой (по решению ведущего программиста)  Unit-тестирование  тесты на класс пишет сам владелец класса  Интеграция (Promote to Build)  Уточнение и детализация соответствующей части диаграммы классов  В результате:  Проинспектированные классы и методы  Классы, допущенные в основной ствол проекта  Реализованная функциональность, понятная заказчику (client-valued features)
  55. 55. Супер: вместо парного программирования – Code Inspection/Review; а вместо мантры «Red-Green-Refactor» – просто написание Unit- тестов (причем после реализации).
  56. 56. Ну и правильно! Всё равно опросы общественного мнения показывают, что в парах мало кто кодит, да и тесты до реализации писать дико – некомпилится ведь!
  57. 57. Важный нюанс • в FDD нет жесткого time-boxing-а итерации: – итерация не заканчивается, пока все взятые в неё feature-и не доделают – т.е. недоделанные feature-и не перетекают в следующую итерацию – их дожимают в текущей, растягивая оную
  58. 58. Разумно, но что они при этом делают со своим план-графиком?...
  59. 59. Отслеживание хода процесса 62 Стандартная пропорция: Обзор Детализация Инспекция Кодирование Инспекция Интеграция модели модели дизайна кода (дизайн) 1% 40% 3% 45% 10% 1%  За счет этого ведется графическое отображение хода выполнения:
  60. 60. Отслеживание хода процесса: для всего проекта 63 Области Наборы функций
  61. 61. Эта штука посильнее будет всяких Burn-down-ов и –up-ов: и бизнесам показать не стыдно, и на конфе козырнуть.
  62. 62. Уровень процессов Управление проектами SCRUM Индикация прогресса Управление проектом Самоорг. команда, Перечень Daily Meetings требований, Итерации Unit-тесты, FDD Стандарт кодирования, Кодирование XP Cont. Integration Жесткость процессов Анархия Водопад --------- Как некий итог ---------
  63. 63. III. DDD Domain-Driven Design
  64. 64. История 2004 год Eric Evans «Domain-Driven Design - Tackling Complexity in the Heart of Software»
  65. 65. Domain (словарь) • наследственная собственность; имение, поместье; земли; владение e.g. DNS • территория, зона, область, район (отмеченные некоторыми физическими особенностями) • сфера (интересов), поле (деятельности), область (знаний) В данном случае этот смысл • область определения (мат.) Домен поля таблицы в БД
  66. 66. Т.е. это о Business Domain Предметной области и Business Logic Бизнес-логики
  67. 67. «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.»
  68. 68. Еще раз вспомним про FDD: Разработка Составление Планирование общей модели списка функций Список функций План разработки (Feature list) (A development plan) 1 – 3 недели Design by Build by feature Диаграмма классов feature предметной области Отгрузка!
  69. 69. Центральная роль в мышлении, проектировании, реализации DDD
  70. 70. Пример: есть сайт конференции, надо сделать голосование за доклад
  71. 71. О чем вы прежде всего начнете думать? 
  72. 72. О чем вы прежде всего начнете думать? votes 
  73. 73. О чем вы прежде всего начнете думать? 
  74. 74. О чем вы прежде всего начнете думать? 
  75. 75. /
  76. 76. Три аспекта DDD
  77. 77. Внимание! Очень важно! Компоненты нижележащего слоя не должны зависеть от компонентов вышележащего ни при каких обстоятельствах
  78. 78. !!!
  79. 79. Постоянно себя спрашивайте: можно ли, используя public API доменной модели, нарушить целостность, согласованность и консистентность данных?
  80. 80. Хоцца «аналогов» SQL и xxxMyAdmin но для компонентов DomainModel, а не СУБД
  81. 81. Этому посвящен значительный объем всех книг, поэтому здесь мы пропустим
  82. 82. Используете ORM => У вас DDD !!! http://www.martinfowler.com/bliki/AnemicDomainModel.html Hibernate Ruby on Rails
  83. 83. По идее, всё нацелено на достаточно сложные модели: Но на практике эффективно используется и для несложных предметных областей
  84. 84. http://www.infoq.com/ presentations/rebuild-guardian-ddd-wills
  85. 85. http://www.infoq.com/ presentations/rebuild-guardian-ddd-wills
  86. 86. http://www.infoq.com/ presentations/rebuild-guardian-ddd-wills
  87. 87. IV. Заключение В стиле «Демотиваторы»
  88. 88. «На кой мне это всё?» Есть Vision и feedback и в проекте ориентируюсь яки рыба в воде артефакты
  89. 89. На одном Scrum-е далеко не уедешь
  90. 90. Внедрение Scrum Не подумав вовремя об этом, вы действуете как кальсонные гномы
  91. 91. Спасибо за внимание! biBIGone@gmail.com http://www.google.com/profiles/biBIGone

×