Когда обсуждают Agile, то очень часто в спектр его методов включают только организационные методы и практики, такие как Scrum и Kanban, обеспечивающие предсказуемое, гибкое и управляемое прохождение потока задач с коррекцией результата на основе обратной связи от заказчика и рефлексивной адаптацией самого процесса. Однако, ограничиваясь ими, Agile бы никогда не достиг успеха в сложной инженерной области, которой является разработка программного продукта. Этот успех обеспечивают многочисленные инженерные методы и практики, которые сопряжены с организационными и дополняют их. И когда мы переносим Agile за пределы IT-отрасли, необходимо позаботится об адекватной замене этих практик, потому что они достаточно плотно наполнены спецификой IT. Да и если говорить об использовании Agile для IT-разработки, то пренебрежение базовым набором практик приведет провалу проектов в том или ином виде. При этом ряд из них стали известны задолго до появления гибких методов, и они обеспечивают устойчивость и успешность IT-разработки. Тем не менее, до сих пор находятся компании и команды, которые считают их второстепенными и не нужными, и встречается это как среди противников Agile, так и среди его сторонников.

Этот пост дает краткий список инженерных практик Agile. Я их перечислял недавно в нескольких дискуссиях, и решил, что полезно зафиксировать результаты в блоге. Практики подробно не раскрыты - их содержание легко можно найти. Но они позиционированы относительно функции в процессе разработки. А если Вас интересует что-то конкретное, возникнут вопросы, то обращайтесь.

  1. Countinuous Integration и его современное развитие - Countinuous Delivery. Предназначен для поддержки системы инкрементальной разработки продукта вплоть до непрерывной поставки. Входит в базовый, гигиенический набор практик. Обычно включает исполнение автоматических тестов, но не обязательно.
  2. Автоматическое тестирование. Обеспечивает стабильность продукта в условиях непрерывного развития и непрерывного рефакторинга - которые являются платой за гибкость разработки. Это - не обязательная практика, у нее есть альтернативы в виде технологичного ручного тестирования, либо применения практик работы с продуктом, ориентированных на качество кода (FDD, DDD), но является основой практик BDD и TDD, о которых дальше.
  3. TDD - Test Driven Development. Разработку начинаем с тестов, это выделилось из XP. Эта практика обеспечивает входное тестирование на достаточность требований: может ли разработчик на их основе написать проверку функционирования системы как черного ящика? Если да - то значит требования достаточно ясные и определенные, и можно начинать продумывать конструкцию системы внутри. Опыт показывает, что слишком часто конструкцию начинают придумывать, не разобравшись с запросом пользователя, и в результате делают совсем не то. что нужно. Кстати, это встречается и в других областях, например. в маркетинге - люди начинают творить не задумавшись о желаемом результате. а лишь наметив область. А еще TDD способствует достаточно ясному и удобному для использования API.
  4. BDD - Behavoiur Driven Development. В принципе является дальнейшим развитием форматов userstory, с одной стороны, и TDD с другой и нацелен на прозрачность коммуникации между разработчиком и заказчиком или конечным пользователем. Разработчик получает ожидания пользователя о поведении системы в достаточно формализованном виде, и это является таким контрактом на поведение системы как черного ящика. В пределе это описание на псевдо-естественном языке (формализованном подмножестве естественного), которое может быть играть роль автоматического теста системы.
  5. FDD - Feature Driven Development. Придумал Джефф де Люка. Это организационная поддержка декомпозиции системы, базирующаяся и овеществляющая закон Конвея. Мы делим системы на кусочки и за каждым закрепляем ответственного и говорим, что API на границах является контрактом, изменение которого - предмет фиксируемой договоренности двух ответственных. Кусочков достаточно много, каждый ответственный за несколько, и при перегрузках можно передавать друг другу. Дополнительная фишка: ответственный - это обычно ведущий (senior, старший) разработчик, у которого есть 1-3 подчиненных, которых он растит (и которым можно передавать ответственность). Получается организация мини-команд, которая достаточно эффективна (почти каждый ведущий легко берет 1-3 подчиненных, в отличие от руководства командой), и мы получаем размер команды в 30-50 человек, или даже более, в зависимости от связности-модульности системы. Практика обеспечивает удержание архитектуры в условиях меняющихся требований и непрерывного развития. Она обеспечивается за счет мелкодисперсной структуры. При этом на архитектуру интеграции напрямую ограничений не накладывается.
  6. DDD - Domain Driven Design, Эрик Эванс. Это - наиболее продвинутый метод работы с требованиями для сложных предметных областей.

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

Инженерные практики Agile.png

А в заключении хочу отметить следующее.

  1. Для сложных систем этого все равно недостаточно, там нужна координация работы с архитектурой и согласованное изменение составных частей. Для этого разработан SAF - Scaled Agile Framework, в котором достаточно много соответствующих активностей. Хотя он больше находится в организационной плоскости, нежели в инженерной.
  2. Организационные и инженерные практики должны быть поддержаны инструментально. Здесь в базовый набор входит система контроля версий, например, Git, Task tracker, Wiki-системы ведения документов, средства непрерывной интеграции, автотестов и конвейера поставки продукта. Наглядные Scrum-доски, как правило, не заменяют, а дополняют их, хотя часто начинать можно с этих средств. А вот если вместо task tracker и Wiki-систем у вас почта и свалка документов на файловом сервере, то процесс работать не будет, независимо от гибких методологий.
  3. Практики дополняют друг друга, собираясь как паззл в метод разработки. Применяемый метод должен быть адекватен проекту, а в пределе - каждый проект разрабатывается собственным адаптированным методом. И недавно разработан формализм для технологичной работы с индивидуализированными методами IT - разработки - OMG Essence. Но это уже тема отдельного поста.