2017-01-08: Инженерные практики Agile

Когда обсуждают 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, Эрик Эванс. Это - наиболее продвинутый метод работы с требованиями для сложных предметных областей.
   • DDD обеспечивает коммуникацию всех участников проекта с обсуждением системы не в виде черного ящика, как делает BDD, а раскрытием ее внутреннего устройства через построение модели системы, то есть позволяет заказчику обсуждать систему как прозрачный ящик. Для этого в рамках проекта создается специальный Единый Язык (ubiquitous language), описывающий предметную область, используемый для работы с требованиями и описания модели предметной области - которая является предметом согласования (контракта) разработчика с заказчиком. В отличие от обычной многостадийной формулировки требований с переводами (модель предметной области на одном языке, проект системы на другом, и так далее). При этом объекты модели должны трассироваться в код реализации, то есть перевод модели в код идет формально - что и позволяет говорить о представлении системы как прозрачном ящике.
   • А еще DDD сделал очень важный практический шаг в части работы с понятиями. Было замечено, что даже в относительно небольшой предметной области (например, банк или торговая компания) создать полную и непротиворечивую модель - сложно, так как разные люди (например, продажники, логистики и финансисты) используют термины по-разному. В рамках DDD вместо формального требования "единый словарь" эта проблема была осознана и предложено асимметричное решение. Единый язык создается не для всей области, а для некоторого ограниченного контекста (bounded context). Мы держим карту контекстов (context map). Но при этом, поскольку область одна. то в контекстах получается много пересекающихся понятий. И Эванс предложил использовать для них весь аппарат, накопленный ООП для объектов - наследование, полиморфизм, или наоборот изоляция и трансляция. Это реально круто, потому что переводит снимает проблемные холивары о "правильных" системах понятий, которые возникали между специалистами, редко взаимодействующими между собой в деятельности.
   • И, наконец, DDD содержит большое количество шаблонов, применяемых для построения модели. При этом подходы и шаблоны ООП переносятся на уровень организации бизнеса.

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

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

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

[ Хронологический вид ]Комментарии