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

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

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

Мне очень нравится аналогия, которая очень точно демонстрирует разницу между гибкими методологиями и негибкими: перекресток с круговым движением и со светофором. Перекресток со светофором, обладая сильно меньшей пропускной способностью, предъявляет минимальные требования к участникам движения: их сознательности должно быть достаточно всего лишь, чтобы понять, что на красный цвет надо стоять, а на зеленый ехать. Перекресток с круговым движением обладает гораздо более высокой пропускной способностью, но он требует от участников движения гораздо более высокого уровня сознательности, так как участники движения должны в каждый момент времени самостоятельно принимать решения о траектории и скорости движения исходя из актуальной дорожной обстановки. Неопытным водителям гораздо проще проезжать перекрестки со светофорами, там труднее попасть в ДТП. С другой стороны, опытный водитель отдаст предпочтение более эффективному круговому движению, но при условии, что другие участники тоже являются опытными и дисциплинированными.

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

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

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

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

Мне очень нравится аналогия, которая очень точно демонстрирует разницу между гибкими методологиями и негибкими: перекресток с круговым движением и со светофором. Перекресток со светофором, обладая сильно меньшей пропускной способностью, предъявляет минимальные требования к участникам движения: их сознательности должно быть достаточно всего лишь, чтобы понять, что на красный цвет надо стоять, а на зеленый ехать. Перекресток с круговым движением обладает гораздо более высокой пропускной способностью, но он требует от участников движения гораздо более высокого уровня сознательности, так как участники движения должны в каждый момент времени самостоятельно принимать решения о траектории и скорости движения исходя из актуальной дорожной обстановки. Неопытным водителям гораздо проще проезжать перекрестки со светофорами, там труднее попасть в ДТП. С другой стороны, опытный водитель отдаст предпочтение более эффективному круговому движению, но при условии, что другие участники тоже являются опытными и дисциплинированными.

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