От понимания до осмысления порой проходит долгое время. Но потом все сразу встает на свои места. Перевод термина agile возник по той же схеме. Наживулька (с). Хорошее такое, емкое русское слово.

Давно было. Один из клиентов, коему были предложены частые итерации, сразу все просек и сказал: ребята, вы не в теме. В смысле, область не знаете. Но не пугайтесь, я вам постановки выложу. И не чаще раза в три месяца мне показывайте свой любрикант полуфабрикат. Более того, трудозатраты подсказал. Весьма точно. Потому, что у него этот проект по теме уже третий был.

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

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

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

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

TDD - разработка "от тестов" - экая прелесть, в начале 21 века мы благодаря нашим парням узнали, что бывают модульные тесты. Но не просто тесты: если их наперед кода писать, то можно целую теорию развести. В ней, правда не говорится, сколько нужно затрат на разработку и поддержание модульных тестов в зависимости от покрытия (и как оптимальное покрытие вообще определять). А интеграционных? А системных? А в каких случаях это надо? А если заказчик сам рвется все тестировать силами пользователей? Но парни правы: модульные тесты гарантируют с высокой вероятностью, что ваш желтый или красный раствор (см.выше) будет пригоден для заливки стен и не развалится от дуновения ветра. Парни вам непременно скажут, что модульные тесты не усложняют, а упрощают реструктуризацию (рефакторинг). Ведь без тестов ломаешь одну структуру, а с тестами - ломаешь структуру и тесты, ломаешь и переписываешь тесты, ломаешь и переписываешь тесты... И все ради того, чтобы не напрягаться вначале, создавая модели предметной области, структуры, архитектуру, которые будут устойчивыми и расширяемыми. И только потом окружать тестами на этапе кодирования.

Для себя я уже давно сформулировал применимость "наживульки":
- собственный отдел АСУ/ИТ на разработке и сопровождении
- первый проект в незнакомой области при отсутствии компетенции у заказчика и невозможности нанять собственного аналитика-постановщика

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

Доказывать же очевидные истины, что 80% требований идет из предметной области не буду. Sapienti sat (*)

На термин agile - "на живульку" ставлю копирайт. Разрешаю цитировать сколь и где душе угодно, но только с указанием источника :)

P.S. Про самоуправляемость в коллективе размером до 10 человек независимо от того, "наживулька" это или нет, я слышал давно. Личной практикой тоже подтверждено. Видимо, эту цифру можно вывести из функции временных затрaт на коммуникации от числа членов команды. Вот пример, статья 11-летней давности, а проект еще старше. См. главку "Организация работы". Приятно, что в статье не употребляется "страшных слов" и прочей религиозно-манипулятивной атрибутики :)

Практика. Комментарий Максима Крамаренко

У нас (http://www.trackstudio.ru), кстати, модульные тесты тоже "не пошли". Сложилось впечатление что их хорошо использовать для продуктов, которые реализуют какой-то стандарт или спецификацию (СУБД, web server), но для обычного web-приложения это смерть.

Причины:

1) При изменении спецификаций затраты времени на приведение в актуальное состояния тестов могут быть куда больше, чем затраты на код. Скажем, если пользователи захотят поменять синтаксис SQL в СУБД и писать SEARCH вместо SELECT, то это 1 изменение продукта в 1 месте, но переписывание почти всех тестов. Если для СУБД такие пожелания пользователей - редкость, то для менее стандартный программ - обычное дело.

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

3) Наличие тестов сильно затрудняет масштабный рефакторинг. Если у нашего приложения есть какой-то внешний API, то все что ниже мы можем менять быстро и без особых проблем. Но если для этого low-level кода есть тесты, то их придется основательно переделывать, т.к. в новой версии может уже не быть тех модулей, которые тестировали старые тесты.

4) Если не заморачиваться с выпуском раз в 2 недели, то возможность быстро что-то протестировать не так уж и важна. Я себя совершенно нормально чувствую с тестированием бета-версии в течении 2-3 месяцев, зачем чаще ?

5) Одни из наших конкурентов широко используют agile-методы и TDD, но что-то оно им не очень помогает писать безглючный код. Мы сравнивали количество найденных глюков в течении месяца-двух после major release - у нас показатели лучше в разы, если не на порядок. Частый выпуск версий просто не позволяет им довести код до ума и провоцирует исправление старых и серьезных проблем методом написания "залепени": http://maximkr.livejournal.com/6286.html

6) Я совсем не уверен, что пользователи _хотят_ получать новую версию раз в 2 недели. TrackStudio 3.5 вышла примерно через полгода, после TrackStudio 3.2, и мы получили кучу негатива от клиентов, что такие частые релизы заставляют их обновлять кучу локальной документации и задерживают _их_ процессы на несколько месяцев. Многие пользователи совершенно спокойно живут без апгрейдов несколько лет. Если они купили продукт - значит он делает то, что они хотят. Если чего-то не делает - они все равно уже нашли workaround и им все равно.

7) Для корпоративного софта пользователи хотят длительного периода саппорта (пара лет). Если мы выпускаем софт раз в 2 недели и находится серьезная бага в версии годичной давности, то нам ее нужно будет исправить примерно в 40 branch-ах :-) Конечно, править 40 branch-ей никто не будет, пользователям сообщат, что бага будет исправлена в следующей версии, многие пользователи проапгрейдится на нее не смогут (см 6) к большой радости конкурентов с competitive upgrade offer :-)