Software People 2010: Отчет Стаса Фомина - История изменений

StasFomin: /* Риски управления рисками */

2011-04-13T16:02:13Z

‎Риски управления рисками

Внесённые изменения

BenderBot: 1 версия

2010-12-06T01:09:08Z

1 версия

StasFomin: /* Мой доклад */

2010-12-05T23:35:24Z

‎Мой доклад

BenderBot: 1 версия

2010-11-12T01:02:11Z

1 версия

StasFomin: /* Архитектура ИС. Принципы построения хорошей архитектуры */

2010-11-12T00:34:37Z

‎Архитектура ИС. Принципы построения хорошей архитектуры

BenderBot: 1 версия

2010-05-07T00:01:02Z

1 версия

StasFomin в 08:56, 6 мая 2010

2010-05-06T08:56:05Z

Внесённые изменения

BenderBot: 1 версия

2010-05-06T00:01:03Z

1 версия

StasFomin: категория

2010-05-05T15:39:38Z

категория

Внесённые изменения

@@ Строка 57: / Строка 57: @@
 ----
@@ Строка 64: / Строка 63: @@
 Не удалось также протестировать и захват.
 Видео в AVI-формате (я притащил его в нескольких разрешениях и кодеках), система трансляции есть отказалась (она явно микрософтовская, ибо родной формат для нее был <tt>WMV</tt>), программа-супер-перекодировщик, которой парни гордились (понимает все форматы!) облажалась тоже, хотя  что может быть проще тупого AVI с h264-видео каналом и MP3-аудио?
 В результате, ночью я возился с видео и подготовил несколько вариантов WVM-разного разрешения, оттестировал его,
@@ Строка 95: / Строка 96: @@
 Ну что же, думаю, если видео будет опубликовано, свою аудиторию доклад соберет, мои жертвы будут не напрасны.
 А так, кроме доклада я забрал, по обыкновению время последующего кофе-брейка, для ответов на вопросы и разговоры с аудиторией (да, я предпочитаю выступать, чтобы было либо «свободное» время после, либо «свободное» время до — его я использую для разогрева аудитории).
 Резюмирую — в общем, был фейл (организаторы прислали мне — «…средний балл за Ваш доклад: '''4,66'''»), но не эпик-фейл.

