Как реализовать подход Agile чтобы качество организации кода было приемлемым?

#архитектура #проектирование #agile #scrum #project_management

Введение

Недавно задал вопрос:


  Agile - это зло? Или при каких условиях это выигрышный подход?


Ближайшие 2 ответа были примерно следующими:


"Аджайл работает только если заказчик готов таким образом работать. ... Но если заказчик
так работать не готов, то лучше и не связываться." (ответ от @Qwertiy)
Наиболее часто требования меняются. "Во всех более-менее крупных разработках я только
пару раз работал не с Agile ..., когда заказчик выдавал действительно законченные ТЗ.
... Во всех остальных работах что-то постоянно менялось (иногда сильно, ... иногда
слабо ...)..." (ответ от @avp)


С учетом заголовка этого моего вопроса, ответы очень в тему и очень полезные. Но
задавая вопрос, мне хотелось узнать еще больше. То есть, как организовать проект, чтобы
из продукта не получился "крокодил"?


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


Если на выходе не получается продукт, который годится и со внутренней и со внешней
стороны, то (не знаю как сказать), либо подход Agile себя не оправдывает, (либо сказать
так) либо за проект по принципам Agile не стоило вообще браться.



Вопрос

Посоветуйте (варианты/мудрость/набитые_шишки), как построить процесс организации
кода при подходе Agile, чтобы согласовываться с рамками подхода с т.з. менеджмента
(спринты, сроки, требования, заказчики, руководство), но и чтобы продукт после сдачи
можно было развивать и поддерживать? 



Уточнение вопроса


Как инициировать структуру проекта, как должен выглядеть фреймворк проекта, включая
БД? Ведь обычно у проекта есть БД!!. Как быть с БД при меняющихся требованиях? То есть,
как сделать гибкую рамку системы, чтобы потом наращивать фукционал (выкидывать, менять,
добавлять) но при этом не делать все заново каждый раз?


Интересны любые советы, мысли, наблюдения, выводы из опыта.



Update:

Очень интересны краткие описания технических решений. Например, из имеющихся ответов:
скрывать старый функционал за Фасадами. Или использовать Агрегаты в БД по принципам DDD.

Спасибо!



Зачеркнуто из старой версии вопроса. Для того, что бы был один вопрос, а не много.


Как сделать, чтобы продукт имел такую организацию кода, чтобы в будущем оставаться
достаточно "живым" на долгое время и служить пользой? Чтобы отвечать новым адекватным
вызовам и в приемлемой степени подстраиваться под реальность? Чтобы не было такого,
что реальность должна подстраиваться под программу из-за структуры кода, потому что
программа делает не совсем то, что нужно, а изменить этого нет никакой возможности
(только сделать новый продукт почти сначала)?

Понятно, что ничего идеального нет. Речь идет скорее о том, чтобы проект не оказался
провальным в долгосрочной перспективе.
Всплывают в уме термины TDD, BDD... Какое им место при проектировании и реализации?
Мне кажется, есть две крайности. Перфекционизм и вылизывание кода, когда это никому
не надо (с одной стороны). И "работает - не трогай", когда все внутри запутанно, но
наращивать функционал надо и это уже почти невозможно (с другой стороны). Мне кажется,
что для успеха надо избегать и той и другой крайности. Где золотая середина? Как при
этой золотой середине выглядит код?
Даже если вначале понятно, что требования нечеткие, и заказчик готов работать по
принципу периодических спринтов, то это, как я понял только необходимые условия, но
не достаточные. Может ли тут быть такое, что если не находится красивое/хорошее решение
по проектированию базовой основы будущего приложения (то, что я называл рамкой, включая
БД), то следует отказаться от ведения проекта по принципу Agile, или отложить начало
проекта (если возможно) до уточнения требований или до нахождения нужного проектного
решения?
Расширенная форма предыдущего пункта. Допустим, есть уже основа из старого ПО, над
которым надо делать новый функционал. Как часто бывает, по хорошему, старое надо конкретно,
структурно модифицировать, прежде чем надстраивать новое (или вообще выкинуть старое).
Старое уже как бы мертвое, но пока используется. Единственная возможность, как мне
кажется, как ботаники делают, к старому стволу прилепить маленькую веточку нового,
чтобы она прижилась и выросла в новое дерево. То есть с помощью какого-нибудь технического
приема использовать старую систему, как черный ящик или как ресурс новой системы. Если
не находится красивых/хороших проектных решений по модификации или по таким выходам
из ситуации, как ботаники делают, то не является ли это ранним признаком провала проекта
в долгосрочной перспективе?
Понимаю, что это все теория. На практике все сложнее. Так же, понимаю, что у каждого
проекта своя ситуация. Какой-то проект будет выигрышным даже если организация кода
запутанная, какой-то наоборот, только если не запутанная.

    

