Секрет производительности аджайла -- это неограниченные и доверительные коммуникации между всеми участниками проекта. При этом, конечно, обязательно будут конфликты, и самое главное, чтобы все сотрудники заранее согласились с единым методом принятия решений, по которому любой конфликт будет разрешен.
Замедляет внедрение аджайла как уравниловка, так и ориентация на бонусы. Стандартные подходы кнута и пряника повсеместно распространены потому, что деятельность обычных коллективов базируется на недоверии (любимая поговорка менеджера-неудачника: "все врут"). Однако pure-аджайл невозможен без доверия всех сторон и всех без исключения участников друг к другу. Но доверительные отношения надо выстраивать, над этим надо трудиться и организовывать в компании нечто вроде реалити-шоу "Аджайл 2: построй свое доверие".
[spoiler]Экстремальное программирование XP упоминалось, что интересно, не очень часто. Основная масса докладов пришлась на Scrum и бережливый лин, а из перспективных методик активнее всего рассматривается разработка, управляемая тестированием (TDD), и ее улучшенные варианты (например, сочетание TDD с в парным программированием).
Группы, применяющие TDD, учатся заметно быстрее других, лучше взаимосвязаны друг с другом, пишут более модульный код, в котором меньше ошибок, и отлично применяют рефакторинг.
Основная идея TDD в том, что тесты пишутся до программирования логики, а реализуется она ритмом "красный - зеленый - рефакторинг":
-- короткими итерациями (минуты) в код добавляется новый тест (этот процесс, собственно, и является ключевым, он своего рода искусство делать тесты не слишком детальными и не слишком глобальными);
-- "красный": сначала тест проверяется сам (красный - цвет неуспешности теста в системе тестирования кода JUnit, которая традиционно используется в TDD);
-- "зеленый": добавляется прикладной код, отвечающий требованиям теста, и разработчик добивается успешности его работы (зеленая полоска в JUnit);
-- с помощью рефакторинга код оптимизируется и вся избыточность исключается.
В отношении TDD существует классический вопрос его оппонентов "если вы фокусируетесь сначала на тестах, откуда вы знаете, что вы будете тестировать?" и не менее классическое возражение "если вы фокусируетесь на прикладном коде, откуда вы знаете, что он будет необходим?".
Существует даже метрика "покрытие кода тестами", иногда формально стремятся к 100%-му покрытию, однако в крупных проектах резко увеличивается число тестов, которые надо изменить, если меняется действующий код, поэтому лучше применять TDD в отношении важного сложного кода, дабы упростить отладку и облегчить его изменение впоследствии.
Согласно исследованиям коммуникаций при парном программировании, 7% времени уходит на оффтопики, 11% -- на обсуждение требований, 14% -- на архитектуру, 68% -- на детали реализации (синтаксис). Отсюда вывод: надо учить разработчиков переводить общение на более высокий уровень абстракции, в терминах проектного дизайна. Применительно к TDD парное программирование реализуется, например, так: один составляет тест, другой пишет реализующий код. Другие варианты: один кодирует все, другой подсказывает и направляет, как штурман; ну и конечно популярна схема "старший -- младший".
Был представлен простой рекурсивный метод Mikado рефакторинга большого проекта. Он достаточно очевиден, но практика показывает, что для немалого числа разработчиков оказывается откровением. Например, программист вносит множество изменений в код, потом применяет рефакторинг, и тут возникает большое число конфликтов. Если пытаться механически устранить их по очереди, скорее всего, проблемы только накопятся (в итоге код зарефакторизовывается до смерти). Лучше же составить список конфликтных рефакторингов, вернуться к исходному варианту проекта до начала массовой модификации, выбрать очередной рефакторинг, добиться устранения связанного с ним конфликта, применить к проекту, и продолжить процесс по оставшимся модификациям. При этом очень возможно, что некоторые текущие рефакторинги тоже приведут к серии конфликтов, и тогда данный метод рекурсивно применяется уже к конкретному шагу.
Признаки того, что проект начинает дурно пахнуть:
-- группа затыкается с текучкой;
-- бэклог (список требований) незрел и неполон;
-- не удается расставить приоритеты требований по их реальной важности;
-- слишком много времени тратится на выпуск очередного релиза;
-- много багов выявляется в последние дни итерации;
-- тим-лидер считает, что все хорошо, а заказчик неудовлетворен.
далее -- как улучшить аромат проекта, довести любое дело до конца, быстро внедрить аджайл, и про разработку, управляемую потоком
