VGn>>Но процессом разработки я бы его называть не стал.
G>Слушай, может ты перестанешь называть его, и перейдешь к предметной критике его содержимого, а? Какая разница как ты его назвал бы или не назвал? Он от этого хуже или лучше станет?
Это был вердикт. В разработке я FDD применять не буду.
VGn>>Абсолютно не вижу что здесь новое относительно других процессов (не считая scrum)
G>Ты тоже новизны захотел? Какая в задницу новизна? Я тебе разве о новизне говорю? Это ватерфол в чистом виде, только облегченный и упрощенный, ты что, не заметил еще? Почитай первый пост — внимательно. Почему ты не читашь посты?
Читаю. Читаю. Зачем так тему назвал?
Облегчённый и упрощённый для чего? Для работы или для понимания?
Процесс разработки для идиотов что-ли?
VGn>>При этом FDD, по моим поверхностным оценкам — ни каким боком не agile. Даже более того — он вообще мало напоминает процесс разработки. Скорее — процесс кодирования.
G>Обоснуй.
Нигде не нашёл даже стоимостных оценок. Не говоря уже об управлении рисками.
> 2) Сейчас я тебе говорю исключительно про программные проекты. Да и откуда тебе знать, как проекты по микроэлектронике от программирования отличаются, а?
Во первых, "проекты по микроэлектронике" — это ты сам только что придумал, нету такого.
Во вторых, программирование разное бывает. Думаю, что ты об этом знаешь И различия очень большие между программированием микроконтроллеров, ОС, SAP, 1С и наколенным.
В третьих, по аналогии знаю — образование затрагивало эту область и книжки читал. Это что касается непосредственно микроэлектроники. Работал в смежной области — инженер-конструктор РЭА я когда-то был.
И в четвертых, я просил завязывать.
Здравствуйте, VGn, Вы писали:
VGn>>>Декларируются принципы и подходы, которые в общем и ежу понятны, G>>Ты предпочитаешь методологии, которые декларируют подходы и принципы, которые понять могут только люди с IQ больше 150, я правильно тебя понимаю? Если нет — то тогда к чему ты вообще это сказал? VGn>Нет. Я имел в виду, что декларируются обычно более общие принципы, чем один человек — один класс и т.п.
Выделенное косяк, он не принципиальный — фигня, я это разумеется поправлю. Как — показано здесь. http://rsdn.ru/forum/message/2921249.1.aspx
Более общими принципами я кого хочешь сам могу накормить. Мне нужен четкий шаблон процесса.
VGn>>>но при этом над ними зачем-то выстраивается какая-то довольно жёсткая методология звязи реализации с требованиями, G>>"Зачем-то"? В самом деле — зачем нам привязывать реализацию к требованиям, нахрена нам трассировка требований нужна? VGn>Я не имел в виду жёсткость связи. Я имел в виду жёсткость самой методологии привязки.
Раскрой тему плиз. Объясни, в чем она состоит, и почему это плохо.
Здравствуйте, VGn, Вы писали:
VGn>>>При этом FDD, по моим поверхностным оценкам — ни каким боком не agile. Даже более того — он вообще мало напоминает процесс разработки. Скорее — процесс кодирования.
G>>Обоснуй.
VGn>Нигде не нашёл даже стоимостных оценок.
Ты о том, что не сказано, как оценивать трудозатраты? Дык батенька, это от процесса разработки слабо зависит. Можно совершенно произвольный способ применять. Оценю каждую фичу пертом — и все. Главное, что в FDD есть момент, когда это полагается делать, — все, этого достаточно.
VGn>Не говоря уже об управлении рисками.
PSP/TSP тоже молчит как рыба об управлении рисками — и что? Это не процесс разработки? Он становится от этого бесполезен?
Опять же, в случае планирования от фичлистов рисками управлять просто. Именно фичи у нас хорошо кладутся в квадрат риск-приоритет, потому, что фичи в отличии от обычной таски имеют бизнес-приоритет, его легко оценить для фичи в том числе и не программеру, а скажем, маркетологу или специалисту кастомер саппорта.
VGn>>Это как? Управление изменениями через их отрицание?
G>Позволь мне поинтересоваться, как ты управляешь изменениями, и что ты под этим понимаешь. Не через их отрицание. G>Вообще — ты не мог бы более развернуто писать, по нормальному? Эти короткие бессмысленные фразы вызывают в основном желание только послать в жопу. Если это то, чего ты добиваешься — то конечно продолжай.
Если ты не видишь смысловой разницы в словах "отрицание" и "управление", я даже не знаю что тебе на это ответить.
Короткий пост, потому что здесь — прямой конфликт тезисов в твоих постах и я даже не вижу зачем это обьяснять.
Управление изменениями — это оценка изменений требованийй, принятие изменений (возможно и отрицание некоторой их части), принятие решений по дальнейшей разработке на основании этих решений (в ватерфоле здесь ты уже будешь мылить упомянутую тобой жопу).
G>>>Наличие управления требованиями является безусловно сильной стороной FDD. Особенно ее ориентированность на "фичи" — строить план от единиц независимого тестирования это очень правильно, такие планы очень легко понимать, и главное — легко перестраивать в динамике при изменении приоритетов и требований. Это вообще не секрет для последователей ватерфола. Заодно — фичлист является отличным звеном для трассировки от бизнес-необходимости к дизайну. По сути, если облегчать процесс управления требованиями, отрезая все что можно — то один фичлист и останется как самый необходимый документ. Очень правильно сделано, просто блестяще.
VGn>>Я бы не назвал это управлением требованиями. Это идентификация требований, но никак не управление.
G>Я бы тоже не назвал фичлист управлением требованиями. Потому что фичлист — это документ, артефакт, а не процесс. А управление требованиями при облегченном процессе в голове происходит, понимаешь? Пост заглавный перечитай пожалуйста внимательно. И посмотри, что я пишу про облегченный процесс.
ДФ>>1. Использование в качестве единиц проектирования и владения отдельных классов. По моему опыту правильнее в качестве базовой единицы использовать домен (или его часть) или внутренний модуль (т.е. группу классов/методов, зачастую довольно большую, но с небольшим внешним интерфейсом). За интерфейсы между — отвечает CP.
G>+1. Это однозначно надо исправлять. Если назначать владельцев крупных подсистем, и вводить правило приглашать их на design review — то станет гораздо лучше. У нас фактически появятся архитекторы.
ДФ>>2. Не совсем понятно, как ведется управление релизами и распределение features и текущих деятельностей между релизами. Хотя и понятно, куда это вставить. (Я не верю, что при наличии процесса поддержки и процесса развития всегда вся группа работает с одним релизом. Скорее с тремя-четырьмя одновременно).
G>Все просто — каждая фича приписана определенному релизу. Процесс корректировки targed fix version для фич — привязать к периодическому (еженедельному) контролю продвижения по графику. Если такого нет — добавить.
ДФ>>4. Нет шага принятия решения о рефакторинге. А при подобной схеме очень быстро накапливаются мелкие грабли и заплатки в коде. Вообще, хочется видеть где-то после Refine Object Model шаг анализа увеличения сложности с принятием решения о упрощении реализации ранее сделанных features.
G>А решения о рефакторинге можно принимать ad-hoc — их принимать должны владельцы подсистем.
ДФ>>5. Ну, всякая фигня про контроль версий и расшаренные папки, конечно, устарела. Confluence все заменит. G>Confluence это круто, факт. Плюс JIRA.
Ну и что осталось от твоего "лёгкого и простого процесса"?
Здравствуйте, grosborn, Вы писали:
>> 2) Сейчас я тебе говорю исключительно про программные проекты. Да и откуда тебе знать, как проекты по микроэлектронике от программирования отличаются, а?
G>Во первых, "проекты по микроэлектронике" — это ты сам только что придумал, нету такого.
Ух ты, ну надо же, нету такого! Надо бывшим коллегам позвонить — мужики-то не знают . Проекты по разработке Intel Core Duo тоже я только что придумал наверное, нету такого.
G>Во вторых, программирование разное бывает. Думаю, что ты об этом знаешь И различия очень большие между программированием микроконтроллеров, ОС, SAP, 1С и наколенным.
О сколько нам открытий чудных . Правда что-ли?
Ты не стесняйся, расскажи, каким программированием у нас ты занимаешься? Наколенным, сайты на PHP пишешь, или утилиты командной строки на перле? Может быть на самом С++ крутую гую на MFC делаешь?
G>В третьих, по аналогии знаю — образование затрагивало эту область и книжки читал. Это что касается непосредственно микроэлектроники. Работал в смежной области — инженер-конструктор РЭА я когда-то был.
Ну, раз ты безымянные книжки читал в институте, то по аналогии ты конечно гораздо круче меня в управлении микроэлектронными проектами разбираешься. Где уж мне с моим 8 лет программерских и 2.5 года микроэлектронных проектов, разбираться в программировании после такого.
G>И в четвертых, я просил завязывать. G>И чего ты меня провоцируешь?
Это ты меня провоцируешь. Хочешь завязывать — завязывай, не пиши ерунды и не переходи на личности.
Здравствуйте, VGn, Вы писали:
VGn>>>Но процессом разработки я бы его называть не стал.
G>>Слушай, может ты перестанешь называть его, и перейдешь к предметной критике его содержимого, а? Какая разница как ты его назвал бы или не назвал? Он от этого хуже или лучше станет?
VGn>Это был вердикт. В разработке я FDD применять не буду.
VGn>>Я не имел в виду жёсткость связи. Я имел в виду жёсткость самой методологии привязки. G>Раскрой тему плиз. Объясни, в чем она состоит, и почему это плохо.
Мне показалось, что весь FDD по факту только и является раскрытием этой темы. А жёсткость в выборе метода осуществления требований, по моему мнению, всегда является слабым местом методологии. Будь то FDD, XP или SCRUM.
Я с первого взгляда, как увидел эти тягучие линейные блоксхемы FDD, понял что мне хотят впарить какую-то ерунду.
Для меня ценность методологии в выборе инструментов, а точнее наборов этих инструментов. Когда инструменты начинают меня ограничивать в выборе методов, я меняю инструменты на другие.
Здравствуйте, VGn, Вы писали:
VGn>>> и ограничивающая свободу в управлении требованиями и собственно в разработке. G>>Обоснуй. Каким именно образом FDD ограничивает свободу в управлении требованиями. И собственно в разработке. VGn>Фиксирование требований и выстраивание проектной группы на их основе — это уже довольно жёсткое ограничение управления. Примерно как блокирование руля на вроде бы прямой трассе.
Требования в FDD не фиксируются. Фичлист может менятся по ходу с относительно небольшими затратами, потому что они откладывают детальный дизайн на потом — до реализации задачи. Это компромисс между жостким предварительным планированием, и полным забиванием на него, как в типичных представителях agile. Который как раз позволяет сохранить контроль на трассе с поворотами.
VGn>>>Т.е., по моему мнению, простановка акцентов здесь более вредит, чем приносит пользу. G>>Обоснуй. VGn>В принципе всё уже описал выше. VGn>С точки зрения гибкой разработки — какой-то маразм просто. Хотя если всё время работать по ватерфолу — может в этом всём и видится что-то привлекательное.
Ну да. Видится. С точки зрения ватерфола — посылки agile это маразм, тут все симметрично . А я — вотерфольщик. Официально сертифицированный Carnegie-Mellon-ом по самому вотерфольному вотерфолу PSP/TSP (в CQG, где я работал, в начале 2000 годов внедряли PSP/TSP), жостко основанному на софтверных метриках, о чем имею сертификат. То есть, я злой вотерфольщик, с чорным поясом по вотерфолу, да. Чего удивляться-то?
VGn>>Не говоря уже об управлении рисками. G>PSP/TSP тоже молчит как рыба об управлении рисками — и что? Это не процесс разработки? Он становится от этого бесполезен?
У меня складывается ощущение, что ты и сам уже понял что этот "простой и лёгкий FDD" на самом деле просто убог и построение разработки на его основе будет напоминать кашу из топора.
(Не надо требовать и здесь раскрытия темы. Пройдись по всей ветке и посмотри сколько усовершенствований и исправлений FDD предложил ты сам)
VGn>>>>Но процессом разработки я бы его называть не стал.
G>>>Слушай, может ты перестанешь называть его, и перейдешь к предметной критике его содержимого, а? Какая разница как ты его назвал бы или не назвал? Он от этого хуже или лучше станет?
VGn>>Это был вердикт. В разработке я FDD применять не буду.
G>Отлично. Круто. Интересно узнать — пачему?
По моему довольно понятно. Ватерфол в своей разработке я не использую, а FDD не буду использовать тем более.
Видимая мной ценность ватерфола — его официозность и понятность для заказчика, если заказчик хочет лезть в процесс разработки.
FDD в этом отношении выглядит откровенно слабым и учитывая, что он имхо по всем статьям проигрывает гибким методам, мне он абсолютно не интересен хотя бы в силу в силу своей опасности (если ты не в курсе: один из основных тезисов agile — ватерфол опасен).
Здравствуйте, VGn, Вы писали:
VGn>>>упускающая при этом другие стороны разработки G>>Какие "другие"? Список и обоснование в студию. VGn>Давай абстрагируемся от твоего железячного подхода и на минутку примем, что требования могут изменяться
У меня не железячный подход. Давай не будем от него абстрагироваться, а вспомним, что года три назад я работал во вполне софтверной компании CQG, где занимался клиент-серверными приложениями на С++ под венду. Слушай, может тебе для простоты мое резюме отправить, а? Ну чтоб ты не предполагал обо мне худого и черт знает чего.
VGn>Ну так бывает. Может не у тебя, но в 90% проектов — точно.
Знаю что могут. Для этого требованиями надо управлять, предвидеть это, и ставить процесс под контроль.
VGn>Имеем: VGn>Риски расширения требований. — придётся менять команду?
Почему это обязательно придется менять команду при расширении требований? Не понимаю.
VGn>А если расширение требований потребует изменение части архитектуры?
То она будет изменена. Либо требованиреализация требований будет отложена. Есть еще варианты?
VGn>Риски исчезновения требований или просто временное снятие фич.
"Временное снятие фич" — это что такое? Пример пожалуйста. Риск исчезновения требований — это как? Если требования ты сам собираешь — как они могут исчезнуть внезапно и неожиданно, независимо от тебя, а?
Этот так называемый риск — симптом отсутствия управления требованиями.
VGn>Где FDD вообще что говорится о тестировании во время разработки?
Неужели не понятно? Каждая фича — это единица тестирования. Она тестируется. После чего попадает в транк.
VGn>Итеративность вообще практически на нуле. Даже инкрементность не проглядывается. Только для показухи и контроля дефектов.
Обоснуй.
VGn>Зато чтоб манагер не скучал, ему добавилась куча контрольных инструментов. Но что он сможет делать по результатам своих оценок?
?! Что манагер может делать? Неожиданные вопросы, однако. Прям я даже растерялся. Манагер может управлять приоритетами и рисками, уточнять прогнозы, что выльется в сортировку и изменение фичлиста. Это что — плохо что ему контрольные инструменты добавились? Знаешь, сколько контрольных инструментов у манагера в PSP/TSP? О, это песня. У манагера полный контроль. В FDD, конечно, поменьше, но зато и разработчикам попроще.
Здравствуйте, shrecher, Вы писали:
G>>Блин, ну просто кто во что горазд. По теме есть что сказать? Конкретные проблемы в подходе FDD найти можете, которые будут мешать разработке?
S>Я те про Фому, ты мне про Ерему: не имеет значение какой процесс навязать людям. Результат будет не зависеть от выбранного процесса, а только от качества людей и разных внешних факторов (к примеру удовлетворенность зарплатой).
Понятно, про FDD тебе сказать нечего. Большое спасибо, послушаем что скажут другие. А про Фому с Еремой с кем нибудь другим поговори, кому жти банальности интересны будут.
Здравствуйте, VGn, Вы писали:
G>>Я бы тоже не назвал фичлист управлением требованиями. Потому что фичлист — это документ, артефакт, а не процесс. А управление требованиями при облегченном процессе в голове происходит, понимаешь? Пост заглавный перечитай пожалуйста внимательно. И посмотри, что я пишу про облегченный процесс.
VGn>Думаешь зачем я абзац с начала процитировал?
Понятия не имею — не умею мыслей читать. И расшифровывать их по коротким шифровкам из центра — тоже.
VGn>>>> и ограничивающая свободу в управлении требованиями и собственно в разработке. G>>>Обоснуй. Каким именно образом FDD ограничивает свободу в управлении G>Требования в FDD не фиксируются. Фичлист может менятся по ходу с относительно небольшими затратами, потому что они откладывают детальный дизайн на потом — до реализации задачи. Это компромисс между жостким предварительным планированием, и полным забиванием на него, как в типичных представителях agile. Который как раз позволяет сохранить контроль на трассе с поворотами.
Не во всех agile методологиях на дизайн забивают. Его обычно просто откладывают по времени. В том числе и для возможности более детального обоснования. При этом самые критичные вопросы дизайна всегда решаются на первом этапе (точнее: чем выше критичность, тем раньше решение — это кстати к вопросу о необходимости управления рисками). Т.е. если ты в своём фдд увидел возможность отложить реализацию, то сделай шаг вперёд и рассмотри возможность отложить рассмотрение части архитектурного дизайна.
Но и не в этом суть. Это всё об инкрементной разработке. А я говорил об управлении изменениями требований. Надеюсь ты не станешь спорить с тезисом, что увидев рабочий прототип, заказчик может (и должен иметь право) изменить некоторые свои требования (в том числе и с подачи разработчиков)?
Здравствуйте, VGn, Вы писали:
VGn>>>Это как? Управление изменениями через их отрицание?
G>>Позволь мне поинтересоваться, как ты управляешь изменениями, и что ты под этим понимаешь. Не через их отрицание. G>>Вообще — ты не мог бы более развернуто писать, по нормальному? Эти короткие бессмысленные фразы вызывают в основном желание только послать в жопу. Если это то, чего ты добиваешься — то конечно продолжай.
VGn>Если ты не видишь смысловой разницы в словах "отрицание" и "управление", я даже не знаю что тебе на это ответить.
А тебе кажется, что понимание смысловой разницы между этими двумя словами — это достаточно для понимания твоей очередной шифровки? Так вот, нет, не достаточно.
VGn>Короткий пост, потому что здесь — прямой конфликт тезисов в твоих постах и я даже не вижу зачем это обьяснять.
То есть тебе показалось, что процесс FDD отрицает изменения, так? Обоснуй это пожалуйста. Объясни, почему именно тебе так показалось. Может я чего пропустил? ТОКА ПОДРОБНО, БЛИН. За шыфровки из центра буду ставить принцыпиальные минусы, у меня уже силы кончились.
VGn>Управление изменениями — это оценка изменений требованийй, принятие изменений (возможно и отрицание некоторой их части), принятие решений по дальнейшей разработке на основании этих решений (в ватерфоле здесь ты уже будешь мылить упомянутую тобой жопу).
Нет, не буду я мылить жопу, если мой план составлен от фич. Или же, как при взрослом ватерфоле — план составлен от единиц тестирования (что то же самое). Потому, что перепланирование в этом случае тривиально, как и управление приоритетами. А это как раз то, что мы имеем в FDD. Оно сводится к простой коррекции списка фич. Он же является и планом в случае FDD, или же — основой плана при большом вотерфоле.
Какая разница как ты его назвал бы или не назвал? Он от этого хуже или лучше станет? 
Надо бывшим коллегам позвонить — мужики-то не знают 