Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, B0rG, Вы писали:
G>Дискуссия — это когда отвечают на посты друг друга. Вы — монологируете, не слушая меня. Вы удаляете весь мой пост, и ведете беседу сам с собой. Borg, я не просил вас рассказывать мне прописных истин. Мне совершенно не интересно выслушивать отвлеченные философские рассуждения базового уровня. И меня раздражает, когда в ответ на конкретные просьбы меня начинают учить жизни в духе урока для умственно отсталых детей. Сказать больше нечего чтоли? Неужели не можете косяков в процессах FDD найти? Все, философская дискуссия закрыта, уважаемый коллега. Я вам отвечать ничего не буду, монологируйте дальше.
По некоторым причинам я не использую "фидошный" квотинг. На мой взгляд, придирки к каждому предложению уводят дискуссию от темы, и она перерастает в перепалку вида "ты меня дураком обозвал", "ты черезчур утрируешь", "много воды" и т.д. Впрочем, оставим это. Если вас обижает, что я черезчур утрирую, то извините, этого я не хотел.
Я всего лишь устанавливал рамки для обсуждения. В той самой статье она и описана:
Область применения:
FDD was initially devised by Jeff De Luca to meet the specific needs of a 15 month, 50 person software development project at a large Singapore bank in 1997. Jeff De Luca delivered a set of five processes that covered the development of an overall model and the listing, planning, design and building of features.
Экосистема: Bank. Сингапур (азиаты как нация склонны к иерархиям).
Если уж хотите обсуждать методологию, то давайте ограничим поле обсуждения — поиграем в бизнес игру с заданными правилами: установим размер проекта, численность группы и ее состав, суммарный бюджет (или просто допустимые отклонения от бюджета), сволочизм заказчика. И на основе этих условий будем разбирать степень применимости той или иной методологии. В том числе и FDD.
Без таких установок, я сейчас наблюдаю примерно следующее:
Gaperton: это лучше чем Agile
Хор1: вы не умеете его готовить
Хор2: хуже чем Agile быть просто не может.
Я на вскидку могу сказать примерно следующее: роли (об этом уже говорили), и их психологический фактор. Иерархия подозрительная — за все отвечает Chief Developer. Где BA? Где Арки? Какой-то странный процесс feature approval? Кто feature owner? Ну и т.д.
К тому же задача поставлена несколько не корректно "найти дыры в методологии". Как можно найти дыры в методологии разработки софта, что известна только по книге ее евангелиста. Вы работали под FDD? Вот и я тоже не работал.
Вы когда-нибудь читали книгу о методологии софта, где бы автор писал — на этом проекте мы попробовали мою новую и замечательную методологию разработки софта, и пришли к единодушному мнению "она — не работает"? Я о чем: евангелизм в методологиях это немного другая бизнес модель. У нас с вами бизнес модель "делать софт — получать деньги". У ем (евангелистов методологий) бизнес модель "учить других делать софт — получать деньги".
Как я вас понимаю вы хотите попробовать установить свой процесс, и хотите понять из этой дискуссии подойдет ли FDD. А для этого недостаточно исходных данных.
G>>>А что такое Agile? Я этого не понимаю. Что такое FDD, Scrum, и XP — понять могу. А раз я не понимаю что такое Agile — то мне кажется странным утверждение, почему никому не придет в голову разрабатывать ОС на Agile.
S>>Вто то и дело что не понимаете.
G>Прошу вас воздержиться от подобных замечаний. Не надо меня злить.
G>Это не объяснение, это хорошая сказка на ночь. Аналогия довольно наивна, и, наверное хорошо действует на людей, плохо разбирающихся в процессах разработки софта. Вероятно — именно так и впаривают agile.
S>>Если говорить о ядре Linux, то сейчас он разрабатывается по методологии Open Source.
G>Надо же, кто бы мог подумать? А я-то думал они работают по Closed Sourcе.
Вы никогда не задумывались, что если люди разбросанные по всему миру умудряются умудряются создавать достаточно успешный софт, это означает, что эти люди смогли наработать определенный опыт и приемы, помогающие им в этом нелегком деле. Именно это и называется Open Source Projects. Ваша ирония свидетельствует лишь о вашей некомпетентности в данной области.
G>ЗЫ: сколько умных слов не по теме — кошмар, но почему-то никто не в состоянии ничего предметно сказать про FDD, и прочитав его описание. Интересно — я вообще в профильную конфу "управление пректами" написал — или случайно попал в "священные войны"?
Здравствуйте, Gaperton, Вы писали:
G>Короче — fdd лишен косяков скрама и хр. Ну а утяжелить его всегда можно, при желании. Но благодаря легкости — его легко внедрять и поддерживать. Что скажут Отцы? Читайте википедию, пишите, оппонируйте.
Можно я попробую?
Поскольку FDD родом из водопада, ей грозят типичные водопадные проблемы.
1. Я вижу склонность к затягиванию итераций. Прежде чем мы сможем выкатить заказчику релиз, должны пройти фазы сбора требований, проектирования, планирования, разработки и тестирования. FDD не предлагает инструментов для сокращения продолжительности итерации. Это означает, что когда заказчик (или рынок) потребует решения прямо сейчас либо он не получит ничего, либо весь FDD пойдет прахом.
2. Индивидуальное владение кодом, это замечательная идея, но она приводит к тому, что код становится сильно зависим от разработчиков. Это усложняет взаимозаменяемость, увеличивает риски срыва сроков из-за ухода разработчиков, усложняет планирование и приводит к неравномерному качеству кода отдельных частей проекта. Если качество кода еще можно привести к приемлемому уровню посредством инспекций, то что делать с остальными последствиями FDD не говорит.
3. FDD выглядит уязвимым для изменения требований на поздних стадиях проекта. От того что мы назвали требования фичами, а фазу анализа разработкой общей модели риск неполного анализа не уменьшится. FDD не предлагает никаких инструментов для верификации модели предметной области. Поэтому FDD сильно чувствителен к качеству аналитиков, осуществляющих сбор требований и анализ предметной области.
Исходя из этого, FDD выглядит приемлемым только:
при наличии аналитиков, детально знающих предметную область;
предметной области, не подверженной частым изменениям;
и стабильной команде с низкой текучкой.
Здравствуйте, B0rG, Вы писали:
BG>Область применения: BG>
FDD was initially devised by Jeff De Luca to meet the specific needs of a 15 month, 50 person software development project at a large Singapore bank in 1997. Jeff De Luca delivered a set of five processes that covered the development of an overall model and the listing, planning, design and building of features.
BG>Экосистема: Bank. Сингапур (азиаты как нация склонны к иерархиям).
Да, я это прочитал. 15 месяцев и 50 персон — это довольно большой проект.
BG>Если уж хотите обсуждать методологию, то давайте ограничим поле обсуждения — поиграем в бизнес игру с заданными правилами: установим размер проекта, численность группы и ее состав, суммарный бюджет (или просто допустимые отклонения от бюджета), сволочизм заказчика. И на основе этих условий будем разбирать степень применимости той или иной методологии. В том числе и FDD.
Принято. Отличный подход. Ситуации:
1) Продуктовая разработка. Группа разработки человек 20. Продукт уже написан, и продается. Его надо развивать и регулярно выпускать версии с исправлениями ошибок. При этом, есть небольшие фичреквесты и улучшения. Иногда затеваются рефакторинги и серьезные переделки подсистем. Иногда докручиваются новые фичи. Есть отдел тестеров, и кастомер саппорт. Отдельно — маректинг. Нужен единый процесс работы product development team в задачу которых входит выпуск релизов — как maintenance, так и general. Законченный процесс не требуется — нужен минимальный и простой процесс-шаблон, который сам по себе работоспособен, и при желании легко кастомизируется. Продукт может быть не один — у компании есть продуктовая линейка.
2) Продуктовая разработка. Компания стартует разработку нового перспективного продукта. Продукт имеет длительное время жизни, естественно, и его разработка должна плавно перейти в поддержку. В распоряжении компании до 20 человек, которые она постепенно может перекинуть на новую разработку — начинает с небольшой группы. Ситуация та же. Процесс должен быть минимально работоспособным шаблоном для департамента product development, не всеобъемлющим, но при этом работоспособным good enough. Процессу весьма желательно обрабатывать кейсы 1 и 2 единообразно.
3) Заказная разработка. Разумеется — fixed cost. Длительность проектов — от 3 месяцев до года. Размер команд — скажем, от 3 до 10 человек.
BG>Я на вскидку могу сказать примерно следующее: роли (об этом уже говорили), и их психологический фактор. Иерархия подозрительная — за все отвечает Chief Developer. Где BA? Где Арки? Какой-то странный процесс feature approval? Кто feature owner? Ну и т.д.
Посмотрю подробнее что с этим и лечится ли, пока не обращал внимания.
BG>К тому же задача поставлена несколько не корректно "найти дыры в методологии". Как можно найти дыры в методологии разработки софта, что известна только по книге ее евангелиста. Вы работали под FDD? Вот и я тоже не работал.
Мне при беглом взгляде она понравилась. Хочу копнуть подробнее. Насчет поиска дыр — в скраме и хр их несложно определить анализом процесса. Они уже детально препарировались здесь на форуме, в том числе и мной. Вообще — процессы поддаются и умозрительному анализу, при некотором опыте разработки.
BG>Вы когда-нибудь читали книгу о методологии софта, где бы автор писал — на этом проекте мы попробовали мою новую и замечательную методологию разработки софта, и пришли к единодушному мнению "она — не работает"? Я о чем: евангелизм в методологиях это немного другая бизнес модель. У нас с вами бизнес модель "делать софт — получать деньги". У ем (евангелистов методологий) бизнес модель "учить других делать софт — получать деньги".
Скажу вам о пользе методологий. Если я подберу удобный шаблон в качестве известной методологии, у меня будет меньше проблем с обучением персонала. Так проще, чем собирать процесс на ровном месте в одиночку. Устал я это делать. А отдельные косяки этого шаблона я исправлю — главное чтобы он не был убитым изначально, как scrum например. Сложные штуки вроде RUP в качестве шаблона для практичного менеджера не подходят — я вовсе не хочу убить остаток жизни на разбирательство в дебрях RUP.
Я бы сделал и свой шаблон, наверное, но на это почему-то нет времени — работать надо.
BG>Как я вас понимаю вы хотите попробовать установить свой процесс, и хотите понять из этой дискуссии подойдет ли FDD. А для этого недостаточно исходных данных.
Я никогда не внедряю методологий, и готовых процессов. Сейчас я оцениваю — получится ли у меня залатав несколько дыр в FDD взять его за основу, и много ли я на этом сэкономлю по сравнению с тем, чтобы собирать свой процесс из более мелких элементов, как я обычно делаю. Сейчас я в положении, когда мне надо на неорганизованной команде с существующим продуктом ставить разработку с нуля. И я надеюсь, что мне бы помогло что-то очень простое и примитивное для быстрого старта, чтобы потом его оптимизировать и кастомизировать. Причем — хорошо бы чтобы учебные материалы и process scripts уже существовали хоть в каком-то виде, а то уж больно геморройно их рисовать с нуля. Я устал это делать.
За меня не надо беспокоится — у меня-то данных достаточно и я не ошибусь. Так что советов мне давать не надо и моральной ответственности за них вы тоже нести не будете — все проще. Пока я хочу в рамках дискуссии идентифицировать слабые места FDD — чтобы быть уверенным, что ничего не пропустил. И все. Так я сэкономлю массу времени — в одиночку буду разбираться дольше.
Здравствуйте, stump, Вы писали:
G>>ЗЫ: сколько умных слов не по теме — кошмар, но почему-то никто не в состоянии ничего предметно сказать про FDD, и прочитав его описание. Интересно — я вообще в профильную конфу "управление пректами" написал — или случайно попал в "священные войны"?
S>Я так понимаю, что по делу вам возразить нечего.
Вы для начала по делу хоть что-нибудь скажите, ладно? Эта тема — о FDD. А глубокий смысл брэнда "agile" на уровне детсадовских аналогий разъясняйте пожалуйста кому-нибудь другому.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Gaperton, Вы писали:
G>>Короче — fdd лишен косяков скрама и хр. Ну а утяжелить его всегда можно, при желании. Но благодаря легкости — его легко внедрять и поддерживать. Что скажут Отцы? Читайте википедию, пишите, оппонируйте.
M>Можно я попробую?
Нужно.
M>Поскольку FDD родом из водопада, ей грозят типичные водопадные проблемы.
Да, это ватерфол! Я сразу узнал за FDD старый добрый вотерфол, поэтому мне FDD так и глянулся . Потому что это потрясающе "легкий" и изящный вотерфол, в котором при этом не упущено ничего существенного. Сразу видно — над ним работал практик.
M>1. Я вижу склонность к затягиванию итераций. Прежде чем мы сможем выкатить заказчику релиз, должны пройти фазы сбора требований, проектирования, планирования, разработки и тестирования. FDD не предлагает инструментов для сокращения продолжительности итерации. Это означает, что когда заказчик (или рынок) потребует решения прямо сейчас либо он не получит ничего, либо весь FDD пойдет прахом.
Гхм, с этим я, имея богатую практику применения вотерфола, как-нибудь разберусь.
M>2. Индивидуальное владение кодом, это замечательная идея, но она приводит к тому, что код становится сильно зависим от разработчиков. Это усложняет взаимозаменяемость, увеличивает риски срыва сроков из-за ухода разработчиков, усложняет планирование и приводит к неравномерному качеству кода отдельных частей проекта. Если качество кода еще можно привести к приемлемому уровню посредством инспекций, то что делать с остальными последствиями FDD не говорит.
Я с удовольствием отметил это как плюс — автор FDD определенно имел опыт работы с legacy code и долгоживущими эволюционирующими продуктами. Это необходимая мера при работе с существующей базой кода, чтобы он не превратился в помойку. "Зоны ответственности" — это очень правильно. Можно это немного твикнуть, и назначить "смотрящих" за кодом только из ведущих спецов — это будет аналог архитекторов. Соответственно, при пересечении "зоны ответственности" эти люди обязаны учавствовать в design review. Очень хорошая и эффективная практика.
M>3. FDD выглядит уязвимым для изменения требований на поздних стадиях проекта. От того что мы назвали требования фичами, а фазу анализа разработкой общей модели риск неполного анализа не уменьшится. FDD не предлагает никаких инструментов для верификации модели предметной области. Поэтому FDD сильно чувствителен к качеству аналитиков, осуществляющих сбор требований и анализ предметной области.
Наличие управления требованиями является безусловно сильной стороной FDD. Особенно ее ориентированность на "фичи" — строить план от единиц независимого тестирования это очень правильно, такие планы очень легко понимать, и главное — легко перестраивать в динамике при изменении приоритетов и требований. Это вообще не секрет для последователей ватерфола. Заодно — фичлист является отличным звеном для трассировки от бизнес-необходимости к дизайну. По сути, если облегчать процесс управления требованиями, отрезая все что можно — то один фичлист и останется как самый необходимый документ. Очень правильно сделано, просто блестяще.
Точность модели обеспечивается участием представителем заказчика при моделировании — он проверяет модель по ходу. Это допустимо, удобно и практично, ускоряет процесс и как ни странно повышает качество результата — при передаче требований через документ происходит больше потерь либо документ раздувается и получается еще хуже. Можно усилить этот момент review экспертом в предметной области, юзабилистом — кем угодно, при необходимости, процесс не запрещает, а если этого не требуется — то и не надо и так будет good enough. А на практике в реальных условиях — будет гораздо лучше.
M>Исходя из этого, FDD выглядит приемлемым только: M>при наличии аналитиков, детально знающих предметную область;
Представитель заказчика включен в проектную группу на первом этапе. Аналитик как промежуточное звено устраняется. Грамотно. Не всегда стработает, конечно, но в тяжелых случаях можно добавить и аналитика. Как стартовая заготовка — очень хорошо на мой взгляд.
M>предметной области, не подверженной частым изменениям;
Фичлист — это ключевое. Это проверенный ватерфольный способ управлять этими изменениями сохраняя ватерфольный контроль и прозрачность. И все лишнее отрезано — но может быть добавлено при необходимости обратно. Очень хорошо.
M>и стабильной команде с низкой текучкой.
Вы забыли про обязательные design и code review. Это единственно работающий на практике механизм рапространения знаний, помимо того что он увеличивает качество софта и дает лучший контроль над процессом. В скраме у вас есть пустые декларации — здесь — вместо них имеем проверенный и эффективный механизм реального распространения знаний, который при необходимости может быть легко отмасштабирован заменой review на полномасштабные inspections Фагана.
Отличный процесс. Чем дальше — тем больше мне нравится FDD.
Здравствуйте, Gaperton, Вы писали:
G>Принято. Отличный подход. Ситуации:
нужно кое-что уточнить:
Если это та контора, что у вас в жж, то к списку факторов еще можно добавить достаточную сложность разработки. Это накладывает определенные ограничения на сложность процесса. Вы сами сказали: процесс должен быть простой. Я бы добавил, если процесс занимает больше листа А4 — инженеры наверняка будут его саботировать.
Другой вопрос как и в любом процессе: зачем? А именно проблемы, которые мы пытаемся решить этим процессом. Они бывают разные: начальство вмешивается в ход разработки напрямую, сейлы вмешиваются в ход разработки через политические игры, все в конторе имеют странную идею "мы тестируем за 2 часа до деплоймента, и все баги магическим образом пофиксены". На мой взгляд процесс все таки вторичен — он должен решать какие-то достаточно определенные проблемы.
Так же стоит уточнить примерный состав команд: что-то вроде 20 чел = 2 кул хацкера (очень кул, но не юзер френдли) + 5 обязательных сеньоров, с некоторыми пробелами в estimation skills + один билд инженер + и 11 джуниоров (5 из них хотят быть сеньорами, 6 просто ходят на работу).
BG>Если это та контора, что у вас в жж, то к списку факторов еще можно добавить достаточную сложность разработки.
Управление проектами не оперирует такими понятиями как "сложность разработки" и такими мерами как "достаточная". Оно оперирует понятиями рисков и трудозатрат, а также точными качественными и количественными характеристиками. Не надо ничего добавлять, ладно?
BG>Это накладывает определенные ограничения на сложность процесса. Вы сами сказали: процесс должен быть простой. Я бы добавил, если процесс занимает больше листа А4 — инженеры наверняка будут его саботировать.
Это не накладывает никаких ограничений на сложность процесса. На лист а4 не уложится даже описание простейшего процесса прохождения дефекта. Будут или не будут процесс саботировать — вопрос внедрения. А не размера процесса.
Короче, не надо ничего добавлять, спасибо, мне все понятно.
BG>Другой вопрос как и в любом процессе: зачем? А именно проблемы, которые мы пытаемся решить этим процессом. Они бывают разные: начальство вмешивается в ход разработки напрямую, сейлы вмешиваются в ход разработки через политические игры, все в конторе имеют странную идею "мы тестируем за 2 часа до деплоймента, и все баги магическим образом пофиксены". На мой взгляд процесс все таки вторичен — он должен решать какие-то достаточно определенные проблемы.
Никто никуда не вмешивается, никто не имеет странных идей, все все сделают как вы скажете. Хорошо? Процессы разработки всегда решают проблемы разработки, а не перечисленные вами проблемы. Если сказать упрощенно — сделать то что нужно, с заданным качеством, и в срок. Неожиданно, не так ли?
BG>Так же стоит уточнить примерный состав команд: что-то вроде 20 чел = 2 кул хацкера (очень кул, но не юзер френдли) + 5 обязательных сеньоров, с некоторыми пробелами в estimation skills + один билд инженер + и 11 джуниоров (5 из них хотят быть сеньорами, 6 просто ходят на работу).
Представьте что все 20чел у вас одинакового среднего уровня. Ну что, дождусь я от вас хоть чего нибудь? Или вам для анализа сильных и слабых сторон fdd надо еще выяснить психополовой портрет нашего директора, и цвет волос нашей секретарши?
Пока посмотрел на FDD крайне поверхностно.
Что смущает:
1. Использование в качестве единиц проектирования и владения отдельных классов. По моему опыту правильнее в качестве базовой единицы использовать домен (или его часть) или внутренний модуль (т.е. группу классов/методов, зачастую довольно большую, но с небольшим внешним интерфейсом). За интерфейсы между — отвечает CP.
2. Не совсем понятно, как ведется управление релизами и распределение features и текущих деятельностей между релизами. Хотя и понятно, куда это вставить. (Я не верю, что при наличии процесса поддержки и процесса развития всегда вся группа работает с одним релизом. Скорее с тремя-четырьмя одновременно).
3. В описании на Wikipedia я вообще не увидел процессов тестирования релиза целиком. И процессов подготовки и выкладки. А это, в общем, часть процесса. И не увидел описания "закрытия" итерации.
4. Нет шага принятия решения о рефакторинге. А при подобной схеме очень быстро накапливаются мелкие грабли и заплатки в коде. Вообще, хочется видеть где-то после Refine Object Model шаг анализа увеличения сложности с принятием решения о упрощении реализации ранее сделанных features.
5. Ну, всякая фигня про контроль версий и расшаренные папки, конечно, устарела. Confluence все заменит.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Пока посмотрел на FDD крайне поверхностно. ДФ>Что смущает: ДФ>1. Использование в качестве единиц проектирования и владения отдельных классов. По моему опыту правильнее в качестве базовой единицы использовать домен (или его часть) или внутренний модуль (т.е. группу классов/методов, зачастую довольно большую, но с небольшим внешним интерфейсом). За интерфейсы между — отвечает CP.
+1. Это однозначно надо исправлять. Если назначать владельцев крупных подсистем, и вводить правило приглашать их на design review — то станет гораздо лучше. У нас фактически появятся архитекторы. И чем крупнее подсистемы — тем с этой точки зрения лучше. Теоретически — для больших систем владельцев можно объединять в деревья . Шутка. В которой есть доля шутки.
ДФ>2. Не совсем понятно, как ведется управление релизами и распределение features и текущих деятельностей между релизами. Хотя и понятно, куда это вставить. (Я не верю, что при наличии процесса поддержки и процесса развития всегда вся группа работает с одним релизом. Скорее с тремя-четырьмя одновременно).
Все просто — каждая фича приписана определенному релизу. Процесс корректировки targed fix version для фич — привязать к периодическому (еженедельному) контролю продвижения по графику. Если такого нет — добавить. Или я чего-то не понял, и там это куда-то в другое место вставляется?
ДФ>3. В описании на Wikipedia я вообще не увидел процессов тестирования релиза целиком. И процессов подготовки и выкладки. А это, в общем, часть процесса. И не увидел описания "закрытия" итерации.
В книге это вроде как есть. Они там даже про разработку документации пишут. Придется, блин, покупать.
ДФ>4. Нет шага принятия решения о рефакторинге. А при подобной схеме очень быстро накапливаются мелкие грабли и заплатки в коде. Вообще, хочется видеть где-то после Refine Object Model шаг анализа увеличения сложности с принятием решения о упрощении реализации ранее сделанных features.
Очень быстро как раз накопиться не должна. Здесь есть design review — если на них приглашать owner-ов соседних подсистем (см пункт 1) — они не дадут накосячить и лажу не пропустят, фактически играя роль архитекторов (не надо тока кого попало владельцами подсистем назначать). А решения о рефакторинге можно принимать ad-hoc — их принимать должны владельцы подсистем.
ДФ>5. Ну, всякая фигня про контроль версий и расшаренные папки, конечно, устарела. Confluence все заменит.
Confluence это круто, факт. Плюс JIRA.
> Вы сказали — несистематична, не самодостаточно, не сбалансирована. Раскройте тему пожалуйста. Почему так? Аргументы плиз. Интересны не общие суждения, а конкретные указания на конкретные косяки. Были бы интересны суждения — я б опрос зарядил, а не дискуссию.
Мне не нравится схема, в которой agile сочетается с параллельной несвязанной друг с другом реализацией множества недофич (там так и написано). Решение этой проблемы в описании процесса я не увидел.
Тут нужно или всё сразу, но не тестировать ранние релизы на потребителях, или ... я не совсем понял там код, люди, фичи всё по доменам раскидано? Расширять доменный состав по мере законченности предыдущих это уже не получится...
И такое деление перпендикулярно матрице квалификаций. Может быть вы работаете с универсальными солдатами или инженерами — типа "сегодня ты вот эту фичу, завтра вот эту, а послезавтра я тебе зарплату прибавлю и будешь у меня тим-лидером вот туда".
Но я вот таких универсальных практически и не вижу.
Здравствуйте, grosborn, Вы писали:
>> Вы сказали — несистематична, не самодостаточно, не сбалансирована. Раскройте тему пожалуйста. Почему так? Аргументы плиз. Интересны не общие суждения, а конкретные указания на конкретные косяки. Были бы интересны суждения — я б опрос зарядил, а не дискуссию.
G>Мне не нравится схема, в которой agile сочетается с параллельной несвязанной друг с другом реализацией множества недофич (там так и написано). Решение этой проблемы в описании процесса я не увидел.
Давайте не будем употреблять слова agile. От греха. Ничего кроме путаницы оно не привнесет. "Мы, следователи, должны говорить конкретно — существительными и глаголами: он пришел, она сказала." (Мюллер, 17 мгновений весны).
Если вы посмотрите на реальный процесс выпуска релизов уже существующего продукта — любого, вы именно это и увидите. Множество относительно простых фич, слабо связанных между собой. В релизе надо исправить сотню разных дефектов, реализовать пару десятков относительно мелких suggestions и improvements (это в сумме может составлять весьма значительную часть работы — процентов 80), иногда — затевают относительно продолжительные и крупные проекты связанные с переписываниями, дописываниями, и рефакторингами. То есть — проблема в принципе налицо — любая продуктовая компания сталкивается с проблемой maintenance и развития продукта. Надо что-то делать.
Самое простое решение — тупо разделить группы maintenance и "перспективной разработки". На бумаге это получается, на практике — нет, потому что дефекты имеют обыкновение все равно попадать к тому, кто их лучше диагностирует и лучше знает систему. А также потому, что исправление дефектов и реализация фич иногда требует хирургического рефакторинга и тонкой инженерной работы, подчас — продолжительной и объемной. Если однако настоять на этом разделении — то будет еще хуже, потому что программеры из группы maintenance разбегутся. И ухудшится качество основного продукта, который продается и приносит деньги. Короче — проигрышная это стратегия, плюс в ней ровно один — проще планировать загрузку ресурсов, остальное — минусы. Плюс — плохой. Вашим клиентам неважно, насколько вам легко планировать загрузку ресурсов.
Короче говоря, я вижу прямую и очень значительную выгоду в том, чтобы не разделять группы maintenance и перспективной разработки. Но если я сделаю так, то я столкнусь с другой проблемой. Из-за хаотичности процесса maintenance, мне будет крайне тяжело планировать перспективную разработку, потому что ей заняты те же люди. То есть делать это конечно можно, но на порядок лучше и удобнее обрабатывать maintenance и разработку единым процессом, делая исключения только для совсем крупных, новых, и независимых подсистем. То есть, в частности, все задачи должны проходить в одной тулзе с дефектами — в issue tracker. Те кто этого не понимают — обыкновенно имеют непредсказуемые сдвиги сроков разработки, потому, что ресурсное планирование выполнить очень тяжело.
Этот процесс, который основан на правилах управления выпуском maintenance releases, я называл в своих постах "цикл maintenance", имея в виду процесс поддержки и развития продукта, принятый дефакто во многих продуктовых компаниях. Он в литературе особо не описан, но у всех почти одинаков. Так вот — FDD исходит из той же посылки. Это есть совершенно невозможное — удачный гибрид вотерфола — дитем порядка, с дитем хаоса — "циклом maintenance". Он обладает свойствами и того, и другого. И может быть кастомизирован в любую сторону.
А теперь конкретно. Итак, фичи/дефекты независимы, и их много. Это, натурально, приводит к "расползанию" кода, с чем можно и нужно бороться. Потому что реализация "параллельная" и фичи несвязанны. Так вот, в FDD предусмотрен достаточный набор необходимых мер борьбы с этим — очень похож на тот, что применялся когда-то у нас в CQG без всякого FDD . Да я думаю многие компании самостоятельно пришли к тому же. Что именно:
1) Code ownership. "Зоны ответственности". В описанных мной условиях, архитектор — это инженер, отвечающий за порядок и дизайн в некоторой подсистеме. Реализация фичи может затрагивать несколько подсистем. Любое изменение дизайна подсистемы — и "владелец" подсистемы обязан подтвердить его на
2) Design review. И не пропустить плохой дизайн. Если предполагается, что изменения будут значительны — владелец подсистемы включается в фичгруппу.
3) Code review.
Таким образом, у нас получается как бы матрица — с одной стороны есть "владельцы" кода, с другой — фичи, и группы фичей, перпендикуларно структуре кода.
G>Тут нужно или всё сразу, но не тестировать ранние релизы на потребителях, или ... я не совсем понял там код, люди, фичи всё по доменам раскидано? Расширять доменный состав по мере законченности предыдущих это уже не получится...
Люка не склонен тестировать ранние релизы на потребителях и морщится при таком вопросе (узнаю реакцию ватерфольщика, правильно — на потребителях нормальные люди тестируют бета-версии и релиз-кандидаты, а для ранних релизов есть тестеры), хотя говорит что при большом желании это сделать можно . По доменам раскиданы только фичи — код не обязан им соответствовать. Людей можно приписать к доменам — получится матрица прикладной компетенции. Группы можно собирать по любому принципу, я думаю. Расширять доменный состав разумеется можно.
Например, если потребуется выделить группу разработки "ядра" системы, которая пользовательские фичи не делает, то делаем так. Внимание. Добавляем новый домен — "Ядро". После чего пускаем работу тем же процессом, только "заказчиком" у нас будут другие программисты из прикладных групп.
G>И такое деление перпендикулярно матрице квалификаций. Может быть вы работаете с универсальными солдатами или инженерами — типа "сегодня ты вот эту фичу, завтра вот эту, а послезавтра я тебе зарплату прибавлю и будешь у меня тим-лидером вот туда". G>Но я вот таких универсальных практически и не вижу.
Есть две матрицы квалификаций — в предметной области, и в коде (отражается владением), которые не обязательно совпадают. Разумеется, так как вы пишете делать низя. Разумно побить людей на группы, соответствующие, например, крупным секторам по предметным областям. Это упрощает маршрутизацию фич на верхнем уровне. А тимлидеры этих групп сделают назначение правильно, зная в деталях кто на что способен. Знаете — именно так многие и работают, это естественно.
Ой! Минусик! Я так и думал, что ничего вы про FDD не скажете — смотрите-ка, угадал .
Большое спасибо за ваш ответ, вы мне очень помогли. Вы сделали 5 постов, умудрившись не сказать ни одного слова про FDD — ни достоинств, ни недостатков, зато рассказали мне много познавательных вещей, например, что если описание методологии будет больше чем лист А4 то ее внедрение обязательно будут саботировать.
С вами, BoRG, сразу все понятно было, вообще-то. Не можете ничего сказать — ну бывает что нечего вам по теме — ну промолчите вы, ну кто за язык тянет, а? Да ладно б просто — так что меня изумляет, вы еще при этом "жизни" меня учить пытаетесь . Вас кто-то просил? Короче все. Всего доброго, большое спасибо, до следующих встреч. Слава богу, появились ответы по существу.
Здравствуйте, A.Lokotkov, Вы писали:
G>>Я не делал проектов с agile. Все success stories только с waterfall.
AL>Давно хотел спросить, но стеснялся. Можно хотя бы одну success story? Например, с предыдущего места работы. Спасибо.
Можно. IP-блок видеоконтроллера, формирующего ТВ сигнал высокой и стандартной четкости. Слой для видео, слой для меню с аппаратным наложением через альфу. Аппаратное масштабирование изображения основного слоя с независимыми коэффициентами по вертикали и горизонтали, с уменьшением/увеличением до 3 раз без видимой потери качества. Что еще? Ну там всякие хитрые режимы работы в слое меню.
Предназначен для применения в микросхемах класса "система-на-кристалле" с шинной иерархией AMBA 3.0. На момент начала разработки (лето прошлого года) таких блоком было на рынке по пальцам одной руки, стоимость лицензий — от 300К USD на один чип. Наш контроллер соответствует лучшим образцам такого IP, немного победнее в функциональности чем ближайшие аналоги, зато существенно превосходит их по качеству и возможностям масштабирования изображения и заметно меньше по занимаемой площади.
В проекте занято 6-7 человек, проект имеет продолжительность 9 месяцев, проект имеет общий вылет за график не превышающий двух недель. Работы ведутся в три этапа. Архитектурный (завершается выверенной документацией и программными моделями — цель этого этапа — запараллелить работу на следующий этап), разработка (завершается интегированной моделью на Verilog, которая умеет делать корректно единственный сценарий), ну и типа "отладка" (результат — блок работающий во всех заявленных режимах и соответствующий ТЗ). ПЛИС прототипирование и ASIC-синтез не предполагается — за это жадный заказчик не заплатил.
На втором этапе мы заказчика удивили. Когда он жалобно поинтересовался, работает ли там хоть что-нибудь (я специально настоял, чтоб в ТЗ было записано, что мы не обязаны ничего рабочего давать на втором этапе — страховался), мы ему небрежно так говорим: да, эта штука уже показывает видео в стандартном разрешении. Тот изумился. А как это может быть, у вас же ничего кроме Verilog нет? Хм, сказали мы, и загадочно улыбнулись. Наша технология тестирования, сказали мы, позволяет и не такое.
Как было на самом деле: аппаратчики тупо сбрасывают выходы блока BT-656 в лог-файл. После чего, Миша Потанин пишет на перле тулзу которая читает этот файл и преобразует его в картинки tga. Полдня он кажется на это потратил. Да, это не все. Еще мы сделали преобразователь из картинки tga в модель памяти, которую можно подцепить при моделировании Verilog. Ну, пришлось естественно сделать простой AXI Slave — но это мелочи. Короче, сделано это очень просто, и экономит массу времени. И у нас все так устроено в процессе тестирования. Стратегия тестирования разрабатывалась на первом этапе, и отдельно проверялось, что мы ей закрываем все типы дефектов. Стратегия определяет виды тестов и общие процедуры. После чего пишется перечень тестов, и доказывается, что мы накрываем все сценарии при всех разумных сочетаниях режимов. В процессе измеряется code coverage. В состав команды на полное время включен программист — выполняет роль архитектора, проверяет программный интерфейс — он как бы "представитель пользователей", прототипирует, и пишет тулзы тестирования.
> Давайте не будем употреблять слова agile. От греха. Ничего кроме путаницы оно не привнесет. "Мы, следователи, должны говорить конкретно — существительными и глаголами: он пришел, она сказала." (Мюллер, 17 мгновений весны).
Ну хорошо, мне не нравится схема, в которой частые релизы и обкатка их на пользователях сочетается с параллельной, несвязанной друг с другом разработкой множества недофич.
> Если вы посмотрите на реальный процесс выпуска релизов уже существующего
Мы говорим о разработке включающей весь цикл развития, а не только доработку уже существующего продукта. Доработка существующего продукта без развития функционала в данном случае — слишком натянутый пример.
> продукта — любого, вы именно это и увидите. Множество относительно простых фич, слабо связанных между собой. В релизе надо исправить сотню разных дефектов, реализовать пару десятков относительно мелких suggestions и improvements (это в сумме может составлять весьма значительную часть работы — процентов 80), иногда — затевают относительно продолжительные и крупные проекты связанные с переписываниями, дописываниями, и рефакторингами. То есть — проблема в принципе налицо — любая продуктовая компания сталкивается с проблемой maintenance и развития продукта. Надо что-то делать.
Я вижу всё это несколько под другим углом и проблема реализации уже запроектированных фич играет тут даже не третью роль.
Что я вижу:
Нереализованный или недореализованный функционал — фичи, которые даже незапроектированы.
Несоответствие требованиям.
Разделение по компетенциям, технологиям, срокам. По фичам — вторично.
И это в предлагаемую схему не ложится.
> Самое простое решение — тупо разделить группы maintenance и "перспективной разработки". На бумаге это получается, на практике — нет, потому что дефекты имеют обыкновение все равно попадать к тому, кто их лучше диагностирует и лучше знает систему. А также потому, что исправление дефектов и реализация фич иногда требует хирургического рефакторинга и тонкой инженерной работы, подчас — продолжительной и объемной. Если однако настоять на этом разделении — то будет еще хуже, потому что программеры из группы maintenance разбегутся. И ухудшится качество основного продукта, который продается и приносит деньги. Короче — проигрышная это стратегия, плюс в ней ровно один — проще планировать загрузку ресурсов, остальное — минусы. Плюс — плохой. Вашим клиентам неважно, насколько вам легко планировать загрузку ресурсов.
У меня как раз пример с точностью до наоборот, есть острая потребность выделить перспективную разработку, а ресурсы использовать максимально эффективно. Видишь ли, не в госбюджете работаем и не на военщину.
> Этот процесс, который основан на правилах управления выпуском maintenance releases, я называл в своих постах "цикл maintenance", имея в виду процесс поддержки и развития продукта, принятый дефакто во многих продуктовых компаниях. Он в литературе особо не описан, но у всех почти одинаков. Так вот — FDD исходит из той же посылки. Это есть совершенно невозможное — удачный гибрид вотерфола — дитем порядка, с дитем хаоса — "циклом maintenance". Он обладает свойствами и того, и другого. И может быть кастомизирован в любую сторону.
> А теперь конкретно. Итак, фичи/дефекты независимы, и их много. Это, натурально, приводит к "расползанию" кода, с чем можно и нужно бороться. Потому что реализация "параллельная" и фичи несвязанны. Так вот, в FDD предусмотрен достаточный набор необходимых мер борьбы с этим — очень похож на тот, что применялся когда-то у нас в CQG без всякого FDD . Да я думаю многие компании самостоятельно пришли к тому же. Что именно: > > 1) Code ownership. > 2) Design review. > 3) Code review.
Не смешите меня. Кто это делает всерьез? Как ЭТО контролировать? Всё выглядит прекрасно, пока сотрудник не увольняется.
Изначально неправильное деление и мы пытаемся ликвидировать последствия. Только пытаемся.
Code ownership должен быть, но это вторично, а не первично.
Сколько воплей по поводу "принял часть проекта на грудь, а там — ужас, что делать?".
А должно быть: "принял часть проекта — код мне не нравится, но если прижмет, я смогу даже переписать его".
> Таким образом, у нас получается как бы матрица — с одной стороны есть "владельцы" кода, с другой — фичи, и группы фичей, перпендикуларно структуре кода.
"Но потом пришлось долгие месяцы уродовать его для имитирования реальной физики, так как реальная физика далека от совершенства"
> G>Тут нужно или всё сразу, но не тестировать ранние релизы на потребителях, или ... я не совсем понял там код, люди, фичи всё по доменам раскидано? Расширять доменный состав по мере законченности предыдущих это уже не получится... > > Люка не склонен тестировать ранние релизы на потребителях и морщится при таком вопросе (узнаю реакцию ватерфольщика, правильно — на потребителях нормальные люди тестируют бета-версии и релиз-кандидаты, а для ранних релизов есть тестеры), хотя говорит что при большом желании это сделать можно . По доменам раскиданы только фичи — код не обязан им соответствовать. Людей можно приписать к доменам — получится матрица прикладной компетенции. Группы можно собирать по любому принципу, я думаю. Расширять доменный состав разумеется можно.
FDD приписано к agile, частые релизы прописаны, это я и понимаю как обкатку на пользователях. Мы же схему обсуждаем, а не её производные?
Компетенции слабо сочетаются с фичами. Чаще — перпендикулярны.
В общем — нету в схеме никаких ролей и компетенций, нечем оперировать. Я так бесчеловечно не могу
Тим-лидер — не Роль в моем понимании, а техническая или административная роль к процессу мало относящаяся.
> Например, если потребуется выделить группу разработки "ядра" системы, которая пользовательские фичи не делает, то делаем так. Внимание. Добавляем новый домен — "Ядро". После чего пускаем работу тем же процессом, только "заказчиком" у нас будут другие программисты из прикладных групп.
Мне кажется, это будет ересь для идеологии FDD. И это уже не простое представление процесса, к которому ты так стремишься.
> G>И такое деление перпендикулярно матрице квалификаций. Может быть вы работаете с универсальными солдатами или инженерами — типа "сегодня ты вот эту фичу, завтра вот эту, а послезавтра я тебе зарплату прибавлю и будешь у меня тим-лидером вот туда". > G>Но я вот таких универсальных практически и не вижу. > > Есть две матрицы квалификаций — в предметной области, и в коде (отражается владением), которые не обязательно совпадают. Разумеется, так как вы пишете делать низя. Разумно побить людей на группы, соответствующие, например, крупным секторам по предметным областям. Это упрощает маршрутизацию фич на верхнем уровне. А тимлидеры этих групп сделают назначение правильно, зная в деталях кто на что способен. Знаете — именно так многие и работают, это естественно.
Только при условии, что народу этак несколько десятков. А при таком количестве разработчиков, нам уже упрощение процесса как бы и не очень нужно.
В общем — не нравится мне изначальная компоновка процесса, изначально расставленные приоритеты.
Не нравится слишком сильное упрощение.
Развивать её корректировать такую схему, костыли приставлять — не хочу.
Вообще надо понимать несколько вещей.
1) Аппаратные системы имеют комбинаторную сложность существенно ниже программных, но зато на порядок более сложны в тестировании, и в них высочайшие требования к качеству — очень высока цена ошибки. Традиционно — у них считается, что модели и тесты должны писать другие люди, и они должны общаться через раздутую спецификацию, их должно быть поровну. Теперь внимание: у нас в данном проекте нет выделенных тестеров. И при этом — мы обеспечиваем хороший контроль над качеством и сроками, и делаем проект гораздо быстрее и дешевле, чем это происходит в среднем по индустрии.
Почему так, за счет чего? Я глубоко переработал процесс разработки, максимально задействовав принципы PSP/TSP, с одной стороны. PSP/TSP непревзойден в плане инструментов и процедур для обеспечения контроля качества. С другой стороны — я убрал из него все лишнее — скажем, убрал группу высокоуровневого моделирования. Вместо этого, я придал программистам-модельщикам статус архитекторов, и включил их на полных правах в проектные группы. Второе — в качестве языка для моделирования применяется Хаскель, от тяжелого SystemC я отказался. Это дало просто потрясающий эффект. На ранних этапах программеры учавствуют в разработке архитектуры и пишут высокоуровневые модели (сразу убираем тормозное звено в коммуникации и снижаем требования к architecture spec — Хаскель по сути и есть исполняемая спецификация — это турбореактивно ускоряет архитектурную фазу и повышает качество). На поздних — они занимаются программным окружением для тестов.
Еще один важный аспект процесса. Дизайн — это групповая активность. На архитектурном этапе все заняты разработкой архитектуры, потом те же люди будут реализовывать свой блок на втором этапе.
Тесты. Один человек отвечает за политику тестирования и тест-план. Тесты — генерируются автоматически или полуавтоматически. Юнит-тестов в традиционном смысле нет — вместо этого снимаются эталонные воздействия с высокоуровневой модели, и пишутся генераторы тестовых векторов. Ну, на самом деле там длинный комплекс мер и тестовых мероприятий, составленный так, чтобы максимально исключить ручной труд при тестировании, генерировать тесты по возможности автоматически, но при этом — обеспечить отлов всех возможных классов ошибок. И этот факт доказывается — методы PSP/TSP позволяют это сделать. Качество тестов контроллируется по метрикам тестового покрытия.
Итого — я сохраняю принципы ватерфола, при этом избавляюсь от необязательной документации, уделяю очень большое внимание автоматизированному тестированию — это очень самый важный аспект планирования и организации работ, предпочитаю смешанные рабочие группы людей разных специальностей, предпочитаю групповой дизайн индивидуальному, но индивидуальное владение кодом.
Оценка трудозатрат производилось по моим методам — оценка вариаций сроков модифицированным PERT Estimation с проверкой через корелляции с метриками объема. Это позволило соблюсти график с мизерным вылетом в пару недель на девять месяцев. 5% погрешность. Неплохо, не так ли?
Короче — это, вероятно, один из самых совершенных процессов разработки аппаратуры сейчас.
Здравствуйте, grosborn, Вы писали:
>> Давайте не будем употреблять слова agile. От греха. Ничего кроме путаницы оно не привнесет. "Мы, следователи, должны говорить конкретно — существительными и глаголами: он пришел, она сказала." (Мюллер, 17 мгновений весны).
G>Ну хорошо, мне не нравится схема, в которой частые релизы и обкатка их на пользователях сочетается с параллельной, несвязанной друг с другом разработкой множества недофич.
FDD не предполагает обкатки частых релизов на пользователях. Не путайте со скрамами.
Параллельная разработка несвязанных друг с другом фич — это более половины активности в развитии и поддержке продукта.
>> Если вы посмотрите на реальный процесс выпуска релизов уже существующего
G>Мы говорим о разработке включающей весь цикл развития, а не только доработку уже существующего продукта. Доработка существующего продукта без развития функционала в данном случае — слишком натянутый пример.
Не надо приписывать мне того, что я не говорил. Пример был с развитием функционала.
G>Я вижу всё это несколько под другим углом и проблема реализации уже запроектированных фич играет тут даже не третью роль. G>Что я вижу: G>Нереализованный или недореализованный функционал — фичи, которые даже незапроектированы.
Где видите? Фичи в FDD проектируются — там есть дизайн и даже детальный дизайн, который встречается не в каждом ватерфоле.
G>Несоответствие требованиям.
Что это такое и где вы это видите я вообше не понимаю. Давайте без коротких фраз, ладно? Раскройте тему.
G>Разделение по компетенциям, технологиям, срокам. По фичам — вторично.
Разделение чего? Персонала? Плана разработки? Задач? Бессвязица какая-то. Внятнее плиз.
G>И это в предлагаемую схему не ложится.
Раскройте тему. Совершенно непонятно, что вы видите.
>> Самое простое решение — тупо разделить группы maintenance и "перспективной разработки". На бумаге это получается, на практике — нет, потому что дефекты имеют обыкновение все равно попадать к тому, кто их лучше диагностирует и лучше знает систему. А также потому, что исправление дефектов и реализация фич иногда требует хирургического рефакторинга и тонкой инженерной работы, подчас — продолжительной и объемной. Если однако настоять на этом разделении — то будет еще хуже, потому что программеры из группы maintenance разбегутся. И ухудшится качество основного продукта, который продается и приносит деньги. Короче — проигрышная это стратегия, плюс в ней ровно один — проще планировать загрузку ресурсов, остальное — минусы. Плюс — плохой. Вашим клиентам неважно, насколько вам легко планировать загрузку ресурсов.
G>У меня как раз пример с точностью до наоборот, есть острая потребность выделить перспективную разработку, а ресурсы использовать максимально эффективно. Видишь ли, не в госбюджете работаем и не на военщину.
Если перспективаная разработка является отдельным проектом, не связанным с предыдущим — она будет отделена естественным образом. Но если ты не учтешь опыт поддержки старого продукта при разработке нового, и посадишь туда новых людей — то ты провалишь проект.
"максимально эффективно", "госбюджет", "военщина" — не надо деклараций, а?
G>Не смешите меня.
Это вы меня смешите. Вы думаете вы просто скажете "ребята, с этой минуты все владеют кодом" — и знания магически сами рапространятся, да? Наивняк.
G>Кто это делает всерьез? Как ЭТО контролировать? Всё выглядит прекрасно, пока сотрудник не увольняется.
google "formal inspections". Это поддается полному контролю и делают всерьез это все, кто знает про formal inspections — с 70х годов прошлого века. Вы не умеете — это не значит что это невозможно.
G>Изначально неправильное деление и мы пытаемся ликвидировать последствия. Только пытаемся.
Кто сказал, что оно неправильное? Обоснуйте сначала.
G>Code ownership должен быть, но это вторично, а не первично.
А почему не третично? На слово не верю даже Иисусу Христосу. А вы ведь не Иисус, нет? Так объясните, почему вам кажется что это так.
G>Сколько воплей по поводу "принял часть проекта на грудь, а там — ужас, что делать?".
Не припомню что-то таких воплей. Ну зачем вы выдумываете.
G>А должно быть: "принял часть проекта — код мне не нравится, но если прижмет, я смогу даже переписать его".
Должно быть? Переписать код, и написать свою какашку любой дурак может. Для этого ума много не надо. Это проще, чем в чужом разобраться, даже если чужой код хорош.
G>FDD приписано к agile, частые релизы прописаны, это я и понимаю как обкатку на пользователях. Мы же схему обсуждаем, а не её производные?
Частые релизы не предполагают обкатки на пользователях. Я кажется ясно сказал, что по этому поводу сказал автор FDD. Хочешь — послушай интервью с ним сам.
G>Компетенции слабо сочетаются с фичами. Чаще — перпендикулярны.
Вы как-то странно и очень по своему трактуете термин "компетенция". "Компетенция" она бывает в чем-то. Компетенции в предметной области впрямую сочетаются с фичами.
G>В общем — нету в схеме никаких ролей и компетенций, нечем оперировать. Я так бесчеловечно не могу
Добавляйте свои роли и компетенции, в чем проблема. Это лучше, чем если б они были, но были кривые, правильно?
G>Тим-лидер — не Роль в моем понимании, а техническая или административная роль к процессу мало относящаяся.
Если роль не относится к процессу — то никакой роли не существует вовсе.
>> Например, если потребуется выделить группу разработки "ядра" системы, которая пользовательские фичи не делает, то делаем так. Внимание. Добавляем новый домен — "Ядро". После чего пускаем работу тем же процессом, только "заказчиком" у нас будут другие программисты из прикладных групп.
G>Мне кажется, это будет ересь для идеологии FDD. И это уже не простое представление процесса, к которому ты так стремишься.
Пардон — а я не усложнил процесс ни капли. Я его вообще не изменил. А вопросы религии — ересь или нет, кошерно или нет, мнея мало волнуют, главное чтоб съедобно было.
>> G>И такое деление перпендикулярно матрице квалификаций. Может быть вы работаете с универсальными солдатами или инженерами — типа "сегодня ты вот эту фичу, завтра вот эту, а послезавтра я тебе зарплату прибавлю и будешь у меня тим-лидером вот туда". >> G>Но я вот таких универсальных практически и не вижу. >> >> Есть две матрицы квалификаций — в предметной области, и в коде (отражается владением), которые не обязательно совпадают. Разумеется, так как вы пишете делать низя. Разумно побить людей на группы, соответствующие, например, крупным секторам по предметным областям. Это упрощает маршрутизацию фич на верхнем уровне. А тимлидеры этих групп сделают назначение правильно, зная в деталях кто на что способен. Знаете — именно так многие и работают, это естественно.
G>Только при условии, что народу этак несколько десятков. А при таком количестве разработчиков, нам уже упрощение процесса как бы и не очень нужно.
Да. Но если людей одна группа — то все еще проще. Строишь две матрицы компетенции — одна по предметной области, вторая по code ownership и knowledge. И все.
G>В общем — не нравится мне изначальная компоновка процесса, изначально расставленные приоритеты. G>Не нравится слишком сильное упрощение.
Вот это основное. А мне как раз нравится упрощение. Усложнить я всегда смогу.
G>Развивать её корректировать такую схему, костыли приставлять — не хочу.
Любой процесс надо "твикать" и изменять под себя. Никода от этого не денетесь.
G>Можно. IP-блок видеоконтроллера, формирующего ТВ сигнал высокой и стандартной четкости. Слой для видео, слой для меню с аппаратным наложением через альфу.
.... G>Предназначен для применения в микросхемах класса "система-на-кристалле" с шинной иерархией AMBA 3.0.
Теперь понятно почему так разнятся наши позиции по процессам разработки. Ты разрабатываешь больше технологичные, железячные вещи, а весь agile в общем рассчитан больше на софт с значительной долей взаимодействия с пользователем и для удовлетворения собственно пользователей, а не фиксированных интерфейсов — здесь.
При этом FDD, по моим поверхностным оценкам — ни каким боком не agile. Даже более того — он вообще мало напоминает процесс разработки. Скорее — процесс кодирования.
Вполне возможно где-то он и применим (где вообще чудовищный бардак с определением требований и назначением задач и нет возможности тесно общаться с клиентами), но имхо это больше процесс дизайна, как впрочем и TDD, обсуждение которого зачем-то засунули в этот форум.
G>А также потому, что исправление дефектов и реализация фич иногда требует хирургического рефакторинга и тонкой инженерной работы, подчас — продолжительной и объемной.
Прочитал три раза. Думал привиделось
А я-то думал они работают по Closed Sourcе.
. Вас кто-то просил? Короче все. Всего доброго, большое спасибо, до следующих встреч. Слава богу, появились ответы по существу.
