А>Кроме того, достаточно очевидно, что внедрение "методологий" слишком трудоемкая штука, чтобы делать это под каждый проект.

То ли у вас проекты какие-то невероятно короткие, то ли вы что-то адское делаете для внедрения методологий.

Я вам даже больше скажу: может быть вполне целесообразным использовать более одной методологии в рамках одного проекта.

Допустим, у нас есть приложение, которое содержит некоторую функциональность, требующую применения сложных, наукоемких алгоритмов. Проект распадается на две части: первая часть содержит интерфейс пользователя, бизнес-логику и некоторую мелкую функциональность, а вторая — те самые сложные алгоритмы, которые нужно разработать. К первой части проекта Agile отлично подходит и с большой вероятностью приведет к успеху, а во второй части Agile нафиг не упал, так как там требования формулируются довольно просто и коротко, user stories тоже много не наскребешь, а вся сложность заключается в реализации. В наукоемкой части целесообразно будет применить водопад.

По-моему, такое разделение проекта на методологии является совершенно естественным, я даже не вижу других вариантов.

А>Для проектов методологии не нужны — понятие методологии противоречит самой сути "гибкости". Нужны методы, которые можно свободно комбинировать.

Методология — это система методов, объединенных общей идеей. Собственно, в этом ее и смысл. Если вы свободно комбинируете методы — значит, у вас либо своя собственная методология, либо вообще нет никакой методологии.

Могу согласиться, что если у вас достаточно опыта и интеллекта, то вам методологии могут быть не нужны — вы и без них знаете, что и как делать.

Очевидно, смысл использования методологии — получение некоторой гарантии успеха, независимо от личных качеств конкретного руководителя. Это как бы "рецепт успеха" (в идеале, конечно).

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

А>>Кроме того, достаточно очевидно, что внедрение "методологий" слишком трудоемкая штука, чтобы делать это под каждый проект.

SC>То ли у вас проекты какие-то невероятно короткие, то ли вы что-то адское делаете для внедрения методологий.

А вы думаете, для этого достаточно модную книжку прочитать? Чтобы всем рассказывать, что "у вас РУП", или "у вас Agile" — этого достаточно. Но не более.

Для внедрения методологии необходимо обучить людей, предварительно адаптировав ее процессы под ситуацию, и поддержав методологию тулами. Обычно, для этого разумно привлекать консультантов. Внедрение методологий — дорогое удовольствие, и в начале, пока люди не привыкнут (ибо работа под методологией — это командный навык), будет наблюдаться просадка продуктивности.

Отдачу подобные меры дают не ранее чем через полгода.

А когда вы адаптируете конкретные методы, вы полагаетесь на существующий командный навык, и получаете отдачу немедленно.

SC>Я вам даже больше скажу: может быть вполне целесообразным использовать более одной методологии в рамках одного проекта.

Сказать можете.

А>>Для проектов методологии не нужны — понятие методологии противоречит самой сути "гибкости". Нужны методы, которые можно свободно комбинировать.

SC>Методология — это система методов, объединенных общей идеей. Собственно, в этом ее и смысл. Если вы свободно комбинируете методы — значит, у вас либо своя собственная методология, либо вообще нет никакой методологии.

Я же ясно выразился, без всяких "либо". Методологии не нужны, нужны методы. И если я свободно комбинирую методы — это означает ровно то, что означает. А именно — я свободно комбинирую методы. Все.

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

SC>Методология — это система методов, объединенных общей идеей. Собственно, в этом ее и смысл. Если вы свободно комбинируете методы — значит, у вас либо своя собственная методология, либо вообще нет никакой методологии.

У ДеМарко в peopleware отлично написано про "методологии" и "Методологии". Первые нужны, вторые — нет.

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

SC>>Методология — это система методов, объединенных общей идеей. Собственно, в этом ее и смысл. Если вы свободно комбинируете методы — значит, у вас либо своя собственная методология, либо вообще нет никакой методологии.

G>У ДеМарко в peopleware отлично написано про "методологии" и "Методологии". Первые нужны, вторые — нет.

Я предпочитаю "методы" и "методологии", это точнее. Сам понимаешь, кто-то испытывает потребность в "общей идее", и при этом штоб ни в коем случае не думать, а кто-то — в том, чтобы сделать работу.

Ты выше писал — "что тогда продавать"? В случае с Методологиями продается именно идея, превращая инженерию в религиозный предмет. Big-M Methodology проще продать, ибо на дурака не нужен нож. Нет идеи — и че-та сразу и продавать нечего .

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

M>Что плохого в прогнозировании времени выполнения? Чувак вообще слышал про фокус фактор?!
я тебе скажу что плохого в планировании — оно тупо не работает. хоть с фокус хоть с покус фактором.
эджайл сосёт, проверено на людях.

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

SC>Очевидно, смысл использования методологии — получение некоторой гарантии успеха, независимо от личных качеств конкретного руководителя. Это как бы "рецепт успеха" (в идеале, конечно).

LOL.

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