← Предыдущая		Версия 00:34, 12 ноября 2010
Строка 225:		Строка 225:

	Это видео (четыре файла видео, которое он раздавал на конференции, в сумме меньше чем два часа), можно посмотреть параллельно с ненапряжной работой, и так сказать «вкурить основы», не тратя время на несколько толстых книжек.		Это видео (четыре файла видео, которое он раздавал на конференции, в сумме меньше чем два часа), можно посмотреть параллельно с ненапряжной работой, и так сказать «вкурить основы», не тратя время на несколько толстых книжек.
		+
		+	== Доклады, просмотренные в видео ==
		+	=== Архитектура ИС. Принципы построения хорошей архитектуры ===
		+	;Докладчик: [http://andrey-verbitsky.moikrug.ru/ Андрей Вербицкий]
		+
		+	Вообще доклад был ориентирован скорее на бизнес-людей, чем на ITшников,
		+	ибо архитектура рассматривалась абстрактная, без указания на уровень (бизнес-архитектура, системная крупная, средняя, мелкая, микроархитектура классов и т.п.), и это абстрагирование не мешало докладчику, ибо доклад был общефилософский.
		+	Разве что в конце, когда начали задавать вопросы, выяснилось, что у аудитории уж очень разное представление о том, что есть архитектура, о которой только что рассказывали.
		+
		+	Андрей же, заинтриговав волшебной формулой «Современная архитектура ИС стоит на трех китах — Identity, CRM, SelfCare»,
		+	сразу же ушел в дебри надежных строительных метафор.
		+	Цель было пояснить, что архитектура — это компромисс, причем далеко не одномерный и не плоский — даже строительную архитектуру нельзя свести только к технологиям или только к формам, влияет и ландшафт (метафора окружения), и время, и потребители.
		+	И все это подтвержается известными разношерстными примерами плохих и хороших архитектурных решений:
		+	;Плохие:
		+	:* Домик над водопадом
		+	:* Паромная переправа в Белфасте
		+	;Хорошие:
		+	:* классический русский сруб
		+	:* бруклинский мост
		+	:* эйфелева башня
		+
		+	Так и в информационной архитектуре, лучше не синтезировать что-то нежизнеспособное, а сначала найти удачный прототип, не изобретая велосипед, минимизировать его, убрав все лишнее (разумеется, постараясь не выплеснуть с водой и ребенка), и затем постепенно наращивать функционал, проверяя, что пациент-система жива, работает, и не теряет связь с реальностью.
		+
		+	При этом во главу угла надо поставить процессы, отложив вопросы типа безопасности. (Насколько я понял, докладчик имел в виду приоритет функциональных требований над нефункциональными — безопасность, производительность).
		+
		+	Разумеется, важно достигать компромисса между универсальностью (супер-универсальная-нежизнеспособная система) и специализацией (бодрая, но заточенная под конкретные условия или заказчика система, которую потом, пытаются продавать другим заказчикам<ref>Они пытаются надеть квадратное ведро на наши круглые головы! (наши клиенты о конкурирующем решении).</ref>
		+
		+	В качестве эффективных hacks предложен ТРИЗ, и принцип Парето<ref>Очевидно имелось в виду не «Парето-оптимальные решения» и «равновесие по Нэшу», а принцип «80/20» в какой-либо форме, означающий неравноценность проблем и возможностей (за 20% ресурсов можно снять 80% требований и т.п.)</ref>.
		+
		+	Очень важно сразу закладываться на изменения (метафора — «расписание на послезавтра») — причем и в случае с заказной системой, и в случае с продуктом. Все меняется!
		+	В частности, из этого следуюет, что в продуктовой разработке нельзя смело доверять ''benchmarking''у в сравнении с конкурентами и почивать на лаврах, если эти циферки лучше — если не следить за погодой, ветер может переменится и все преимущество полностью испарится.
		+
		+	Следующий важны момент — неизбежный учет окружения.
		+	Больше нет «девственных» заказчиков, у которых нет никаких информационных систем, которым можно сделать или продать все «с нуля», оптимально заполнив своей мебелью чистую комнату. Увы!
		+	Интеграция обязательно понадобится, особенно интеграция по данным.
		+
		+	Далее — классический менеджерский треугольник рисков (''Scope-Cost-Time''), который традиционно рисуют равнобедренным — устарел.
		+	Время сейчас всем важнее всего!
		+
		+	Именно в этом успех Agile, где Scope и Cost разменивают на время и выигрывают!
		+	Сделайте 80% самого нужного заказчику за 20% времени (Парето, ага) и разбегайтесь взаимоудовлетворенными! ''Счастье всем даром и пусть никто не уйдет обиженным!''©
		+
		+
		+	В области безопасности Андрей пообещал, что логины-пароли уйдут в прошлое, а в светлом будущем всех нас ждет полное,
		+	материально-географическое, отделение бизнес-информации (в частности, персональных данных), от технической.
		+	Будет единые права доступа, вероятно Single Sign On и все такое.
		+
		+	Это как раз и был первый кит-тренд из формулы — ''Identity''.
		+
		+	Однако почему так таки будет — не пояснили, кроме мантры «ну елки-палки, тыща сайтов и везде разные пароли — не запомнить, а один пароль — взломаю, так что так жить нельзя!».
		+	Тут я готов поспорить — вот [[SuperGenPass\|эффективное, удобное и надежное решение паролей в интернете]].
		+	Ну это частность, а в абстрактном смысле это пример эффективного децентрализованного решения, с минимальным обменом информацией.
		+	Так что многое возможно, многое. (Вот OpenID — опять таки распределенный протокол).
		+
		+
		+	Следующий кит — CRM (под которым, я думаю, все привыкли понимать Customer Relationship Management, как проблемы, так и продукты-решения), тут с одной стороны означал «персонализацию клиента» (учет разных культур, географий-континентов и т.п.), с другой — почему-то означал возможность задания бизнес-логики (как-то мне неочевидно, почему это сюда).
		+
		+	Ну и третий тренд — ''SelfCare'', по сути — делегация всего на клиента, но в удобной для него форме, чтобы убить опять таки двух зайцев — и сократить свои расходы, и повысить лояльность клиента.
		+	Девиз: «Клиент, это тоже равноправный сотрудник, только зарплату получает услугами».
		+
		+	Раскрыв свое понимание информационной архитектуры, Андрей стал сетовать, что разработка — слишком молодая отрасль, в которой еще не сложилось традиции обучения, такие как в традиционной архитектуре, когда студенты годами разглядывают каталоги и альбомы
		+	архитектурных бестпрактик.
		+
		+	В IT это якобы не принято — нет ни мировых обучающих ресурсов, ни внутрикорпораттивных библиотек правильных архитектур, к которым должны обращаться архитекторы при старте нового проекта (там какое-то странное представление — архитектор «набирает» лучшие решения из разных архитектур, аки меню…).
		+
		+	Ну тут я совсем не согласен. Полно ресурсов по архитектуре! Книги — тот же Фаулер с паттернами всего, плюс как раз на этой конференции всем участникам раздавали бесплатно русский перевод микрософтовского свода архитектурных практик.
		+	Интернет ресурсов тоже не мало, от того же Фаулера до целого портала http://infoq.com (статьи, презентации, видеовыступления — архитектурные решения, свежие кейсы — все очень актуальное).
		+
		+	Что касается корпоративной библиотеки архитектур, как «меню» и чего-то такого, «текстового» — то внутри компаний best архитектуры воплащаются не в бумажки (ну и в них немного тоже), а в первую очередь в работающие фреймворки, программные каркасы (свои самоделки или адаптации-интеграции других, свободных или вендорский фреймворков, в общем, живой код, а не мертвый текст!
		+	И тогда да, при старте нового проекта в первую очередь примеряются имеющиеся в «гардеробе» компании каркасы, и даже, если ни один из них не подойдет окончательно, часто на их основе строится прототип (потому что это быстро, это Agile, и даже если этот прототип окончательно не приживется, разведка боем даст возможность выяснить настоящую иерархию требований).
		+
		+	Далее начались вопросы зрителей.
		+	* Управление проектами …?
		+	** — нет, не связано с архитектурой.
		+
		+	* Управление знаниями… где надежный фундамент в IT-архитектуре?
		+	** Докладчик посетовал на бескультурье.
		+	** Я же думаю, что это принципиально неверная метафора «идеальный неизменный фундамент» — нет такого. Зашившись на бестпрактику («лучший Cobol!» «Лучшая СУБД — Informix с прогрессивной двухзвенкой!») — и глазом не моргнешь, как окажешься на обочине, с умчавшимися в точку горизонта конкурентами.
		+
		+	* UML… ?
		+	** Нет, это не архитектура.
		+	** ''Угу, это как раз началось выяснение, о какой архитектуре шла речь.''
		+
		+	* ТРИЗ… ? Это же вроде разрушение шаблонов?
		+	** Нет, ТРИЗ это как раз шаблонные алгоритмы. Только другие.
		+
		+	* Может Архитектура это Платформа? (''ага, близко к моему пониманию'').
		+	** Нет, платформа это как Шарепоинт или 1С, т.е. это конструктор, это ограниченность. (''Фреймворки! Вот что надо было говорить!'')

	= Примечания =		= Примечания =

← Предыдущая	Версия 01:09, 6 декабря 2010
(нет различий)

← Предыдущая	Версия 01:02, 12 ноября 2010
(нет различий)

← Предыдущая	Версия 00:01, 7 мая 2010
(нет различий)

← Предыдущая	Версия 00:01, 6 мая 2010
(нет различий)