Я читаю книгу "Профессия архитектора программного обеспечения" Марка и Лоры Сьюэлл (ссылка Amazon), и мне стало интересно, архитектор программного обеспечения является частью старого несовместимого подхода BDUF.
Есть ли место для архитекторов программного обеспечения в гибком подходе? Меня особенно интересует Scrum.
BTW Я в настоящее время являюсь разработчиком приложений Unix для крупной компании.
веселит,
Rob
Конечно.
Помните - подвижный - это не подход "принеси мне рок". По-прежнему существуют требования, которые по-прежнему представляют собой проект и все еще нуждаются в солидной архитектуре.
Когда вы строите линию продуктов или продуктов и используете Scrum или какой-либо другой гибкий подход к управлению вашим проектом, одна из ключевых идей заключается в разработке короткого цикла итерации, определении приоритетности отставания задач для выполнения, определения того, что собирается быть в итерации A, B, C и т.д. Там, где архитектор может действительно быть ценным. Если кто-то с ясным представлением о том, как X, Y и Z будут соответствовать друг другу, могут сделать ваши итерации Scrum намного более производительными.
Моя роль архитектора в Scrum включает следующее.
Технические спайки - доказательства концепции - как мы это сделаем. ( "Было бы проще, если бы вы просто использовали библиотеку SMTP напрямую, он уже обертывает существующие библиотеки SMTP, а писать собственную обертку вокруг нашей обертки не очень помогает. Мы можем добавить нужный вам метод".)
Координация между разработчиками в соответствии с предполагаемой архитектурой. ( "Ummm... почему вы используете свой собственный файл свойств?"
Работа с пользователями для правильного определения отставания. ( "Эти три связаны, если мы делаем одно, мы получаем два других при почти нулевой дополнительной стоимости".)
Работа с менеджерами для покрытия отставания. (Нет, менеджер проекта не может этого сделать, у них нет технической глубины. Нет, программисты не могут этого сделать, они не имеют обзора.)
Объяснение, почему имена пакетов таковы, и почему модель данных имеет эти функции.
Поиск недостающих вещей и переориентация отставания по техническим причинам ( "Нам понадобится этот дополнительный спринт для интеграции [X], обновления [Y] и замены [Z], или мы никогда не получайте эти спринты".)
Проворное развитие не означает анархистское развитие, оно по-прежнему должно быть согласованным, чтобы оставаться постоянным с течением времени.
Но... Может быть, самая большая разница между методологией водопада и гибкими методологиями заключается в том, что там, где вы обнаружите программное обеспечение achitect PERSON в водопаде, вы, вероятно, будете использовать программный продукт SKILL в гибких разработках. Я имею в виду, поскольку люди работают более аккуратно, тем не менее, есть высокая вероятность того, что навыки со временем станут более доступными для команды скважин, что хорошо.
Конечно, архитектор программного обеспечения "лидер" будет тем, кто сохранит общую картину и обеспечит согласованность всех строительных блоков, но он не будет единственным, кто будет ссылаться на время, поскольку его знания будут преподаваться другим.
Абсолютно да, особенно в средних и крупных проектах. Архитектор обеспечивает техническое направление, имея вид на птицу с точки зрения проекта и отвечающий за оценку и смягчение технического риска. Разработчики, как правило, имеют более узкий фокус и менее подвержены серьезным проблемам.
Полностью.
Процесс разработки/проекта, о котором вы упоминали, предназначен для создания того, что проектировал архитектор.
Таким образом, часто используемая аналогия, архитектор проектирует и планирует город, дороги, здания.
Разработчики строят город, дороги, здания.
Разработчики могут использовать любую систему управления проектами, необходимую им для создания здания, автомобилей на дороге и в городе.
Так же, как архитекторы зданий могут следить за зданием вместе с инженерами, так и архитектор программного обеспечения может под рукой следить за процессом разработки.
Обе роли Architect и Developer связаны друг с другом, но могут следовать различным процессам, чтобы выполнить свою собственную рабочую программу.
Я бы сказал, что, безусловно, есть. Несмотря на то, что сосредоточенность на гибкости заключается в том, что разработчики могут свободно соизволивать собственный код, все же существует потребность в разработке общей программы на более высоком уровне, чем работает отдельный разработчик.
Абсолютно - архитектор желателен и необходим в команде схватки. Возможно, вы не услышите об этом от страстных евангелистов, тренеров и т.д., Но любой опытный владелец продукта скажет вам об этом. роль архитектора в схватке очень важна.
Я думаю, что это скорее проблема навыков, чем проблема подхода. Так что да, он может сыграть свою роль, даже если у него есть этот титул.
Однако... Agile лучше всего подходит для небольших проектов, а специализированные архитекторы обычно более полезны в крупных проектах.
То, как я думаю, будет работать хорошо, это если Архитектор закроет всю дорожную карту и определит необходимые модули вместе с лидерами команд в стиле Scrum. Однако тогда руководители Команды и их команды Scrum выполняют фактическую разработку.
Вид двухэтапного Scrum.
Даже в методологии Agile, которая может не иметь строгой иерархии, программисты не будут равны. У вас будут опытные участники кампании, новички, те, кто знает кодовую базу и проблемную область назад, и комбинации вышеперечисленного.
Я думаю, что, хотя, возможно, не существует "формальной" архитектуры в действительно гибком проекте, всегда есть архитектурные проблемы, которые необходимо решать, и, как правило, более опытные члены команды будут иметь знания для решения некоторых из этих вещи.
И также имейте в виду, что внутренний метод проекта может быть отделен от уровня зарплаты - поэтому заголовок может в значительной степени игнорироваться "на задании", так сказать.
+1 на ответ С. Лотта. Роль архитектора важна, но гибкий подход требует, чтобы архитектор спустился с башни из слоновой кости и достал его/ее руки грязными с командой. Это может быть сложно, так как башни из слоновой кости часто приводят к разъединению с созданием программного обеспечения.
Мы успешно практикуем Scrum в течение 1 года, и то, что мы пережили, состоит в том, что нужно сбалансировать две вещи: -System Architecture является важным "противовесом" в среде, ориентированной исключительно на характеристики. Стратегическое и среднесрочное планирование на техническом уровне должно быть сделанные явно, поскольку владельцы продуктов сосредоточены на следующих функциях, которые они хотят реализовать (что, конечно, нормально с их стороны) - С другой стороны, действительно подвижный означает, что -Системные архитекторы не должны сидеть в башнях из слоновой кости (как упоминалось в нескольких предыдущих сообщениях) и разрабатывать вещи, которые работают только теоретически - Знание должно быть распространено, чтобы каждая команда обладала достаточными архитектурными навыками.
Наше решение было следующим (мы работаем в среде с несколькими командами): Мы создали виртуальную команду, возглавляемую ведущим архитектором (который не входит в команду Scrum). Каждая команда решает каждую проблему, которая должна быть обсуждена члены которого хотят принять участие в обсуждении. Команда принимает общее решение. Если необходима дополнительная работа, это делается либо с помощью новой истории пользователя или если он маленький за пределами Scrum. Члены команды, которые присоединились к решению, несут ответственность за передачу решения и контролировать его выполнение в пределах своих команд.
Совершенно верно. Нет причин, по которым архитектура должна быть сделана все впереди.
Да очень нравится
"Архитектор был термином программного обеспечения, украденного из строительной отрасли с намерением описать кого-то, кто курировал проект в целом. Архитектором в строительной отрасли является тот, кто консультируется с инженерами-строителями по поводу внешнего вида и" человеческого интерфейса "проекта. Более тесная параллель может быть проведена между строительным" архитектором "и" дизайнером UX" программного проекта. Термин, который, как я считаю, более подробно описывает то, что делает архитектор программного обеспечения, является системным инженером.
Итак, какова роль архитектуры программного обеспечения в гибкой разработке? Чтобы понять это, важно понять принципы гибкой разработки программного обеспечения. Эти принципы можно найти в Манифесте для разработки Agile Software Development http://agilemanifesto.org
Лица и взаимодействия над процессами и инструментами
Рабочее программное обеспечение по полной документации
Сотрудничество с клиентами по заключению договора
Ответ на изменение в соответствии с планом
Дополнительная информация здесь: http://carlospliego.com/2016/10/08/agileSoftwareDevelopmentAndArchitecture/
Прежде всего: команда Scrum организована самостоятельно. Это означает, что роль технического управления не так выражена. Да, команда может выбрать/пригласить участника на роль. Но в этой роли также нужно делегировать команду. Да, на самом деле это не так. Кроме того, команда очень сильна в встречах и спринтерских частях, в основном. Техническая архитектура обеспечивает решения уровня эпоса и, по крайней мере, требует построения дорожной карты, утверждения технологий, обратной связи с заинтересованными сторонами и другими конкретными операции - это тема темы. Кроме того, технические архитекторы действуют в интересах корпоративного развития компании, особенно для поддержания DRY и других принципов повторного использования решений, качества и т.д. Крупные спринты могут быть и должны быть взаимосвязаны в многопользовательской компании, что также требует договоренности на уровне руководства. В этих аспектах архитектор от имени заинтересованных сторон и, кроме того, технические элементы, ограничения, шаблоны, технологии, которые являются предметом реализации, являются правильной частью истории пользователей. В принципе, при необходимости архитектор может писать код в спринтерских фреймах, если он в интересах бизнеса (это сильно зависит от кода руководства в конкретной компании, я не вижу здесь ничего не выходящего за пределы диапазона). Но определенная роль архитектора - это технические решения от имени заинтересованных сторон для ведения бизнеса для перевода технических определений и технического руководства.
Я не думаю, что есть необходимость, поскольку руководство SCRUM, написанное оригинальными формантами SCRUM Д-р Джефф Сазерленд и Кеном Швабером, не упоминает необходимости в одном.