Agile, на мой взгляд - почти целиком вредная гиль.

Вредная - что? Гниль?

(Ответить) (Thread)

(Ответить) (Parent) (Thread) (Развернуть)

Зато парное программирование иногда очень полезно.

(Ответить) (Thread)

Ключевое слово - "иногда".

(Ответить) (Parent) (Thread) (Развернуть)

Подписался и приготовил попкорн.

(Ответить) (Thread)

Agile конечно не идеален, но его альтернатива - программирование по дизайну не работает значительно чаще чем agile.

(Ответить) (Thread)

Это ложная дилемма.

(Ответить) (Parent) (Thread)

Сложно это.
С одной стороны - есть набор методологий и разнообразная жизнь. Подразумевается, что под конкретный проект всегда можно подобрать наиболее подходящую методологию, универсальных решений не бывает.
С другой стороны, практически не бывает универсальных людей, которые одинаково хорошо владеют всеми практиками, чтобы непредвзято выбирать в каждом конкретном случае - всегда человек тяготеет к какому-то определённому подходу и знает его лучше. Не говоря уже про маркетинговые и прочие денежные факторы, не дающие менеджеру развернуться.
Вот я например использовал всегда только что-то waterfall-образное, прибегая только к отдельным XP/agile практикам по обстановке и очень редко. Но это по большей части было обусловлено обстоятельствами и я понимаю, что по-настоящему я agile не знаю и подозреваю, что от этого сам выбираю не ту методологию, когда выбор возможен.

(Ответить) (Thread)

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

Но вот тут мы как-то разговаривали с кандидатом, который пришел из большой конторы, и в том числе очень подробно обсуждали с ним наш development process. В конце он сказал - "мне так нравится что у вас такой зрелый agile process!". Но позвольте, ответили мы, какой нафиг agile? Ну как же, вы же говорите, что у вас любой программист увидевший проблему в дизайне может все остановить, созвать митинг и попытаться с коллегами найти решение. Но ведь это же просто здравый смысл, сказали мы, никакой agile. А он и отвечает - да вы что, у нас бы надо было сообщить менеджеру чтобы он на следующем заседании steering committee обсудил бы проблему с архитектором и тот бы тогда подготовил презентацию для старшего архитектора и .. и бла-бла

Вот тогда я понял почему многие настолько хватаются за agile. Ну действительно, по сравнению с таким это действительно революция и лучшая вещь после sliced bread

(Ответить) (Thread)

да, это тоже правда, порой просто процесс настолько закостеневший, что agile кажется долгожданным глотком воздуха, а протолкнуть его позволяет "мода"
но тут уж всё зависит от общей вменяемости высшего менеджмента

(Ответить) (Parent) (Thread)

(Ответить) (Thread)

>заражены агилевским баззвордизмом и радикализмом

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

(Ответить) (Thread)

Склонность к излишнему использованию buzzwords, модных слов.

(Ответить) (Parent) (Thread)

Насколько я понимаю, agile определяется довольно просто (хотя и несколько общо):

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

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

(Ответить) (Thread)

А какой пункт в "Землю - крестянам, фабрики - рабочим" вреден?

(Ответить) (Parent) (Thread) (Развернуть)

Очень здравые заметки. Agile может получиться у спецефической команды, но он и для нее будет только инструментом, помогающим привлечь domain experts и держать их стопроцентно занятыми в проекте. Что, вообще-то, немало. В этом случае Agile как набор buss words может быть очень полезен для переговоров с начальством.

(Ответить) (Thread)

А Agile как "агиль" произносят только (1) израильтяне, (2) русскоязычные, (3) русскоязычные израильтяне, или ещё кто-нибудь?

(Ответить) (Thread)

Никто по-моему не произносит.

(Ответить) (Parent) (Thread)

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

(Ответить) (Thread)

there is no silver bullet.

(Ответить) (Parent) (Thread)

Согласен.

Мне не понятно веяние, согласно которому смешиваются понятия TDD и агил. Агил хорош сам по себе и в определенных задачах. Без сомнения хорош в эволюционном макетировании, что прекрасно видно, например, в ruby on rails. Юнит-тесты хороши для библиотек и протоколов, нет сомнений. Но хороши, пока не начинают влиять на дизайн программы. Это я к тому, что без проектирования хорошие юнит-тесты, покрывающие каждый сценарий не появятся, а это уже не агил никакой. Так что TDD хорош сам по себе, когда закрывает именно вопрос кодирования сложных сценариев и автоматов, но не начинает претендовать на что-то похожее на парадигму программирования. Действительно, TDD может стать спасением, если язык сильно динамический и плохо типизируемый. И мне кажется, что в яву и C все это переползло по недостатку в этих языках большого количества простых типов на всякий случай жизни. Вот и приходится по десять раз парсить строки, проверять соответствие между запросами и схемой БД, хитрым образом сравнивать даты и т.д. и т.п.

(Ответить) (Thread)

Это я к тому, что без проектирования хорошие юнит-тесты, покрывающие каждый сценарий не появятся

Юнит-тесты не покрывают сценарии использования, юнит-тесты покрывают API.

(Ответить) (Parent) (Thread)

