G>1) Code ownership. "Зоны ответственности". В описанных мной условиях, архитектор — это инженер, отвечающий за порядок и дизайн в некоторой подсистеме. Реализация фичи может затрагивать несколько подсистем. Любое изменение дизайна подсистемы — и "владелец" подсистемы обязан подтвердить его на G>2) Design review. И не пропустить плохой дизайн. Если предполагается, что изменения будут значительны — владелец подсистемы включается в фичгруппу. G>3) Code review.
G>Таким образом, у нас получается как бы матрица — с одной стороны есть "владельцы" кода, с другой — фичи, и группы фичей, перпендикуларно структуре кода.
Абсолютно не вижу что здесь новое относительно других процессов (не считая scrum)
Всё, завязали. Мы с тобой видимо совершенно с разными продуктами работаем, разными людьми и в разных условиях. Я уже лет десять с железками не работаю.
BG>>Честно сказать, я ничего нового в fdd не увидел, все вышеперечисленное есть во всех нормальных командах. Вероятно, вы забыли упомянуть те самые факторы, которые и отличают его от всех остальных процессов. Т.е. пока что я не вижу ничего революционного в fdd.
G>"Вода", которую вы пропустили: G>
G>Хороший процесс людям не нужен — им нужен в первую очередь простой процесс, который был бы лучше полного бардака и мало мальски преемлем. Сложные процессы хороши — но их тяжело заставить работать на практике. Поэтому легковесные процессы — это естественный запрос индустрии — она возжелала хоть худого, но порядка.
G>Не понятно? Могу пояснить. Ничего нового и революционного в легком процессе быть и не должно. Его единственное достоинство — легковесность и низкие затраты на внедрение и поддержание. Его единственный плюс — он не должен быть полным дерьмом, если он при легковесности дает результат "удовлетворительно", на троечку — это очень хороший легкий процесс.
Особой легковесности я в этом FDD в общем не заметил. Декларируются принципы и подходы, которые в общем и ежу понятны, но при этом над ними зачем-то выстраивается какая-то довольно жёсткая методология звязи реализации с требованиями, упускающая при этом другие стороны разработки и ограничивающая свободу в управлении требованиями и собственно в разработке. Т.е., по моему мнению, простановка акцентов здесь более вредит, чем приносит пользу.
G>1) Продуктовая разработка. Группа разработки человек 20. Продукт уже написан, и продается. Его надо развивать и регулярно выпускать версии с исправлениями ошибок. При этом, есть небольшие фичреквесты и улучшения. Иногда затеваются рефакторинги и серьезные переделки подсистем. Иногда докручиваются новые фичи. Есть отдел тестеров, и кастомер саппорт. Отдельно — маректинг. Нужен единый процесс работы product development team в задачу которых входит выпуск релизов — как maintenance, так и general. Законченный процесс не требуется — нужен минимальный и простой процесс-шаблон, который сам по себе работоспособен, и при желании легко кастомизируется.
О! А в этом что-то есть. Как процесс доработки и поддержки, а не разработки или развития, когда практически все задачи и проблемы уже решены, FDD вполне может подойти.
Но процессом разработки я бы его называть не стал.
G> За меня не надо беспокоится — у меня-то данных достаточно и я не ошибусь. Так что советов мне давать не надо и моральной ответственности за них вы тоже нести не будете — все проще. Пока я хочу в рамках дискуссии идентифицировать слабые места FDD — чтобы быть уверенным, что ничего не пропустил. И все. Так я сэкономлю массу времени — в одиночку буду разбираться дольше.
Держи нас в курсе оформления формы твоего процесса. Это интересно.
Здравствуйте, Gaperton, Вы писали:
G>Читайте википедию, пишите, оппонируйте.
Неплохо бы было сразу ссылочку для ленивых написать Ну да ладно, попробую разобраться в FDD. Поехали. Попробую применить его к своему environment.
Develop Overall Model
Вообще-то у нас исходным документом является SoW, в котором прописаны фичи и обсуждения с бизнесом начинаются как раз со списка фич, а не с объектной модели, т.е. этот пункт по идее должен идти вторым. Что же касается разработки модели, то необходимо уточнить — насколько детально ее надо разрабатывать? Если исходить из class ownership, то по идее надо опускаться до класса. И тут есть сложность. Может я конечно фиговый архитектор, то на практике не получается нарисовать диаграммы до класса, т.к. при имплементации постоянно вылазят непредусмотренные косяки и архитектуру приходится постоянно исправлять (рефакторить). И это даже для небольшой модели из десятка классов! Так что:
Вывод №1. Нужен гуру-архитектор, который сможет спроектировать систему до класса так, что бы потом не пришлось ее переделывать.
Build Feature List
Тут все понятно, беру SoW, выдираю из него фичи и пишу фич-лист. Непонятно другое. Что делать, если фич лист поменялся в процессе разработки? Похоже надо откатываться до самого начала, т.к. новая фича запросто может потребовать изменения модели.
Вывод №2. Фич-лист должен быть фиксирован на все время итерации.
Plan By Feature
Распределяем фичи по сеньорам. В принципе, понятно
Design By Feature
Сеньор собирает девелоперов (class owners), рисует sequence diagrams и фиксит модель. Ага! Значит архитектор имеет право на ошибку, уже более реально. Вызывает интерес такой вот вопрос. У нас есть несколько сеньоров и девелоперы. Разные сеньоры работают с одними и теми же девелоперами и независимо кривят модель. Налицо изначально конфликтная ситуация, особенно если разные фичи требуют разного подхода к дизайну. Да и у бедных девелоперов получается несколько сеньоров которые хотят разного. Перетягивание одеяла гарантировано.
Вывод №3. Надо быть готовым к конфликтам между сеньорами.
Build By Feature
Девелоперы пишут код для своих классов, покрывают его тестами и делается code-review. Хорошо, это в принципе везде так, за исключением:
Class Ownership
С одной стороны куча плюсов — девелопер занимается только тем, к чему у него есть способности (кто-то умеет классно хранимки писать, кто-то знает тонкости гуя), у него есть четко ограниченные рамки отвественности. Все замечательно, только есть и проблемы:
Возьмем простой пример. Есть в наличии 4 девелопера и 1 сеньор (не будем усложнять жизнь конфликтами между сеньорами). Фичлист такой — надо сгенерить из базы разные отчеты (это у нас будут разные фичи) и показать их в веб-приложении. Распределяем девелоперов — один будет делать хранимки (DB), второй DAL (DAL), третий бизнес уровень (BL), четвертый вебгуй (Web). Делаем для них таски:
DB — написать хранимки для вытаскивания данных
DAL — сделать классы для доступа к базе
BL — сделать бизнес объекти и реализовать необходимые расчеты
Web — нарисовать веб сайт и показать отчеты.
Правильно? Что происходит дальше, DB долго возится с хранимками, т.к. есть проблемы (очень сложный запрос), все остальные сделали все, что не зависит от данных и банально ждут, даже нормально потестировать не получается, т.к. данных нет. И это в практически идеальных условиях. А если чуть усложнить и добавить еще одного BL? Получается веселее. Потребовались им новые данные из БД. Пошли они к сеньору, тот покривил модель, добавил пару методов в DAL, поставил DAL таски на реализацию этих методов, DAL пошел к сеньору, сказал, что нужна еще пара хранимок, сеньор покривил модель, поставил таску DB, DB делал хранимки неделю и все это время все остальные ждали.
Еще один распространенный сценарий. Программа вываливается с exception, выясняется, что если передать в DAL null, то нет проверки, DAL девелопер начинает кричать и переводить стрелки, типа нефиг null мне передавать, BL орет, типа делай проверку. Приходится сеньору разгребать всю эту мелочевку.
Вывод №4. Нагрузка не сеньора получается большая.
Я уж молчу про самый поганый для этой методы сценарий, когда, к примеру надо сделать кучу работы на вебсайте, не затрагивая другие компоненты. Все остальные девелоперы просто будут простаивать в течении всей итерации. Или, что делать, если DB ушел на месяц в отпуск?
Вывод №5. Class ownership неплох только для больших команд, которые по каким-либо причинам нельзя разбить. В небольших командах до 10 человек просто банально не хватит девелоперов для дублирования.
Итог
В чистом виде FDD неплох для случая большой команды, которую невозможно разбить по компонентам системы, в условиях четко указанных и не меняющихся в процессе итерации требований. В состав команды при этом могут входить девелоперы с невысоким уровнем.
У нас ситуация другая — есть либо много мелких проектов, либо проект легко разбивается на слабо связанные компоненты, которые реализуют сформированные команды из 3-5 девелоперов действительно сеньорского уровня во главе с тимлидами. В этом случае девелоперы вырождаются в сеньоров по классификации FDD и код становится shared в пределах компонент (в FDD он тоже shared среди сеньоров). Специализация девелоперов учитывается при распределении фич.
Так что не получается из FDD панацеи. Годится лишь для оговоренных выше случаев.
Здравствуйте, VGn, Вы писали:
G>>Можно. IP-блок видеоконтроллера, формирующего ТВ сигнал высокой и стандартной четкости. Слой для видео, слой для меню с аппаратным наложением через альфу. VGn>.... G>>Предназначен для применения в микросхемах класса "система-на-кристалле" с шинной иерархией AMBA 3.0.
VGn>Теперь понятно почему так разнятся наши позиции по процессам разработки. Ты разрабатываешь больше технологичные, железячные вещи, а весь agile в общем рассчитан больше на софт с значительной долей взаимодействия с пользователем и для удовлетворения собственно пользователей, а не фиксированных интерфейсов - VGn>здесь.
Аппаратурой я занимался 2.5 года. До этого — восемь лет софтом. И сейчас — я опять занимаюсь софтом. Как именно разнятся наши позиции по процессам разработки — не знаю. Ты ведь свою позицию не изложил. И я не уверен, что ты понял мою.
VGn>При этом FDD, по моим поверхностным оценкам — ни каким боком не agile. Даже более того — он вообще мало напоминает процесс разработки. Скорее — процесс кодирования.
Обоснуй.
VGn>Вполне возможно где-то он и применим (где вообще чудовищный бардак с определением требований и назначением задач и нет возможности тесно общаться с клиентами), но имхо это больше процесс дизайна, как впрочем и TDD, обсуждение которого зачем-то засунули в этот форум.
Не понял, то ли это процесс кодирования, то ли процесс дизайна, и самое главное — наблюдая за этими колыханиями поверхности воды, совершенно не понятно, что у тебя за процессы в глубине головы происходят. Может ты все-таки раскроешь тему? Развернуто — выдвини тезисы, обоснуй их логически. Давай базар не будем разводить, мы же профессионалы, и речь не о вымирании динозавров, правильно?
Здравствуйте, VGn, Вы писали:
VGn>Абсолютно не вижу что здесь новое относительно других процессов (не считая scrum)
Ты тоже новизны захотел? Какая в задницу новизна? Я тебе разве о новизне говорю? Это ватерфол в чистом виде, только облегченный и упрощенный, ты что, не заметил еще? Почитай первый пост — внимательно. Почему ты не читашь посты?
G>Наличие управления требованиями является безусловно сильной стороной FDD. Особенно ее ориентированность на "фичи" — строить план от единиц независимого тестирования это очень правильно, такие планы очень легко понимать, и главное — легко перестраивать в динамике при изменении приоритетов и требований. Это вообще не секрет для последователей ватерфола. Заодно — фичлист является отличным звеном для трассировки от бизнес-необходимости к дизайну. По сути, если облегчать процесс управления требованиями, отрезая все что можно — то один фичлист и останется как самый необходимый документ. Очень правильно сделано, просто блестяще.
Я бы не назвал это управлением требованиями. Это идентификация требований, но никак не управление.
M>>предметной области, не подверженной частым изменениям; G>Фичлист — это ключевое. Это проверенный ватерфольный способ управлять этими изменениями сохраняя ватерфольный контроль и прозрачность. И все лишнее отрезано — но может быть добавлено при необходимости обратно. Очень хорошо.
Это как? Управление изменениями через их отрицание?
M>>и стабильной команде с низкой текучкой. G>Вы забыли про обязательные design и code review. Это единственно работающий на практике механизм рапространения знаний, помимо того что он увеличивает качество софта и дает лучший контроль над процессом. В скраме у вас есть пустые декларации — здесь — вместо них имеем проверенный и эффективный механизм реального распространения знаний, который при необходимости может быть легко отмасштабирован заменой review на полномасштабные inspections Фагана.
-1
В design и code review участвуют разработчики того же уровня? разработчики более низких уровней? Не особо себе это представляю.
По поводу единственно работающего ты имхо погорячился.
Здравствуйте, VGn, Вы писали:
VGn>Особой легковесности я в этом FDD в общем не заметил.
Это огромный недостаток FDD.
VGn>Декларируются принципы и подходы, которые в общем и ежу понятны,
Ты предпочитаешь методологии, которые декларируют подходы и принципы, которые понять могут только люди с IQ больше 150, я правильно тебя понимаю? Если нет — то тогда к чему ты вообще это сказал?
VGn>но при этом над ними зачем-то выстраивается какая-то довольно жёсткая методология звязи реализации с требованиями,
"Зачем-то"? В самом деле — зачем нам привязывать реализацию к требованиям, нахрена нам трассировка требований нужна?
VGn>упускающая при этом другие стороны разработки
Какие "другие"? Список и обоснование в студию.
VGn> и ограничивающая свободу в управлении требованиями и собственно в разработке.
Обоснуй. Каким именно образом FDD ограничивает свободу в управлении требованиями. И собственно в разработке.
VGn>Т.е., по моему мнению, простановка акцентов здесь более вредит, чем приносит пользу.
Обоснуй.
Мнение можно иметь любое и на любую тему. Мне не интересно твое "мнение". Мне интересен твой анализ. Тут уже и так вся ветка заполнена переливанием из пустого в порожнее — предметно высказались всего несколько человек.
Здравствуйте, grosborn, Вы писали:
G>Всё, завязали. Мы с тобой видимо совершенно с разными продуктами работаем, разными людьми и в разных условиях. Я уже лет десять с железками не работаю.
Для справки:
1) С железками я работал 2.5 года. И уже как месяц работаю опять с софтом (телеком), не планируя возвращаться к железкам. До железок я работал с софтом лет 8. Так что не переживай, у меня основной background — это софт.
2) Сейчас я тебе говорю исключительно про программные проекты. Да и откуда тебе знать, как проекты по микроэлектронике от программирования отличаются, а?
Однако завязать я не против — это правильное решение, вы вряд ли чего нового про FDD добавите.
Здравствуйте, VGn, Вы писали:
G>>1) Продуктовая разработка. Группа разработки человек 20. Продукт уже написан, и продается. Его надо развивать и регулярно выпускать версии с исправлениями ошибок. При этом, есть небольшие фичреквесты и улучшения. Иногда затеваются рефакторинги и серьезные переделки подсистем. Иногда докручиваются новые фичи. Есть отдел тестеров, и кастомер саппорт. Отдельно — маректинг. Нужен единый процесс работы product development team в задачу которых входит выпуск релизов — как maintenance, так и general. Законченный процесс не требуется — нужен минимальный и простой процесс-шаблон, который сам по себе работоспособен, и при желании легко кастомизируется.
VGn>О! А в этом что-то есть. Как процесс доработки и поддержки, а не разработки или развития, когда практически все задачи и проблемы уже решены, FDD вполне может подойти.
VGn>Но процессом разработки я бы его называть не стал.
Слушай, может ты перестанешь называть его, и перейдешь к предметной критике его содержимого, а? Какая разница как ты его назвал бы или не назвал? Он от этого хуже или лучше станет?
VGn>>Декларируются принципы и подходы, которые в общем и ежу понятны, G>Ты предпочитаешь методологии, которые декларируют подходы и принципы, которые понять могут только люди с IQ больше 150, я правильно тебя понимаю? Если нет — то тогда к чему ты вообще это сказал?
Нет. Я имел в виду, что декларируются обычно более общие принципы, чем один человек — один класс и т.п.
VGn>>но при этом над ними зачем-то выстраивается какая-то довольно жёсткая методология звязи реализации с требованиями, G>"Зачем-то"? В самом деле — зачем нам привязывать реализацию к требованиям, нахрена нам трассировка требований нужна?
Я не имел в виду жёсткость связи. Я имел в виду жёсткость самой методологии привязки.
VGn>> и ограничивающая свободу в управлении требованиями и собственно в разработке. G>Обоснуй. Каким именно образом FDD ограничивает свободу в управлении требованиями. И собственно в разработке.
Фиксирование требований и выстраивание проектной группы на их основе — это уже довольно жёсткое ограничение управления. Примерно как блокирование руля на вроде бы прямой трассе.
VGn>>Т.е., по моему мнению, простановка акцентов здесь более вредит, чем приносит пользу. G>Обоснуй.
В принципе всё уже описал выше.
С точки зрения гибкой разработки — какой-то маразм просто. Хотя если всё время работать по ватерфолу — может в этом всём и видится что-то привлекательное.
Здравствуйте, VGn, Вы писали:
G>>Наличие управления требованиями является безусловно сильной стороной FDD. Особенно ее ориентированность на "фичи" — строить план от единиц независимого тестирования это очень правильно, такие планы очень легко понимать, и главное — легко перестраивать в динамике при изменении приоритетов и требований. Это вообще не секрет для последователей ватерфола. Заодно — фичлист является отличным звеном для трассировки от бизнес-необходимости к дизайну. По сути, если облегчать процесс управления требованиями, отрезая все что можно — то один фичлист и останется как самый необходимый документ. Очень правильно сделано, просто блестяще.
VGn>Я бы не назвал это управлением требованиями. Это идентификация требований, но никак не управление.
Я бы тоже не назвал фичлист управлением требованиями. Потому что фичлист — это документ, артефакт, а не процесс. А управление требованиями при облегченном процессе в голове происходит, понимаешь? Пост заглавный перечитай пожалуйста внимательно. И посмотри, что я пишу про облегченный процесс.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, shrecher, Вы писали:
G>>>Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
S>>Это как раз о процессах. Если кадры соответвуют поставленной задаче, то никакой процесс им не помеха. Точнее так, какой процесс им ненавижи, они все равно будут делать как им удобнее. А для неподходящих кадров, любой процесс самый модерновый процесс как мертвому припарка.
G>Блин, ну просто кто во что горазд. По теме есть что сказать? Конкретные проблемы в подходе FDD найти можете, которые будут мешать разработке?
Я те про Фому, ты мне про Ерему: не имеет значение какой процесс навязать людям. Результат будет не зависеть от выбранного процесса, а только от качества людей и разных внешних факторов (к примеру удовлетворенность зарплатой).
Здравствуйте, VGn, Вы писали:
M>>>предметной области, не подверженной частым изменениям; G>>Фичлист — это ключевое. Это проверенный ватерфольный способ управлять этими изменениями сохраняя ватерфольный контроль и прозрачность. И все лишнее отрезано — но может быть добавлено при необходимости обратно. Очень хорошо.
VGn>Это как? Управление изменениями через их отрицание?
Позволь мне поинтересоваться, как ты управляешь изменениями, и что ты под этим понимаешь. Не через их отрицание.
Вообще — ты не мог бы более развернуто писать, по нормальному? Эти короткие бессмысленные фразы вызывают в основном желание только послать в жопу. Если это то, чего ты добиваешься — то конечно продолжай.
Здравствуйте, VGn, Вы писали:
M>>>и стабильной команде с низкой текучкой. G>>Вы забыли про обязательные design и code review. Это единственно работающий на практике механизм рапространения знаний, помимо того что он увеличивает качество софта и дает лучший контроль над процессом. В скраме у вас есть пустые декларации — здесь — вместо них имеем проверенный и эффективный механизм реального распространения знаний, который при необходимости может быть легко отмасштабирован заменой review на полномасштабные inspections Фагана. VGn>-1 VGn>В design и code review участвуют разработчики того же уровня? разработчики более низких уровней? Не особо себе это представляю.
1) Основная цель review — поиск ошибок. Делай выводы, какого уровня в review учавствуют разработчики. Для важных кусков должен быть как минимум один такого же уровня или выше. Для особо критичных — консилиум собирают.
2) Если не представляешь — почему сразу пишешь "-1"?
VGn>По поводу единственно работающего ты имхо погорячился.
Возражаешь — так возражай нормально, называй другие способы, объясни почему и как они работают. Мне из тебя клещами блин тянуть каждое слово надо?
VGn>>упускающая при этом другие стороны разработки G>Какие "другие"? Список и обоснование в студию.
Давай абстрагируемся от твоего железячного подхода и на минутку примем, что требования могут изменяться
Ну так бывает. Может не у тебя, но в 90% проектов — точно.
Имеем:
Риски расширения требований. — придётся менять команду?
А если расширение требований потребует изменение части архитектуры?
Риски исчезновения требований или просто временное снятие фич.
Где FDD вообще что говорится о тестировании во время разработки?
Итеративность вообще практически на нуле. Даже инкрементность не проглядывается. Только для показухи и контроля дефектов.
Зато чтоб манагер не скучал, ему добавилась куча контрольных инструментов. Но что он сможет делать по результатам своих оценок?
За меня не надо беспокоится — у меня-то данных достаточно и я не ошибусь. Так что советов мне давать не надо и моральной ответственности за них вы тоже нести не будете — все проще. Пока я хочу в рамках дискуссии идентифицировать слабые места FDD — чтобы быть уверенным, что ничего не пропустил. И все. Так я сэкономлю массу времени — в одиночку буду разбираться дольше.
Ну да ладно, попробую разобраться в FDD. Поехали. Попробую применить его к своему environment.