SC>Допустим, у нас есть приложение, которое содержит некоторую функциональность, требующую применения сложных, наукоемких алгоритмов. Проект распадается на две части: первая часть содержит интерфейс пользователя, бизнес-логику и некоторую мелкую функциональность, а вторая — те самые сложные алгоритмы, которые нужно разработать. К первой части проекта Agile отлично подходит и с большой вероятностью приведет к успеху, а во второй части Agile нафиг не упал, так как там требования формулируются довольно просто и коротко, user stories тоже много не наскребешь, а вся сложность заключается в реализации. В наукоемкой части целесообразно будет применить водопад.

Кроме "сложных алгоритмов" есть немало моментов в разработке ПО где нужно семь раз подумать один раз закодить, как то общий дизайн подсистемы/модуля (классы/структуры данных, dataflow — кто push, кто pull и как оно это push/pull, errorflow — как и кем будут обрабатываться ошибки, драйвить всё через data или через code, асинхронно/синхронно, етц етц етц), бесшовная интеграция со сторонними апи и библиотеками, перформанс vs наглядность кода, и много ещё всяких ништяков приходится решать по ходу дела. Самое больное место при эджайле это рефакторинг. Не мелкий аля отформатировать код в соответствии с codestyle, а действительно глубокий рефакторинг какой-либо подсистемы. Больное оно потому что рефакторинг не добавляет функционал, а весь эджайл нацелен на замыливание глаз заказчика и как следствие очень feature-biased. Т.е. новому функционалу — да, рефакторингу — отложим.
В общем я для себя решил, что эджайл это такое уг для каких-то ну очень штамповочных вещей, вроде как мелкого сайтоклепательства. Т.е. там где цикл разработки продукта весьма невелик (до полугода) и вся разработка настолько шаблонна по природе, что её впору аутсорсить индусам. В общем эджайл — для индусов и замыливания глаз заказчика. Так и запишите.

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

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

M>>Что плохого в прогнозировании времени выполнения? Чувак вообще слышал про фокус фактор?!
Х>я тебе скажу что плохого в планировании — оно тупо не работает. хоть с фокус хоть с покус фактором.
Х>эджайл сосёт, проверено на людях.

Работает планирование, работает. Когда им занимаются квалифицированные инженеры, и когда оно не сводится к разным фокусам.

А Эджайл — сосет.

Здравствуйте, Аноним, Вы писали:

А>Работает планирование, работает. Когда им занимаются квалифицированные инженеры, и когда оно не сводится к разным фокусам.

согласен, нормальное планирование работает. а планирование в стиле эджайл — разобъём любую задачу на таски в несколько часов — сосёт.

А>Для внедрения методологии необходимо обучить людей, предварительно адаптировав ее процессы под ситуацию, и поддержав методологию тулами. Обычно, для этого разумно привлекать консультантов.

А вы, случайно, не являетесь тем самым консультантом, которого рекомендуется приглашать?

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

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

M>>Что плохого в прогнозировании времени выполнения? Чувак вообще слышал про фокус фактор?!
Х>я тебе скажу что плохого в планировании — оно тупо не работает. хоть с фокус хоть с покус фактором.
Х>эджайл сосёт, проверено на людях.

Прикольно Мой опыт работы в НИИ (6 лет) показывает, что все вариации водопада и спирали полный отстой, по сравнению с agile, с которым я на стороне работаю (3 года)
Если мозга нет — ничего не поможет

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>В свежем выпуске NT Insider обнаружил материал как раз для этого форума — представляю вашему вниманию статью из серии "Все что ты давно знал про Agile, но боялся сказать вслух"

У нас-то ситуация еще веселее. Широкие массы не в состоянии посмотреть в словаре, как "agile" переводится на русский, но готовы с жаром защищать...

__>У нас-то ситуация еще веселее. Широкие массы не в состоянии посмотреть в словаре, как "agile" переводится на русский, но готовы с жаром защищать...

agile более уместно не защищать, а агитировать

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

D>agile более уместно не защищать, а агитировать

Но его больше проповедуют Потому как требует веры, а не осмысления.

VAB>>Всем привет. В свежем выпуске NT Insider обнаружил материал как раз для этого форума — представляю вашему вниманию статью из серии "Все что ты давно знал про Agile, но боялся сказать вслух"

R>Ну а вообще, да, нормальное такое мнение, с дельными замечаниями. Только непонятно: если автор (чем он известен, кстати? книжкой про написание драйверов?) не работал в аджайле — то откуда такие ценные знания, а если работал — то почему мужественно все это терпел, не ушел и не сделал лучше?
Понятно. Проведем небольшую сессию Q&A для тех кто не в курсе:

Кто сказал что автор не имеет опыта?
— статья однозначно показывает (тому кто ее прочел внимательно и до конца), что автор напротив имеет очень четкое понимание что есть Scrum и прочие agile-пермутации, судя по всему без практики тут не обошлось

Кто сказал что не сделал лучше?
— именно эти люди ежедневно и уже много-много лет (20+) подряд доказывают своей работой (в т.ч. и щедро делясь своими секретами с сообществом) что если кто и делает что-то лучше, то это именно они. А книга по драйверам — это совсем уж не главный вклад, поверьте. К тому же чуток подустарела уже, время-то бежит.
— хотя бы то что эта статья написана и сейчас здесь обсуждается — они уже сделали мир лучше

