Здравствуйте, 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ов, играющих роль коллективного архитектора, очень хороша.
Кстати, такое построение позволяет еще и решить сложные задачи с минимумом человекоресурса.
Пример пожалуйста. Риск исчезновения требований — это как? Если требования ты сам собираешь — как они могут исчезнуть внезапно и неожиданно, независимо от тебя, а?
Мы уже победили, просто это еще не так заметно...
. А так хочется...