Редко что-то комментирую, но тут захотелось ответить.
Не согласен с Вами насчёт agile. У нас в конторе начали вводить эту методологию около года назад. В начале процесса, многие включая меня были уверены что это туфта по тем причинам которые вы тут написали. По прошествии года я полностью изменил свое мнение. Считаю что в нашей ситуации это отличная штука, если относиться к ней без фанатизма. То есть там куча дырок, но применяя common sence можно добиться хороших результатов. Может быть вы скажете что это никакой не Agile а просто обычный здравый смысл, но мы почерпнули эти принципы именно из этой методологии. И Вообще какая разница как называть.

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

Принцип недалёкого планирования и коротких итераций.
Раньше одни дизайнеры писали общую картину, передавали на более конкретние задачи другим дизайнерам, которые в свою очередь делили дальше. И так несколько ступенек. Весь процесс занимал месяцы. каждая группа/компонента получала requirements, писала design на несколько месяцев вперед и писался код. В процессе почти невозможно было понять что будет в конце. Когда код был готов и прошел тестирование он попадал к клиентам (другая компонента внутри фирмы) и все оказывалось не то и не так. Еще куча времени уходит чтобы понять, что все таки надо переделать и вернуть назад. А те уже продолжают дальше, дизайн то у них написан. С тестами таже проблема, начинауются когда почти всё готово, переделывать дорого, программисты уже пишут дальше и находятся в совсем другом контексте. Короче стандартный waterfall.
Сегодня планы идут на месяц вперед. Этот месяц вклучает в себя полный development cycle вклучая testing и adoption. Естественно есть планы и дальше но они совсем не детальние. По факту за этот год все разы когда мы примерно намечали что-то на следующую итерацию заранее, это кардинально менялось когда доходило до дела. По моему это огромный плюс что мы с такой легкостю можем менять планы. Естественно мы за это платим тем что иногда приходится переписывать, но это редкость. Все это благодоря тому что и наши клиенты (другие компоненты) не строят далеких планов, а только обшее направление и тому что у нас почти полная автомация тестов. Всё поделено на очень маленькие куски, так чтобы каждый кусок имел конкретную пользу для клиента (deliverable). Это позволяет делать очень частую интеграцию с другими компонентами и вылавливать дыры рано. Деление на такие deliverables требует очень много нудной работы, но это стоит того.
Вообще сама методология на первый взгляд отнимает кучу времени, но это всё возвращается.
Второй плюс это полная видимость прогресса. Планируя итерацию принимается во внимания каждая известная мелочь на которую тратится время (до резолюции часов), заместо всех этих примерных бафферов. Все делится на очень мелкие таски и все ежедневно отмечают индивидуальний прогресс на общем графе. Тоже
требует усилий но результат поразительний. У людей которые видят групповое продвижение ежедневно повышается мотивация.

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

Итересно почему у вас такое мнение? Пробовалили ли вы работать по Agile принципам?

(Ответить) (Thread)

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

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

(Ответить) (Parent) (Thread)

Неполезны радикальный agile и радикальная TDD, в любой методологии вреден радикальный подход. Agile это в первую очередь отсутсвие такого радикального подхода, это risk-driven development. Agile это не полноценная методология, абстрактный это подход, позволяющий практически в каждый момент времени иметь готовый продукт. Чтобы его успешно использовать, нужно создать конкретную методологию, подходящую для конкретных организации, задачи, условий.

(Ответить) (Thread)

У меня не создалось впечатления на практике, что agile - "в первую очередь отсутствие такого радикального подхода", скорее наоборот.

(Ответить) (Parent) (Thread)

По Agile тов. Yegge хорошо прошёлся в своё время:

Good Agile, Bad Agile
Egomania Itself
I take it all back! Send me your money!

(Ответить) (Thread)

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

(Ответить) (Parent) (Thread)

Кажется, вам встречались в основном "не тру" аджайлисты.

Очень часто различные полезные течения опошлялись последователями N-ого поколения, копирующими лишь внешние признаки, ритуалы, и превращающие полезные паттерны в ригидные правила.

Так, например, раннее христианство отличается от того, что сформировалось в 5-7 веке, когда сформировался канон.

В то время как одним из ключевых принципов Agile на мой взгляд является необходимость модификации и постоянной подстройки процесса под конкретный проект/команду/сложившуюся ситуацию. (inspect and adapt)

Вы правильно заметили, что Agile определён достаточно расплывчато. Это так, потому что фактически каждая команда имеет свой собственный процесс - и он мутирует с течением времени.

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

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

Маркетинговая привлекательность баззвордов, конечно, играют отрицательную роль. Знакомый работал в одной аутсорсинговой конторе и заказчики требовали Agile. В результате был имплементирован некий дубовый процесс, заключающийся главным образом в том, что не было предварительного проектирования. А других практик, которые делают это возможным, внедрено не было. Команды как целостности не было. И главное, не было предусмотрено адаптации процесса (да и некому было это делать и брать за это ответственность - команды же нет, есть отдельные индивидуумы). В результате у знакомого, естественно, сложилось отрицательное мнение об Agile.

У Agile есть две стороны - инженерные практики и практики командной работы/управления. Вы в этом посте затронули только инженерные практики (которые, как я понял, вы любите, если без фанатизма). Интересно, как вы относитесь к неинженерным практикам (Iteration Planning Meeting, Daily Scrum Meeting, Retrospective и т.д.)?

(Ответить) (Thread)

(Ответить) (Parent) (Thread)

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

(Ответить) (Thread)

считают, да. Не спорю.

(Ответить) (Parent) (Thread)

Хороший пост! Познавательно!

(Ответить) (Thread)