[spoiler]Краткий ее пересказ.
11-13 февраля 2010 г. отмечался юбилей легендарного манифеста Agile (десять лет назад семнадцать человек во главе с Кентом Беком, собравшись в горах Юты, провозгласили новое поколение методик разработки софта).
Agile-методики первоначально позиционировались как решение принципиальных ограничений модели водопада. Но постепенно весьма эмоциональный и вдохновляющий манифест заразил множество молодых программистов едва ли не религиозным энтузиазмом -- и люди принялись внедрять неожиданные и нестандартные техники, которые стали сущим проклятием для классически обученных профессионалов. Но мало-помалу такие вещи, как частые релизы, активное привлечение заказчика к обсуждению и всесторонне тестирование, стали повседневной мэйнстримовской практикой.
В начале десятилетия аджайлы оставались преимущественно вотчиной программистов -- парное программирование, частые check-ins (слияние с главной проектной веткой в системе управления версиями), непрерывная интеграция кода, и TDD, ориентированная на индивидуальную роль разработчика. Однако к сегодняшнему дню agile-индустрия серьезно повзрослела и теперь ориентирована на процесс и жизненный цикл ПО. Ведущими стали Scrum и Kanban, а дальнейшее движение вперед вдохновляется Лином (бережливой разработкой).
Ориентирован современный аджайл на командную работу. Он задает способ, коим группа взаимодействует с доступными технологиями. Интересным шагом в этом направлении стал эволюционный отход от принципа непрерывной интеграции к непрерывной разработке. Более того, Andrew Binstock из DrDobbs назвал непрерывную разработку основной для революционных изменений в индустрии производства софта -- это движение к более глубокому и всестороннему осознанию практик, традиционно ориентированных на программиста. Так, TDD сегодня часто воспринимается как "сперва пишем тест, потом сразу же код для него". Однако дух TDD совсем в другом -- в создании более лучшего, более качественного внутреннего дизайна (архитектуры) системы, а отнюдь не всестороннего набора тестирования.
С парным программированием идея была такая же: два разработчика за одним экраном и с одной клавиатурой, обсуждая кодируемую логику, по идее должны генерировать в три и более раз качественную структуру приложения, чем если бы каждый программировал в одиночку. Однако на практике результат противоположный: два программиста выдают в полтора раза лучший код, нежели один разработчик, что только ухудшает общую производительность.
Процессные подходы скрам, канбан и лин дают реальный выигрыш, и хотя полноценно их освоить непросто, организации, способные на это, потом уже не променяют аджайл ни на что другое. Это без сомнения очень хорошо работающие методики, и сегодня идет серьезная работа по их масштабированию на проекты объемом от пяти миллионов строк кода (как Windows) и коллективы от 500 разработчиков. Лет через пять, полагает Andrew Binstock, такие методики будут достаточно хорошо отлажены, благо потребность в подобных проектах только нарастает.
А вот Ralph Kelsey из Огайского университета назвал аджайл-движение смесью хороших идей, здравого смысла, чепухи, вранья и религии. Он считает классическую методику "водопад" и agile-подходы двумя экстремальными позициями -- а истина вроде как лежит посередине. По его мнению:
-- парное программирование реально работает в 1% случаев, но мэйнстримом никогда не станет;
-- Scott Ambler, один из основных гуру аджайла, "духовный лидер" agile modeling, agile data и enterprise unified process, безусловно, сделал много полезного, но его высказывания, что agile вылечит все что угодно, даже простуду, смотрятся просто бредом;
- TDD. Весьма практичная методика, в ней все на своем месте. Тем удивительнее комментарии в духе "использование TDD неправильно, если тесты будут добавляться не до написания кода, а после" -- попробуйте добавить тест после кода, и вас назовут экстремистом Талибана. Да пишите тесты когда и где угодно -- до, после, в течение, и так далее -- тесты всегда будут к месту (Andrew Binstock прокомментировал это так: "TDD -- это прежде всего о проектировании, но вместе с тем добавление теста к готовому коду, а не наоборот -- признак того, что вы не понимаете, что делаете" (в том смысле, что просто подстраиваете тесты под свой код, а не выстраиваете осознанно свой код под некоторые внешние формализованные требования)).
- Я впервые обнаружил аджайл лет сорок назад. Тогда я сперва немного думал об общей структуре программы, помаленьку писал код, тестировал его, добавлял новые фичи, и так доводил дело до конца. А вот когда столкнулся с действительно крупными проектами, где участвует много разработчиков, я понял, что главное -- это предварительное планирование, тщательное проектирование, создание и тестирование прототипов и т. д. Этот старый классический подход работает много лучше аджайлов.
далее -- какие аджайлы сумели обойти ограничения классической TDD
