Каморка

Расскажите, что это такое, пожалуйста. Где можно про это почитать? Особенно интересует применение этой методологии к тестированию.

Гуглом я умею пользоваться. Все, что находил в интернете - как-то размыто обьясняют. Кто может обьяснить "на пальцах"? Что такого "военного" в этой методологии?

deemster писал(а):Гуглом я умею пользоваться. Все, что находил в интернете - как-то размыто обьясняют. Кто может обьяснить "на пальцах"?

Что непонятно тут: http://ru.wikipedia.org/wiki/Гибкая_методология_разработки ?
Работа ведется итерациями, каждая итерация - как проект в миниатюре, дающий на выходе какой-то результат. Фактически по окончании каждой итерации есть рабочий продукт. Дальше по результатам предыдущей итерации планируется следующая, и т.д.

Что такого "военного" в этой методологии?

В смысле? Просто одна из методологий. Модная в последнее время.

Почему переход на нее происходит достаточно тяжело? Почему она так популярна в последнее время?

Не надо идти туда работать.

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

deemster писал(а):Почему переход на нее происходит достаточно тяжело? Почему она так популярна в последнее время?

Потому что для больших проектов больше подходят другие модели. А создание работоспособных промежуточных версий требует дополнительных усилий. Например, в геймдеве принято перед выставками делать демо-версии текущих проектов. Это сильно напрягает всех в студии, поскольку забагованная вусмерть версия произведет худшее впечатление, чем отсутствие продукта вообще. В результате -- незапланированный кранч и срыв дальнейших сроков, поскольку все силы уходят на полировку времянки, вместо того, чтобы работать дальше в рамках привычной waterfall-модели (например).
Популярность agile скорее не среди разработчиков, а среди инвесторов, дающих деньги. Они могут видеть промежуточные стадии, что дает ощущение контроля за происходящим.
Вообще, я бы не сказал, что так уж популярна эта модель. Применяется, да, но наряду с другими, более традиционными. Хотя в agile есть некислый такой шанс "за деревьями леса не увидеть", то есть сосредоточившись на краткосрочных задачах проморгать долгосрочные.

Это работает примерно так, как строят БАМ. Нужно построить дорогу от начало до конца за одну пятилетку. В общих чертах все знают, что должен в финале проехать паровоз из одной точки в другую. Делают план разбитый по годам на все 5, и начинают строить с одного конца, в лучшем случае. Каждый год обязуясь отчитатся о проделанной законченной работе и начать следующий как бы с нуля, на базе предидущего. Где то ко второму году стройки , в лучшем случае опять же, всё нахер сбивается, смежники подвели, внезапная зима нагрянула, паровозы вобще ни кому не нужны больше итд. Планы перекраивают сдвигая сроки. Всё это решается на совещаниях и утверждается на заседаниях. Но люди с кувалдами пока упорно строят и рапортуют - Пройден поворотный этап. Планы пересматриваются заново в соответствии с проделанной работой. В итоге задание построить мост, приходит позже, чем там уже построен тунель. Документы отсылаются на передел, чтоб потом рапартуя на съезда, не перепутать, что ж построенно. Все в мыле. Планировали 5 за 5 лет, хотели за 3 года, но ранше чем в 7 не уложится. В итоге получается грандиозный продукт-стройка века, о которой все знают из газет и новостей, но которым пока никто не хочет пользоватся. Ждут SP1 Вот это и есть Agile methodology.

deemster писал(а):Почему переход на нее происходит достаточно тяжело? Почему она так популярна в последнее время?

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

Rai писал(а):Например, в геймдеве принято перед выставками делать демо-версии текущих проектов. Это сильно напрягает всех в студии, поскольку забагованная вусмерть версия произведет худшее впечатление, чем отсутствие продукта вообще. В результате -- незапланированный кранч и срыв дальнейших сроков, поскольку все силы уходят на полировку времянки, вместо того, чтобы работать дальше в рамках привычной waterfall-модели (например).

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

nonn писал(а):Все в мыле. Планировали 5 за 5 лет, хотели за 3 года, но ранше чем в 7 не уложится. В итоге получается грандиозный продукт-стройка века, о которой все знают из газет и новостей, но которым пока никто не хочет пользоватся. Ждут SP1 Вот это и есть Agile methodology.

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

Главное преимущество Agile на мой взгляд - то, что постоянно есть в какой-то степени готовый продукт, и планы можно легко скорректировать в соответствии с текущим моментом.

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

alpax писал(а):Ой и не говори. До сих пор с ужасом вспоминаю как мы демо на E3 готовили в середине проекта. И сам проект был сложный (первая игра для Wii, к тому же на базе сделанной другой студией), и сроки перенести никак нельзя было. Домой приходил в час ночи. :(

Консольные игры -- это вообще стрельба по части подхода к качеству продукта. Не то что на персоналках раздолбайство...

alpax писал(а): При нормальном подходе реально учитывается предыдущая итерация, и в принципе ненужная работа не делается.

ну по Вики Agile methodology - реально учитывается предыдущая итерация, и в принципе ненужная работа не делается.
а по жизни Agile methodology - бардак
или вот ещё сравнение.
оба метода это быки, стоящие на горе и смотрящие на стадо. Молодой-Agile methodology, Старый -waterfall

Что посоветуете почитать, чтобы побыстрее войти в курс этой методологии? Желательно, чтобы доступным языком было написано и с примерами

deemster писал(а):Что посоветуете почитать, чтобы побыстрее войти в курс этой методологии? Желательно, чтобы доступным языком було написано и с примерами

анекдоты.
для интервью хватит и того что тут написали, а для налаживания процесса, надо знать даже характеры коллег