Форум Сообщества Аналитиков
Обсуждения => Обсуждение статей => Тема начата: uml2.ru от 04 Февраля 2010, 20:06:33
-
Автор: Александр Якима (www.enter-agile.com) Давно стало классикой, когда выступающий перед аудиторией евангелист всего гибкого сравнивает Agile с другими более ранними методологиями разработки (чаще всего достается Waterfall'у и RUP) в негативном контексте - и то и это неправильно во всем, кроме Agile. И поскольку я искренне поддерживаю идею того, что Agile пришел на смену другим методам, должен согласиться, что гибкие методы лучше... однако, не ценой беспощадной критики классических методов. Объясню почему... Оригинал: Антипаттерн: Agile против всего на свете
-
Выводы автора: "Очевидно, не следует бояться или пренебрегать классическими методами и частичным использованием лучших практик прошлого. Все поколения грешат одним и тем же — отсутствием дисциплины, понимания сути и эффективным достижением бизнес-целей, как в традиционных методах, так и, к сожалению, в Agile. Но это реальность, которую лучше принять и вооружиться ею с пользой. А именно, не отвергая проверенного временем практического пласта методов, подходов, техник и дисциплин, развитых в других методах. Наоборот, настоящий Agile — это абсолютная гибкость ради бизнес-целей и вам решать, что в эту гибкость вкладывать, чтобы преуспеть."
-
Уфф... у Agile есть два перимущества (если уметь ими пользоваться ;) ) -использование Парето и снижение главного риска - риска времени.
-
преимущества перед чем?
-
Выводы автора: "Очевидно, не следует бояться или пренебрегать классическими методами и частичным использованием лучших практик прошлого. Все поколения грешат одним и тем же — отсутствием дисциплины, понимания сути и эффективным достижением бизнес-целей, как в традиционных методах, так и, к сожалению, в Agile. Но это реальность, которую лучше принять и вооружиться ею с пользой. А именно, не отвергая проверенного временем практического пласта методов, подходов, техник и дисциплин, развитых в других методах. Наоборот, настоящий Agile — это абсолютная гибкость ради бизнес-целей и вам решать, что в эту гибкость вкладывать, чтобы преуспеть."
Что бы этот вывод значил только... Несколько раз перечитал - бессмысленница.
-
преимущества перед чем?
Преимущества перед менее "итерационными" методиками.
Принципы Agile позволяют быстрее выдать первый релиз продукта заказчику, включив в него только самые ключевые требования. Часто - этого уже оказывается достаточно или это позволяет изменить предстваление о важности тех или иных требований, учесть и быстро реализовать их в следующем релизе.
-
Что бы этот вывод значил только... Несколько раз перечитал - бессмысленница.
Сей вывод означает, что никакая метода не гарантирует того результата, который собственно с ее помощью должен был получаться. Происходит из-за того, что разработка ПС во многом лежит в организации и сильно определяется человеческим фактором.
Например, можно создать абсолютно строгую технологию создания ТФТ матрицы и, следуя ей, получать гарантированный результат. Другое дело когда Вы начинаете ее продавать или использовать для достижения каких-то бизнес-целей.
-
Преимущества перед менее "итерационными" методиками.
Принципы Agile позволяют быстрее выдать первый релиз продукта заказчику, включив в него только самые ключевые требования. Часто - этого уже оказывается достаточно или это позволяет изменить предстваление о важности тех или иных требований, учесть и быстро реализовать их в следующем релизе.
Всегда ли важно выдать быстрее? Не страдает ли при этом качество? А часто ли вы применяли в своей практике чистый водопад?
-
Всегда ли важно выдать быстрее? Не страдает ли при этом качество? А часто ли вы применяли в своей практике чистый водопад?
Водопад я применял более 10 лет (в отрасли я 20 лет).
Сейчас время - главный проектный риск.
Что касается качества, то запуску первого Agile-цикла должен предшествовать полноценный этап анализа. Если этого не делать - да, будут проблемы.
P.S. внутри Agile живет водопад;)
-
P.S. внутри Agile живет водопад;)
Ну водопад живет в любой итерационной методы. Это как говорится аксиома. Невозможно же что-то сотворить, хотя бы на мгновение на зафиксировав. Даже электроны квантуются, чего же говорить о человеческих делах :)
Да кроме того, как известно из вычислительной математике, численные методы, основанные на итерациях в общем более затратные и не позволяют достигнуть абсолютной точности, зато более просты, очевидны, понятны и воспроизводимы. Аналитическое решение, конечно, идеально (если оно есть). Оно максимально экономит время и максимально точно и проверяемо. Но в конечном счете приемлемо только для частных задач и существенно более затратно.
Насколько, я понимаю Agile позволяет более быстро найти нулевое приближение проекта и возможно построить более быструю процедуру схождения к "идеалу" (в определенных рамках и контексте конечно).
Интересно, а можно ли использовать Agile внутри какого-то проекта, который по Agile не развивается? Например, проект идет скорее как водопад или инкрементная разработка, а тестирование существует по Agile?
-
Интересно, а можно ли использовать Agile внутри какого-то проекта, который по Agile не развивается? Например, проект идет скорее как водопад или инкрементная разработка, а тестирование существует по Agile?
А почему нет? Я бы перефразировал фразу Андрея и сказал "внутри водопада живет agile" :)
Общие фазы по водопаду, а итерации по эджайл
-
А почему нет? Я бы перефразировал фразу Андрея и сказал "внутри водопада живет agile" :)
Общие фазы по водопаду, а итерации по эджайл
Позволю не согласиться - в таком варианте могут потеряться главные "плюсы" - раннее появление у заказчика первой версии и возможность внесения изменений в генеральный план по фитбеку от заказчика. Если это попытаться сохранить, будет уже не водопад - а скорее V-модель - поскольку существует вероятность откатиться на этап анализа после начала разработки.