Чем известны эти ребята (OSR)?
— Ну как бы объяснить попроще... ок, Марка Руссиновича знают многие — так вот он в молодые годы прошел школу и у этих ребят. Включая автора статьи.

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

SC>Ну да, если он разрабатывает какие-то компоненты операционных систем, то да, Agile для него не подходит, это понятно. Пользовательских требований у него вряд ли очень много, а надежность первостепенна. Если он будет использовать Agile, его любой назовет идиотом. Он в своей статейке возмущается, как, видите ли, неудобно забивать гвозди отверткой.
Коллега, мне кажется, у вас немного упрощенная картина мира по поводу низкоуровневых ребят ИМХО. Смотрите, сложность тут немного другого порядка — встраиваясь в ОС ты вынужден "жить в мире" со всем и вся (ОС, третий софт и железо, со всеми его глюками, пардон, особенностями). А это означает как раз массу use cases (и user stories, если угодно) на поддержку и на реализацию. Ну и надежность, т.е. качество — требуются высшего порядка, об этом можно даже не говорить — ну да, все в курсе

SC>Очевидно, что для разных проектов нужны разные методологии. Выбор методологии, например, определяется соотношением сложности требований к сложности их реализации. Например, в бизнес-приложениях обычно не требуется сложных алгоритмов и нестандартных архитектурных решений, но сложность и изменчивость требований может быть колоссальной; в научных расчетах, наоборот, требования к программе могут формулироваться коротко и однозначно, но сложность решения очень высока. Ясно, что в программе, требующей разработки сложных алгоритмов или обладающей большой архитектурной сложностью, не сядешь сразу писать код, так как просто ничего не получится, а в бизнес-приложении можно потерпеть неудачу, пытаясь сразу спроектировать все от начала до конца и учесть все требования. Отсюда и выбор методологии. Не знаю, зачем я это написал, это и так все знают.
послушайте, да ведь речь же в статье про другое. Причем тут специфическая предметная область и прочий BS? Речь о простой, веками усвоенной и знакомой нам с детства из поговорок, мудрости: "семь раз отмерь — один отрежь" и т.п. Своим всегда говорю "сначала думаем — потом делаем". Это полезно делать даже в "проектах с колоссальной изменчивостью требований" — просто потому, что это полезно делать едва ли не всегда. Не знаю, зачем я это написал, это и так все знают.

с тем что есть для agile подходящие области где он более-менее рулит — согласен. Даже не области — а, скажем так, стадии и фазы проектные — иной раз полезно выполнить в этом стиле. Плюс есть полезные (не во всех случаях!) на самом деле практики — типа standup meetings. Правда раньше их звали по простому — планерки

SC>Понятно, что заявления в статье смысла не имеют. Плохо забивать гвозди отверткой. Ну да, все в курсе.
имеют, имеют Но спасибо — вот это уже хороший ответ у Вас получился Только все же ИМХО дело не только в отвертках и гвоздях [ Ну почему мне кажется, что это просто чуть более изощренный метод риторики? Чуть более чем, например, вот такой

Автор: rlabs
Дата: 15.08.10

— прим. В.Б. ]

А как насчет, например, вот этого открытия ученых

Автор: Valery A. Boronin
Дата: 06.09.10

? Давайте вместе подумаем — не выдвигает ли оно определенных требований к agile командам?

Просто в топикстартовой статье, если правильно помню, претензии предъявляются в частности по следующим пунктам:

решения и оценки принимаются коллегиально всей командой (Planning Poker, etc) при том что люди просто не обладают необходимым уровнем компетенции для этого

каждый (теоретически) должен быть способен выполнять любую работу в проекте (пресловутое утреннее задание с листочка на доске)

Так вот, если ученые правы — то их исследование объясняет некоторые из фундаментальных проблем Scrum и прочих agile методологий! Ребята фактически показали, что проповедуемая agile схема не совсем уместна, если только речь не про команду одинакового уровня специалистов, с примерно одним и тем же опытом и запасом знаний [что действительно крайне редко встречается в жизни, даже если люди годами работают вместе — прим В.Б.].

Это же может являться одной из причин, почему, словами автора статьи, "Agile software development methodology sucks ass. Big time. Totally. 100%. Entirely."?

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>Всем привет. В свежем выпуске NT Insider обнаружил материал как раз для этого форума — представляю вашему вниманию статью из серии "Все что ты давно знал про Agile, но боялся сказать вслух"

Вот еще вести с полей о страданиях агилистов: Agile Ruined My Life.

VAB>Так вот, если ученые правы — то их исследование объясняет некоторые из фундаментальных проблем Scrum и прочих agile методологий! Ребята фактически показали, что проповедуемая agile схема не совсем уместна, если только речь не про команду одинакового уровня специалистов, с примерно одним и тем же опытом и запасом знаний [что действительно крайне редко встречается в жизни, даже если люди годами работают вместе — прим В.Б.].

Совершенно согласен. Точно к таким же выводам я пришел некоторое время назад. Agile — для небольшой команды действительно сильных программистов.