Feature Driven Development: анализ
Хочешь сделать что-то хорошо - сделай это сам, блин. Вот описание процессов FDD.
http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf
Делаю выжимку. Для начала - FDD разработан как хорошо масштабируемый процесс. 50 человек в группе разработки - и утверждается что это далеко не предел для FDD. FDD при этом не покрывает все аспекты работы компании разработчика ПО - он описывает только группу разработки. Там пять процессов.
Резюме - херовенький какой-то процесс получается у нас FDD, не смотря на то, что действительно использует неплохой набор best practices. Просто удивительно, как ложка дерьма может испортить вест суп.
1. "Разработка обще модели"
Учавствуют: Domain Experts, Chief Programmer, Chief Architect (он координирует процесс). Есть постоянно действующий состав modelling team. Остальные - могут приглашаться по требованию или желанию.
Это архитектурный этап. Его цель - разработка общей объектной модели в виде структуры классов. Это делается при старте проекта, после чего архитектура дополняется и расширяется. Причем, предполагается, что мы уже знаем, что хотим разработать. Вполне вероятно, у нас даже уже есть требования в том или ином виде - неважно каком.
Как разрабатывается архитектура. Сначала эксперты в предметной области дают введение в предметную область и ее проблемы, которые надо решить. Их слушают, и курят мануалы, если есть.
Потом - группы по 2-3 человека (очень правильно) разрабатывают свои варианты архитектуры, после чего представитель каждой группы делает доклад на совещаниях.
Архитектор может предлагать свои варианты. После серии обсуждений, группа приходит к единому варианту.
Что хорошо: включение domain expert в команду, групповой процесс разработки архитектуры. То, что вообще есть этот этап - это уже хорошо.
Чего не хватает: ничего не сказано про требования. Просто - ноль информации о требованиях на архитектурном этапе. Странно. Что за модель они делают?
FDD Process #2: Build a Features List
После того, как они сделали архитектуру, они делают фичлист. Хм. Странно.
An initial project-wide activity to identify all the features to support the requirements.
Это дико странно, на самом деле. Фича должна поддерживать требования. Какая нафиг фича после того, как разработана объектная модель - в виде UML классов? Ну ладно, разберемся.
Заняты этим Chief Programmers из команды первого процесса. Делают они вот что: разбивают все поведение системы на Subject Areas, в пределах каждой из них выделяют Business Activity, которая состоит из шагов-фич. Не так плохо - но невооруженным глазом видна заточка этого процесса под автоматизацию бизнес-процессов.
Фича - это отдельная задача разработки, назначаемая на одного разработчика. Она не может превышать две недели. То есть, говоря человеческим языком - на данном этапе они составляют список задач и оценивают их продолжительность.
Ну чо, нормально - сначала архитектуру сделали, потом на задания порезали.
FDD Process #3: Plan By Feature
Все просто. Теперь, имея список бизнес-активностей, они выполняют scheduling.
Каждой бизнес-активности назначается месяц завершения. За каждую бизнес-активность целиком отвечает один Chief Developer. Ну чо, в принципе нормально.
После чего, классы, которые надо заколбасить, распределяются по просто developer-ам - назначаются их владельцы.
Получается, что Chief Developer до боли напоминает старого доброго тимлида.
Все, на это глобальные активности при старте проекта заканчиваются. Дальше идет разработка.
FDD Process #4: Design By Feature
Периодически, наш тимлид-chief programmer выгребает фичи, которые надо реализовать, группирует их в пакеты фич - так, чтобы использовались примерно одни и те же классы. Потом заглядывает в матрицу оунершыпа, и выбирает программеров из владельцев классов - они составят фич-тим.
Фич тим выполняет детальное проектирование пакета фичей, рисуют sequence диаграммы, и уточняет общую модель. После чего дизайн проходит инспекции. Этот пакет фич - такой маленький проектик, а chief programmer получается его тимлид.
Хм. Это реально очень хорошо масштабируемый процесс - по крайней мере авторы старались. Интересно - они матричную структуру на программеров навернули. Что-то в этом есть такое.
FDD Process #5: Build By Feature
На этом этапе пакет фич реализуется. Причем - фичи сквозные, но каждый программер работает над одним классом! Что будет, если фича "сквозная" - проходит через несколько классов? Непонятный это момент, короче говоря. Совсем. Отслеживается-то работа по фичам.
Чтобы это работало, на практике, они скорее всего поступают просто. Каждому программеру выделяется некоторая относительно изолированная подсистема - группа классов. После чего, чтобы нормально выдавать по одному заданию на человека, и сохранить соответствие фича-задача, надо чтобы фича не вылезала за границу подсистемы. Это соблюсти можно, однако процесс FDD не дает средств это поставит на поток - он не оперирует понятием "подсистема". И Chief-у придется делать это каждый раз ad-hoc. Неудобно, мягко говоря.
Второй вариант - проще в осуществлении. Фича выделяется тому программеру, кто владеет большим количеством классов для фичи. Он делает ее целиком, при этом владельцы классов, которые он правит - делают ему code и design review. Кстати, получается что основная модель служит во многом для того, чтобы сопоставлять классы фичам.
На практике - надо бы не морочить людям головы. А именно, выделять на первом этапе вовсе не классы, а подсистемы, и очертить границы их функциональности. После чего затребовать гранулярность отдельных фич до уровня подсистем - это важно. Для этого даже инструмент известный есть - CRC-карты - вот и использовать его на первом этапе, причем укрупнив классы до подсистем. Назначить владельцев подсистем, а не классов и не фич. Выбирать не "пакет фич" к реализации, а создавать подпроект, который реализует важный и законченный кусок функциональности, полезный пользователю. Таким образом у нас почти вся ненормальность уйдет, но только это уже будет не FDD :)
А в оригинале - неадекватно выходит. Представление на первом этапе используется для определения связки фичи-классы, но оно слишком мелкогранулярно для этого. Надо укрупнять - будет кстати реже меняться. Плюс ко всему, фичи, то есть функциональность, объективно доступны раньше, чем будет закончена модель классов.
Короче, или я чего-то в FDD не понял, или я нашел в нем крупный косяк. Одно из двух.
http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf
Делаю выжимку. Для начала - FDD разработан как хорошо масштабируемый процесс. 50 человек в группе разработки - и утверждается что это далеко не предел для FDD. FDD при этом не покрывает все аспекты работы компании разработчика ПО - он описывает только группу разработки. Там пять процессов.
Резюме - херовенький какой-то процесс получается у нас FDD, не смотря на то, что действительно использует неплохой набор best practices. Просто удивительно, как ложка дерьма может испортить вест суп.
1. "Разработка обще модели"
Учавствуют: Domain Experts, Chief Programmer, Chief Architect (он координирует процесс). Есть постоянно действующий состав modelling team. Остальные - могут приглашаться по требованию или желанию.
Это архитектурный этап. Его цель - разработка общей объектной модели в виде структуры классов. Это делается при старте проекта, после чего архитектура дополняется и расширяется. Причем, предполагается, что мы уже знаем, что хотим разработать. Вполне вероятно, у нас даже уже есть требования в том или ином виде - неважно каком.
Как разрабатывается архитектура. Сначала эксперты в предметной области дают введение в предметную область и ее проблемы, которые надо решить. Их слушают, и курят мануалы, если есть.
Потом - группы по 2-3 человека (очень правильно) разрабатывают свои варианты архитектуры, после чего представитель каждой группы делает доклад на совещаниях.
Архитектор может предлагать свои варианты. После серии обсуждений, группа приходит к единому варианту.
Что хорошо: включение domain expert в команду, групповой процесс разработки архитектуры. То, что вообще есть этот этап - это уже хорошо.
Чего не хватает: ничего не сказано про требования. Просто - ноль информации о требованиях на архитектурном этапе. Странно. Что за модель они делают?
FDD Process #2: Build a Features List
После того, как они сделали архитектуру, они делают фичлист. Хм. Странно.
An initial project-wide activity to identify all the features to support the requirements.
Это дико странно, на самом деле. Фича должна поддерживать требования. Какая нафиг фича после того, как разработана объектная модель - в виде UML классов? Ну ладно, разберемся.
Заняты этим Chief Programmers из команды первого процесса. Делают они вот что: разбивают все поведение системы на Subject Areas, в пределах каждой из них выделяют Business Activity, которая состоит из шагов-фич. Не так плохо - но невооруженным глазом видна заточка этого процесса под автоматизацию бизнес-процессов.
Фича - это отдельная задача разработки, назначаемая на одного разработчика. Она не может превышать две недели. То есть, говоря человеческим языком - на данном этапе они составляют список задач и оценивают их продолжительность.
Ну чо, нормально - сначала архитектуру сделали, потом на задания порезали.
FDD Process #3: Plan By Feature
Все просто. Теперь, имея список бизнес-активностей, они выполняют scheduling.
Каждой бизнес-активности назначается месяц завершения. За каждую бизнес-активность целиком отвечает один Chief Developer. Ну чо, в принципе нормально.
После чего, классы, которые надо заколбасить, распределяются по просто developer-ам - назначаются их владельцы.
Получается, что Chief Developer до боли напоминает старого доброго тимлида.
Все, на это глобальные активности при старте проекта заканчиваются. Дальше идет разработка.
FDD Process #4: Design By Feature
Периодически, наш тимлид-chief programmer выгребает фичи, которые надо реализовать, группирует их в пакеты фич - так, чтобы использовались примерно одни и те же классы. Потом заглядывает в матрицу оунершыпа, и выбирает программеров из владельцев классов - они составят фич-тим.
Фич тим выполняет детальное проектирование пакета фичей, рисуют sequence диаграммы, и уточняет общую модель. После чего дизайн проходит инспекции. Этот пакет фич - такой маленький проектик, а chief programmer получается его тимлид.
Хм. Это реально очень хорошо масштабируемый процесс - по крайней мере авторы старались. Интересно - они матричную структуру на программеров навернули. Что-то в этом есть такое.
FDD Process #5: Build By Feature
На этом этапе пакет фич реализуется. Причем - фичи сквозные, но каждый программер работает над одним классом! Что будет, если фича "сквозная" - проходит через несколько классов? Непонятный это момент, короче говоря. Совсем. Отслеживается-то работа по фичам.
Чтобы это работало, на практике, они скорее всего поступают просто. Каждому программеру выделяется некоторая относительно изолированная подсистема - группа классов. После чего, чтобы нормально выдавать по одному заданию на человека, и сохранить соответствие фича-задача, надо чтобы фича не вылезала за границу подсистемы. Это соблюсти можно, однако процесс FDD не дает средств это поставит на поток - он не оперирует понятием "подсистема". И Chief-у придется делать это каждый раз ad-hoc. Неудобно, мягко говоря.
Второй вариант - проще в осуществлении. Фича выделяется тому программеру, кто владеет большим количеством классов для фичи. Он делает ее целиком, при этом владельцы классов, которые он правит - делают ему code и design review. Кстати, получается что основная модель служит во многом для того, чтобы сопоставлять классы фичам.
На практике - надо бы не морочить людям головы. А именно, выделять на первом этапе вовсе не классы, а подсистемы, и очертить границы их функциональности. После чего затребовать гранулярность отдельных фич до уровня подсистем - это важно. Для этого даже инструмент известный есть - CRC-карты - вот и использовать его на первом этапе, причем укрупнив классы до подсистем. Назначить владельцев подсистем, а не классов и не фич. Выбирать не "пакет фич" к реализации, а создавать подпроект, который реализует важный и законченный кусок функциональности, полезный пользователю. Таким образом у нас почти вся ненормальность уйдет, но только это уже будет не FDD :)
А в оригинале - неадекватно выходит. Представление на первом этапе используется для определения связки фичи-классы, но оно слишком мелкогранулярно для этого. Надо укрупнять - будет кстати реже меняться. Плюс ко всему, фичи, то есть функциональность, объективно доступны раньше, чем будет закончена модель классов.
Короче, или я чего-то в FDD не понял, или я нашел в нем крупный косяк. Одно из двух.