Ответы

Ответ 1

Краткое изложение моего опыта.

Я Proxy Product Owner / техдиректор на SaaS проекте, который разрабатывается по SCRUM.
Я же и занимался внедрением SCRUM на проект около 6-7 лет назад.

Проект с историей (живет больше 12 лет), с несколькими сменами целевых ниш, 2 попытками
переписать с нуля.

Основной принцип при внедрении любой вещи / фичи / технологии (тестов, agile, вообще
чего угодно) - все заинтересованные люди (включая заказчика/PO) должны четко понимать,
что и зачем внедряется. 


Заказчик должен понимать, что команда пишет тесты не просто так, а ради снижения
регрессии
Заказчик должен понимать, чем именно череваты конкретные технические долги (не вообще
факт наличия техдолга, а вот каждый конкретный оставшийся долг).
Команда должна понимать мотивацию заказчика и пользователей. Должна наступить себе
на горло, и, если нужно, релизить с багами.
Заказчик должен понимать цену каждого измения (причем не только $, а в импакте изменения
на ту же самую поддерживаемость продукта)


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

Иначе не взлетит.

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



В своем вопросе вы пытаетесь охватить сразу все. К сожалению, вещи, о который вы
спрашиваете:


процесс разработки (анализ требований, планирование, взаимодействие людей)
абстрактный подход к архитектуре (TDD/BDD/DDD и прочие DD)
какие-то конкретные технические решения конкретно вашей проблемы (старый проект,
черный ящик и все такое)


это ортогональные понятия.


Можно работать по Водопаду и при этом использовать вообще какие угодно решения в коде.
Можно работать по Agile и при этом использовать вообще какие угодно решения в коде.


Продумывание архитектуры не привязано к процессу разработки. Сам по себе Agile, грубо
говоря, это даже не процесс. Это группа процессов, каждый из которых в какой-то мере
подходит под манифест Agile.


Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan.


Проблема с этим манифестом в том, что он просто озвучивает здравые мысли. Вполне
применимые в том же водопаде. 

Как этот манифест контролирует, в какой момент вам надо "делать базу" и как "работать
с заказчиком"? Да вообще никак.

Разработка ПО - это выбор подходящего процесс + подходящего технического решения
+ подходящих инструментов + подходящих людей. Серебряной пули нет. Золотой средины,
кстати, тоже нет.


Ответ 2

Добрый день.
Судя по размеру вопроса проблема является наболевшей. К сожалению, Agile это про
людей. Т.е. ваш вопрос немного не корректен. Вам нужен архитектор. Который разработает
и зафиксирует архитектурные решения, ограничения системы и т.д. Процесс этот сложный
и трудоемкий, но именно правильная архитектура позволяет в дальнейшем систему модифицировать
и изменять. Причем, даже самая замечательная в мире архитектура не позволит вам из
прогулочного катера сделать авианосец. Из вертолотоносца сделать авианосец - да, а
из катера - нет. Тут самое главное это ограничение. 
Agile тоже про это говорит, просто надо слышать. Например, в Agile есть пункт, что
нужно откладывать принятие решений на максимально поздний срок, насколько это возможно.
Но не позже. Если вы приняли решение делаем катер, то при пожелании заказчика - авианосец,
вам придется начинать с нуля.
Ну а дальше, когда у вас определены основные ограничения вы начинаете смотреть в
сторону SOLID, паттернов и т.д. 
Адекватная архитектура позволит вносить изменения в существующее решение при небольших
затратах, но если вы промахнулись в архитектурном решении, то вы опять в начале пути.
Ну и по конкретике. Ваш последний пункт про старую систему. Если там SOLID соблюдается,
то вы многие части старой системы можете адекватно перенести в новую. Если нет, то
как вариант сделать адекватные фасады (паттерн проектирования), через которые использовать
старый функционал, постепенно заменяя его на свои реализации.
Сложно отвечать на такой большой крик души. Если есть что-то по конкретике, уточните,
давайте попробую помочь.


Ответ 3

