А>Устойчивость к изменяющемуся ТЗ — это, по-моему, лишь часть Agile. Там еще много всего, в том числе спорного.

Agile на то и agile, что допускает вольности — не хотите "спорное", не пользуйтесь.

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

А>Устойчивость к изменяющемуся ТЗ — это, по-моему, лишь часть Agile.
Это одна из основных целей. Остальное — средства.

А>Там еще много всего, в том числе спорного.
Например?

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

M>Если серьёзно, то на разных уровнях одного проекта вполне может работать и Agile, и водопад. Agile хорошо работает с часто меняющимися требованиями, но требует тесного общения внутри команды (каждый с каждым) и коротких итераций. Понятно, что в командах из более чем 100 человек это нереализуемо. Водопад наоборот — хорошо масштабируется с ростом размера команды и проекта, но сопротивляется изменению требований. Так что главное — гармония.

На масштабе проекта, который будет делать команда из более чем 100 человек, прописать требования так, чтобы потом их не пришлось менять, попросту невозможно (и даже на проектах гораздо меньшего масштаба это невозможно). Но я не об этом, на самом деле. Мне непонятно, почему вопрос вообще стоит как "или православный Agile, или waterfall — третьего не дано"? Наличие фазы предварительного планирования и процесса формального управления конфигурацией никак не противоречит концепции итеративно-инкрементальной разработки. Тот же пресловутый RUP никто не назовет водопадным подходом, но и Agile подходом (если не считать адаптацию OpenUP) он тоже не является.

Собственно, даже оставаясь в рамках Agile-подхода, его можно адаптировать к большим и серьезным проектам. Почитайте, например, Скотта Эмблера про масштабирование Agile-подхода и про подход Accelerated Delivery Platform

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

А>>Вот скажем я програмю . А дальше?
B>Вы программите, вас это мало касается.

Как это мало, когда по Agile разработчики должны участвовать в планировании, расставлять приоритеты и самостоятельно выбирать себе таски на скрамах?
Как раз в рамках Agile роль руководителя сводится к соблюдению процесса (уменьшается).

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

N>Как это мало, когда по Agile разработчики должны участвовать в планировании, расставлять приоритеты и самостоятельно выбирать себе таски на скрамах?
скрам и Agile это не одно и то же

N>Как раз в рамках Agile роль руководителя сводится к соблюдению процесса (уменьшается).
как раз руководитель выбирает процесс и следит за его соблюдением, поэтому понимание и организация процесса это первоочередная задача руководителя, а не разработчика, который "вот я програмлю, а дальше что?"

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

N>>Как это мало, когда по Agile разработчики должны участвовать в планировании, расставлять приоритеты и самостоятельно выбирать себе таски на скрамах?
B>скрам и Agile это не одно и то же
Я проходил корпоративный курс Agile, в рамках которого Scrum был назван его частью. Общим случаем не интересовался, так что возможно ошибаюсь.

N>>Как раз в рамках Agile роль руководителя сводится к соблюдению процесса (уменьшается).
B>как раз руководитель выбирает процесс
В рамках всех наблюдаемых случаев процесс выбирает не собственно руководитель проекта, а консилиум с вышестоящим руководством, где решаются концептуальные вопросы.

B>и следит за его соблюдением, поэтому понимание и организация процесса это первоочередная задача руководителя
Я это же сказал.

B>а не разработчика, который "вот я програмлю, а дальше что?"
По моему, человек который так говорит не может считаться разработчиком, это ранняя юниорская позиция. Разработчик должен понимать, что генерация кода — не самая значительная часть его работы.

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

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

G>>Более серьезные проекты в основном делаются по фиксированному ТЗ хотя бы даже потому, что заказчик хочет знать сколько надо платить и когда он получит конкретный, заранее оговоренный товар, а не кота в мешке.
B>Угу, и такое ТЗ потом в течении всего времени разработки сопровождается Change Request-ами. Невозможно полноценно и достаточно детально проработать любой крупный проект. Когда проект разрабатывается по фиксированой спецификации, а все запросы посылаются лесом, то заказчик опять проигрывает, так как лишен гибкости в маневре в свете вскрывшихся обстоятельств.

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

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

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

Хороший человек по имени Peter Viscarola, который является одним из лучших специалистов по ядру Windows за пределами MS, помнится, сильно ругал Agile.

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

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

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

Для решения проблемы с качеством в Agile часто ее комбинируют с TDD, но это сильно повышает нагрузку в плане человекоресурсов и зачастую по этой причине просто нереально для стартапа.

MSS>Причина: эта методология приучает людей писать код наспех, без должного внимания, приводит к медленной сходимости числа багов к нулю, и в отраслях девелопмента с высокой (по человеко-часам исправления) ценой баги может просто убить проект. Что не раз и случалось.

Т.е. "нетлёнку" по Agile не сделаешь, так?

MSS>В случае б) провал может произойти потому, что, после получения инвестиции необходимо делать уже не прототип, а продукт, который зачастую просто нереально сделать в Agile — не сойдется качество.

Почему качество не сойдется? Если в Definition of Done указаны критерии качества, в чем проблема?

MSS>Для решения проблемы с качеством в Agile часто ее комбинируют с TDD, но это сильно повышает нагрузку в плане человекоресурсов и зачастую по этой причине просто нереально для стартапа.

