Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: AlexTheRaven от 07 Июня 2009, 23:22:02
-
<не уверен, что это сюда, но не нашёл раздела "сравнение методологий">
Вышел у меня на днях спор: кто такой системный архитектор?
Я говорил, что это как у нас, это такой программист-тренер, который (как минимум):
- владеет сразу всем кодом с высоты "от двух метров над землёй до фотографии из космоса"
- может читать требования
- может сказать, что из требований не реализуемо, что реализуемо, но требует существенных модификаций в архитектуре, а что отлично в архитектуру укладывается
- имеет свои планы технологического развития, и может сказать, что соответствует технической стратегии развития системы, а что противоречит
- умеет перевести требование "система должна..." в ряд задач "изменить компонент... чтобы он мог... рекомендуется реализовать там (такой-то паттерн, такой-то известный алгоритм, использование такой-то известной библиотеки)"
- порекомендовать на задачу программиста, прикинуть трудоёмкость
- во время проектирования и реализации с программистами свои решения обсуждать (именно обсуждать, а не диктовать в стиле "приказы старших по званию не обсуждаются").
Т.е. на входе у него новые требования, а на выходе новая архитектура и diff'ы между текущей архитектурой и новой архитектурой. А в самом лучшем случае - технические формулировки и очень примерные оценки трудоёмкости задач.
При этом архитектор может попросить уточнить требования, но сам их не диктует, аналитиками не управляет, с Заказчиками не беседует, roadmap единолично не задаёт.
А мне два человека, называющих себя, по-видимому, системными архитекторами, говорили, что архитектор - это вообще "всё-в-одном", в т.ч. владелец проекта:
- сам с Заказчиками и более высокими начальниками "на высоком уровне" общается
- "на высоком уровне, стратегически" определяет, что система будет уметь, из чего состоять, как работать
- выдаёт задачи аналитикам "опиши то так, опиши это этак"
- организовывает и согласовывает работу всех остальных.
На моей же практике был один раз первый случай, два раза - второй, а один раз вообще архитектора не выделяли - был "коллективный разум". Всякий раз результаты проектов я оцениваю от "удовлетворительно" до "хорошо", без явных провалов, но и без "идеальных" результатов. Поэтому и задаю вопрос:
Дамы и господа, как у кого разработка с точки зрения роли системного архитектора устроена? У кого к какому варианту склоняется, и что из этого получается?
-
"на высоком уровне, стратегически" определяет, что система будет уметь, из чего состоять, как работать
А мне всегда казалось, что только Заказчик определяет, ""на высоком уровне, стратегически" определяет, что система будет уметь", и даже не Аналитик и МП, а тем более Архитектор.
Я работал по классической схеме Заказчик->Аналитик->Архитектор->Разработчик->...
Причем, Архитектор был как явный, когда писались Архитектурные Решения, так и неявный, когда эту роль играл наиболее опытный Разработчик и он делал наиболее сложные куски.
ИМХО и другие варианты возможны, тем более у нас, т.к. единой терминологии нет. Например, у нас Аналитиком могут называть и Архитектора и Постановщика Задач и Бизнес-Аналитиком и ...
-
IMHO архитектор создает, управляет построением и контролирует архитектуру разрабатываемой системы Собственно, это ключевой момент при выделению роли архитектора и определении необходимых навыков.
Это во-первых.
Во-вторых, источником информации для архитектора являются требования к системе, которые идут от аналитика (преобразовавшего требования заказчика в некий формализованный вид),
В-третьих, источником требований также являются возможности имеющегося материала - существующие в распоряжении архитектора компоненты. (хотя у нас обычна практика, когда таковых вообще не имеется, в связи с этим одна из задач архитектора обеспечить их наличие/разработку).
В-четвертых, архитектор не управляет в прямом смысле персоналом (разработчиками), он определяет (!) решение и отвечает за это. А разработчики реализуют (!) это решение. Поэтому прикинуть трудоемкость архитектор конечно может (из опыта), но фактическую оценку дает ответственный за разработку программист (опять же у нас так обычно построена работа). Так что не архитектор за это отвечает.
Важно: порядок формирования и обсуждения решения может быть любым, как сверху (как бы это ни было неприятно и неудобно для программирующей братии), так и снизу.
И не забываем, что архитектура системы нужна не сама для себя, а для реализации системы, УДОВЛЕТВОРЯЮЩЕЙ ПРИНЯТЫМ (утвержденным, согласованным) ТРЕБОВАНИЯМ!
А мне всегда казалось, что только Заказчик определяет, ""на высоком уровне, стратегически" определяет, что система будет уметь", и даже не Аналитик и МП, а тем более Архитектор.
Вопрос "кто определяет" в приведенной трактовке спорный, все перечисленные лица скорее участвуют в процессе разработки требований к системе (не забываем, что требования к системе бывают разные, а не только функциональные)
Я работал по классической схеме Заказчик->Аналитик->Архитектор->Разработчик->...
Причем, Архитектор был как явный, когда писались Архитектурные Решения, так и неявный, когда эту роль играл наиболее опытный Разработчик и он делал наиболее сложные куски.
Правильно, Архитектор (как и другие участники) - это РОЛЬ! Способы реализации этой роли могут быть весьма разнообразны. Аналогично и по другим приведенным примерам...
И, наконец, ответ на исходный вопрос: как лучше?
Лучше так, как работает как бы банально это не звучало. У нас бывают случаи, когда подобную роль играет человек, который и швец, и жнец, и на дуде игрец - и при этом у него всё получается, в таких случаях его можно не трогать. А если есть проблемы, т.е. человек не справляется - тогда надо раскидывать ролевые функции по другим участникам (к сожалению, они обычно воспринимают это дело в штыки).
P.S. Советую посмотреть на роль архитектора при строительстве зданий и т.п., что он делает и чего не делает. С программной индустрией очень схоже. Отличаются материалы и методы реализации :о)))
-
У нас архитектор организационно отделен от разработчиков, по требованиям, требующим изменений архитектуры, формирует/дополняет архитектуру (и ее модель) и высокоуровневую концепцию реализации, при необходимости может спуститься вплоть до детализированной инструкции для разработчика. Сроками и управлением проектной группой не занимается. В работу аналитика (если она не затрагивает архитектурные глубины) не вмешивается.
Перед запуском проекта проводит аудит проектных решений по проекту. Аудит не пройден - проектные решения переделываются. Так отслеживается, совпадают ли понятие "архитектурно значимые требования" у команды проекта и у архитектора.
-
Архитектор - человек, разрабатывающий эту картину в виде документа, пакета документов или модели.
бери шире - системы.
Например, в большой степени зависит именно от архитектуры и архитектора способность работы системы в режиме реального времени или какие-то другие неочевидные и зачастую нефункциональные (а даже и функциональные) особенности системы
-
А как обстоят дела с самым главным критерием - [финансовым] результатом?
Встречались ли Вы на практике с ситуациями, когда
1) Все подчинялись архитектору, архитектор единолично определял, что реализовывать, а что нет, и требования были для него "ещё одной какой-то ерундой", а аналитики - странными лишними людьми, в результате
1.а) всё получилось, "попали в яблочко", систему всё равно "отрывали с руками"
1.б) ничего не получилось, при всём внутреннем изяществе система оказалась бесполезной и никому не нужной?
2) Все были ориентированы на требования, архитекторы могли делать что-либо только в рамках требований, и
2.а) всё получилось, система нормально работала и удовлетворяла нужды Заказчиков
2.б) система превратилась в безумное bloatware, и несмотря на формальное удовлетворение требований, была такой нецелостной, некачественной и без внутренней идеи, что никому не была нужна?
-
В систуации 1 я была, результат получился средний, т.е. систему покупали, финансовый результат хороший, но и клиенты, и проектная команда часто ругались на странные решения и нечеловеческий интерфейс. Но в такой ситуации очень удобно обвинить именно этих странных людей аналитиков - т.к. они систему не знают, не понимают, поэтому и придумывают идиотские требования, а раз требования идиотские, на них можно забить и сделать так, как хочется.
-
была ситуация и 2.а и 2.б :)
-
Обычно кого назвали архитектором, тот и есть. То есть у всех по своему.
При этом архитектура - это описание устройства (состава и связей) и особенностей разрабатывемого объекта.
То есть картина в целом. Архитектор - человек, разрабатывающий эту картину в виде документа, пакета документов или модели.
Один комментарий ... Архитектура - это собственно структура и связи. А их описание - это architecture description.
-
А Вы что-нибудь знаете о том, как устроена разработка у больших и успешных, наподобие Microsoft, Google, Oracle, SAP? Autodesk, Corel, Borland, Symantec, Novell, Electronic Arts и других "богатых и знаменитых"? Какие у них используются методологии, есть ли там роль "авторитарный суперархитектор"?
Если честно, интересует в некотором смысле инсайдерская информация, а не та, которая уходит в прессу. Может, Вы сами там работаете? Или знаете кого-нибудь, кто там работает, и можете спросить?
-
Я пока только с 2.а сталкивался.
И у нас архитектор - точь в точь как и у AlexTheRaven.
Насчет гугла надо Дениса Бескова спросить.
-
Насчет гугла надо Дениса Бескова спросить.
Ага, я тоже клюнул на эту первоапрельскую шутку. :)
-
Добрый день
По поводу роли архитектора и его активностей в проекте.
Заметил такую вещь, что компании где архитекторы занимаются абсолютно всем (от согласования требований и бюджета до кодирования) как правило не имеют развитых производственных процессов (уровень CMMI не выше 2).
Это и логично т.к. в процессе разработки ПО, что ни говори кодирование и проектирование первично - без них системы не будет вообще (разработка требований и тестирование очень желательно, но не обязательно).
Соответветсвенно, центральным управляющим звеном в отсутвии развитых процессов становится руководитель разработки. т.е. архитектор. Как правило это люди очень ответсвенные, технически грамотные с высоким уровнем интеллекта, для них разобраться с азами управления проектом и управления требованиями не составляет особого труда.
В проектах же с четко регламентированными активностями для каждой роли в проекте и хорошо поставленными процессами, управление проектом и требованиями становится выделенным и архитектор занимается лишь перечисленными Вами активностями (в моих проектах они + - такие же )
Однако проект проекту рознь и в технологических проекта (где львиная доля требований это протоколы и детальные алгоритмы реализации) роль архитектора по сбору и анализу требований возрастает, иногда становится ключевой.
Т.е. главный вывод - перечень активностей определяется зрелостью процессов в компании, однако может уточняться в связи со спецификой конкретного проекта
-
Ida,
Я работаю в компании CMM Level 3 в России
Два года назад принимал участие в сертификации нашей компании на CMMI Level 5 SCAMPI B
Насколько я знаю Luxoft имеет CMMI Level 5
-
Гигантский скачок в развитии индустрии что ли проспала...
Или теперь сертификация подешевела... антикризисные расценки.
Однозначно проспала. В России даже собственный CMMI оценщик уже появился.
http://ocenchiki.ru/2009/pervyj-v-rossii-ocenshhik-po-cmmi/
-
Мое скромное имхо:
"Компания имеет сертификат CMMI level N" не равно "Компания имеет уровень зрелости CMMI level N"
А если этот сертификат получен год, два и более назад, то разница может быть очень существенной.
-
У нас так и есть в России. Гонятся за "грамотой" чтобы похвастаться на рынке и пропиарить свою компанию. Это конечно хорошо для привлечения клиентов, но в жизни, то что написано на сертификате так там и остается на бумаге, и люди даже в компаниях 3 уровня и выше занимаются "ремеслом".
-
Мое скромное имхо:
"Компания имеет сертификат CMMI level N" не равно "Компания имеет уровень зрелости CMMI level N"
А если этот сертификат получен год, два и более назад, то разница может быть очень существенной.
+1
Сертификация не значит, что работа реально построена по CMM (равно как по ISO, ГОСТ, СНиП, СанПиН, ГСН, ВНП, ВН, ГЭСНр, ЕНиР и т.д. :) ). Тем более, то, даже если CMM 3+, процессы описаны и зафиксированы, и даже развиваются, совсем не означает, что эти процессы работают эффективно и приводят к хорошему [финансовому] результату.
Что-то я не слышал, чтобы Microsoft, Google или Oracle сертифицировались на CMM. Потому что им эти ритуалы (сам понимаю, что назвать CMM ритуалами очень спорно) и PR не нужны, они и так хорошо работают.
Поэтому и хочется информации о практике :) . Может быть, с авторитетным-авторитарным архитектором, который концентрирует на себе принятие всех решений о функциональности и архитектуре (а то ещё и и управленческих), работа объективно идёт эффективнее, а проекты - быстрее и [финансово] успешнее? За счёт того же, за счёт чего и при индивидуальном программировании, например?
-
Да, безусловно CMMI имеет главной целью - маркетинговые. Так кстати было и у нас когда речь шла о сертификации.
Но несогласен, что компании имеющие CMM или CMMI по факту работают на коленке. У нас в компании точно не так и за выполнением активностей в проектах строго следит аудит.
Что касается финансовой успешности - то CMMI не имеет к этому никакого отношения, а местами идет в разрез. Эта модель предназначена для организации производственных процессов для достижения в первую очередь качества.
По поводу авторитарных архитекторов могу сказать, что всегда хорошо, когда есть один держатель проекта, представляющий себе и увязывающий в единую модель от требований до реализации всю систему у себя в голове.
Вероятность возникновения несогласованности требований и реализации в таком проекте резко уменьшаются. Работы идут на порядок быстрее.
Однако весь вопрос во времени - когда на тебе висит не один а несколько проектов (идут один за другим конвейером), да еще надо и кодить очень много и ревьювить что другие накодили, волей неволей приходится уступать позиции аналитикам и ПМ мам.
-
Но несогласен, что компании имеющие CMM или CMMI по факту работают на коленке. У нас в компании точно не так и за выполнением активностей в проектах строго следит аудит.
...
Эта модель предназначена для организации производственных процессов для достижения в первую очередь качества...
А как насчет конфликта интересов? между качеством и результатом...
Вопрос: а за достижением результата кто следит? а за затратами на аудит (в отличие о производственных)?
а ведь еще нужно устранять замечания аудита, и это тоже чего-то стоит...
Кстати, поделитесь, пожалуйста, KPI аудита.
-
Но несогласен, что компании имеющие CMM или CMMI по факту работают на коленке. У нас в компании точно не так и за выполнением активностей в проектах строго следит аудит.
Круто. Может быть хоть вы расскажете, как вы используете инструкцию по подгонке в реальных проектах? И в каждом ли проекте вы используете инструкцию по подгонке?
-
Может быть хоть вы расскажете, как вы используете инструкцию по подгонке в реальных проектах? И в каждом ли проекте вы используете инструкцию по подгонке?
что за зверь?
-
что за зверь?
Отсутствие этого зверя хотя бы в одном проекте означает отсутствие 2-го уровня CMMI (и всех остальных более высоких). Пока мне не удалось найти ни одной фирмы, где бы этого неуловимого зверька использовали. Что со всей очевидностью означает, что мне не удалось найти ни одной фирмы с уровнем выше первого.
Сертификаты есть. Уровня нет. Но я не теряю надежды. Вдруг где то найдется хотя бы второй уровень? Ну хотя бы одна фирма на Россию?
-
Сергей, так все же что за зверь? :) В CMMI про такого не говориться или может быть вы назовете его по "аглицки"?
-
Ща поднимется волна критики, что нужно было по англицки называть сразу и что термин всем известен ;D
-
To Salar:
Насколько мне известно, приличные люди сначала договариваются о терминах. Так что порадуйте, плиз, народонаселение.
-
Хочется всё-таки вернуть дискуссию в рамки "что делал тот, кого называли архитектором, в известных Вам успешных проектах".
-
В наших проектах не было того, кого называли архитектором.
А вот проекты тем не менее успешно были.
Такие примеры считаются?..
Конечно, более чем :) . А архитектурными вопросами занимались ведущие программисты? И у них получалось договориться между собой о целостной, единообразной архитектуре? Когда они договаривались, их кто-нибудь модерировал?