- это мертвый 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.

Здравствуйте, Gaperton, Вы писали:


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 (не столь много внимания уделено называнию каждого чиха отдельным термином).

Но пока — всё. Надо воскурить мануалы...

Здравствуйте, 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 вместе не живут . А так хочется...

Ткни пожалуйста пальцем, где роли и компетенции? Как они сюда вообще лягут? Я честно понять хочу, но не могу...

Здравствуйте, Gaperton, Вы писали:

Хех, все большие флеймы по поводу методологий начинаются только когда некий юноша напишет что-нибудь вроде "я знаю новую методологию (...) она действительно поможет вам делать проекты быстро и качественно".

Когда же умудренный опытом джентлемен спокойно и взвешенно рассуждает о плюсах и минусах конкретных методологий тут флейма не дождесся. Потому как остальные джентлемены уже вполне в курсе, что проекты делают не методологии, а команды. И если команда хорошая, то она с 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. Это меня удивило, и заинтересовало. Захотелось разобраться подробнее.

Вот статья — вполне себе обзор. Я просил прочитать ее, и поискать в ней косяки, и обсудить это.
http://en.wikipedia.org/wiki/Feature_Driven_Development

Хорошего в легких методологиях только одно — что они "легкие", и поэтому их проще внедрить. Вопрос в одном — они нам убьют разработку, оставят бардак как был, или все-таки дадут некоторый положительный результат. Я пока не вижу, как 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 вместе не живут . А так хочется...

О! Нашел пост делюки на эту тему.

http://www.featuredrivendevelopment.com/node/527

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>Кадры решают все!

Хотите поговорить о кадрах — ну откройте отдельную тему — кадры решают все, и все с вами дружно согласятся, в том числе и я. А пока — может о процессах поговорим, а?