Архитектуру надо придумывать только тогда, когда продукт рефакторится.
Её нужно начинать продумывать уже на стадии формирования концепции продукта. Даже для гибкой методологии это необходимость. При рефакторинге адекватное описание архитектуры поможет быстро найти точки вмешательства.
До этого создавать самое простое, что возможно; обвешивать датчиками (измерять все что можно) и по необходимости оптимизировать узкие места, покрывать все тестами и чистить код и инфраструктуру от пахнущих кусков.
Ранняя разработка архитектуры нужна, прежде всего, чтобы избежать масштабных циклов тестирования — исправления ошибок в конце спринта. Если же архитектуру и детальное проектирование не проводить, то команда заплатит очень дорого за ошибки, которые можно было легко устранить на ранних стадиях, когда неверные решения ещё не были облеплены слоями кода.
Как говорил Макконнелл:
«Тестирование представляет собой способ определения уровня качества программного продукта, а не способ его обеспечения.»
И ещё цитата из Руководства Microsoft, указанного в конце статьи:
«Важно, особенно при проектировании и разработке по гибкому процессу, чтобы итерация включала как проектирование архитектуры, так и разработку реализации. Это поможет избежать масштабного проектирования наперёд.»
Не согласен. Архитектуру надо документировать даже, если в проекте один человек, но продукт предполагает длительное использование и может развиваться в будущем. Человек уйдёт с проекта и забудет о нём. Как восстанавливать причины всех принятых решений, если потребуется через год что-то добавить? Пролезть по всему коду? Это будет значительно дороже, чем сделать сразу нормальное, пусть и не формальное, описание архитектуры.
Нет, не побоку, а сбоку. Сквозная функциональность пронизывает все слои логической архитектуры, поэтому в выбранной нотации их рисуют вертикально, а чтобы схема была читаемой, сдвигают вправо.
Не согласен. Поэтапное рисование совы архитектуры можно найти, в том числе в Руководстве Microsoft, предлагаемом в конце статьи.
Но есть нюанс: в руководствах пропущен самый первый шаг. Остаётся открытым вопрос, как же начать проектировать систему. Я даю простой приём, который применим для любой системы и в любой нотации: начать от внешних систем и пользователей и постепенно углубляться внутрь.
Нотацию для своего примера я выбрал ту, которая, по моему опыту, наиболее понятна новичкам. Но тот же подход можно применить, рисуя схему в EnterpriseArchitect с использованием Archimate. Только объяснять условные обозначения придётся долго.
Так что с точки зрения методологии тут всё в порядке. Не надо отбрасывать последний абзац.
К сожалению, есть молодые коллеги, для которых уже вопрос о том, с чего начать проектирование системы, вызывает дрожь. А когда речь идёт об очень сложных системах, оторопь берёт и опытных архитекторов. Хотя суть-то остаётся почти той же, разве что решение бывает несколько хитрее и, вы правы, содержит гораздо больше подсистем, слоёв и уровней.
Рост — понятие комплексное. Если менеджеры чувствуют Ваше понимание и видят Ваши способности, они дают Вам более ответственные проекты, в результате чего Вы получаете возможность изучать новые технологии и работать над более сложными проблемами. Бизнес начинает вкладывать в Вас деньги: у Вас появляется более комфортное рабочее место, более качественное оборудование, нужная поддержка со стороны других специалистов. Возможно, Вас пошлют на курсы повышения квалификации, особенно, если бизнес заинтересован в наличии у некоторых сотрудников «корочек». Иными словами, профессиональный рост программиста имеет сильную зависимость от его лояльности понимания интересов бизнеса.
Но должен Вас огорчить. Одним из интересов бизнеса является рост Вашей ответственности. Не только ответственности за свой код, но и ответственности за работу всей команды в целом. Те же «корочки» бизнесу нужны, чтобы показать потенциальному заказчику способность команды реализовать сложный проект. Но заказчика редко интересует рядовой программист с кучей корочек. Заказчику нужны ключевые разработчики — архитекторы, тим-лиды, ведущие программисты. Те, с кого он может спросить.
Поэтому, если Вы хотите развиваться как программист, Вы должны понять, что отсидеться в стороне не удастся. Как говорил Джоэль Спольски:
«Ты никогда не стремился стать менеджером. Как и большинство разработчиков программ, с которыми я знаком, ты был бы гораздо счастливее, если бы тебе позволили спокойно сидеть и писать код. Но ты лучший разработчик...»
Путей много. Я вот до архитектора дорос. Знакомый техническим директором стал в не самой слабой компании. Как говорил старина Деминг: «Совершенствоваться не обязательно. Выживание — дело добровольное.»
Программисту имеет смысл всегда смотреть на продукт с точки зрения бизнеса, потому что бизнес на самом деле для него главный и единственный заказчик. Если он не продаёт продукт и это не его бизнес, то на этом все разговоры заканчиваются, и он просто выполняет именно то, что правильно с точки зрения бизнеса. Или идёт искать другую работу.
Но если программист проявляет усердие и воспринимает продукт как свой бизнес, то у него появляется возможность проявлять инициативу и за счёт этого расти. Он начинает по-другому воспринимать желания заказчика и своего руководства, и, понимая разницу между желаниями и истинными потребностями и имея техническую подготовку, может предлагать весьма интересные альтернативы. И тогда ему доверяют больше, платят больше, стараются дать более ответственные проекты.
Конечно, только сам программист решает, как воспринимать свой продукт.
Ваши эмоции понятны. Но картина несколько другая. У нас, во всяком случае.
У нас разрабатывалась несколько лет назад комплексная система безопасности. Поставлялась как «коробка». Покупателей было не очень много, но они были, и проект приносил прибыль. К нам приехал начальник службы безопасности АФК «Система» с кучей фич, которые, как он считал, самые нужные и обязательно должны быть реализованы в нашем продукте. Надо сказать, он был сильно удивлён, услышав мой твёрдый отказ. У нас была стратегия развития продукта, и его фичи нарушали эту стратегию. Мы могли попасть на сопровождение «кастомной» версии, что могло сделать проект убыточным в среднесрочной перспективе.
Мы включили в проект только небольшую функцию для поддержки печати пропусков на магнитных картах. Небольшой плагин. И таки поставили наш продукт в АФК. И получили благодарность и рекомендации, благодаря которым смогли привлечь других покупателей.
На самом деле, заказчику ВАЖНО как работает код. И бизнесу это очень ВАЖНО. Потому что корректно написанный код, учитывающий жизненно важные потребности исполнителя и заказчика, становится опорой для бизнеса и того, и другого.
Но да, есть вещи, которые бывают неважны. Например, если один и тот же функционал может достигаться применением старой, проверенной и надёжной технологии или новой, перспективной, но пока не проверенной, и заказчик, и топ-менеджмент исполнителя предпочтут первое, хотя программисту хотелось бы использовать второе.
Так что код интересен всем, но у каждого при этом свой интерес.
Вспомнилось тут, что у Джоэля Спольски была заметка «Мастерство». Он там говорил, что иногда исправление 1% ошибок влечёт 500% усилий. Так вот, лучше я со своей командой сделаю ещё 5 проектов, чем буду править ошибку, которая не сказывается на применимости и правильности нашего ПО. И, заметьте, если эти проекты будут сделаны для одного и того же заказчика, он будет больше счастлив, чем если бы ему пришлось ждать всё это время от нас исправления бага, незначительного для его бизнеса.
Мы последние годы в обязательном порядке в процессе разработки учитываем не только требования заказчика, но и интересы своей конторы. У нас есть стадия анализа востребованности проекта, где мы решаем, насколько и в каком объёме нам (нам, а не заказчику!) нужен продукт. При разработке требований мы учитываем и требования заказчика, и требования своего бизнеса. Фичуризм учитывается как риск. При реализации всегда исходим из минимальных затрат, позволяющих удовлетворить требования заказчика. Начиная с концепции и заканчивая кодированием.
Это даёт свои плоды. Наше ПО применимо, работает правильно и чуть лучше, чем у конкурентов. Может работать ещё лучше, но… всему своё время.
человек не может по определению заниматься 100% какой-то работой. Разработчики ходят на совещания, проходят обучение, обсуждают что-то с коллегами, участвуют в тимблидингах и т.д. Думаю 80-90% времени на написание кода — это неплохой показатель.
Фокус-фактор в максимуме достигает только 0,7, а в реальности — около 0,55-0,6. Это если разработчики мотивированные и опытные.
Но на самом деле, фокус-фактор тут ни при чём. Он учитывается при планировании работ. А тут нам нужно общее время, которое нужно оплачивать разработчику.
На привлечение нового сотрудника нужны деньги
На работу HR — да, нужны. Но он, как правило, не задействован на проекте 100% времени. Чаще всего он вообще на проекте не задействован.
На обучение нового сотрудника — тот же фокус-фактор. Новый сотрудник всё равно получает, как правило, ту же сумму или чуть меньше.
Был опыт работы над облаком. В него в том числе заливали и нестабильные Linux (мы, в частности, плотно работали с командой ALT Linux). Делалось это для того, чтобы разработчики, включая и наших, могли протестировать своё ПО и, если нужно, что-то в нём поправить. Широкому кругу пользователей мы нестабильные платформы не открывали, но к моменту обретения стабильности ОС мы уже имели некоторый набор стабильного ПО для этих платформ.
Так что моё мнение — нужны, с пометкой о нестабильности и, возможно, с ограничением доступа.
Спасибо. Мне кажется, надо такое вставлять в статью.
Да, учту это на будущее :)
А нельзя как-то по другому композировать.
Композировать получилось. Но не разбитием модели: она теряет смысл при малейшей потере целостности.
Мы применили известный подход многоэтапной поставки. Плюс некоторые наши практические наработки.
Грубо говоря, в данном проекте первый этап — фундаментальные функции, на которые опирается модель (тут был почти чистый scrum, поскольку вёлся эвристический поиск технологических подходов, способов обхода ограничений среды разработки и выполнения и прочая исследовательская работа, но при этом всегда вёлся контроль за превышением рамок, заранее определённых для задач этого этапа). Второй этап — полностью реализованная модель (тут гибкость уже стала отжирать неоправданно много времени и сил, требования и технологии были полностью определены ранее). Третий — прикладные надстройки над моделью (тут тоже гибкость была ни к чему). К концу любого этапа система была полностью рабочей. Первая фактическая поставка была на втором этапе.
На всех этапах разработчикам нужна была целостная концепция системы и единое качественное архитектурное решение. Опытная эксплуатация тоже была возможна только для полностью завершённой системы, иначе диспетчеры просто не могли её проверить, т.к. критерием готовности системы было совпадение наших результатов с теми, которые рассчитывались по старой технологии, с соблюдением заданных нам жёстких ограничений на время расчёта и используемые ресурсы.
Таким образом, гибкие методологии можно использовать, но на определённых этапах и не теряя фокус с цели и задач проекта в целом. Но гибкость процесса в сложном проекте начинает изматывать людей и забирать слишком много времени. Поэтому там, где гибкость не требуется, от неё нужно отказываться.
Я бы сказал, что в данном проекте схема процесса в целом была наиболее близка к RUP с жёстким контролем концепции проекта, но со своей спецификой.
Статья — обобщение моего опыта в надежде, что это поможет кому-то из моих коллег. Поэтому списка литературы не даю.
Примеры указал в ответе на один из комментариев выше. Но детально их раскладывать в статье, посвящённой только «верхнеуровневому» обзору используемого мной процесса, считаю, неуместным. Чтобы такой пример в статье был полезен, мне бы пришлось углубляться в каждый этап процесса, и тогда вместо статьи получилась бы увесистая книга.
Пример заказного ПО. Системное ПО для обеспечения процесса прогнозирования Единой энергосистемы России. Рассчитывается прогноз по всем типам оборудования, участвующим в генерации, передаче и потреблении электроэнергии, с учётом международных перетоков. Система чрезвычайно высоконагруженная, требует высокой точности вычислений, высочайшей надёжности: от её работы зависит, насколько точно будет сбалансировано производство электроэнергии и её потребление. Чтобы создать систему, пришлось изучать специфику каждого типа оборудования, специфику управления ими, фактически, специфику работы специалистов, управляющим энергосистемой. Архитекторам и программистам пришлось бороться за каждый байт и за каждый такт процессора. Нужно было учитывать специфику виртуализации вычислительных ресурсов. И ещё многое другое. Заказчик при этом не может надолго предоставить нам своих диспетчеров: они, поверьте, очень занятые люди. Всю систему нужно поставлять только целиком: никому не нужно ПО, рассчитывающее только 99% модели. Моя схема сработала: мы выпустили ПО в срок (хотя опытная эксплуатация несколько затянулась: был ряд моментов. которые можно было отследить только в боевых условиях).
Пример инвестиционного ПО. Мы долгое время разрабатывали одну комплексную систему безопасности. Под моим руководством было выпущено последовательно четыре версии этой системы. Она использовалась в мэрии Москвы, АФК «Система», ВГТРК и ещё тысячах организациях, начиная с нашего собственного офиса. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок. В тот момент, когда Россию накрыл кризис 2008-2009 года, мы не только не потеряли доходы, но и получили новый сегмент: бизнес-центры решили вкладывать в нашу систему на пике кризиса, хотя раньше не были на это готовы. Моя схема сработала.
Мы годами оттачиваем свои процессы. У нас много проектов, и мы гордимся, что наши продукты работают, а наши заказчики рекомендуют нас своим партнёрам.
Я не против гибкой методологии. Но я хочу говорить о том, что работает на практике для действительно сложных систем. Мой опыт двадцатилетней работы показывает, что приведённая в статье схема точно работает. И она для наших проектов достаточно гибкая.
Её нужно начинать продумывать уже на стадии формирования концепции продукта. Даже для гибкой методологии это необходимость. При рефакторинге адекватное описание архитектуры поможет быстро найти точки вмешательства.
Ранняя разработка архитектуры нужна, прежде всего, чтобы избежать масштабных циклов тестирования — исправления ошибок в конце спринта. Если же архитектуру и детальное проектирование не проводить, то команда заплатит очень дорого за ошибки, которые можно было легко устранить на ранних стадиях, когда неверные решения ещё не были облеплены слоями кода.
Как говорил Макконнелл:
И ещё цитата из Руководства Microsoft, указанного в конце статьи:
Если Вам нужно такое подробное руководство, то ссылка на него приведена в конце статьи. Почитайте.
совыархитектуры можно найти, в том числе в Руководстве Microsoft, предлагаемом в конце статьи.Но есть нюанс: в руководствах пропущен самый первый шаг. Остаётся открытым вопрос, как же начать проектировать систему. Я даю простой приём, который применим для любой системы и в любой нотации: начать от внешних систем и пользователей и постепенно углубляться внутрь.
Нотацию для своего примера я выбрал ту, которая, по моему опыту, наиболее понятна новичкам. Но тот же подход можно применить, рисуя схему в EnterpriseArchitect с использованием Archimate. Только объяснять условные обозначения придётся долго.
Так что с точки зрения методологии тут всё в порядке. Не надо отбрасывать последний абзац.
К сожалению, есть молодые коллеги, для которых уже вопрос о том, с чего начать проектирование системы, вызывает дрожь. А когда речь идёт об очень сложных системах, оторопь берёт и опытных архитекторов. Хотя суть-то остаётся почти той же, разве что решение бывает несколько хитрее и, вы правы, содержит гораздо больше подсистем, слоёв и уровней.
лояльностипонимания интересов бизнеса.Но должен Вас огорчить. Одним из интересов бизнеса является рост Вашей ответственности. Не только ответственности за свой код, но и ответственности за работу всей команды в целом. Те же «корочки» бизнесу нужны, чтобы показать потенциальному заказчику способность команды реализовать сложный проект. Но заказчика редко интересует рядовой программист с кучей корочек. Заказчику нужны ключевые разработчики — архитекторы, тим-лиды, ведущие программисты. Те, с кого он может спросить.
Поэтому, если Вы хотите развиваться как программист, Вы должны понять, что отсидеться в стороне не удастся. Как говорил Джоэль Спольски:
Но если программист проявляет усердие и воспринимает продукт как свой бизнес, то у него появляется возможность проявлять инициативу и за счёт этого расти. Он начинает по-другому воспринимать желания заказчика и своего руководства, и, понимая разницу между желаниями и истинными потребностями и имея техническую подготовку, может предлагать весьма интересные альтернативы. И тогда ему доверяют больше, платят больше, стараются дать более ответственные проекты.
Конечно, только сам программист решает, как воспринимать свой продукт.
У нас разрабатывалась несколько лет назад комплексная система безопасности. Поставлялась как «коробка». Покупателей было не очень много, но они были, и проект приносил прибыль. К нам приехал начальник службы безопасности АФК «Система» с кучей фич, которые, как он считал, самые нужные и обязательно должны быть реализованы в нашем продукте. Надо сказать, он был сильно удивлён, услышав мой твёрдый отказ. У нас была стратегия развития продукта, и его фичи нарушали эту стратегию. Мы могли попасть на сопровождение «кастомной» версии, что могло сделать проект убыточным в среднесрочной перспективе.
Мы включили в проект только небольшую функцию для поддержки печати пропусков на магнитных картах. Небольшой плагин. И таки поставили наш продукт в АФК. И получили благодарность и рекомендации, благодаря которым смогли привлечь других покупателей.
На самом деле, заказчику ВАЖНО как работает код. И бизнесу это очень ВАЖНО. Потому что корректно написанный код, учитывающий жизненно важные потребности исполнителя и заказчика, становится опорой для бизнеса и того, и другого.
Но да, есть вещи, которые бывают неважны. Например, если один и тот же функционал может достигаться применением старой, проверенной и надёжной технологии или новой, перспективной, но пока не проверенной, и заказчик, и топ-менеджмент исполнителя предпочтут первое, хотя программисту хотелось бы использовать второе.
Так что код интересен всем, но у каждого при этом свой интерес.
Мы последние годы в обязательном порядке в процессе разработки учитываем не только требования заказчика, но и интересы своей конторы. У нас есть стадия анализа востребованности проекта, где мы решаем, насколько и в каком объёме нам (нам, а не заказчику!) нужен продукт. При разработке требований мы учитываем и требования заказчика, и требования своего бизнеса. Фичуризм учитывается как риск. При реализации всегда исходим из минимальных затрат, позволяющих удовлетворить требования заказчика. Начиная с концепции и заканчивая кодированием.
Это даёт свои плоды. Наше ПО применимо, работает правильно и чуть лучше, чем у конкурентов. Может работать ещё лучше, но… всему своё время.
Спасибо всем за конструктивные замечания!
Фокус-фактор в максимуме достигает только 0,7, а в реальности — около 0,55-0,6. Это если разработчики мотивированные и опытные.
Но на самом деле, фокус-фактор тут ни при чём. Он учитывается при планировании работ. А тут нам нужно общее время, которое нужно оплачивать разработчику.
На работу HR — да, нужны. Но он, как правило, не задействован на проекте 100% времени. Чаще всего он вообще на проекте не задействован.
На обучение нового сотрудника — тот же фокус-фактор. Новый сотрудник всё равно получает, как правило, ту же сумму или чуть меньше.
Так что моё мнение — нужны, с пометкой о нестабильности и, возможно, с ограничением доступа.
Да, учту это на будущее :)
Композировать получилось. Но не разбитием модели: она теряет смысл при малейшей потере целостности.
Мы применили известный подход многоэтапной поставки. Плюс некоторые наши практические наработки.
Грубо говоря, в данном проекте первый этап — фундаментальные функции, на которые опирается модель (тут был почти чистый scrum, поскольку вёлся эвристический поиск технологических подходов, способов обхода ограничений среды разработки и выполнения и прочая исследовательская работа, но при этом всегда вёлся контроль за превышением рамок, заранее определённых для задач этого этапа). Второй этап — полностью реализованная модель (тут гибкость уже стала отжирать неоправданно много времени и сил, требования и технологии были полностью определены ранее). Третий — прикладные надстройки над моделью (тут тоже гибкость была ни к чему). К концу любого этапа система была полностью рабочей. Первая фактическая поставка была на втором этапе.
На всех этапах разработчикам нужна была целостная концепция системы и единое качественное архитектурное решение. Опытная эксплуатация тоже была возможна только для полностью завершённой системы, иначе диспетчеры просто не могли её проверить, т.к. критерием готовности системы было совпадение наших результатов с теми, которые рассчитывались по старой технологии, с соблюдением заданных нам жёстких ограничений на время расчёта и используемые ресурсы.
Таким образом, гибкие методологии можно использовать, но на определённых этапах и не теряя фокус с цели и задач проекта в целом. Но гибкость процесса в сложном проекте начинает изматывать людей и забирать слишком много времени. Поэтому там, где гибкость не требуется, от неё нужно отказываться.
Я бы сказал, что в данном проекте схема процесса в целом была наиболее близка к RUP с жёстким контролем концепции проекта, но со своей спецификой.
Примеры указал в ответе на один из комментариев выше. Но детально их раскладывать в статье, посвящённой только «верхнеуровневому» обзору используемого мной процесса, считаю, неуместным. Чтобы такой пример в статье был полезен, мне бы пришлось углубляться в каждый этап процесса, и тогда вместо статьи получилась бы увесистая книга.
Пример инвестиционного ПО. Мы долгое время разрабатывали одну комплексную систему безопасности. Под моим руководством было выпущено последовательно четыре версии этой системы. Она использовалась в мэрии Москвы, АФК «Система», ВГТРК и ещё тысячах организациях, начиная с нашего собственного офиса. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок. В тот момент, когда Россию накрыл кризис 2008-2009 года, мы не только не потеряли доходы, но и получили новый сегмент: бизнес-центры решили вкладывать в нашу систему на пике кризиса, хотя раньше не были на это готовы. Моя схема сработала.
Мы годами оттачиваем свои процессы. У нас много проектов, и мы гордимся, что наши продукты работают, а наши заказчики рекомендуют нас своим партнёрам.
Я не против гибкой методологии. Но я хочу говорить о том, что работает на практике для действительно сложных систем. Мой опыт двадцатилетней работы показывает, что приведённая в статье схема точно работает. И она для наших проектов достаточно гибкая.