Вы в одном сообщении себе противоречите. Если у стартапа нет ресурсов на качественную и хорошую "нетленку", то им как раз Agile и поможет _хоть что-то_ сделать. А "нетленка" так и останется неготовой для продакшна, стартап загнется.

Вообще, смотрите истории всех успешных компаний. Все и везде начинали с "говнокода" (С), который просто был раньше, чем у других. Такова природа современного предпринимательства.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Хороший человек по имени Peter Viscarola, который является одним из лучших специалистов по ядру Windows за пределами MS, помнится, сильно ругал Agile.

Agile — то, что доктор прописал для команд, у которых еще нету никакого опыта совместной работы.
Сразу же наводится хоть какой-то порядок и получается performance boost
С уже устоявшимися командами с поставленными процессами ситуация может быть совсем иной.
Может помочь, а может и все нафиг похерить. Наблюдал неоднократно.
Проблема Agile только в ортодоксальности последователей Agile.
Ярые стронники гибких процессов на деле оказываются упертыми и негибкими

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

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

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

Бардак в головах у 95% разработчиков. Для этого есть тим-лид, чтоб бардак упорядочивать. В агиле каждый сам себе "тим-лид" и это печально.

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

G>В агиле каждый сам себе "тим-лид" и это печально.
Это ваша странная интерпретация agile. Ничего такого в манифесте нет. Возможно, как и многие в этой теме, вы имеете ввиду Scrum, который, действительно, не работает, когда для многих команд, по причине того что они не способы самоорганизоваться.

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

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

G>>В агиле каждый сам себе "тим-лид" и это печально.
B>Это ваша странная интерпретация agile. Ничего такого в манифесте нет. Возможно, как и многие в этой теме, вы имеете ввиду Scrum, который, действительно, не работает, когда для многих команд, по причине того что они не способы самоорганизоваться.
Как в манифесте такого нет? а это: "self-organization and motivation". Если двух "индусов" посадить по парам, они "саморганизуются"?

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

G>Как в манифесте такого нет? а это: "self-organization and motivation". Если двух "индусов" посадить по парам, они "саморганизуются"?
Самоорганизация не обозначает отсутствие контроля возведенное в абсолют.

Та же разработка, но с ежедневными сеансами десятиминутного группового интеллектуального онанизма.

SD>Т.е. "нетлёнку" по Agile не сделаешь, так?
Если только вопреки, а не благодаря.

SD>Почему качество не сойдется? Если в Definition of Done указаны критерии качества, в чем проблема?
Потому что появляется куча отвлекающих сущностей и англоязычных терминов, прямо не влияющих на качество кода.

SD>Вы в одном сообщении себе противоречите. Если у стартапа нет ресурсов на качественную и хорошую "нетленку", то им как раз Agile и поможет _хоть что-то_ сделать. А "нетленка" так и останется неготовой для продакшна, стартап загнется.
Точно так же он загнется и при наличии регулярных митингов. Если есть энтузиазм и хороший идеолог, то аджаил не поможет и не помешает.

SD>Вообще, смотрите истории всех успешных компаний. Все и везде начинали с "говнокода" (С), который просто был раньше, чем у других. Такова природа современного предпринимательства.
Не все и не везде. Всегда есть некий процент "золотого кода" в куче г-на. В каждом успешном проекте.

B>Проблема Agile только в ортодоксальности последователей Agile.

IMHO здесь проблема не Agile, — конкретные ортодоксальные личности ровно так же ортодоксалили бы waterfall или что угодно еще. Кстати, Agile это упоминает — мол, люди и их коммуникации важнее процессов и инструментов

TСП>Если только вопреки, а не благодаря.

Откуда такая статистика?

SD>>Почему качество не сойдется? Если в Definition of Done указаны критерии качества, в чем проблема?
TСП>Потому что появляется куча отвлекающих сущностей и англоязычных терминов, прямо не влияющих на качество кода.

Поясните, пожалуйста. Не нравится английский термин, используйте русский "что значит сделано". Это прямой и непосредственный способ проверки качества. Пока не проходят тесты, фича не сделана. Если у вас есть критерий качества — внесите его в определение "сделано" и у вас будет заданный уровень качества.

TСП>Точно так же он загнется и при наличии регулярных митингов. Если есть энтузиазм и хороший идеолог, то аджаил не поможет и не помешает.

Ваше мнение понятно. Допускаю, что у вас был негативный опыт применения чего-то из Agile. Это не значит, что у всех остальных опыт будет негативным. Кроме того, не всем же "нетленку" писать, у большинства проекты как раз "быстрее сделать и забыть".

TСП>Не все и не везде. Всегда есть некий процент "золотого кода" в куче г-на. В каждом успешном проекте.

А вот это, действительно, никакого отношения к Agile не имеет, и может существовать что в Agile-процессе, что вне его.

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

B>>Проблема Agile только в ортодоксальности последователей Agile.

SD>IMHO здесь проблема не Agile, — конкретные ортодоксальные личности ровно так же ортодоксалили бы waterfall или что угодно еще. Кстати, Agile это упоминает — мол, люди и их коммуникации важнее процессов и инструментов

Это так. Но любая идея собирает вокруг себя людей определенного типа.
Ортодоксальность многих последователей Agile — это следствие методов,
с помощью которых Agile продвигается в "массы".
Ты был на официальных курсах по тому же SCRUM?
Тот еще brainwashing...