Попробую написать своё видение, но оно очень субъективно.


  Посоветуйте (варианты/мудрость/набитые_шишки), как построить процесс организации
кода при подходе Agile, чтобы согласовываться с рамками подхода с т.з. менеджмента
(спринты, сроки, требования, заказчики, руководство), но и чтобы продукт после сдачи
можно было развивать и поддерживать.


От кода тут практически ничего не зависит. Главное условие - код не должен быть страшной
лапшой без признаков ООП. Всё остальное вполне исправимо.
Максимально используйте основной плюс - обратную связь. Всё, что делается, должно
быть как можно раньше показано если не пользователям, то хотя бы аналитику\PO\заказчику.
Все их отзывы - обрабатывайте, решая какие из них важны для продукта, а какие - блажь
и не нужны. Ну и, кто-то главный (PO обычно) должен держать в голове всегда виденье
продукта целиком. Не каждой отдельной частицы, а именно всего продукта. Чтобы добавление
новой плюшки не выглядело костылем. Чтобы изменение какой-нибудь мелочи не выбивалось
из общего "стиля" программы.


  Или как сделать, чтобы продукт имел такую организацию кода, чтобы в будущем оставаться
достаточно "живым" на долгое время и служить пользой? Чтобы отвечать новым адекватным
вызовам и в приемлемой степени подстраиваться под реальность? Чтобы не было такого,
что реальность должна подстраиваться под программу из-за структуры кода, потому что
программа делает не совсем то, что нужно, а изменить этого нет никакой возможности
(только сделать новый продукт почти сначала)?


Я не понял, в чем конкретно проблема. Почитайте DDD, он довольно толково объяснит,
как разрабатывать программы, чтобы они не оказались "от программистов для программистов",
а были разработаны с учетом потребностей пользователей и для пользователей.


  Самое для меня интересное! Как инициировать структуру проекта, как должен выглядеть
фреймворк проекта? Ведь обычно у проекта есть БД!!. Как быть с БД при меняющихся требованиях?
Как сделать гибкую рамку системы, чтобы потом наращивать фукционал (выкидывать, менять,
добавлять) но при этом не делать все заново каждый раз?


БД всегда можно конвертировать. В БД должны быть "агрегаты" в понимании DDD, чтобы
принципиально их переделывать никогда не пришлось. Агрегат всегда существует в этом
мире, а потому понятен пользователям. Более того, сам агрегат должен быть навязан вам
пользователями, а не наоборот,тогда он скорее будет расширяться, а не переписываться.

По поводу переписывания старого и всего остального:
Для того чтобы начать писать проект или начать переписывать проект - вам нужны специалисты,
которые смогут это спланировать\спроектировать и будут при этом понимать предметную
область хотя бы по крупному. Опытный архитектор как минимум на начальной стадии - необходим.
Разбить крупную тему "продукта" на таймлайне критически необходимо как можно раньше,
согласовать её с заказчиком - тем более. Таймлайн поможет идти по аджайлу - выпустили
сырой продукт, показали аналитику\PO\заказчику, получили фидбэк, переделали. Пара-тройка
прототипов до всего этого - тоже вполне хороший вариант.

Если вам нужна какая то другая информация - то либо формулируйте конкретные вопросы,
либо читайте литературу. По аджайлу её достаточно.


Ответ 4

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

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

Но в любом случае есть "заготовки".


используйте системы контроля версий. Если что то сломается, то можно найти когда
и почему.
используйте тесты. Хотя бы для критических участков. Если нужно модифицировать старый
код - обложите тестами и вперед.
сделайте сборку "одной кнопкой". да, да, должен быть либо Jenkins (или любая другая
система), либо, хотя бы один скрипт, который может полностью собрать и проверить проект.
Используйте миграции для базы данных. 



  Как при этой золотой середине выглядит код?


а код выглядит так, что бы решать задачу заказчика.


  Может ли тут быть такое, что если не находится красивое/хорошее решение по проектированию
базовой основы будущего приложения (то, что я называл рамкой, включая БД), то следует
отказаться от ведения проекта по принципу Agile, или отложить начало проекта (если
возможно) до уточнения требований или до нахождения нужного проектного решения?


А почему поиск решения не может быть частью спринтов? вполне можно разбить команду
на группы и каждая пилит минимальный прототип. Менеджеры также могут работать по спринтам.

В целом, все Ваши вопросы возникают потому, что Вы пытаетесь взять на себя роботу
архитектора, а опыта нет.