- это мертвый agile, как сказали бы (и говорили) "отцы" форума. Однако, коллеги, удивительное рядом. Я нашел легковесную методологию, которая не убьет проект, не противоречит здравому смыслу, и вполне жизнеспособна. Короче — не killed in assembly . Более того — она мне нравится, и я ее рекомендую. Очень хочу собрать консилиум "эдиповых отцов" и просто "жостких патерналистических мужиков", чтобы это обсудить.
Начну из далека. Я слушаю подкасты software engineering radio. Что настоятельно рекомендую вам — это круто. Только что прослушал интервью с Джефом ДеЛюка — автором feature driven development. И в результате я понял, что привлекает людей в agile.
Дело не в отсутствии планирования, обещаниях высокой продуктивности, и прочих фичах скрама и хр. Дело в том, что люди чувствуют потребность в простых и практичных методах, которые было бы легко внедрить, и которые дали бы адекватный результат.
Хороший процесс людям не нужен — им нужен в первую очередь простой процесс, который был бы лучше полного бардака и мало мальски преемлем. Сложные процессы хороши — но их тяжело заставить работать на практике. Поэтому легковесные процессы — это естественный запрос индустрии — она возжелала хоть худого, но порядка.
Скрам и хр — это ответ на запрос индустрии, но он не адекватен. Мы неоднократно разбирались почему. Значит ли это, что невозможно сделать не слишком паршивый легковесный процесс? Разумеется нет. И feature driven development — наглядное тому подтверждение.
Все, чем я занимался, когда налаживал процесс разработки — пытался облегчить классику, устраняя тормозящие элементы, сделать процесс легче.
И все действительно необходимые элементы жизнеспособного процесса я увидел в FDD. Они делают планирование и предварительное проектирование. Они делают детальный дизайн. У них есть дизайн и код ревью. У них есть управление приоритетами и возожна трассировка требований — там есть фичлисты. Они рассчитаны на работу в больших командах. И ничего лишнего, без чего действительно нельзя обойтись.
Короче — fdd лишен косяков скрама и хр. Ну а утяжелить его всегда можно, при желании. Но благодаря легкости — его легко внедрять и поддерживать. Что скажут Отцы? Читайте википедию, пишите, оппонируйте.
Так, коллега, мимо прошел, оценку поставил — это здорово, а оппонировать кто будет? Кто будет критиковать FDD, и рвать его на ошметки? Я на тебя рассчитываю. Лучше схемы адвокат-обвинитель человечество пока ничего не придумало, в этот раз адвокат я. Но отсутствие "обвинителей" лишает обсуждение всякого смысла.
G>Так, коллега, мимо прошел, оценку поставил — это здорово, а оппонировать кто будет? Кто будет критиковать FDD, и рвать его на ошметки? Я на тебя рассчитываю. Лучше схемы адвокат-обвинитель человечество пока ничего не придумало, в этот раз адвокат я. Но отсутствие "обвинителей" лишает обсуждение всякого смысла.
Откажусь от поверхностных суждений.
Может быть зайду сюда позже. Когда достаточно вникну в тему.
Здравствуйте, VGn, Вы писали:
G>>Так, коллега, мимо прошел, оценку поставил — это здорово, а оппонировать кто будет? Кто будет критиковать FDD, и рвать его на ошметки? Я на тебя рассчитываю. Лучше схемы адвокат-обвинитель человечество пока ничего не придумало, в этот раз адвокат я. Но отсутствие "обвинителей" лишает обсуждение всякого смысла.
VGn>Откажусь от поверхностных суждений. VGn>Может быть зайду сюда позже. Когда достаточно вникну в тему.
И ты эту дурацкую дискуссию читал, да? Блин, и кто меня за язык тянул.
Слушай, давай хоть поверхностные, а? Там разберемся по ходу дела, что на самом деле с FDD.
G>- это мертвый agile, как сказали бы (и говорили) "отцы" форума. Однако, коллеги, удивительное рядом. Я нашел легковесную методологию, которая не убьет проект, не противоречит здравому смыслу, и вполне жизнеспособна. Короче — не killed in assembly . Более того — она мне нравится, и я ее рекомендую. Очень хочу собрать консилиум "эдиповых отцов" и просто "жостких патерналистических мужиков", чтобы это обсудить.
G>Начну из далека. Я слушаю подкасты software engineering radio. Что настоятельно рекомендую вам — это круто. Только что прослушал интервью с Джефом ДеЛюка — автором feature driven development. И в результате я понял, что привлекает людей в agile.
Поздравляю с просветлением.
Хороший процесс — это процесс который принес результат: удовлетворенный заказчик, готовый продукт, в рамках бюджета и в срок. А будет это тяжелый водопад, или веселый скрам, дело десятое.
А вот за что я не люблю Agile (вернее евангелистов от Agile), так это за их идиотский проповеднический подход в бабтистком стиле, с лозунгами, песнями и плясками.
Люди наслушаются их подкасов и, вот так вот, вылетают на форумы с воплями: "FDD (Lean, Scrum, TDD, BDD, IDD) рулеззз форева!!!".
Вы бы рассказали нам как, вы завершили дико успешный проект. Как FDD помог вам этого добиться. Как в решающий момент вы переломили косяки скрама при помощи FDD и добились успеха.
А мы бы вас послушали и поспрашивали, как вы те аспекты разруливали, как эти вопросы решали, какими инструментами пользовались.
Здравствуйте, Gaperton, Вы писали:
G>И все действительно необходимые элементы жизнеспособного процесса я увидел в FDD.
По первому впечатлению — перекосов и буйной идеологизированности и вправду меньше, чем у XP, и не такой тяжёлый, как RUP (не столь много внимания уделено называнию каждого чиха отдельным термином).
Но пока — всё. Надо воскурить мануалы...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, stump, Вы писали:
S>Поздравляю с просветлением. S>Хороший процесс — это процесс который принес результат: удовлетворенный заказчик, готовый продукт, в рамках бюджета и в срок. А будет это тяжелый водопад, или веселый скрам, дело десятое.
Одного результата мало. Это условие необходимое, но далеко не достаточное. Можно успешно и гланды через задний проход удалить, но вряд ли это будет оптимально.
S>А вот за что я не люблю Agile (вернее евангелистов от Agile), так это за их идиотский проповеднический подход в бабтистком стиле, с лозунгами, песнями и плясками.
Ну да. Я тоже.
S>Люди наслушаются их подкасов и, вот так вот, вылетают на форумы с воплями: "FDD (Lean, Scrum, TDD, BDD, IDD) рулеззз форева!!!".
Ну я знаешь ли достаточно крепок духом для того, чтобы кричать "рулез форева" наслушавшись подкастов. Кстати, этот подкаст не похож на скрамовские. FDD не впаривают так, как XP и Scrum — автор FDD тупо применяет его в своей работе, и все.
S>Вы бы рассказали нам как, вы завершили дико успешный проект. Как FDD помог вам этого добиться.
Я не делал проектов с agile. Все success stories только с waterfall. Видите ли, я вообще противник agile — почитайте топик "недостатки agile", например. А успеха в любом случае помогает добится в первую очередь голова на плечах, а не процесс.
S>Как в решающий момент вы переломили косяки скрама при помощи FDD и добились успеха.
Зачем переламывать косяки скрама при помощи FDD? Зачем вообще скрам? Для косяков, чтоб были?
FDD судя по описанию скрамовских косяков не имеет by design — это по сути облегченная классика.
S>А мы бы вас послушали и поспрашивали, как вы те аспекты разруливали, как эти вопросы решали, какими инструментами пользовались.
И что, мне все бросить, и ради этого внедрять FDD? Увольте . Давайте вы лучше для начала поможете мне разобраться со слабыми сторонами FDD.
G>Более того — она мне нравится, и я ее рекомендую. Очень хочу собрать консилиум "эдиповых отцов" и просто "жостких патерналистических мужиков", чтобы это обсудить. G>Короче — fdd лишен косяков скрама и хр. Ну а утяжелить его всегда можно, при желании. Но благодаря легкости — его легко внедрять и поддерживать. Что скажут Отцы? Читайте википедию, пишите, оппонируйте.
Видимо, "Жостким патерналистическим мужикам" в лом читать и разбираться в FDD, либо в лом тягаться с могучим разумом топикстартера
А серьезно, может вы бы сделали нам небольшой обзорчик FDD и мы бы обсудили чем он может быть хорош или плох в разных ситуациях?
Мне вот было бы интересно пообщаться на тему "применения agile (FDD) в fixed price проектах". Ибо почитал тут Фаулера и он говорит что agile и fixed price вместе не живут . А так хочется...
Хех, все большие флеймы по поводу методологий начинаются только когда некий юноша напишет что-нибудь вроде "я знаю новую методологию (...) она действительно поможет вам делать проекты быстро и качественно".
Когда же умудренный опытом джентлемен спокойно и взвешенно рассуждает о плюсах и минусах конкретных методологий тут флейма не дождесся. Потому как остальные джентлемены уже вполне в курсе, что проекты делают не методологии, а команды. И если команда хорошая, то она с Agile напишет, а если не очень, то никакой SCRUM тут не поможет.
Здравствуйте, Gaperton, Вы писали:
G>Короче — fdd лишен косяков скрама и хр. Ну а утяжелить его всегда можно, при желании. Но благодаря легкости — его легко внедрять и поддерживать. Что скажут Отцы? Читайте википедию, пишите, оппонируйте.
Мое ИМХО, если позволите.Все еще верим в «серебряную пулю»?
В разработке ПО есть функциональная зависимость 4х «П»:
Процесс = F (Проект, Продукт, Персонал).
Это означает:
Процесс будет сильно разный для проекта в 10 чел.*лет и проекта в 100 чел.*лет.
Процесс будет сильно разный для разработки Web-сайта и АСУ АЭС.
Процесс будет сильно разный для сработавшейся команды профессионалов и группы студентов, собранных только вчера, для разных стадий развития команды: 1) Forming, 2) Storming , 3) Norming, 4) Performing.
Выводы:
Нет одного лучшего способа решения всех дифференциальных уравнений.
Нет одного лучшего языка программирования для разработки всех программных систем.
Нет одного лучшего процесса для разработки ПО.
“Linux vs Widows”, “C++ vs Java”, “FDD vs Scrum” – все в «священные войны».
Здравствуйте, craft-brother, Вы писали:
CB>Здравствуйте, Gaperton, Вы писали:
G>>Короче — fdd лишен косяков скрама и хр. Ну а утяжелить его всегда можно, при желании. Но благодаря легкости — его легко внедрять и поддерживать. Что скажут Отцы? Читайте википедию, пишите, оппонируйте.
CB>Мое ИМХО, если позволите.Все еще верим в «серебряную пулю»?
У меня к вам просьба. Вы пост прочитайте внимательно сначала, потом отвечайте по существу, хорошо?
ХЪ CB>ЗЫ. "Ничего личного. Только бизнес"
"Бизнес" был бы, если бы вы ответили содержательно. Я просил конкретной критики FDD. Рассуждения про "серебрянные пули" существования лучших способов и прочие общие слова мне малоинтересны. Этот ответ для меня совершенно бесполезен и оффтопичен.
Здравствуйте, B0rG, Вы писали:
BG>Хех, все большие флеймы по поводу методологий начинаются только когда некий юноша напишет что-нибудь вроде "я знаю новую методологию (...) она действительно поможет вам делать проекты быстро и качественно".
BG>Когда же умудренный опытом джентлемен спокойно и взвешенно рассуждает о плюсах и минусах конкретных методологий тут флейма не дождесся. Потому как остальные джентлемены уже вполне в курсе, что проекты делают не методологии, а команды. И если команда хорошая, то она с Agile напишет, а если не очень, то никакой SCRUM тут не поможет.
Что-то странно как-то, все что-то отвлеченное пишут, и никто ничего по теме сказать не может — никто даже не цитирует оригинальный пост. По существу вопроса вы чего-нибудь сказать можете, коллега? Вы пост мой внимательно прочитали? По беглому описанию FDD вы можете найти в процессах FDD выраженные косяки?
Здравствуйте, RGB_Dart, Вы писали:
G>>Более того — она мне нравится, и я ее рекомендую. Очень хочу собрать консилиум "эдиповых отцов" и просто "жостких патерналистических мужиков", чтобы это обсудить. G>>Короче — fdd лишен косяков скрама и хр. Ну а утяжелить его всегда можно, при желании. Но благодаря легкости — его легко внедрять и поддерживать. Что скажут Отцы? Читайте википедию, пишите, оппонируйте.
RGB>Видимо, "Жостким патерналистическим мужикам" в лом читать и разбираться в FDD, либо в лом тягаться с могучим разумом топикстартера RGB>А серьезно, может вы бы сделали нам небольшой обзорчик FDD и мы бы обсудили чем он может быть хорош или плох в разных ситуациях?
Я не знаю FDD. По беглому взгляду на страницу FDD в википедии — я не нашел в ней ни одного косяка характерного для SCRUM/XP и прочего agile. Это меня удивило, и заинтересовало. Захотелось разобраться подробнее.
Хорошего в легких методологиях только одно — что они "легкие", и поэтому их проще внедрить. Вопрос в одном — они нам убьют разработку, оставят бардак как был, или все-таки дадут некоторый положительный результат. Я пока не вижу, как FDD может убить разработку. Вы видите?
RGB>Мне вот было бы интересно пообщаться на тему "применения agile (FDD) в fixed price проектах". Ибо почитал тут Фаулера и он говорит что agile и fixed price вместе не живут . А так хочется...
Я не вполне понимаю, что такое "agile" в fixed price проектах, и откуда вообще возникает такое желание — "применять agile". Для фиксед прайс ключ к успеху — управление требованиями, предварительное проектирование и точное планирование. Фиксед прайс заказуха — уже ставит вас в определенные рамки, если вы следуете, скажем, ГОСТ-у. А ему лучше следовать, не изобретая велосипедов.
Хотя насчет FDD — она в колючевых моментах сильно отличается от Скрама, по сути это "ленивый ватерфол" — где некоторые активности (скажем, детальный дизайн и планирование) откладываются на потом, плюс планирование идет от единиц независимого тестирования, что грамотные ватерфольщики тоже должны делать. Там есть предварительное проектирование, планирование, и там нет характерного для agile "time boxing". Ее несложно модифицировать так, чтобы делать fixed price — "форсируя отложенные операции". Но она при этом превратится в честный благородный водопад .
Короче, FDD имеет мало общего с прочими agile и гораздо больше с waterfall и RUP. Захотите делать с ней fixed price — и она окончательно превратится в вариант классики.
Здравствуйте, Gaperton, Вы писали:
G>Что-то странно как-то, все что-то отвлеченное пишут, и никто ничего по теме сказать не может — никто даже не цитирует оригинальный пост. По существу вопроса вы чего-нибудь сказать можете, коллега? Вы пост мой внимательно прочитали? По беглому описанию FDD вы можете найти в процессах FDD выраженные косяки?
Ну этому есть несколько причин:
1) мне нужно дописать с*** masked text edit control и передвинуцца на более интересную задачу.
2) и самая главное, вы начали издалека, но по существу так ничего и не сказали.
Поясню:
вода
*) коллеги, удивительное рядом
*) Я слушаю подкасты software engineering radio
*) я понял, что привлекает людей в agile
*) люди чувствуют потребность в простых и практичных методах
*) нужен в первую очередь простой процесс
*) Сложные процессы хороши — но их тяжело заставить работать
*) Скрам и хр — это ответ на запрос индустрии, но он не адекватен (почему не адекватен, кстати?)
про fdd
*) планировка
*) предварительное проектирование
*) детальный дизайн
*) код ревью
*) приоритизация
*) фичлисты
про команды вода, включать не буду.
Честно сказать, я ничего нового в fdd не увидел, все вышеперечисленное есть во всех нормальных командах. Вероятно, вы забыли упомянуть те самые факторы, которые и отличают его от всех остальных процессов. Т.е. пока что я не вижу ничего революционного в fdd.
И самое главное выбор процесса и методологии должен зависеть от экосистемы, например никому не придет в голову разрабатывать ОС на Agile.
Расскажу о своем опыте: когда я работал под процессом, что мне нравился, мы его никак не называли, и там был набор методологий из разных процессов, адаптированных под нашу действительность. Лучше всего его было бы назвать BDUF (Big Design Up Front: 6 месяцев архитектуры, 4 месяца кодинга, 4 месяца тестинга — релиз). Там было:
*) планировка
*) проектирование и детальный дизайн (функ спека, и тех спека с описанием по функциям, тест спека наша и тестеров)
*) юнит тесты
*) continuous integration
*) 3 level testing (unit test, integration, system test)
Чего не было:
*) приоритизации и фичлистов, потому как это все укладывалось в планировку и проектирование на архитектурном этапе.
*) общение с заказчиком было в одностороннем порядке через Change request, которые удовлетворялись по взаимному соглашению между пм арком тимлидом и программером на уровне: мы успеваем это сделать? те от кого мы зависим сделают это вовремя? осталось ли время? Если нет хотя бы на один вопрос — отправляется в след релиз.
Здравствуйте, grosborn, Вы писали:
G>Ткни пожалуйста пальцем, где роли и компетенции? Как они сюда вообще лягут? Я честно понять хочу, но не могу...
Вроде как, процесс это не регламентирует. По крайней мере — не нашел. Это в принципе для меня даже хорошо — дает большую свободу, можно любую ролевую модель попробовать натянуть. Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО.
Меня вот больше интересует, как это ляжет на процесс продуктовой разработки — когда надо выпоскать регулярные bugfix release и периодические major releases. В этом случае у тебя есть тестеры, девелоперы, и кастомер саппорт. Что мне пока кажется — design by feature отлично увязывается с исправлениями дефектов — а подружить эти два процесса и обрабатывать разработку с поддержкой единообразно — это очень большой плюс, я считаю. Но это надо проверить.
Здравствуйте, RGB_Dart, Вы писали:
RGB>Мне вот было бы интересно пообщаться на тему "применения agile (FDD) в fixed price проектах". Ибо почитал тут Фаулера и он говорит что agile и fixed price вместе не живут . А так хочется...
FDD реально мало общего со скрамом имеет. И это хорошо. А Делюка мне определенно нравится — нормальный ответ, вижу — сработает, возражений нет никаких.
Здравствуйте, B0rG, Вы писали:
BG>Честно сказать, я ничего нового в fdd не увидел, все вышеперечисленное есть во всех нормальных командах. Вероятно, вы забыли упомянуть те самые факторы, которые и отличают его от всех остальных процессов. Т.е. пока что я не вижу ничего революционного в fdd.
"Вода", которую вы пропустили:
Хороший процесс людям не нужен — им нужен в первую очередь простой процесс, который был бы лучше полного бардака и мало мальски преемлем. Сложные процессы хороши — но их тяжело заставить работать на практике. Поэтому легковесные процессы — это естественный запрос индустрии — она возжелала хоть худого, но порядка.
Не понятно? Могу пояснить. Ничего нового и революционного в легком процессе быть и не должно. Его единственное достоинство — легковесность и низкие затраты на внедрение и поддержание. Его единственный плюс — он не должен быть полным дерьмом, если он при легковесности дает результат "удовлетворительно", на троечку — это очень хороший легкий процесс.
Для справки — воды в моих сообщениях вообще немного. Если вы как следует прочитали мое сообщение — то поняли бы, что меня мало интересует революционность и новизна, и что удивлять вас революционностью я не собираюсь. Вы бы поняли, что я прошу вас половить fdd на предмет косяков, почитав про нее в википедии. Итак, по существу вопроса вы что-нибудь скажете? А то философия меня начинает утомлять, честно.
BG>И самое главное выбор процесса и методологии должен зависеть от экосистемы, например никому не придет в голову разрабатывать ОС на Agile.
А что такое Agile? Я этого не понимаю. Что такое FDD, Scrum, и XP — понять могу. А раз я не понимаю что такое Agile — то мне кажется странным утверждение, почему никому не придет в голову разрабатывать ОС на Agile.
Вот кстати — при помощи какого процесса и методологии разрабатывается Linux по вашему? Охарактеризуйте его пожалуйста. Неужто тяжеленный MIL-STD-434367856-SOME-SHIT?
BG>Чего не было: BG>*) приоритизации и фичлистов, потому как это все укладывалось в планировку и проектирование на архитектурном этапе.
Приоретизация и фичлисты не может быть уложена в планировку и проектирование никак. Если вы только не определите эти термины заново как то по своему.
BG>*) общение с заказчиком было в одностороннем порядке через Change request, которые удовлетворялись по взаимному соглашению между пм арком тимлидом и программером на уровне: мы успеваем это сделать? те от кого мы зависим сделают это вовремя? осталось ли время? Если нет хотя бы на один вопрос — отправляется в след релиз.
Это как вам угодно. Меня сейчас больше продуктовая разработка интересует, а эффективно общаться с заказчиком я и так умею, у меня на эту тему вопросов нет.
Здравствуйте, B0rG, Вы писали:
BG>Когда же умудренный опытом джентлемен спокойно и взвешенно рассуждает о плюсах и минусах конкретных методологий тут флейма не дождесся. Потому как остальные джентлемены уже вполне в курсе, что проекты делают не методологии, а команды. И если команда хорошая, то она с Agile напишет, а если не очень, то никакой SCRUM тут не поможет.
Здравствуйте, shrecher, Вы писали:
S>Кадры решают все!
Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
> G>Ткни пожалуйста пальцем, где роли и компетенции? Как они сюда вообще лягут? Я честно понять хочу, но не могу... > > Вроде как, процесс это не регламентирует.
Ну вот и я так понял. Ты более внимательно разбирался, тебе верю — никто о них и не упоминает, обычное дело.
> По крайней мере — не нашел. Это в принципе для меня даже хорошо — дает большую свободу, можно любую ролевую модель попробовать натянуть. Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО. > > Меня вот больше интересует, как это ляжет на процесс продуктовой разработки — когда надо выпоскать регулярные bugfix release и периодические major releases. В этом случае у тебя есть тестеры, девелоперы, и кастомер саппорт. Что мне пока кажется — design by feature отлично увязывается с исправлениями дефектов — а подружить эти два процесса и обрабатывать разработку с поддержкой единообразно — это очень большой плюс, я считаю. Но это надо проверить.
Моё мнение — эта технология представляет собой отдельный взгляд из серии "вы садитесь вдоль этой стенки, а вы — по диагонали комнаты". К _организации_ реального процесса имеет отношение процентов на 10. Пониманию и улучшению уже существующего процесса может помогать. Но так же может и в сторону увести, поскольку не систематична, не самодостаточна, не сбалансирована.
К слову сказать — я сам не зная этого определения работал примерно по такой схеме частенько.
А что касается в частности четкого разделения на фичи, так это очень хорошо при уже налаженном процессе. И абсолютно смертельно такое сочетание на ранних этапах, когда ещё продукт есть по сути недоносок. Потребителю, который поработает с системой недофич 5 минут, кошмары будут сниться всю жизнь. И каждый раз он будет плеваться при упоминании имени компании, такое сделавшей. Это я как всегда преувеличиваю конечно, но доля шутки тут есть.
RM — это люди, программы железо и т.д., т.е. "чем мы делаем софт".
WM — это фичлисты, приоритизация, "что мы делаем".
EM — это юзеры, зазазчики, сейлы и т.д., "для кого мы делаем".
Любая методология разработки софта (тм) так или иначе пытается сказать, 1 главнее чем 2, но 3 главнее чем оба, или же наоборот. Так же у методологии есть область применения (ос на agile).
Остальное вечером, тут еще рабочий день в разгаре.
> S>Кадры решают все! > > Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
Кадры решают все!
В том смысле, что кадры должны быть учтены в описании процесса.
Без этого всё — вода...
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, shrecher, Вы писали:
S>>Кадры решают все!
G>Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
Это как раз о процессах. Если кадры соответвуют поставленной задаче, то никакой процесс им не помеха. Точнее так, какой процесс им ненавижи, они все равно будут делать как им удобнее. А для неподходящих кадров, любой процесс самый модерновый процесс как мертвому припарка.
> Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО.
А не опыт ли работы с заводскими инженерами заставляет тебя так действовать?
Там действительно людей можно расставлять по разному, естественно несколько учитывая их способности.
Здравствуйте, Gaperton, Вы писали:
G>"Вода", которую вы пропустили: G>
G>Хороший процесс людям не нужен — им нужен в первую очередь простой процесс, который был бы лучше полного бардака и мало мальски преемлем. Сложные процессы хороши — но их тяжело заставить работать на практике. Поэтому легковесные процессы — это естественный запрос индустрии — она возжелала хоть худого, но порядка.
G>Не понятно? Могу пояснить. Ничего нового и революционного в легком процессе быть и не должно. Его единственное достоинство — легковесность и низкие затраты на внедрение и поддержание. Его единственный плюс — он не должен быть полным дерьмом, если он при легковесности дает результат "удовлетворительно", на троечку — это очень хороший легкий процесс.
У вас ложное представление об Agie процессах, как о слегка упорядоченном бардаке. Такое отношение понятно, поскольку, по вашим словам, вы сами в agile не работали.
Но agile это вовсе не слегка упорядоченный бардак. Это просто другой процесс, который базируется на другом типе жизненного цикла продукта и на других методах delivery (не знаю как подобрать адекватный русский термин). Все что на виду: спринты, игра в планирование, бэклоги, парное кодирование, это все внешние проявления,- суть инструменты.
G>Для справки — воды в моих сообщениях вообще немного. Если вы как следует прочитали мое сообщение — то поняли бы, что меня мало интересует революционность и новизна, и что удивлять вас революционностью я не собираюсь. Вы бы поняли, что я прошу вас половить fdd на предмет косяков, почитав про нее в википедии. Итак, по существу вопроса вы что-нибудь скажете? А то философия меня начинает утомлять, честно.
BG>>И самое главное выбор процесса и методологии должен зависеть от экосистемы, например никому не придет в голову разрабатывать ОС на Agile.
G>А что такое Agile? Я этого не понимаю. Что такое FDD, Scrum, и XP — понять могу. А раз я не понимаю что такое Agile — то мне кажется странным утверждение, почему никому не придет в голову разрабатывать ОС на Agile.
Вто то и дело что не понимаете. Различие в самом способе производства. Традиционный способ производства софта подобен производству любых других материальных ценностей. Вы приходите в ателье и заказываете костюм. С вас снимают мерки, и через неделю приглашают на примерку, устраняют недочеты и через пару дней вы забираете готовый костюм. Это класичесский водопад.
Но дело в том что софт — это не обычный материальный товар, а род абстракции. И с ним методы применяемые к материальному производству работают плохо. Зато работают методы, которые к материальному производству не применимы. Вы не можете прийти в ателье на следующий день после примерки, одеть и начать носить недошитый жилет. А портной все это время будет бегать вокруг вас и превращать жилет в полноценный пиджак. Это не возможно. А с софтом возможно. И это называется agile.
G>Вот кстати — при помощи какого процесса и методологии разрабатывается Linux по вашему? Охарактеризуйте его пожалуйста. Неужто тяжеленный MIL-STD-434367856-SOME-SHIT?
Если говорить о ядре Linux, то сейчас он разрабатывается по методологии Open Source.
RGB>>Мне вот было бы интересно пообщаться на тему "применения agile (FDD) в fixed price проектах". Ибо почитал тут Фаулера и он говорит что agile и fixed price вместе не живут . А так хочется...
G>О! Нашел пост делюки на эту тему. G>http://www.featuredrivendevelopment.com/node/527 G>FDD реально мало общего со скрамом имеет. И это хорошо. А Делюка мне определенно нравится — нормальный ответ, вижу — сработает, возражений нет никаких.
Вы это серьезно?!
Де Люка пишет, как "классно" можно прикинуть сроки. "Если за две недели мы разработали domain model, то конструирование займет 6 месяцев". Дальше в комментах пишет, что это НЕ человеко-месяцы. Охренеть просто .
Он на полном серьезе говорит о сроке разработки, открещиваясь от трудоемкости и говорит как классно узнать сроки (но не трудоемкость!) в самом начале проекта (после первых 3х активностей).
...
Почитал дальше камменты там Ему (Люку) народ на все это указал и выцепил нормальное соотношение ролей. На 1 бизнес-эксперта три chief programmers, и на каждого chief programmer 4 девелопера. Оттуда народ вывел пример расчетов трудоемкости и ждет подтверждения мыслей. Люка пока молчит .
З.Ы.
А вообще, прочитав все это — мне не очень понятно, почему FDD = agile? Если почитать agile manifesto (например перевод здесь), то там есть фраза типа
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
А в FDD мы feature list формируем заранее. Итеративными (как я понимаю) являются только фазы конструирования.
З.Ы.Ы. Ну а вообще, 90% agile manifesto можно применять в любом случае — не взирая на методологию...
Здравствуйте, Gaperton, Вы писали:
G>"Бизнес" был бы, если бы вы ответили содержательно. Я просил конкретной критики FDD. Рассуждения про "серебрянные пули" существования лучших способов и прочие общие слова мне малоинтересны. Этот ответ для меня совершенно бесполезен и оффтопичен.
Ну, извини, ты первый начал…
Видимо, я был недостаточно убедителен в своем первом ответе.
Подставь в свой начальный пост вместо FDD – «аспирин», а вместо Scrum и XP – «валерьянку» и «пурген», а вместо слова проект – «больной», и перечитай.
G>«Я нашел легковесную методологию, которая не убьет проект, не противоречит здравому смыслу, и вполне жизнеспособна. [...] Более того — она мне нравится, и я ее рекомендую [...] Хороший процесс людям не нужен — им нужен в первую очередь простой процесс».
Подставил? Перечитал?
Людям нужен именно хороший процесс, который позволит им работать с наибольшей эффективностью, позволит решить свои проблеммы при наименьших затратах. А вовсе не простой процесс.
Так вот, суть моего ответа заключалась в том, что пока ты не поставил больному диагноз, бессмысленно говорить о том, что "аспирин мне нравится, отговорите меня его применять". Применяй, если он лечит твоего больного, но рекомендовать его на все случаи жизни, ИМХО, не стоит.
Здравствуйте, RGB_Dart, Вы писали:
RGB>>>Мне вот было бы интересно пообщаться на тему "применения agile (FDD) в fixed price проектах". Ибо почитал тут Фаулера и он говорит что agile и fixed price вместе не живут . А так хочется...
G>>О! Нашел пост делюки на эту тему. G>>http://www.featuredrivendevelopment.com/node/527 G>>FDD реально мало общего со скрамом имеет. И это хорошо. А Делюка мне определенно нравится — нормальный ответ, вижу — сработает, возражений нет никаких.
RGB>Вы это серьезно?! RGB>Де Люка пишет, как "классно" можно прикинуть сроки. "Если за две недели мы разработали domain model, то конструирование займет 6 месяцев". Дальше в комментах пишет, что это НЕ человеко-месяцы. Охренеть просто . RGB>Он на полном серьезе говорит о сроке разработки, открещиваясь от трудоемкости и говорит как классно узнать сроки (но не трудоемкость!) в самом начале проекта (после первых 3х активностей).
Ну зачем так волноваться. Ну сказал Люка глупость, ну бывает. Я это при беглом просмотре пропустил — потому что искал в тексте другое. Предлагаю обратить на это другое внимание. Главное — что он предлагает сделать domain model две недели, и продать это задешево, а по итогам domain model выдать прогноз всего проекта. Это — правильно. У нас в этот момент будет достаточно информации, чтобы дать нормальный качественный прогноз трудозатрат.
И делать прогноз можно вовсе не таким дебильным образом, как умножение длительности первой фазы на пи. А по нормальному — с оценкой вариаций сроков, и проверкой через коридоры метрик. Это в сущности не так важно. Важно — что есть предварительное проектирование и предполагается планирование. Сама технология планирования — вторична, фундаментальным косяком не является. Для оценки трудозатрат можно что угодно применять. Я, например, в любом случае воспользуюсь своим методом оценки трудозатрат, он гораздо совершеннее, чем придумки агилистов.
RGB>Почитал дальше камменты там Ему (Люку) народ на все это указал и выцепил нормальное соотношение ролей. На 1 бизнес-эксперта три chief programmers, и на каждого chief programmer 4 девелопера. Оттуда народ вывел пример расчетов трудоемкости и ждет подтверждения мыслей. Люка пока молчит .
Это какой-то странный расчет. Я все равно по другому считаю, и буду дальше считать по своему — мнение Люка насчет оценки трудозатрат мне малоинтересно, я и так неплохо fixed cost умею оценивать. Главное — что я могу свой метод оценки вписать в процесс FDD — потому что там есть хорошее место, куда оценки можно вписать. А вот в скраме и XP это вписывать просто некуда.
RGB>З.Ы. RGB>А вообще, прочитав все это — мне не очень понятно, почему FDD = agile? Если почитать agile manifesto (например перевод здесь), то там есть фраза типа RGB>"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." RGB>А в FDD мы feature list формируем заранее. Итеративными (как я понимаю) являются только фазы конструирования.
Да, мне тоже это непонятно, что общего у FDD и типичных agile вроде scrum и XP. FDD — не имеет косяков agile — вы назвали один из них зацитировав манифест . FDD выглядит как облегченнная классика.
Думаю, надо перестать употреблять термин agile — это скорее маркетинговый термин, заменив его на "легковесный процесс". Потому, что FDD безусловно легковесный процесс. О чем, собственно, я в исходном посте написал.
RGB>З.Ы.Ы. Ну а вообще, 90% agile manifesto можно применять в любом случае — не взирая на методологию...
Ну, а мне этот agile манифест кажется пустыми словами и балшытом. Мое личное мнение, конечно. Но декларировать можно все что угодно — хоть удекларируйся.
Здравствуйте, grosborn, Вы писали:
G>Ну вот и я так понял. Ты более внимательно разбирался, тебе верю — никто о них и не упоминает, обычное дело.
Нет, пока я еще не разобрался.
G>Моё мнение — эта технология представляет собой отдельный взгляд из серии "вы садитесь вдоль этой стенки, а вы — по диагонали комнаты". К _организации_ реального процесса имеет отношение процентов на 10. Пониманию и улучшению уже существующего процесса может помогать. Но так же может и в сторону увести, поскольку не систематична, не самодостаточна, не сбалансирована.
Ну-ну-ну. Подождите суждения общего характера высказывать. По частностям не разобрались пока. В сторону увести может все что угодно. Была бы дурь в голове. Назовите метод, который не может в сторону увести принципиально, в конце концов. Ведь нет таких. Сложная самодостаточная методология вроде RUP — стройна на бумаге, но трудно внедрябельна и понимабельна из-за как раз своей излишней систематичности и монструозности. Что делать? Ладно, предлагаю с FDD разбераться сначала.
Вы сказали — несистематична, не самодостаточно, не сбалансирована. Раскройте тему пожалуйста. Почему так? Аргументы плиз. Интересны не общие суждения, а конкретные указания на конкретные косяки. Были бы интересны суждения — я б опрос зарядил, а не дискуссию.
G>К слову сказать — я сам не зная этого определения работал примерно по такой схеме частенько.
По FDD?
G>А что касается в частности четкого разделения на фичи, так это очень хорошо при уже налаженном процессе. И абсолютно смертельно такое сочетание на ранних этапах, когда ещё продукт есть по сути недоносок. Потребителю, который поработает с системой недофич 5 минут, кошмары будут сниться всю жизнь. И каждый раз он будет плеваться при упоминании имени компании, такое сделавшей. Это я как всегда преувеличиваю конечно, но доля шутки тут есть.
Не соглашусь. Четкое разделение на фичи необходимо продукту и на ранней стадии, а чтобы недофичей не было то надо добавить к этим фичлистам управление приоритетами и рисками. За фичлисты же зацепляется и маркетинг — фичлист вообще является центральным связующим документом между маркетингом и разработкой при разработке продукта. Это как раз то, чего многие не понимают и от этого страдают. И это чрезвычайно правильно, что в FDD делается на фичлистах акцент. Причем — даже не важно, как конкретно они там устроены. Я все равно устрою фичлист так, как мне надо .
Здравствуйте, grosborn, Вы писали:
>> Скажем — у меня особые взгляды на ролевые модели, я как раз не люблю когда методология на них акцентируется, лучше обязанности раздавать по месту и индивидуально ИМХО.
G>А не опыт ли работы с заводскими инженерами заставляет тебя так действовать? G>Там действительно людей можно расставлять по разному, естественно несколько учитывая их способности.
Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают.
Здравствуйте, B0rG, Вы писали:
BG>Любая методология разработки софта (тм) так или иначе пытается сказать, 1 главнее чем 2, но 3 главнее чем оба, или же наоборот. Так же у методологии есть область применения (ос на agile).
Дискуссия — это когда отвечают на посты друг друга. Вы — монологируете, не слушая меня. Вы удаляете весь мой пост, и ведете беседу сам с собой. Borg, я не просил вас рассказывать мне прописных истин. Мне совершенно не интересно выслушивать отвлеченные философские рассуждения базового уровня. И меня раздражает, когда в ответ на конкретные просьбы меня начинают учить жизни в духе урока для умственно отсталых детей. Сказать больше нечего чтоли? Неужели не можете косяков в процессах FDD найти? Все, философская дискуссия закрыта, уважаемый коллега. Я вам отвечать ничего не буду, монологируйте дальше.
Re[5]: Хороший agile
От:
Аноним
Дата:
18.04.08 15:48
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают.
Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально,
с учетом сильных и слабых сторон.
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>"Вода", которую вы пропустили: G>>
G>>Хороший процесс людям не нужен — им нужен в первую очередь простой процесс, который был бы лучше полного бардака и мало мальски преемлем. Сложные процессы хороши — но их тяжело заставить работать на практике. Поэтому легковесные процессы — это естественный запрос индустрии — она возжелала хоть худого, но порядка.
G>>Не понятно? Могу пояснить. Ничего нового и революционного в легком процессе быть и не должно. Его единственное достоинство — легковесность и низкие затраты на внедрение и поддержание. Его единственный плюс — он не должен быть полным дерьмом, если он при легковесности дает результат "удовлетворительно", на троечку — это очень хороший легкий процесс.
S>У вас ложное представление об Agie процессах, как о слегка упорядоченном бардаке. Такое отношение понятно, поскольку, по вашим словам, вы сами в agile не работали.
У вас ложное представление о моих представлениях об Agile процессах. И вы не читали моего первого поста, а если читали — то не поняли. Странно.
G>>А что такое Agile? Я этого не понимаю. Что такое FDD, Scrum, и XP — понять могу. А раз я не понимаю что такое Agile — то мне кажется странным утверждение, почему никому не придет в голову разрабатывать ОС на Agile.
S>Вто то и дело что не понимаете.
Прошу вас воздержиться от подобных замечаний. Не надо меня злить.
S>Различие в самом способе производства. Традиционный способ производства софта подобен производству любых других материальных ценностей. Вы приходите в ателье и заказываете костюм. С вас снимают мерки, и через неделю приглашают на примерку, устраняют недочеты и через пару дней вы забираете готовый костюм. Это класичесский водопад. S>Но дело в том что софт — это не обычный материальный товар, а род абстракции. И с ним методы применяемые к материальному производству работают плохо. Зато работают методы, которые к материальному производству не применимы. Вы не можете прийти в ателье на следующий день после примерки, одеть и начать носить недошитый жилет. А портной все это время будет бегать вокруг вас и превращать жилет в полноценный пиджак. Это не возможно. А с софтом возможно. И это называется agile.
Это не объяснение, это хорошая сказка на ночь. Аналогия довольно наивна, и, наверное хорошо действует на людей, плохо разбирающихся в процессах разработки софта. Вероятно — именно так и впаривают agile.
G>>Вот кстати — при помощи какого процесса и методологии разрабатывается Linux по вашему? Охарактеризуйте его пожалуйста. Неужто тяжеленный MIL-STD-434367856-SOME-SHIT?
S>Если говорить о ядре Linux, то сейчас он разрабатывается по методологии Open Source.
Надо же, кто бы мог подумать? А я-то думал они работают по Closed Sourcе.
ЗЫ: сколько умных слов не по теме — кошмар, но почему-то никто не в состоянии ничего предметно сказать про FDD, и прочитав его описание. Интересно — я вообще в профильную конфу "управление пректами" написал — или случайно попал в "священные войны"?
Здравствуйте, Аноним, Вы писали:
G>>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают.
А>Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально, А>с учетом сильных и слабых сторон.
Я оперирую обязанностями и ответственностью, а не ролями.
Здравствуйте, grosborn, Вы писали:
>> Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
G>Кадры решают все! G>В том смысле, что кадры должны быть учтены в описании процесса.
Как именно они должны быть учтены в описании процесса? Пример пожалуйста.
G>Без этого всё — вода...
О сколько нам открытий чудных.
Здравствуйте, shrecher, Вы писали:
G>>Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?
S>Это как раз о процессах. Если кадры соответвуют поставленной задаче, то никакой процесс им не помеха. Точнее так, какой процесс им ненавижи, они все равно будут делать как им удобнее. А для неподходящих кадров, любой процесс самый модерновый процесс как мертвому припарка.
Блин, ну просто кто во что горазд. По теме есть что сказать? Конкретные проблемы в подходе FDD найти можете, которые будут мешать разработке?
Здравствуйте, craft-brother, Вы писали:
CB>Так вот, суть моего ответа заключалась в том, что пока ты не поставил больному диагноз, бессмысленно говорить о том, что "аспирин мне нравится, отговорите меня его применять". Применяй, если он лечит твоего больного, но рекомендовать его на все случаи жизни, ИМХО, не стоит.
На всякий случай напоминаю — я просил найти слабые стороны процесса FDD, а не выливать мне на уши тонны общих фраз.
Суть твоего ответа заключалась в том, что ты не умеешь анализировать процесс разработки по его описанию, определять сильные и слабые стороны, и границы его применимости. Понятно. Посмотрим, что скажут другие.
Re[7]: Хороший agile
От:
Аноним
Дата:
18.04.08 16:26
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
G>>>Жизнь заставляет. Я стараюсь учитывать сильные и слабые стороны людей индивидуально, а не подходить к ним с общей гребенкой. Люди от этого лучше мотивированы и продуктивнее работают.
А>>Роль — это всего лишь шапка, а на кого ее нацепить — это всегда надо решать индивидуально, А>>с учетом сильных и слабых сторон.
G>Я оперирую обязанностями и ответственностью, а не ролями.
Но ведь обязанности как-то классифицированны и сгруппированы?
В общем не верю, что ты совсем не оперируешь ролями.
Если я у тебя спрошу, а кто у тебя руководитель проекта, то ты наверняка ответишь.
А иначе было бы очень странно...
Здравствуйте, Gaperton, Вы писали:
G>Блин, ну просто кто во что горазд. По теме есть что сказать? Конкретные проблемы в подходе FDD найти можете, которые будут мешать разработке?
Мне понравилось — особенно явный акцент на class ownership. Такое впечатление, что там много основано на здравом смысле и практическом опыте, а не на неких абстрактных размышлениях типа того, что если посадить двух программистов за один монитор, то они будут друг-за-другом надзирать и код получится идеальным. Может для абстрактных сферических программистов это и так, но ежу понятно, что два реальных человека поссорятся насмерть уже через пару недель такого плотного общения Вообще, мне кажется, что это правильная метода, надо будет изучить более подробно, спасибо за наводку
Здравствуйте, 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>А также потому, что исправление дефектов и реализация фич иногда требует хирургического рефакторинга и тонкой инженерной работы, подчас — продолжительной и объемной.
Прочитал три раза. Думал привиделось
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 вообще что говорится о тестировании во время разработки?
Итеративность вообще практически на нуле. Даже инкрементность не проглядывается. Только для показухи и контроля дефектов.
Зато чтоб манагер не скучал, ему добавилась куча контрольных инструментов. Но что он сможет делать по результатам своих оценок?
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, или же — основой плана при большом вотерфоле.
Здравствуйте, VGn, Вы писали:
VGn>Ну и что осталось от твоего "лёгкого и простого процесса"?
Как что? Основные фазы, процессы, и артефакты. Организация работ внутри product development — разработчикам можно тупо книгу дать для прочтения, а потом сказать список коррекций, и все. А не читать круглые сутки курсы лекций, а потом личным примером показывать и рассказывать. А сквозные процессы между отделами я все равно кастомными сделаю.
Здравствуйте, VGn, Вы писали:
VGn>У меня складывается ощущение, что ты и сам уже понял что этот "простой и лёгкий FDD" на самом деле просто убог и построение разработки на его основе будет напоминать кашу из топора. VGn>(Не надо требовать и здесь раскрытия темы. Пройдись по всей ветке и посмотри сколько усовершенствований и исправлений FDD предложил ты сам)
Ну да. Я собственно, ничего страшного не вижу в этом. Любой процесс надо кастомизировать, чтобы он заработал.
Теперь смотри. Берем RUP — его кастомизация при внедрении сведется к выбрасывынию и упрощению части его фич и процедур. Все равно внерить его сразу в тяжелом виде невозможно — и упрощения будут. Геморрой это, РУП внерять. Разработка стопорнется.
Проще поступить по другому. Взять простую заготовку — вроде FDD. Внедрить малой кровью. Потом, вторым этапом — оптимизировать, накрутив поверх несколько кастомных расширений по месту, и станет хорошо. Понимаешь — я в данный момент озабочен вопросом реального внедрения процесса. А ты — похоже, относишься к процессу как к вещи в себе. Ищешь в них чего-то удивительного и нового. Да не может быть ничего нового в работающих процессах.
Отличие FDD от скажем скрама — FDD это хорошая заготовка, которая очень хорошо расширябельна и в правильные стороны. А если и не расширять — то она будет все равно лучше чем колхозная разработка. То есть, она даст положительный эффект сразу после внедрения.
VGn>>Декларируются принципы и подходы, которые в общем и ежу понятны, G>Ты предпочитаешь методологии, которые декларируют подходы и принципы, которые понять могут только люди с IQ больше 150, я правильно тебя понимаю? Если нет — то тогда к чему ты вообще это сказал?
Кстати. Ты не находишь, что тут есть некоторое противоречие:
— разработчики достаточно талантливы, чтобы обойтись без аналитиков и сформулировать чёткие и безопасные требования до разработки
— разработчики недостаточно умны, чтобы вникнуть в сколько бы то ни было сложный процесс
?
VGn>>Ну так бывает. Может не у тебя, но в 90% проектов — точно. G>Знаю что могут. Для этого требованиями надо управлять, предвидеть это, и ставить процесс под контроль.
В соседней ветке я уже писал о том, что подход, когда надо предвидеть все изменения требований, сильно сильно утяжеляет архитектуру. Потому что более гибкая архитектура при том же качестве обычно более тяжеловесна и менее производительна.
VGn>>Имеем: VGn>>Риски расширения требований. — придётся менять команду? G>Почему это обязательно придется менять команду при расширении требований? Не понимаю.
Это о привязке структуры команды к структуре требований. Может быть слишком утрировано.
VGn>>Риски исчезновения требований или просто временное снятие фич. G>"Временное снятие фич" — это что такое? Пример пожалуйста. Риск исчезновения требований — это как? Если требования ты сам собираешь — как они могут исчезнуть внезапно и неожиданно, независимо от тебя, а?
Заказчик не статичен. Все мои рассуждения (как и тезисы agile) построины именно на этом.
VGn>>Итеративность вообще практически на нуле. Даже инкрементность не проглядывается. Только для показухи и контроля дефектов. G>Обоснуй.
Ткни меня носом в инкрементность в FDD. Хотя бы с точки зрения MSF. Не вижу. Где цикличность процессов?
G>?! Что манагер может делать? Неожиданные вопросы, однако. Прям я даже растерялся. Манагер может управлять приоритетами и рисками, уточнять прогнозы, что выльется в сортировку и изменение фичлиста.
Всё. Проехали. У нас с тобой разное понимание слова "управление".
Здравствуйте, VGn, Вы писали:
VGn>По моему довольно понятно. Ватерфол в своей разработке я не использую, а FDD не буду использовать тем более. VGn>Видимая мной ценность ватерфола — его официозность и понятность для заказчика, если заказчик хочет лезть в процесс разработки. VGn>FDD в этом отношении выглядит откровенно слабым и учитывая, что он имхо по всем статьям проигрывает гибким методам, мне он абсолютно не интересен хотя бы в силу в силу своей опасности (если ты не в курсе: один из основных тезисов agile — ватерфол опасен).
Это ватерфол опасен? Ну прям не знаю. Мир agile — мир зазеркалья какого-то. Там все наоборот .
Короче, резюмируя. С точки зрения человека, привыкшего к agile (вероятно — scrum), FDD — это, во первых, не agile. Он слишком много берет от ватерфола, и разделяет все его основные недостатки, как-то: и далее по списку agile vs waterfall. Я правильно понял твое заключение? Если так, то ты, кстати, второй, кто такое говорит.
И это меня радует. Значит, не зря мне FDD приглянулся.
Здравствуйте, VGn, Вы писали:
VGn>>>Я не имел в виду жёсткость связи. Я имел в виду жёсткость самой методологии привязки. G>>Раскрой тему плиз. Объясни, в чем она состоит, и почему это плохо. VGn>Мне показалось, что весь FDD по факту только и является раскрытием этой темы. А жёсткость в выборе метода осуществления требований, по моему мнению, всегда является слабым местом методологии. Будь то FDD, XP или SCRUM. VGn>Я с первого взгляда, как увидел эти тягучие линейные блоксхемы FDD, понял что мне хотят впарить какую-то ерунда.
Хм. А я их пока не смотрел. Ну-ка загляну тоже, вдруг и правда ерунда.
VGn>Для меня ценность методологии в выборе инструментов, а точнее наборов этих инструментов. Когда инструменты начинают меня ограничивать в выборе методов, я меняю инструменты на другие.
А я не отношусь к методологии как к набору ограничений. Для меня это — тулкит для построения своих собственных процессов (этому кстати учит PSP/TSP — не работает — меняйте!). Что-то мешает — внесу правку и рука не дрогнет. Вопрос — не пришлось бы менять слишком много. Вот скрам придется заменять весь целиком . А FDD — пока кажется что точечных правок хватит.
Здравствуйте, VGn, Вы писали:
VGn>Но и не в этом суть. Это всё об инкрементной разработке. А я говорил об управлении изменениями требований. Надеюсь ты не станешь спорить с тезисом, что увидев рабочий прототип, заказчик может (и должен иметь право) изменить некоторые свои требования (в том числе и с подачи разработчиков)?
Ах ты об этом, оказывается? Так в чем проблема-то? Составляешь вместе с заказчиком фичлист на первую итерацию. Забубенил итерацию. Показал прототип. Повторяешь — перечисленное — новый фичлист на вторую итерацию. Нет проблем. А итерации вывести на заданную дату — в чем проблема, я перекину фичи которые не успеваю на следующию итерацию, и все.
VGn>>Думаешь зачем я абзац с начала процитировал?
G>Понятия не имею — не умею мыслей читать. И расшифровывать их по коротким шифровкам из центра — тоже.
А по экрану?
Наличие управления требованиями является безусловно сильной стороной FDD.
vs
Я бы тоже не назвал фичлист управлением требованиями. А управление требованиями при облегченном процессе в голове происходит, понимаешь?
G>Теперь смотри. Берем RUP — его кастомизация при внедрении сведется к выбрасывынию и упрощению части его фич и процедур.
Скорее к построению процесса из постоянно растущего набора доступных фич и процедур. RUP довольно гибок.
G>Проще поступить по другому. Взять простую заготовку — вроде FDD. Внедрить малой кровью. Потом, вторым этапом — оптимизировать, накрутив поверх несколько кастомных расширений по месту, и станет хорошо. Понимаешь — я в данный момент озабочен вопросом реального внедрения процесса.
Главное в таком случае не напороться на принципиальные противоречия разнородных методов.
G>Отличие FDD от скажем скрама — FDD это хорошая заготовка, которая очень хорошо расширябельна и в правильные стороны. А если и не расширять — то она будет все равно лучше чем колхозная разработка. То есть, она даст положительный эффект сразу после внедрения.
Ню-ню. Попробуй. Потом расскажешь.
Здравствуйте, VGn, Вы писали:
VGn>>>Декларируются принципы и подходы, которые в общем и ежу понятны, G>>Ты предпочитаешь методологии, которые декларируют подходы и принципы, которые понять могут только люди с IQ больше 150, я правильно тебя понимаю? Если нет — то тогда к чему ты вообще это сказал?
VGn>Кстати. Ты не находишь, что тут есть некоторое противоречие:
Тут нет противоречия. Сейчас объясню.
VGn> — разработчики достаточно талантливы, чтобы обойтись без аналитиков и сформулировать чёткие и безопасные требования до разработки
Талантливость разработчиков тут не причем. Они строят модель в присутствии заказчика, и я прослежу чтобы в группе был программер кто имеет навык работы с требованиями. Это, кстати, не редкость. Нормальный аналитик — редкость.
VGn> — разработчики недостаточно умны, чтобы вникнуть в сколько бы то ни было сложный процесс VGn> ?
Здесь не причем ум. Ты исходишь из посылки, что основная сложность при внедрении процесса — это ум индивидуальных разработчиков. Это не так. Видишь ли, как я говорил — во время работы в CQG у нас был профессионально внедрен PSP/TSP по всей конторе. И я видел, как идет внедрение и какие происходят при этом сложности.
Вот смотри. Футбол. Там от ума и профессионализма отдельных игроков зависит много. Но еще больше зависит от сыгранности команды. И ее, этой сыгранности, добиться — это основной геморрой. За это тренерам платят большие деньги, и именно это определяет успех. Когда ты говоришь о процессе — надо понимать, что это командный навык. И чтобы он выработался — нужно время. И умение менеджера. Либо — можно конечно забашлять консультантам баблос, чтобы они стопорнув тебе разработку внедрили процесс. При этом — эти консультанты — лохи процентов на 90.
Поэтому, процесс надо внедрять постепенно, по элементам, и он должен быть простым. Это ключевой фактор успеха. Сложные процессы внедрять затрахаешься. Вот, скажем, PSP/TSP — это сложнейший процесс, который внедрить без отрыва от производства и привлечения внешних консультантов вообще невозможно. Кроме того, сложные процессы тяжелее поддерживать, они требуют инфраструктуры и оттягивают ресурсы на поддержку своего функционирования. Либо — работают только в воображении руководства, а на местах их игнорируют и наблюдается на самом деле бардак и скрюап.
Вот почему легкий процесс — это единственно работающий на практике способ. А вовсе не потому, почему говорят в манифестах agile. Это мое мнение.
Здравствуйте, VGn, Вы писали:
G>>Теперь смотри. Берем RUP — его кастомизация при внедрении сведется к выбрасывынию и упрощению части его фич и процедур. VGn>Скорее к построению процесса из постоянно растущего набора доступных фич и процедур. RUP довольно гибок.
RUP мне нравится, но убить полжизни на его изучение я не готов. Оттуда можно брать идеи. Но это слишком сложный процесс тулкит имхо, хоть и хороший. То же самое я могу сказать о PSP/TSP.
G>>Проще поступить по другому. Взять простую заготовку — вроде FDD. Внедрить малой кровью. Потом, вторым этапом — оптимизировать, накрутив поверх несколько кастомных расширений по месту, и станет хорошо. Понимаешь — я в данный момент озабочен вопросом реального внедрения процесса. VGn>Главное в таком случае не напороться на принципиальные противоречия разнородных методов.
Верно. Ты абсолютно прав. Именно это я сейчас и пытаюсь выяснить — нет ли где скрытых противоречий. Пока вроде все гладко.
Здравствуйте, VGn, Вы писали:
VGn>>>Думаешь зачем я абзац с начала процитировал?
G>>Понятия не имею — не умею мыслей читать. И расшифровывать их по коротким шифровкам из центра — тоже.
VGn>А по экрану? VGn>
VGn>Наличие управления требованиями является безусловно сильной стороной FDD.
VGn>vs VGn>
VGn>Я бы тоже не назвал фичлист управлением требованиями. А управление требованиями при облегченном процессе в голове происходит, понимаешь?
А, ты об этом. Фичлист — это артефакт. Процесс управления требованиями — это работа с этим артефактом. Элемент фичлиста — требование. Составление и правка фичлиста — управление требованиями. Есть фичлист — все, управлять требованиями возможно, это минимально необходимый для этого артефакт.
Здравствуйте, VGn, Вы писали:
G>>Ты тоже новизны захотел? Какая в задницу новизна? Я тебе разве о новизне говорю? Это ватерфол в чистом виде, только облегченный и упрощенный, ты что, не заметил еще? Почитай первый пост — внимательно. Почему ты не читашь посты?
VGn>Читаю. Читаю. Зачем так тему назвал?
Хм. Да как-то не подумал, что меня будут рвать на куски сторонники agile Втупил . Я это название для ватерфольщиков писал.
VGn>Облегчённый и упрощённый для чего? Для работы или для понимания? VGn>Процесс разработки для идиотов что-ли?
Читаю я эту статью (по второму разу, поглядывая на обсуждения) и задумался — а что такое project в рамках FDD.
Т.е. когда у нас большой проект стартует с нуля, без имеющейся системы и т.п. — то все понятно.
А вот когда близкая моему сердцу проблема поддержки и развития большой системы (ну, как всегда, немножко багов, куча мелких украшательств, множество больших задач и не меньшее множество требующихся рефакторингов и все это для 24*7).
Что проект в этом случае. Develop Overoll Model мы когда делаем?
Разделять "большие задачи" (как отдельные проекты) и текучку (как специальный проект) — не хочется.
Прогонять каждую просьбу заказчика (от "подвиньте кнопку влево" до "а еще хочется тесную интеграцию с SAP R3") через весь процесс — тяжеловато (хотя смысл есть — по FeatureRequest у нас появится Feature, которой можно будет управлять и которую можно трекать. Правда, в FDD нет ничего до "Feature" — что пугает, непонятно, откуда она берется).
Можно еще считать, что у нас есть замечательный проект "продержаться еще квартал" и делать DOM на основании всего, что хочется в квартале реализовать, но это тоже как-то не то.
Кстати, баги проходят по процессу как Features, да?
G>. Главное — что он предлагает сделать domain model две недели, и продать это задешево, а по итогам domain model выдать прогноз всего проекта. Это — правильно. У нас в этот момент будет достаточно информации, чтобы дать нормальный качественный прогноз трудозатрат.
Согласен.
Осталось научится продавать предварительный этап (по итогам которого делать оценку) отдельно от основной разработки.
G>И делать прогноз можно вовсе не таким дебильным образом, как умножение длительности первой фазы на пи. А по нормальному — с оценкой вариаций сроков, и проверкой через коридоры метрик..... Я, например, в любом случае воспользуюсь своим методом оценки трудозатрат, он гораздо совершеннее, чем придумки агилистов.
Где-нибудь можно о вашем методе почитать?
RGB>>А вообще, прочитав все это — мне не очень понятно, почему FDD = agile? Если почитать agile manifesto (например перевод здесь), то там есть фраза типа RGB>>"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." RGB>>А в FDD мы feature list формируем заранее. Итеративными (как я понимаю) являются только фазы конструирования. G>Да, мне тоже это непонятно, что общего у FDD и типичных agile вроде scrum и XP. FDD — не имеет косяков agile — вы назвали один из них зацитировав манифест . FDD выглядит как облегченнная классика.
Почему косяк? Вот тезис:
Если допустить постоянное контролируемое изменение требований — у нас больше шансов сделать именно то, что нужно клиенту. В самом начале разработки ни у заказчика ни у исполнителя может не быть понимания — что это должна быть за система. И предварительное проектирование и прототипирование может не помочь в этом. Бывает, что заказчик осознает что же ему нужно только после того как увидит первую версию системы. Согласны?
RGB>>Мне вот было бы интересно пообщаться на тему "применения agile (FDD) в fixed price проектах". Ибо почитал тут Фаулера и он говорит что agile и fixed price вместе не живут . А так хочется...
G>Я не вполне понимаю, что такое "agile" в fixed price проектах, и откуда вообще возникает такое желание — "применять agile". Для фиксед прайс ключ к успеху — управление требованиями, предварительное проектирование и точное планирование. Фиксед прайс заказуха — уже ставит вас в определенные рамки, если вы следуете, скажем, ГОСТ-у. А ему лучше следовать, не изобретая велосипедов.
Рассказываю откуда возникает желание "применять agile" .
Хочется
1) Делать продукт, который нужен клиенту, а не тот, на который клиент подписался в начале разработки.
2) Быстрее осязать результат разработки — принцип frequent delivery. Просто приятно видеть как оно работает уже через неделю а не через 2 месяца.
3) Ощущать обратную связь от заказчика (пользователей) — работать вместе с ними.
4) Работать в команде мотивированных профессионалов, которым руководство доверяет в принятии решений.
5) Минимизировать количество документации "на будущее". Общаться лицом к лицу с другими девелоперами (а не по бумажкам в почте). Меньше бюрократии.
6) Не изобретать "универсальных велосипедов" в реализации. Руководствоваться принципом "нам это никогда не понадобится".
M>>предметной области, не подверженной частым изменениям; G>Фичлист — это ключевое. Это проверенный ватерфольный способ управлять этими изменениями сохраняя ватерфольный контроль и прозрачность. И все лишнее отрезано — но может быть добавлено при необходимости обратно. Очень хорошо.
FDD — не предполагает какое бы то ни было изменение набора (или содержимого) фич, после того как конструирование началось. Это — недостаток FDD о котором вам уже несколько раз говорили . Вы говорите, что сами справитесь с управлением изменениями имея фичлист. Замечательно. Только в FDD — этого нет. Эта ваша "додумка". Мы ведь собрались покритиковать FDD, а не то как вы изящно будете выкручиваться из неприятностей используя его .
M>>и стабильной команде с низкой текучкой. G>Вы забыли про обязательные design и code review. Это единственно работающий на практике механизм рапространения знаний, помимо того что он увеличивает качество софта и дает лучший контроль над процессом.
Ну отлично . А, например, парное кодирование делает design и code review более дешевым и эффективным. Оно происходит в процессе design и code.
Про design и code review в FDD ни сказано не слова. Опять выкручиваетесь?
Дочитал таки тред до конца и кратко изложу свой опыт использования похожего подхода, т.к. процесс уже неплохо проанализировали по доке
В Мотороле применяется как раз процесс разработки от фича листа, т.к. это дает возможность на всех уровнях четко отслеживать функциональность поставляемую потребителю. Все проблемы делятся на новую функциональность (фича) и Change Request (СR. он же баг). Даже процессы рефакторинга, чистки кода, улучшения производительности и т.п. выполняются как фичи. Естественно процесс работы всей организации существенно сложнее и удовлетворяет СММ 5 уровня (или уже CMMI), но суть разработки от этого не меняется — выкинув неинтересные в данном контексте приплясы разных отделов получаем разработку в точности по FDD.
Проекты ведутся на длительной основе, т.к. один и тот же продукт сдается множеству заказчиков в течении продолжительного времени. Провайдеров много и требования у них специфичные. Кодовая база существует уже 15 с лишним лет и разделяется на несколько бейзлайнов. По сути на одном бейзлайне с одновременной поддержкой кучи провайдеров (команда поддержки 100+) нужно начинать разработку нового функционала и для этого формировалась фича команда (в зависимости от размера фичи от 5 до 25 человек), а далее все примерно как описано. Недостатком было то, что код фича команды по завершению работы обязательно ломал какие либо другие фичи не зависимо от инспекций и фича тестирования. Просто кода много и что-то обязательно сломается, а выплывало все при тестировании "в поле" или у провайдера. Таким образом, главным недостатком данного подхода на больших продуктах с одновременным циклом поддержки является появление ошибок в несвязанных на первый взгляд кусках кода во время сдачи продукта заказчику и необходимость перевода большей части фича команды на фикс багов в авральном режиме. Повторюсь — инспекции кода с участием архитекторов, опытных разработчиков и людей ответственных за определенные части кода помогают слабо. Глупые ошибки фиксятся и остаются самые трудноуловимые
Для устранения недостатков этого метода было сделано разделение всего кода между компонентами с назначением компонент лидов и теперь фичи делаются так: определяется набор фич, каждая фича анализируется архитектурной командой и результатом анализа является некое разбиение на затронутые компоненты с указанием примерного фронта работ и трудоемкости, компонент лиды анализируют кусочки фичи затрагивающие их компоненту и выполняют разработку силами компонентной команды. За разработкой фичи следит специально выделенный человек — фича лид. Его задача разруливать взаимодействие между компонентными командами и следить за доставкой всей фичи в срок. Ситуация сильно улучшилась, но появились проблемы с тем, что интересность такой работы существенно ниже, т.к. копаться в том, что хорошо знаешь мало интересно. Поэтому компонентные команды набирались так, что бы уход одного или двух человек в другие команды не сильно влиял на конечный результат. Таким образом FDD несколько мутировал и в чистом виде есть только в разработке компонентных команд, а сверху на него надстроили дополнительные контролирующие мероприятия. Основное же отличие от описанного в википедии FDD проявляется в том, что теперь команда не обязана разбираться в соседних предметных областях и понимать суть всей фичи — это обязан делать фича лид и разъяснять кому потребуется. Соответственно, при сколь нибудь серьезной фиче, разработкой ему уже заниматься некогда.
Это я изложил коротко... Если интересуют конкретные моменты практического использования, то спрашивайте
Я бы даже сказал — в тех толковых командах, которым удалось состояться как толковые без чтения кем-то ПиЭмских книжек , именно к этому и приходят интуитивно. Пришли — благо. Не пришли — что ж, тут и развалиться можно.
Роадмап только надо бы иметь, конечно. На фазах 1-2 обсуждается ворох фич на 2-3 релиза вперед, лучше — насколько хватит прозорливости ПиЭма. Цель — убедиться, что "очень будущие" фичи отражены в архитектуре, что позволит их легко реализовать без глобальных изменений.
Фазы 1 и 2 надо объединить в цикл. Архитектура должна быть от фич, и ревью архитектуры должно делаться _в первую очередь_ от фич, вопросами от ПиЭма архитектору — "а как в этой архитектуре будет реализована фича В"?
Слово "класс" я бы убрал напрочь, деление по девелоперам должно быть более крупными кусками, целыми подсистемами.
Идея нескольких subsystem ownerов, играющих роль коллективного архитектора, очень хороша.
Кстати, такое построение позволяет еще и решить сложные задачи с минимумом человекоресурса.
Здравствуйте, A.Lokotkov, Вы писали:
G>>Я не делал проектов с agile. Все success stories только с waterfall.
AL>Давно хотел спросить, но стеснялся. Можно хотя бы одну success story? Например, с предыдущего места работы. Спасибо.
Здравствуйте, stump, Вы писали:
G>>Это не объяснение, это хорошая сказка на ночь. Аналогия довольно наивна, и, наверное хорошо действует на людей, плохо разбирающихся в процессах разработки софта. Вероятно — именно так и впаривают agile.
и все же +1
S>>>Если говорить о ядре Linux, то сейчас он разрабатывается по методологии Open Source. G>>Надо же, кто бы мог подумать? А я-то думал они работают по Closed Sourcе.
тоже верно
S>Вы никогда не задумывались, что если люди разбросанные по всему миру умудряются умудряются создавать достаточно успешный софт, это означает, что эти люди смогли наработать определенный опыт и приемы, помогающие им в этом нелегком деле.
а вот тут возник вопрос:
— можно узнать примеры таких достаточно успешных продуктов, построенных и развиваемых по тому же Scrum?
— заодно к таким примерам интересны и критерии достаточноуспешности. Чтобы было понятнее о чем речь — например у Гапертона в этом ответе
— это важно, сразу отмечаю что хочется послушать не об успехе команды из трех пионеров, прочитавших книгу по Scrum и нарисовавших\поддерживающих сайт с его помощью. Интересно как раз послушать про серьезные проекты\продукты уровня 20 человек и выше.
PS что характерно, в wiki про SCRUM никакой секции про достижения народного хоз-ва — т.е. про реальные всемирноизвестные продукты серьезного уровня, произведенные по этому процессу мной не обнаружено. Проглядел?
G>>ЗЫ: сколько умных слов не по теме — кошмар, но почему-то никто не в состоянии ничего предметно сказать про FDD, и прочитав его описание. Интересно — я вообще в профильную конфу "управление пректами" написал — или случайно попал в "священные войны"?
тоже верно S>Я так понимаю, что по делу вам возразить нечего.
тоже верно
в любом случае вредно смешивать контексты и темы, поэтому просто можно ответ на вопрос чуть выше?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re: возник вопрос про достижения народного Scrum хоз-ва
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>PS что характерно, в wiki про SCRUM никакой секции про достижения народного хоз-ва — т.е. про реальные всемирноизвестные продукты серьезного уровня, произведенные по этому процессу мной не обнаружено. Проглядел?
Учитывая, что Scrum сейчас самая популярная agile метода, то подобные проекты, вероятно, привести можно. Чисто случайно где-то может что-то получится. Этим методом вполне можно сделать хороший продукт, если он состоит из набора слабо связанных между собой фич, и командой фактически руководит гуру в предметной области, который великолепно знает, что надо делать, а что не надо.
Вообще, сам по себе scrum крайне слабый метод. И если кто-то добивается с ним успеха — так это не благодаря, а вопреки. На голом энтузиазме. Проблема скрама и XP в том, что они противоестественны, в том смысле, что противоречат опыту и интуиции опытных разработчиков. Такие вещи не живут и оптимальными являться не могут. Студенты с бестолковыми менеджерами, как люди, не имеющие фактического опыта, подвох распознать не в состоянии.
Огромный плюс FDD — он согласуется как с опытом, так и с известными best practices, и интуитивно понятен. И главное — он разработан на живом и успешном проекте со 150 инженерами, что уже доказывает его жизнеспособность.
Так что я бы вопрос переформулировал.
1) На опыте какого рода проектов разработан Скрам?
2) На каких проектах он проходил обкатку в процессе разработки?
Ответы на данные вопросы позволяют быстро привести разговор с небес на землю. Однако, в данной конфе разговаривать о процессах на таком абстрактном уровне практически не с кем. Те, кто что-то в теме соображают — в дискуссию чаще всего не лезут.
Re[2]: возник вопрос про достижения народного Scrum хоз-ва
Здравствуйте, Gaperton, Вы писали:
VAB>>PS что характерно, в wiki про SCRUM никакой секции про достижения народного хоз-ва — т.е. про реальные всемирноизвестные продукты серьезного уровня, произведенные по этому процессу мной не обнаружено. Проглядел?
G>Учитывая, что Scrum сейчас самая популярная agile метода, то подобные проекты, вероятно, привести можно. Чисто случайно где-то может что-то получится. Этим методом вполне можно сделать хороший продукт, если он состоит из набора слабо связанных между собой фич, и командой фактически руководит гуру в предметной области, который великолепно знает, что надо делать, а что не надо.
согласен. работая именно в таких условиях уже достаточное для формирования определенных выводов время, мне интересно: есть ли заметные (в глобальном масштабе) прецеденты вокруг. не PR в СМИ мол "весь yahoo теперь работает по scrum", а реальные продукты и их линейки с полным циклом поддержки уже отгруженных клиенту версий и где размер команды превышает правило 7 плюс-минус 2, и\или число команд больше чем одна (Scrum of scrum и вопросы масштабирования — тоже отдельная песня) и т.п.
учитывая, что мой вопрос stump задавался также и на Scrum тренингах сертифицированному "профессионалу" по этому делу (и был технично не отвечен с конкретными примерами. Равно как и были проблемы с ответом на вопрос о границах применимости, что характерно) — при прочтении ответа stump у меня возникло логичное любопытство спросить, раз человек утверждает что знает таковые и более того это широко известно.
G>Вообще, сам по себе scrum крайне слабый метод. И если кто-то добивается с ним успеха — так это не благодаря, а вопреки. На голом энтузиазме. Проблема скрама и XP в том, что они противоестественны, в том смысле, что противоречат опыту и интуиции опытных разработчиков. Такие вещи не живут и оптимальными являться не могут. Студенты с бестолковыми менеджерами, как люди, не имеющие фактического опыта, подвох распознать не в состоянии.
к сожалению, все именно так. и это может быть еще вполне мягкое описание положения дел. Есть и много психологических\человеческих аспектов о которых не (на)пишут правдиво ни в одной книге адепты. Или достаточно верно описывая проблемы, извращают выводы на противоположные — что создает нездоровый оптимизм по прочтении у еше не почувствовавших по чем тут фунт изюму товарищей.
но тут стоит снова говорить о границах применимости: считаю, Scrum сам по себе не есть ни зло ни добро.
это как любой инструмент, как нож: где-то подойдет, а где то бесполезен или вреден.
так вот и складывается мнение, что на серьезных продуктах Scrum можно применять, но очень дозированно и точечно — для каких-то исключительно более-менее ложащихся на него вещей: (прототипы) GUI и т.п. штуки\стадии где действительно идет плотная работа с заказчиком и при этом не требуется серьезного технического background (который реально может все красивые задумки "испортить").
Может быть даже лучше говорить о том где нельзя применять Scrum вообще — research, проекты с высокой сложностью и неопределеннностью. Даже если подразумевается высокая изменчивость — у меня серьезное сомнение что agile методы вроде бы так быстро реагирующие как раз на изменения чего-угодно тут всегда есть "best choice".
G>Огромный плюс FDD — он согласуется как с опытом, так и с известными best practices, и интуитивно понятен. И главное — он разработан на живом и успешном проекте со 150 инженерами, что уже доказывает его жизнеспособность.
да, это интересно — поэтому прочел ветку с удовольствием, спасибо всем поучаствовавшим в обсуждении
G>Так что я бы вопрос переформулировал. G>1) На опыте какого рода проектов разработан Скрам? G>2) На каких проектах он проходил обкатку в процессе разработки?
вот именно — то о чем я тоже начал было речь выше и то что неявно подразумевал в своем вопросе из пред сообщения — если честно интересно сверить успешные примеры (если найдутся) как раз по этим параметрам с тем мнением, что уже сложилось по поводу методы.
G>Ответы на данные вопросы позволяют быстро привести разговор с небес на землю. Однако, в данной конфе разговаривать о процессах на таком абстрактном уровне практически не с кем. Те, кто что-то в теме соображают — в дискуссию чаще всего не лезут.
И то верно, зачем лезть, если, вообще говоря, тут если не всё, то многое уже понятно. Особенно, если есть практический опыт работы и "по-старинке" и "по-модному". Да и опыт даже не в Scrum конкретно важен — насколько я понял, например, Вы не вели (под)проектов по такой методе и тем не менее проблемы Вам очевидны — давно плюсую большую часть Ваших ответов т.к. даже не нужно ничего своего писать-добавлять (это экономит время) — Вы отлично справляетесь А спорить с кем-то менее опытным в таких вопросах — зачастую потеря времени (все равно проблема научит лучше), плюс цель обратить в свою веру не стоит (в отличие от адептов).
Нам тоже многие вещи были понятны еще до того как была спущена команда "Фас! Вся компания работает начиная с завтра по Scrum и это не обсуждается". Более того почти все они сыграли, многие печальные прогнозы полностью подтвердились.
Так что то, чем приходится заниматься командам последнее время действительно характеризуется фразами "вопреки, а не благодаря", "на энтузиазме" (который не бесконечен). Тем не менее работать надо в любых условиях и поэтому я очень внимательно читаю и выслушиваю адептов — все что касается "недружественных" опытному разработчику процессов и Scrum в частности — чтобы на своем уровне хоть как-то можно было где-то ослабить негативное влияние, а где-то даже разглядеть и по максимуму использовать те немногие бенефиты, что все же иной раз обнаруживаются.
Плюс допускаю что какие-то вещи могли быть неверно интерпретированы\реализованы в наших краях и соотв. важно сверять с тем как это рекомендуется делать согласно истинному Scrum (о котором у провозгласивших наверху смену курса также весьма искаженное понятие, что характерно). И здесь было бы полезно найти "достаточно успешные" примеры и в идеале выяснить что и как делается у них, какие у них границы применимости и специфика. Вот мой интерес в этом вопросе
посему ответ stump и\или других знающих о достижениях народного хоз-ва коллег — по-прежнему будет с благодарностью принят и прочтен, ссылки приветствуются!
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Однако, коллеги, удивительное рядом. Я нашел легковесную методологию, которая не убьет проект, не противоречит здравому смыслу, и вполне жизнеспособна. Короче — не killed in assembly 
Надо воскурить мануалы...
. А так хочется...
. Вас кто-то просил? Короче все. Всего доброго, большое спасибо, до следующих встреч. Слава богу, появились ответы по существу.
Мы уже победили, просто это еще не так заметно...
