Комментарии 10
Скажите, насколько данный чек-лист подходит для Agile разработки?
Когда и требования и разработка идёт инкрементально и все постоянно меняется после тестирования на реальных пользователях.
Ох... То, как ведется разработка solutions-архитектуры в условиях Agile - это большой и непростой вопрос. Развернутый ответ с примерами потребовал бы отдельного большого поста. Давайте, я отвечу общо: если бизнес большой и сложный, и в продукт/решение вовлечено множество программных компонент, то все перечисленные в посте вопросы придется решать независимо от того, какая методология разработки используется в компании.
Поэтому, если коротко, то да, чек-лист актуален для Agile. И даже не зависит от конкретной методологии разработки. Методология будет влиять только на то, как именно вы идете от идеи к реализации.
Было бы здорово такой развернутый пост почитать, особенно примеры были бы полезны.
Подумаю над этим, но обещать такой пост пока не могу. Скажу честно: пока что не знаю, как писать на тему аджайла. Абстрактные принципы там просты, и они уже много где разобраны со всех сторон. Интересно именно разобрать как они реализуются в контексте конкретного бизнеса. Потому что у каждого бизнеса свои собственные препятствия на пути к реализации аджайла. Проблема в том, что анализировать конкретные бизнесы публично обычно нельзя...
Очень интересная и структурированная статья! А расскажите, какие инструменты вы используете для документирования и рисования диаграмм? Мне только uml на ум приходит, но я не имею опыта в архитектуре ПО.
И ещё, про технический долг, это случайно не про ту компанию, производящую процессоры? Ну это можете не отвечать, я так – посплетничать.
Спасибо за интерес!
Для документирования: Confluence, Microsoft Word. Однако лучшая документация должна жить в самом коде или каким-либо образом автоматически строиться на "живых" системах. Возможно, напишу как-нибудь об этом.
Конкретно для рисования диаграмм предпочитаю Draw.io (это визуальный редактор, очень шустрый) и PlantUML (генерирует sequence-диаграммы по текстовому описанию; очень удобно, если необходимо сравнивать разные ревизии диаграмм между собой, потому что текст сравнивать проще, чем картинки). Еще могу порекомендовать Enterprise Architect. Но это уже не просто рисовалка диаграмм. Это целый фрейморк для проективания систем и решений Enterprise-уровня. Там очень богатый функционал
Что изменится, если проектируется не решение в рамках сервиса, а функциональность в рамках коробочного продукта (кроме очевидно неприменимых пунктов)?
Вспомнил о тех продуктах, над которыми сам работал. Я бы сказал, что ничего, за исключением того, что очевидные лишние пункты уйдут. Но от специфики конректного бизнеса могут меняться акценты, либо исчезать/добавляться новые проблемы. Из своего опыта могу вспомнить проекты, которые предполагали активный вклад в Open Source или программно-аппаратный co-design (или даже и то, и другое сразу). Конкретно для этих случаев мой список был бы немного другим, но по большей части все равно остался бы тем же.
Спасибо за очень интересную и подробную статью. Подскажите пожалуйста, что именно Вы подразумеваете под "зона ответственности компоненты" и как определяете в документации? Интересно также из вашего опыта, как сотрудники, не являющиеся архитекторами/ аналитиками и не знающие решения целиком, справляются с определением зон ответственности отдельных сервисов?
Спасибо за отклик!
Под "зоной ответственности" я понимаю то, что должна делать компонента. Подробный пример потребовал бы много времени. Однако в одном из запланированных постов, на тему технического долга, будет такой пример.
В документации я прямым текстом пишу, что решение подразумевает создание новых компонент, у каждой из них будет такая-то зона ответственности. Дополнительно отражаю эту ответственность в названиях компонент, чтобы сразу было понятно, чем они должны заниматься, а чем - нет.
По моему опыту, не-архитекторы не очень хорошо справляются с назначением зон ответственности. Тому я вижу несколько причин:
1) у разработчиков и менджеров по разработке меньше кругозор. Они могут не учитывать полной картины. И это вполне понятно, потому что им, в основном, приходится концентрироваться на собственных компонентах либо на ближайших соседях
2) разработчики и менеджеры часто стремятся максимально сосредоточить разработку в подконтрольных им компонентах. Потому что это понятнее и быстрее позволяет прийти к результату
3) сейчас все больше менеджеров и разработчиков (хотя и не все, конечно же) стремятся прийти к результату по кратчайшему пути, чтобы побольше медалей получить на погоны в конце года. Долгосрочное развитие часто не принимается во внимание, потому что народ все меньше работает на одном месте. Одна из частых мыслей во время принятия неоптимальных решений: "Меня через два года уже не будет в этой компании". Впрочем, "кратчайший путь" - это часто иллюзия... Срезая неправильные углы, люди часто огребают по полной. И вместо пары месяцев идут в продакшн полтора года (и у меня есть реальные примеры).
Записки архитектора. Чек-лист