Авторы книги - Том ДеМарко, Тим Листер, Питер Хрущка, и други эксперты профессиональной организации Atlantic Systems Guild, проанализировали наиболее характерные черты, присущие поведению проектных команд (как в успешных, так и в провальных проектах), и представили их в форме 86 паттернов поведения. При этом книга не содержит никаких выводов, осталяя их читателю.

Мы предлагаем вашему вниманию интервью с Питером Хрущкой.
Питер - докладчик конференции Software People 2010, кроме того, он проведет прочитает семинар в Москве, Санкт-Петербурге и Минске.

Как Вы встретились с Томом Демарко и Тимом Листером?

В 80-е годы мы с моей командой только завершили разработку инструмента моделирования для структурных методологий, в основу которого легла идея книги Тома ДеМарко «Структурный анализ». Когда мы представили свою разработку на выставке на конференции в Орландо (Флорида) в 1984 году, Том подошел к нашему стенду, и мы разговорились. После этого я встречался со всеми членами профессиональной организации Atlantic Systems Guild на разных конференциях, и мы стали друзьями. Я перевел книгу Тома и Тима «Человеческий фактор» (Peopleware) на немецкий, мы организовывали конференции в Германии, куда я приглашал членов этой организации выступать с докладами. Таким образом, когда я уволился из моей предыдущей компании в 1994 году они пригласили меня стать членом этой профессиональной организации. С этого момента мы работаем вместе уже свыше 10 лет.

Кто был автором идеи книги о паттернах поведения?

Члены проффессиональной ассоциации встречаются раз в год в каком-то уголке мира, чтобы обсудить новые идеи и проекты. На нашей встрече в октябре 2004 в Нью Хампшире целью было создать «продукт Ассоциации». Будет ли это книга, аудио-записи, веб-сайт или что-то еще? Этот вопрос долго оставался открытым. После пары мозговых штурмов мы пришли к идее написать серию эссе о хороших и плохих вещах, которые мы видели по всему миру. Мы быстро набросали более 100 тем, собранных на маленьких белых карточках (фото Сьюзанны Робертсон). Мы распределили работу, назначили автора и одного или двух соавторов к каждому эссе и разъехались по домам работать над книгой.

Как вы работали над книгой при такой распределенной команде?

Как я упомянул раньше, мы разделили работу на нашей первой встрече по проекту (kickoff-meeting), таким образом каждый был первым автором около 15 эссе и у каждого была пара назначенных соавторов. Мы следовали простой модели: первый автор предлагал текст, затем это представлялось соавторам для предложения дополнений и изменений, которые отправлялись обратно автору. Когда автор и соавторы соглашались с текстом, он отправлялся всем для комментариев (или наложения вето). Все шесть из нас должны были согласиться с каждым отдельным эссе до того, как оно будет закончено. Книга писалась на трех континентах, в Европе, США и в Австралии – там, где мы работали в это время. Я добавил фотографию во время путешествия на лодке в северной Германии, где я использовал час для коктейля, чтобы написать больше глав.

Использовали ли вы Agile во время работы над книгой?

На самом деле мы вынуждены были начать использовать Agile методы. В первые 12 месяцев после того, как мы создали короткий список эссе, которые мы хотели написать, каждый был так занят на своей работе, что никто не нашел времени писать. Поэтому мы встретились в моем доме в Аахене для нового старта. За ту неделю мы создавали первые главы вместе на основе ежедневных итераций. У каждого было 2 часа после завтрака, чтобы написать черновик, и затем мы использовали остаток дня, чтобы прочитать то, что написано другими, прокомментировать, обсудить и улучшить. Через 4 дня мы получили наброски более чем 20-ти глав. Затем мы согласились что мы будем делать ежемесячные спринты а-ля SCRUM. Каждый пообщал писать главы каждый месяц. Мы договорились о долгих Skype-звонках, чтобы обсуждать наброски. Организовать Skype-звонки было непросто, так как мы жили в разных временных зонах, и иногда находились на так далеко, что кто-то был в Новой Зеландии, кто-то в США на западном побережье, кто-то на восточном побережье и в Европе. Из-за этого кому-то приходилось оставаться допоздна, а кому-то вставать рано. Но использование ежемесячных спринтов двигало проект вперед, так как мы ожидали.

Мы провели несколько дополнительных встреч в Бостоне и Лондоне, чтобы навести последний лоск, выбрать названия и порядок глав, отобрать фотографии и т.д. Как мы упоминали в нашей книге: особенно распределенные проекты очень нуждаются в личных встречах время от времени.На фотографии наша встреча в Бостоне.

Почему, как Вы считаете, люди должны принять участие в Вашем семинаре?

В книге мы описали, какое поведение мы наблюдали во всем мире в IT проектах. Но как лучше реагировать, если вы наблюдаете нежелательное поведение, описанное в книге? И что вы делаете, если думаете, что какие-то поведенческие паттерны очень выгодны для ваших проектов? На семинаре мы коснемся этих вопросов подробно. Вместе с участниками мы попытаемся разобрать лучшие варианты.

Если бы Вы могли дать только 3 совета руководителью проекта, что бы вы сказали?

Номер один: относитесь к вашей команде как к людям, а не взаимозаменяемым частям. Проекты только выиграют от сплоченной команды.

Во-вторых: Попытайтесь назначить каждому участнику команды работу, где она или он может лучше всего используйте свои сильные стороны и навыки.

И последнее в списке, но не последнее по значению: следите за «Манана-горизонтом» каждого участника команды. О том, почему это так важно, вы узнаете на семинаре.

Мы уже писали про мульт Максима Дорофеева о появлении водопадной модели разработки. Макс очень хотел, чтобы его мультик увидел Ройс Уокер. История получила неожиданное продолжение – Ройс Уокер приезжает в Москву (!) и 26 марта выступит с пленарным докладом на конференции Enterprise Developers Conference. Интересно, видел ли он уже мультик Макса? Если нет, мы обязательно покажем ему на конференции, чтобы узнать его реакцию.

Что делать, если в вашей жизни наступает полоса неудач? Если раз за разом вы не достигаете какой-то важной для вас цели? Чтобы справиться с такой ситуацией, нужно определить причину ваших поражений. О том, как это можно сделать, читайте в статье Натальи Желновой “Five “Why”s как средство анализа вашего поражения”.
Читать статью

Тем, кто занимается web-разработкой, адресована статья Дмитрия Mezya “12 полезных дополнений Firefox для Web-разработчиков”. Эти 12 дополнений - своеобразный “швейцарский нож” каждого web-разработчика, который окажется полезен как при разработке небольшого сайта, так и при работе с большим проектом. Если вы еще не знакомы со всеми широкими возможностями плагинов для Firefox, обязательно прочитайте статью.
Читать статью

Заключительная часть статьи Роджера Сешнса «Оптимальный путь к корпоративным архитектурам» посвящена обзору существующих корпоративных архитектур и анализу лучших практик их построения.

Читать статью

В своей статье “Обширная практика как тормоз мышления” Денис Петелин предостерегает нас от шаблонного мышления, формирующегося у специалистов на основе анализа негативного опыта – и своего, и (преимущественно) чужого.
Читать статью

События:

Конференция Software People 2010 и семинар Питера Хрущки (Минск, Санкт-Петербург, Москва)

На конференции Software People 2010 вы сможете не только пообщаться с коллегами и собрать кучу визиток, но и услышать интересных докладчиков из США, Великобритании, России, Эстонии, Белоруси. В частности, вы услышите доклад Дона Сайма, автора языка F#, который впервые приедет в Россию. Дон Смит, архитектор из команды Patterns and Practice Microsoft специально для нашей конференции пообщался с 70 архитекторами разных компаний, чтобы подготовить доклад о конфликтах в команде.

Кроме того, Питер Хрущка, автор новой книги о шаблонах поведения в команде проекта«Балдеющие от адреналина и зомбированные шаблонами», которая вызвала огромный интерес во всем мире (что и неудивительно, когда в числе авторов легендарные Том ДеМарко и Тим Листер), не только выступит с докладом, но и проведет 8 часовой семинар в трех городах:

19 апреля, Минск
21 апреля, Санкт-Петербург

24 апреля, Москва

Все семинары и доклады западных спикеров пройдут с синхронным переводом на русский язык.

До конца марта действуют специальные условия – не пропустите!

Основные дни конференции.+ Семинар (Москва/СПб) 15000 руб.

Основные дни конференции.++ Семинар (Минск) 1 400 000 бел.руб.

Новость от Спанч Боба

Недавно я решил вспомнить былые времена и заглянул на форум программистов C++. Программисты C++ обожают задавать друг другу задачи. В одной из них (несложной) было предложено отгадать, каким будет код завершения такой программы:

struct S {
static int i;
S() { ++i; }
S(const S&) { ++i; }
};
int S::i = 0;
int main() {
S v(S());
return S::i;
}

Я подумал и сказал, что из общих соображений - ноль (правда, на “пять почему” относительно этого кода я вряд ли отвечу). Но наш ведущий программист посмотрел и сказал, что единица.

Тогда я решил воспользоваться онлайн-компилятором и посмотреть, что получится в итоге.

В итоге получилось:
No errors or program output

Что-то тут не так. Может быть, кто-нибудь объяснит мне, кто прав: я, наш ведущий программист или компилятор?

Очень часто в работе я сталкиваюсь с ситуациями, когда руководитель проекта (ПМ) пытается исполнять роль аналитика. Также бывают проекты, где есть один аналитик, а ПМ пытается играть роль второго аналитика – участвует в интервью, рецензирует документы и т.п. Люди, несомненно, бывают разными. В этих случаях ПМ полностью владеет ситуацией на проекте на этапе анализа и может достаточно точно, хотя и субъективно сразу оценить работу аналитика. Некоторым ПМам удается такое совмещение ролей, а некоторым не очень (что по моему опыту случается чаще).

Однако давайте рассмотрим проект, где ПМ не пытается играть роль аналитика (ни первого номера, ни второго), а занимается исключительно функциями, свойственными роли руководителя. Каким же образом ПМ может убедиться, что работа на этом этапе проекта идет по плану и дела идут в целом хорошо?

Первое это собственно план. Планировать начальные фазы проекта очень сложно, ввиду высокой неопределенности и недостатка объективной информации. План может содержать некоторое количество интервью, встреч, и других активностей, которые легко контролировать по факту. Сходил аналитик на встречу, зафиксировал результаты в протоколе (или другом документе) закрываем задачу и т.д. Другие задачи в плане, связанные с разработкой документов контролировать сложнее. План помимо задач по разработке документов должен содержать достаточно точек контроля и соответствующих задач по проверке документов и их согласованию. Также необходимо запланировать заранее задачи по исправлению недочетов найденных в процессе проверок и согласований.

Однако это никак не гарантирует того, что собственно сам план хорош, и все необходимые активности в нем были предусмотрены. Состав и структура плана работ для ранних фаз разработки ПО зависит от многих факторов. Единого рецепта тут быть не может, поскольку проекты могут начинаться в условиях очень сильно отличающихся друг от друга.

Второе это собственно контроль хода выполнения длинных задач, например, написание документов, являющихся результатами работы аналитиков. Это такие документы, которые пойдут на согласование к заказчику, в контракт, в разработку, в тестирование и т.п.

ПМы, не желающие вдаваться в подробности содержания документов (требований, спецификаций и т.п.) и доверяющие аналитикам, приходят и спрашивают: «сколько тебе еще осталось писать требования?», «успеешь к пятнице?», «сколько ты уже написал?». Ответы практически всегда бывают положительны и оптимистичны, что, естественно, не гарантирует того, что документ будет полностью завершен к запланированному сроку.

ПМы, которые думают, что они хорошо разбираются в работе аналитика, или не доверяют своим подчиненным, делают полную проверку документа – т.е. читают его от начала и до конца. Это, несомненно, метод, хотя не очень быстрый и не единственный.

На мой взгляд, разработка любого документа из постановочной части проектной документации должна начинаться со структуры. Хорошая структура документа так же важна для проекта, как и хорошая архитектура решения. Если у вас есть структура документа, то вы можете очень быстро контролировать ее наполнение. В отличие от полного чтения, анализ наполнения хорошей структуры дает вам больше шансов для оценки процента выполнения полного объема работ, и выявления пробелов в документе.

Второй объективный фактор контроля хода работы – это анализ покрытия. Этот метод работает только в случае, если:

1. на входе в начале проекта вы получили от заказчика требования (или другой подобный документ)

2. импортировали исходный документ в систему управления требованиями

3. отдельно от исходного документа начали разработку вашей версии детальных требований/спецификации в той же системе

4. проставляете связи от требований в вашем документе к требованиям в исходном документе

В этом случае, выполнив анализ покрытия можно увидеть, какие требования из исходного документа еще не раскрыты/уточнены в вашем документе.

Дальше уже можно проверять собственно сам документ целиком. Для приблизительной оценки готовности документа и качества работы аналитика можно считать ошибки и замечания, сделанные в процессе проверки. А можно использовать атрибуты – например, в системе управления требованиями добавить новый атрибут и назвать его «статус проверки». В ходе проверки заполнять этот статус для каждого требования, и после проверки смотреть, какой процент требований в документе не прошел проверку, а какой нет. Такие статусные атрибуты можно также добавить для согласований с заказчиком, разработчиками и тестировщиками.

Если говорить о ретроспективной оценке качества работы аналитиков в проекте, то тут несомненное лидерство за таким показателем, как количество запросов на изменения, поступивших в ходе работы надо проектом и после него. Можно измерять в штуках, а можно и в затратах на доработку связанных с этими запросами на изменения. Конечно, у части из таких запросов может быть причина, лежащая за пределами возможностей предсказания вашей команды (например, мировой финансовый кризис). Но при прочих равных, чем больше запросов на изменения поступает в ходе проекта и после него, тем хуже сработали аналитики.

На мой взгляд, все эти рекомендации могут помочь ПМам в правильной оценки степени состояния работ на проекте и качества работы аналитиков. Начинают они работать, естественно, только с определенного объема. Если у вас проект с 20ю требованиями, то ни связи, ни статусы, ни структура вам как руководителю проекта существенной помощи не окажут. Если требований на порядок больше, то, полагаю, эти рекомендации могут оказаться полезными.

Если достижение этой цели не было для вас жизненно важно, то, скорее всего, вы просто забыли об этом и спокойно живете дальше. Однако если цель, поставленная вами, все же достаточно важна, то, скорее всего, вы задумаетесь о том, что же помешало вам ее достичь. Еще больше поводов задуматься было у тех, кто неоднократно ставил перед собой определенные цели и регулярно их проваливал. Например, начинал новую жизнь с понедельника.

Победителей, как известно, не судят. А вот если мы побеждены - что делать дальше? С чего начать, чтобы понять свои ошибки и извлечь из них полезный опыт?

Тем, кто успел поработать в крупных корпорациях (особенно в азиатских) наверняка знакома методика, которую называют Five Whys. Это методика, изначально придуманная инженерами для того, чтобы наверняка добраться до причины или источника какой-нибудь проблемы. А менеджеры часто использует ее для отказа в какой-нибудь просьбе или “отфутболивания” новой идеи. Принцип действия очень прост. Вы обращаетесь с просьбой или предложением к начальству, и оно просит вас обосновать необходимость того, что вы просите или предлагаете. И далее, слушая ваши ответы, задает вам пять вопросов “зачем” или “почему”, чтобы выяснить, насколько хорошо обоснованы ваша просьба или ваше предложение. Как правило, большинство людей теряет терпение уже где-то на третьем вопросе.

Выглядит это примерно так:
- Нам нужно приобрести 4 дополнительных монитора для этого проекта.
- Зачем?
- Мы хотим, чтобы на рабочих местах у всех, кто принимает участие в разработке продукта, было установлено по 2 монитора.
- Почему?
- Это удобно.
- Почему?
- Разработчику не нужно сворачивать и вновь разворачивать окна во время написания и исполнения кода.
- Почему это так важно?
- Потому что мы живем в XXI веке, и переключение между окнами нереально раздражает!

Скорее всего, четырех мониторов нам не видать, ибо потерявший терпение проигрывает в этой игре. Но не отчаивайтесь: хоть мы и потерпели поражение на этот раз, я покажу вам, как эту методику можно применить для анализа собственных ошибок и причин неудач в задуманном деле.

Давайте рассмотрим простой пример. Я - прикладной программист в IT-компании, и я не справилась сегодня с порученной мне задачей, хотя по плану эта задача должна была быть завершена именно сегодня. Я знаю, что отставание от намеченного графика - мое слабое место. Нас пока не штрафуют за срывы сроков, и увольнение мне еще не грозит. Но я хочу понять причину того, почему я регулярно опаздываю.

Итак, я сегодня не доделала этот отчет.
- Почему?
- Потому что отвлекалась.
- Почему?
- Ну… сначала был митинг, а потом мы праздновали день рождения А., поздравляли именинника, а потом я начала заниматься отчетом, но не закончила.
- Почему?
- Потеряла время, а потом поняла, что все равно не закончу задачу в срок.
- Почему?
- Потому что на митинг и празднование дня рождения ушло много времени.
- Почему?
- Ну… на митинг пригласило начальство. А не отметить день рождения как-то не очень здорово… Но и отчет не доделать тоже.

Итак, сегодня причины моего опоздания по срокам - митинг и праздник. Запишем время, которое было потеряно, чтобы посмотреть, правду ли я сказала самой себе. Теперь нужно посмотреть, как дело пойдет завтра.

На следующий день отчет все-таки был доделан.

Но следующая задача, которой я занялась вскоре после отчета, снова была просрочена.

- Почему?
- Добавленный мной код выдавал ошибку, на исправление которой у меня ушло лишних 4 часа.
- В чем причина ошибки?
- Я плохо понимаю, как работают методы классов BLL.
- Почему?
- Не понимаю, в каком порядке нужно вызывать эти методы в данном случае.
- Почему?
- Плохо ориентируюсь в исходном коде всего проекта в целом.
- Почему?
- Нет необходимой документации.
Записываем потерю времени на исправление ошибок, отмечаем как пожелание: документирование системной архитектуры. Сравниваем мои “рекорды” с такими же досадными потерями моих коллег. Если затраты времени на исправление ошибок превышают время, которое нужно потратить на документирование, решение напрашивается само собой.

Итак, просто отвечая на пять вопросов, я могу достаточно точно установить причины задержек с выполнением задач. Если эти причины будут повторяться (например, вторая), то скорее всего, мы имеем дело с систематическим риском, причину которого необходимо устранить.

Метод five whys применим не только в рабочей обстановке. Что там у нас с личными целями?
- У меня была заветная мечта - съездить отдохнуть в Черногорию. Но увы, она так и не сбылась.
- Почему?
- Да срок действия загранпаспорта истекает, а новый сделать некогда…
- Почему?
- Никак не соберу все нужные документы.
- Почему?
- У них ограниченный срок действия, а дойти до паспортного стола вовремя я все равно не соберусь…
- ПОЧЕМУ?

Волшебная техника, trust me.
Главное - отвечать честно.

Конечно, большинство разработчиков знают об их существовании, но я нацеливаюсь на остальную часть. А также на тех, кто использует альтернативные браузеры. Быть может, это подтолкнёт их к переходу на Огнелиса. Ну и вообще, просто хочется собрать всё в одном месте.

1. Начнём, конечно же, с прекрасного плагина под названием FireBug

Про этот аддон, наверное, знает каждый. Про него много писалось. Он по праву занимает первое место в этом списке.

С ним вы сможете редактировать, выполнять отладку и просматривать CSS, HTML и Javascript в режиме реального времени на любой странице в сети. Аддон также позволяет анализировать запросы и проверять производительность Java-скриптов. В общем, must have.

2. Вторым в списке идёт аддон Web Developer

Дополнение Web Developer добавляет в Firefox удобную и настраиваемую панельку с множеством различных функций.

В перечне имеются: отключение и просмотр Java-скриптов, отключение и просмотр cookie, отключение CSS таблиц, просмотр стилей, просмотр детальной информации для форм, отключение вывода изображений, поиск неработающих изображений, редактирование HTML-кода, просмотр спрятанных элементов, проверка кода на валидность и многое многое другое.

3. ColorZilla

Вы, естественно, видели инструмент «Пипетка» в редакторах изображения? Так вот, это то же самое, но для Firefox. И даже больше. Плагин встраивается в строку статуса браузера. Щелкните иконку пипетки и наведите на нужный элемент страницы и узнаете его цвет. Цвет можно посмотреть как в RGB формате, так и в HEX. В плагине также имеется колёсико цветов, увеличение страницы и пара других функций.

4. HTML Validator

HTML Validator подмигивает вам иконкой из строки статуса браузера. Он показывает количество ошибок HTML на загруженной странице. Вы можете отрыть HTML код в плагине и посмотреть, что же вызывает ошибки.

Да, кстати, аддон по ссылке в заголовке не работает под Mac и Linux. Однако, на сайте разработчиков есть версии и под эти ОС.

5. На 5 месте FTP-клиент FireFTP

Куда же разработчику без FTP-клиента? Этот плагин добавляет возможность использования клиента прямо в браузере. Клиент открывается в отдельном окне. Функции не ограничены только базовыми — есть сравнение директорий и их синхронизация при навигации, SFTP, SSL защита, поиск и фильтры, удалённое управление, drag and drop, проверка хэша файла и многое другое.

6. Измерялка MeasureIt

Часто появляется нужда измерить какой-нибудь элемент на странице. С помощью MeasureIt можно просто выделить элемент и сразу же узнать, какова его высота, а какова ширина. Похожий функционал предлагает и ColorZilla, однако, если вам нужно только измерять, то лучше использовать MeasureIt.

7. Эмулятор Internet Explorer’а Coral IE Tab

В связи с последними тенденциями отказа от вёрстки и поддержки IE многими разработчиками, плагин может показаться бесполезным. Но всё же, не все хотят терять кусочек аудитории, а возможно и потенциальных клиентов/партнёров, потому сохраняют поддержку IE своими сайтами. Этим разработчикам и пригодится аддон — он запускает Internet Explorer прямо в Firefox. Теперь можно проверить вёрстку своего сайта, не открывая другой браузер. И да, плагин работает только под Windows, с установленным IE.

8. Ближе к концу списка, но не менее важный Greasemonkey

Я так думаю, что плагин не нуждается в долгих описаниях и представлении. Greasemonkey — расширение, позволяющее добавить на любую страницу пользовательский Javascript, записанный в формате этого расширения. C февраля 2009 года нативно работает в Google Chrome. Имеет за пазухой сотни скриптов, которые можно найти на сайте userscripts.org.

9. View Source Chart

Просматривать исходный код сайта стандартными средствами Firefox довольно-таки неудобно — код плохо организован. С аддоном View Source Chart делать это станет намного проще — код страницы разбит на блоки, подсвеченные разными цветами. Поэтому вы визуально видите границы тегов и DOM структуры, в которой легче разобраться.

10. Не сильно популярный, но полезный инструмент Aardvark

Хорошая утилита для чистки страницы от лишних элементов, например для печати. Также, удобно использовать для анализа структуры страницы. Наведя курсор на элемент страницы, вы увидите его id, ярлык (если он есть), класс и присвоенный ему стиль. Используя некоторые кнопки клавиатуры, например R, можно удалить элемент со страницы или V для того, чтобы увидеть исходный код.

И ещё пара полезных плагинов…

11. Аддон для упрощения однотипных действий iMacros

Аддон, как вы поняли, создаёт макросы для однотипных простых действий. Например — заполнение форм и запоминание паролей, автоматическая выгрузка и загрузка изображений, файлов или целых страниц (с картинками или без картинок), функциональное, нагрузочное и регрессионное тестирование Веб-приложений и многое другое. Более подробная информация на странице аддона.

12. Последний на сегодня: это FoxyProxy

Это дополнение является расширением стандартного функционала Firefox для управления настройками использования прокси. С ним вы сможете на-лету переключать прокси-сервера, быстро включать и отключать прокси, использовать шаблоны для прокси.

Вот и всё на сегодня. Надеюсь, данная подборка поможет вам в упрощении работы и достижении нужных результатов.

Это продолжение статьи Роджера Сешнса “Оптимальный путь к корпоративным архитектурам”. Рекомендуем прочитать первую и вторую части.

Существующие инфраструктуры корпоративной архитектуры

История существующих стандартных инфраструктур корпоративной архитектуры (включая TOGAF, FEAF и модель Захмана) имеет много общего. Все эти архитектуры подверглись значительному влиянию парадигмы объектно-ориентированного проектирования и анализа (OODA).

Тот факт, что эти модели принадлежат к поколению OODA, очень важен, поскольку он означает, что все эти модели были созданы до появления сервис-ориентированных архитектур (SOA). Сегодня большинство крупных систем основано на концепции взаимодействия автономных приложений с использованием стандартов веб-служб (таких как SOAP, WS-Security и им подобных). Эта концепция тесно связана с парадигмой сервис-ориентированных архитектур, которая не была известна при создании разрабатываемых ранее моделей архитектуры.

Объектные технологии предназначены для создания приложений, а не корпоративных архитектур. Их основной недостаток в том, что невозможно управлять сложностью.

В 2004 году в крупномасштабном исследовании, посвященном сложности ИТ-систем, академия Royal Academy of Engineering и сообщество British Computer Society отметили следующее:

“…существующие рекомендации и методы разработки ПО не обеспечивают масштабирование, которое позволило бы управлять все более сложными, глобальными распределенными системами с сохранением приемлемого уровня затрат или проектных рисков. Поэтому реагирование на непрекращающееся развитие вычислительных технологий и технологий связи является важнейшей задачей разработчиков ПО”. [Roy]

Проблемы, которые необходимо разрешить для крупных и сложных корпоративных архитектур, относятся к взаимодействию приложений, а не к реализации приложений как таковых. Концепция создания больших систем, состоящих из взаимодействующих автономных приложений, представляет собой технический эквивалент декомпозиции; она получила развитие спустя длительное время после окончания эры Объектов и фактически знаменовала наступление эры SOA.

Использование SOA помогает управлять сложностью на техническом уровне. Техническую архитектуру, как и коммерческую, необходимо подвергать декомпозиции, чтобы уменьшить сложность до уровня, на котором можно осуществлять управление. На сегодняшний день архитектуры SOA, безусловно, представляют собой лучшее средство технической декомпозиции.

В инфраструктурах OODA зачастую декларировалась поддержка концепции итераций, однако между итерациями и итерациями с декомпозицией существует значительная разница. Концепция итераций, реализованная в OODA, больше похожа не на итерации, а на рекурсию, как показано на рис. 8. При использовании этой концепции сложность системы обрабатывается путем выделения небольших составляющих. Однако это не делает систему проще, а лишь уменьшает ее сложность в каждый конкретный момент времени.

Рис. 8. OODA-подход к корпоративным архитектурам

Итерации с декомпозицией имеют два существенных отличия от OODA-подхода. Первое (и самое главное) отличие состоит в том, что этот метод уменьшает сложность путем использования декомпозиции, а не пытается управлять сложностью, используя рекурсию. Второе отличие заключается в том, что при выполнении итераций с декомпозицией основное внимание уделяется скорости итераций, а не всеобъемлющему планированию. При этом мы исходим из предположения, что получим больше информации при выполнении действий, а не при их планировании. Этот подход показан на рис. 9.

Рис. 9. Создание корпоративной архитектуры с использованием итераций с декомпозицией

Работа со сложностью системы с помощью декомпозиции принципиально отличается от использования рекурсии, применяемой в OODA. OODA пытается разрешать проблемы, вызванные сложностью, разделяя ее на управляемые составляющие, в то время как метод итераций с декомпозицией призван не просто обеспечить управление сложностью (как в подходе OODA), а уменьшить сложность в целом, используя математический метод, рассмотренный нами ранее при изучении кубиков (снижение сложности путем декомпозиции).

Преимущества подхода на основе итераций с декомпозицией

Применение подхода на основе итераций с декомпозицией позволяет получать коммерческую выгоду от проекта на более ранних этапах, чем при использовании OODA-подхода. Это становится возможным благодаря тому, что система создается по частям. Поскольку мы создаем вертикальные сегменты, каждый из которых имеет коммерческую ценность, итерации позволяют уменьшить время достижения положительного эффекта (TTV).

В мире бизнеса TTV это важнейшая характеристика. Даже более важная, чем уровень возврата инвестиций (ROI). ROI — это цель, которая ставится в долгосрочной перспективе. Для любого проекта, даже очень плохо организованного, разработанного со значительным превышением бюджета и не соответствующего требованиям бизнеса, можно по истечении длительного времени добиться высокого значения ROI, когда затраты на проект будут амортизированы. Вопрос в том, проработает ли компания столько времени?

TTV — это характеристика, ориентированная на более близкую перспективу. Хотя существует несколько определений TTV, я использую следующее: TTV — это промежуток времени между утверждением бюджета проекта и моментом, когда руководство убеждается, что проект оказывает положительное влияние на работу организации. Другими словами, это промежуток времени между расходованием средств и получением положительного эффекта. Значение ROI с TTV почти не связано.

Например, предположим, что руководство утвердило расходы в размере 20 млн долларов на реорганизацию службы поддержки заказчиков. Если использовать традиционный рекурсивный OODA-подход, положительный эффект будет получен только после того, как 20 млн будут полностью потрачены (и только если вам повезет). Однако вместо этого можно использовать итерационный подход с декомпозицией и разбить проект на вертикальные подсистемы, каждая из которых сама по себе является ценной с коммерческой точки зрения.

Предположим, что первая подсистема — это интерактивная библиотека, содержащая полезную информацию для заказчиков и обеспечивающая удобный доступ. Эта подсистема позволяет организации получать коммерческую выгоду задолго до завершения остальной части проекта и даже до достижения положительных значений ROI. Например, если вы сможете продемонстрировать, что в первый месяц библиотека на 20 % уменьшила время, которое затрачивала служба поддержки на решение вопросов заказчиков по телефону, вы докажете наличие положительного эффекта, даже если для достижения положительного значения ROI по проекту в целом необходимо несколько лет.

Как вы считаете, выполнение каких проектов организации чаще всего прерывают, не доводя до конца? Проектов, которые уже через несколько месяцев позволяют получить положительный эффект (итерации с декомпозицией), или проектов, не дающих положительного эффекта даже через два года работы и траты средств (рекурсивный OODA-подход)?

Быстрое получение положительного эффекта помогает проекту находиться «на виду» у руководства. С глаз долой, из сердца вон — именно это зачастую происходит с ИТ-проектами.

Вторым преимуществом итерационного подхода с декомпозицией является повышение вероятности удачного завершения проекта в целом, поскольку этот подход позволяет использовать опыт, полученный при выполнении предыдущих итераций.

Вернемся к примеру с центром обработки обращений заказчиков. Предположим, что задача текущей итерации — разработка нового пользовательского интерфейса для заказчиков, а при выполнении одной из последующих итераций нужно будет разработать пользовательский интерфейс центра обработки вызовов. Предположим также, что вы считаете, что сможете разработать новый пользовательский интерфейс для заказчиков за шесть человеко-месяцев, а новый пользовательский интерфейс центра обработки вызовов — за восемь. Однако, завершив создание пользовательского интерфейса для заказчиков, вы обнаруживаете, что его разработка потребовала девять человеко-месяцев вместо шести. Становится ясно, что вы неверно оценили объем работ по созданию пользовательских интерфейсов.

Однако теперь вы можете извлечь уроки из своих ошибок. Предположим, вы определили, что неверно оценили время, необходимое для обучения разработчиков. В таком случае при создании интерфейса центра обработки вызовов вы сможете выделить более квалифицированных разработчиков. Если средства разработки оказались сложнее, чем вы предполагали, вы можете рассмотреть вариант смены используемых средств. Если разработка просто длилась дольше, чем было запланировано, вы можете изменить расписание дальнейшей работы над проектом.

Очень важно, что при использовании итераций с декомпозицией организация может обнаружить проблемы на ранних этапах, прежде чем они приведут к серьезным негативным последствиям для всего проекта, и даже если не сможет их разрешить, то возникшие задержки не станут неожиданностью для руководства. Руководству могут не нравиться задержки, но неожиданности оно просто ненавидит.

Эффективное управление ожиданиями — важная составляющая практически всех проектов. Итерационный подход с декомпозицией упрощает реагирование на возможные проблемы и позволяет более эффективно сообщать руководству о реальных ожидаемых результатах.

Третьим преимуществом итерационного подхода с декомпозицией является то, что он отнимает меньше времени у сотрудников, занимающих наиболее высокие должности и выполняющих наиболее важную работу (за наиболее высокую зарплату). Так происходит, поскольку проектирование каждой подсистемы требует согласования мнений лишь тех сотрудников, которые непосредственно работают с этой подсистемой. Если же использовать при работе над проектом рекурсивный OODA-подход, для принятия почти всех решений необходимо участие большинства сотрудников, что зачастую превращает принятие даже самого простого решения в трудоемкий процесс.

Четвертым преимуществом итерационного подхода с декомпозицией является представление результатов в виде проекта, структура которого похожа на структуру SOA. В отличие от огромных, неделимых монстров, зачастую порождаемых применением OODA-подхода, сервис-ориентированные архитектуры ?— это набор взаимодействующих между собой небольших автономных служб, которые являются более гибкими и которые намного проще применять для повторного использования, взаимодействия и совместной работы, чем системы, полученные с помощью OODA.

И последнее. Итерационный подход с декомпозицией значительно упрощает дальнейшее расширение возможностей системы по сравнению с OODA-подходом. Это происходит в силу следующих трех факторов:

При использовании итерационного подхода с декомпозицией основной характеристикой является время достижения положительного эффекта, а основное внимание уделяется быстрой реализации. Сегодня никто не спорит с тем, что для быстрой реализации системы необходимо использовать тайм-боксинг (ограничение набора функций, при котором остаются только критически важные функции и те, которые могут быть реализованы в оговоренные сроки). Это приводит нас к необходимости рассмотреть идеологию организации, то есть более тщательно проанализировать функции и отбросить те, без которых можно обойтись.

Как видим, переход от методик создания корпоративной архитектуры на основе OODA-подхода к методикам на основе итераций с декомпозицией предоставляет организациям значительные преимущества. В том числе:

Это и есть те самые важные преимущества, которые должны заинтересовать любую организацию в ее стремлении получить реальную отдачу от усилий по созданию архитектуры.

Слагаемые успеха

Теперь, когда мы рассмотрели теоретические и практические основы методики создания корпоративной архитектуры путем итераций с декомпозицией, я изложу несколько правил, которые, на мой взгляд, помогут достичь успеха при использовании этого подхода.

Правило 1. Сначала используйте простое решение

Выполнив “первый проход” и определив состав проекта и подсистем, вы должны решить, что нужно делать в первую очередь. Многие рекомендации советуют начинать с проектов с высоким риском, поскольку это позволит на ранних этапах обнаружить проблемы, с которыми вы можете столкнуться при работе над проектом. Я не согласен с этим подходом.

Первое, что вам нужно сделать при разработке корпоративной архитектуры, — показать успешность своей работы, чтобы сформировать стимул для достижения более крупной цели. Это правило особенно эффективно действует в организациях, которые ранее столкнулись с неудачными попытками создания корпоративной архитектуры на основе методологии OODA.

Таким образом, вашей первоочередной задачей на начальных итерациях является завоевание доверия. А лучший способ завоевать доверие — продемонстрировать хорошо заметные успешные результаты, которые может оценить каждый сотрудник организации.

В таблице 2 перечислены наиболее важные критерии, влияющие на определение приоритета подсистем, лучшие методы анализа каждого критерия и влияние соответствующего критерия на общий приоритет.

Таблица 2. Критерии выбора приоритета подсистем

Удобным средством определения приоритетов подсистем может стать схема приоритетов, показанная на рис. 10. На этой схеме каждая ось соответствует одному из критериев, перечисленных в таблице 2. При этом положительному влиянию соответствует зона, расположенная ближе к центру, а отрицательному — ближе к краям схемы.

Рис. 10. Схема приоритетов

Нарисовав схему приоритетов, расположите отметки «попаданий» вдоль каждой оси. Если, например, рассматриваемая подсистема имеет средний риск, поместите отметку на оси рисков в желтую зону. Завершив размещение отметок, вы увидите, какие проекты (подсистемы) следует разрабатывать в первую очередь.

Например, предположим, что вы выделили два проекта: проект разработки базы знаний, к которой смогу обращаться заказчики, и проект создания процедуры единого входа, которая повысит безопасность. Вы нарисовали схему приоритетов для каждого из этих проектов и получили результат, показанный на рис. 11. По этому рисунку сразу ясно, какой из проектов больше соответствует определению “простого решения”.

Рис. 11. Сравнение схем приоритетов двух проектов

Правило 2. Используйте возможности для экономии “в мелочах”

Распространенное заблуждение относительно корпоративных архитектур состоит в том, что экономия достигается при выполнении операций в широких масштабах. Теория говорит, что если над крупным проектом работает достаточное число исполнителей, результаты работы неизбежно будут содержать избыточность. Устранение этой избыточности позволяет уменьшить затраты на разработку и сопровождение. Чем крупнее проект, тем выше уровень избыточности. Чем больше избыточности, тем больше возможностей для ее устранения. Чем больше избыточности будет устранено, тем меньше будут конечные затраты на проект.

К сожалению, эта теория не учитывает основополагающий закон управления проектами: закон снижения эффективности ресурсов. Чем больше людей участвует в работе над проектом, тем ниже эффективность проекта в целом. Этот закон является следствием известного закона Брукса. Более 30 лет назад Фред Брукс (Fred Brooks) был первым, кто заметил, что выделение дополнительных ресурсов для проекта, выполнение которого задерживается, лишь увеличивает задержку [Bro]. В 1999 году за открытие этого закона и другие достижения ему была присуждена Премия Тьюринга

Относительно небольшая группа, работающая над четко очерченной подсистемой корпоративной архитектуры, может выполнить приемлемую работу в приемлемые сроки. Большая группа, работающая над архитектурой, не разбитой на подсистемы, обнаружит избыточность. Однако затраты на выявление избыточности, поиск оптимальных методов ее устранения и попытки согласовать проект унифицированного метода решения практически во всех случаях будут значительно больше, чем затраты, связанные с самой избыточностью.

Безусловно, с увеличением масштабов мы можем добиться экономии. Однако настоящую экономию можно обеспечить при работе над небольшими, а не над крупномасштабными задачами.

Правило 3. Централизуйте взаимодействие, децентрализуйте реализацию

Многие организации разрабатывают излишне централизованные корпоративные архитектуры. Зачастую они создают отдел корпоративной архитектуры и предоставляют ему право принимать широкий круг решений. Подобная высокая централизация может вызвать рост бюрократизма и завести проект в тупик.

Централизованная организация корпоративной архитектуры нужна. Однако централизация должна быть направлена на решение важных проблем, а не на бесконечное решение мелких вопросов.

Практический совет состоит в том, что взаимодействие должно быть централизовано, а решения, влияющие на реализацию, должны приниматься децентрализовано. Типичной ошибкой отделов корпоративной архитектуры является попытка выбирать решение, не зная его особенностей.

Давайте рассмотрим некоторые типичные ошибки при создании корпоративных архитектур.

Платформа. Многие организации пытаются выбрать стандартную платформу ПО и нередко ведут бесконечные споры, обсуждая, к примеру, Microsoft .NET, IBM’ WebSphere или BEA WebLogic. Это бесполезная трата сил. Выбор платформы — это решение, которое касается реализации и не влияет на то, как будут организованы совместная работа и взаимодействие приложений на этой платформе. Если платформа удовлетворяет потребности организации в обеспечении взаимодействия, разработчики должны иметь возможность самостоятельно выбирать платформу

Данные. Многие организации пытаются создать единый уровень данных, который будет использоваться всеми приложениями в организации. Эти попытки обычно требуют значительных затрат и редко бывают успешными. Методы хранения данных — это вопросы реализации приложения.

Бизнес-анализ. Большинство организаций использует и данные, и результаты бизнес-анализа. Однако данные (например, хранящиеся в базе данных сведения о заказчике) — это особенности реализации, в то время как результаты бизнес-анализа (такие как информация о сделках нашей компании с конкретным заказчиком) — это активы компании. Поэтому необходимо решить, каким образом будут использоваться эти сведения. Однако на уровне организации не следует принимать решения о том, как приложения будут контролировать данные, на основе бизнес-анализа.

Совместное использование кода. Многие организации считают, что повторное использование компонентов обеспечивается благодаря совместному использованию кода. Удивительно, что это мнение существует, несмотря на неудачные попытки добиться желаемого результата в течение десятков лет. Лучший способ уменьшить объем кода в проекте — делегирование функций (например, с помощью веб-служб), а не совместное использование кода.

Интерфейсы API веб-служб. Многие организации обоснованно полагают, что использование веб-служб является важнейшим условием обеспечения взаимодействия. При этом нередко считается, что это означает обязательную стандартизацию методов использования приложениями интерфейсов API веб-служб. Однако на самом деле интерфейсы API веб-служб лежат намного «ниже» той области, с которой работают приложения. Как правило, приложения используют предоставляемый поставщиком промежуточный уровень (например, предоставляемый платформой Microsoft .NET уровень Windows Communications Framework), избавляющий приложения от необходимости обращаться к сложным интерфейсам API веб-служб. Поскольку каждая платформа использует собственный промежуточный уровень, этот уровень является особенностью реализации приложения.

Из всего вышесказанного можно сделать вывод: корпоративная архитектура и архитектура приложений — это разные понятия. Архитектура приложений определяет возможности приложения, которые должны соответствовать требованиям пользователей этого приложения. Это один из способов, позволяющих добиться экономии в малых масштабах (см. Правило 2. Используйте возможности для экономии “в мелочах”). А корпоративная архитектура описывает, каким образом эти приложения работают вместе, позволяя организации получать коммерческую выгоду.

Заключение

Корпоративная архитектура может быть важным ресурсом, помогающим организациям находить более эффективные способы применения технологий для поддержки основных бизнес-процессов. К сожалению, многие организации тратят гигантские суммы денег на создание корпоративной архитектуры, а в результате обнаруживают, что их усилия привели лишь к ограниченному эффекту или даже дали отрицательный эффект. Неудачные проекты ценой в сотни миллионов долларов регулярно встречаются и в государственном, и в частном секторе.

Ниже перечислены три основные причины столь частого повторения подобных дорогостоящих неудач. Первая причина — чрезмерное увлечение рекурсивными методиками создания архитектуры на основе объектно-ориентированного проектирования и анализа (OODA). Вторая причина — ошибочная уверенность в том, что создание корпоративной архитектуры означает создание подробного плана всей организации. Третья причина — неумение разбить сложные структуры на проекты меньшего размера, которыми можно более эффективно управлять.

Как и любой рекурсивный подход, методологии OODA предоставляют лишь ограниченные возможности управления сложностью. Сложность — это основная проблема, с которой сталкиваются современные организации с высоким уровнем изменчивости.

В этой статье предложен новый подход к созданию корпоративной архитектуры, основанный на вертикальном позиционировании процессов организации, определении их приоритетов и выполнении итераций, при которых основное внимание уделяется времени достижения положительного эффекта (TTV). Такой подход можно назвать итерациями с декомпозицией. В отличие от рекурсивных методик данный подход снижает сложность системы в целом.

В статье приведены следующие три правила, помогающие добиться успеха при использовании описанной выше стратегии:

Применение итераций с декомпозицией предоставляет ряд преимуществ по сравнению с рекурсивными методиками. В том числе:

Итерации с декомпозицией — это наиболее эффективный с экономической точки зрения метод описания целей организации, способов достижения этих целей с помощью бизнес-процессов и методик повышения эффективности обслуживания бизнес-процессов с использованием различных технологий.

Другими словами, применение итераций с декомпозицией позволяет в минимальные сроки и с минимальными затратами реализовывать сложные технические проекты, обеспечивающие значительную коммерческую выгоду. Большая выгода. Минимальное время. Минимальные затраты. Таков результат применения итераций с декомпозицией.

…или почему порядка никогда не будет, а КПД всегда будет низким

— Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.

— Как-то странно ты рассуждаешь, Кристо… Как же искать решение, когда его нет? Бессмыслица какая-то…

— Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица — искать решение, если оно и так есть. Речь идёт о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос…

Аркадий и Борис Стругацкие
“Понедельник начинается в субботу”

Это предисловие – прямо-таки квинтэссенция дискуссий, апогей которых пришелся в четвертом квартале. В связи с этим могу сообщить следующее:

Дорогие камрады! Когда вы начинаете работать в определенной предметной области, вы очень быстро становитесь в ней специалистами. “Стать специалистом” – это значит впитать набор знаний, навыков и культурных особенностей этой предметной области (“дОбыча нефти”, ага). Одна из вещей, которые вы впитаете – это набор “традиционно нерешаемых проблем”. То есть их нерешаемость дается как аксиома -хотя на самом деле она когда-то была доказана, но со временем доказательства настолько заездили, что доказанная теорема перешла в область аксиом. И часто новичкам она дается уже в форме аксиомы – мол, смотри, мы всегда делаем так – считай это аксиомой (ну вот “нету ресурсов” – типа типичная аксиома).

А тут на самом деле не лишне вспомнить начало – откуда аксиома взялась? Так она теорема? А как она доказывалась? А что бралось за основу? А сработает ли она на другой основе? А что если она из лемм или аксиом в основе неверна? И представить свой проект/отдел как систему – со входами и выходами, функциями преобразования, метриками. И взять текущие данные, и спросить “а почему так? а как можно сделать лучше?”

И вы удивитесь – многие проектные и компанейские проблемы (включая самовары известной субстанции) окажутся решаемыми. Но для этого надо чуть-чуть приподнять голову из постоянного пожаротушения – забарывания бесконечных типовых проблем которые “из-практики-мы-знаем-есть-на-каждом-проекте-так-что-надо-просто-писать-код” и подумать - “почему так? в чем причина? как сделать по-другому?”. Искоренение причин – позволяет делать больше с меньшим напрягом. Практика – это не про то чтобы быстро орудовать лопатой, практика – это как построить экскаватор из лопаты и бензопилы “Дружба”.

Но тут конечно есть большой негативный момент: страдает имидж. Если до этого ты был Супер-Занятой-МегаМенеджер, У Которого Длина Списка Задач 5 Экранов и Который Приходит на Работу в 8ам Утра(ТМ) – то теперь ты выглядишь как расслабленный парень, который ходит и всех хвалит. Не каждое начальство способно это перенести - это факт: раньше у тебя было открыто 10 позиций, и на очередной встрече с Главным ты докладывал - “10 позиций так и не закрыты, и я вот один, ОДИН! все делаю!”. Ну и было понятно – пацан впахивает! А теперь ты говоришь “ну я вот подумал – не надо мне 10 позиций, нужно 2 и вообще про другое” – тогда вообще непонятно, как тебя оценивать. Видимо, расслабился чувак – за что поощрять? Ну и самооценка опять же страдает – раньше как мерялись: вот у Васи 100 подчиненных, а у меня – 120 – все в порядке! А теперь – даже чем меряться непонятно: показатели эффективности у всех разные, КПД абсолютный не посчитаешь… Имхо вот это как раз и есть главный тормоз решения проблем – ежели побороть источники, думают менеджеры, то чем мы заниматься будем?

Не волнуйтесь, господа, проблем найдется! Но это уже будет совсем другая история – история про другую галактику

Почему некоторые автоматизированные системы причиняют людям столько всяких неудобств? Почему большое количество ИТ-систем создается не для того, чтобы максимально облегчить жизнь пользователям, а с какой-то другой целью? Об этом уже было рассказано много историй. Об очередном опыте неравной борьбы человека с машиной рассказывает Михаил Острогорский: «Автоматизированные системы кусают людей»
Читать статью

В статье Алексея Янчука «О культурных различиях и «профессиональных стандартах»» рассказывается о различии моделей, по которым строится профессиональный стандарт в разных странах, в частности, в России и в западных странах. Автор статьи полемизирует с разработчиками проекта российских профессиональных стандартов в области ИТ
Читать статью

Говоря об эффективной корпоративной архитектуре, нельзя не принимать во внимание такой аспект, как сложность системы. Во второй части статьи “Оптимальный путь к корпоративным архитектурам” Роджер Сешнс дает определение сложности системы и показывает, каким образом декомпозиция и итерации помогают бороться со сложностью систем.
Читать статью

События:

12 марта Certified Usability Professional: «Анализ пользователей и задач бизнеса»

Приняв участие в CUP, вы получите все необходимые знания о юзабилити в одной учебной программе. Теоретические блоки программы созданы в формате онлайн-курсов, а значит, Вы можете учиться в удобное для Вас время и в удобном месте. После успешной сдачи экзамена выдается сертификат.
Стоимость 12 000 рублей

26 марта, Москва Enterprise Developers Conference

Enterprise Developers Conference — первая конференция для технических директоров, руководителей разработки, архитекторов и разработчиков крупных компаний о технологиях и решениях для эффективной поддержки бизнеса. Вы узнаете о MDD от одного из его авторов Кейта Шорта, о том, как организовать распределенную Agile разработку, о том, как уже завтра в 8:05 положить на стол руководства детальный отчет по прогрессу разрабатываемой системы и о многом другом.
Стоимость 10 000 рублей. Специальное пакетное предложение для организаций.

Новость от Спанч Боба

Недавно я задумался о том, что такое тестирование, как, когда и зачем оно должно проводиться и кто должен искать «баги».
Я расспросил об этом своих друзей. Друзья прислали мне ссылку на ролик. Я вообще очень люблю ролики, а в этом ролике все очень подробно рассказано. И даже показано. А какой там перевод! Мне показалось, что он чем-то напоминает знаменитого Гоблина.
Однако мне так и не удалось понять одного: о какой методологии рассказывал в этом ролике докладчик? В прошлый раз, просмотрев ролик про waterfall, я все понял, и даже ответил на несколько вопросов. А вот сейчас я – увы – затрудняюсь отвечать на вопросы, и поэтому решил обратиться за помощью к аудитории. Помогите мне, пожалуйста, и объясните, что это за методология и каковы ее основные преимущества. Я поговорил с организаторами конференции Microsoft Quality Assurance Day, и они сказали, что первый, кто пришлет мне краткий и точный ответ, сможет участвовать в конференции бесплатно! Ответы можно отправить на info@careerlab.ru. В комментариях к этому дайджесту на сайте я назову победителя.

Это продолжение статьи Роджера Сешнса “Оптимальный путь к корпоративным архитектурам”. Рекомендуем прочитать первую часть

Сложность

Чтобы определить причины неудач при использовании различных методик создания корпоративных архитектур, нужно понять, что общего между всеми неудачными попытками создания корпоративных архитектур. Что же общего у столь разных систем — у системы управления финансами Налогового управления, системы управления бизнесом Министерства обороны, системы управления действиями в чрезвычайных ситуациях Министерства национальной безопасности, системы управления ФБР Virtual Case File, системы управления бизнесом компании Макдоналдс, системы закупок компании Форд и системы управления каналом поставок компании KMart?

У всех этих систем только одна общая характеристика — сложность. Все эти системы обладают высокой сложностью. Я считаю, что основным недостатком архитектур FEAF и TOGAF и архитектуры Захмана является невозможность управления сложностью систем.

К сожалению, сложность — это не сиюминутная помеха. Можно с уверенностью сделать три предположения о будущем ИТ-отрасли:

В недавней статье, опубликованной в InformIT, Ричард Мур (Richard Murch) охарактеризовал положение дел следующим образом:

“Ничего не предпринимать, чтобы помешать дальнейшему повышению сложности ИТ-инфраструктур и архитектур — неприемлемо и безответственно. Если мы просто бросим на решение этой проблемы новых квалифицированных программистов и других специалистов, настанет хаос … Пока пользователи и поставщики ИТ-систем решают проблему сложности похожим образом, подобные проблемы будут возникать снова и снова, мешая работе отрасли”. [Mur]

Моделирование сложности

Чтобы управлять сложностью, необходимо вначале понять ее особенности. Научившись моделировать сложность, мы сделаем большой шаг к ее пониманию.

Лучшая модель сложности, которая мне известна, — это игральный кубик. Она интуитивно понятна, наглядна, предсказуема и математически обоснована. Я изложил основные положения этой модели в виде закона сложности Сешнса: сложность системы является функцией числа возможных состояний системы

Для понимания этого закона воспользуемся кубиком. Я буду сравнивать сложность двух случайных систем: системы А и системы Б, показанных на рис. 1. Система А состоит из одной двусторонней фигуры (т. е. “монеты”). Система Б состоит из одного кубика с шестью гранями (стандартный игральный кубик).

Рис. 1. Система А и система Б

Система А имеет два возможных состояния: орел и решка. Система Б имеет шесть возможных состояний: 1, 2, 3, 4, 5 и 6. В соответствии с законом сложности Сешнса система Б в 6/2 раз (т. е. в 3 раза) сложнее системы А. Даже если не вникать в математическое обоснование, это интуитивно понятно.

В общем случае число состояний системы, состоящей из D кубиков, каждый из которых имеет S сторон, равно SD. С помощью этой формулы мы можем определять сложность других систем.

Теперь давайте сравним системы Б и В. Система Б, как и ранее, состоит из одного кубика с шестью гранями, а система В — из трех кубиков с шестью гранями, как показано на рис. 2.

Рис. 2. Система Б и система В

Число состояний системы Б по-прежнему равно 6¹ (или 6), а число состояний системы В равно 6³ (т. е. 216). В соответствии с законом сложности Сешнса система В в 216/6 раз (т. е. в 36 раз) сложнее системы Б.

Если вы захотите предсказать результат броска кубиков в системе В, у вас будет 1 шанс из 216 угадать правильную комбинацию. Если вы захотите предсказать результат броска кубиков в системе Б, у вас будет 1 шанс из 6 угадать правильную комбинацию. Если вы сделаете серию предсказаний относительно обеих систем, в среднем вы сможете правильно предсказать состояние системы Б в 36 раз чаще, чем системы В. Поскольку система Б менее сложная, чем система В, она легче поддается прогнозированию

Декомпозиция

Используя эту базовую модель сложности, мы можем найти методы, позволяющие усовершенствовать организацию сложных систем.
Сравним две системы — систему В и систему Г, — каждая из которых состоит из трех шестигранных кубиков. В системе В кубики, как и ранее, находятся вместе, а в системе Г разделены на три подсистемы. Эти системы показаны на рис. 3.

Рис. 3. Система В и система Г

Предположим, мы можем использовать каждую из трех подсистем независимо (т. е. каждая подсистема будет представлять собой систему, подобную системе Б).

Мы знаем, что сложность системы В будет равна 216. Совокупная сложность системы Г определяется как сумма сложностей подсистем 1, 2 и 3. В соответствии с правилом S^D, сложность каждой подсистемы будет равна 6¹, или 6. Таким образом, сложность системы Г будет равна 6+6+6, или 18.

Если вас это не убеждает, представьте себе, что вам надо проверить правильность работы систем В и Г. При проверке системы В вам придется проверить правильность 216 различных состояний, а при проверке системы Г — только 6 различных состояний при проверке работы первой подсистемы, еще 6 — при проверке работы второй подсистемы и еще 6 — при проверке работы третьей.

Таким образом, сложность системы, состоящей из P подсистем, каждая из которых имеет сложность C, составляет C*P. Если каждая подсистема будет состоять только из одного кубика, эта формула примет вид S¹*D, что снижает сложность до S*D.

Теперь давайте обобщим полученный результат на все системы, прошедшие и не прошедшие декомпозицию. Чтобы упростить задачу, предположим, что подсистемы всегда состоят из одного кубика (как в случае с системой Г). При этом сложность системы, не проходившей декомпозицию (например, системы В) всегда равна S^D, а сложность системы, прошедшей декомпозицию (например, системы Г), всегда равна S*D.

Таким образом, вопрос можно свести к следующему: как соотносятся между собой формулы (S*D) и (S^D)? В таблице 1 приведены значения, вычисленные по формулам S*D (система с декомпозицией) и S^D (система без декомпозиции) для различных значений величин S и D.

Таблица 1. Сложность систем с декомпозицией и без декомпозиции

Таблица 1 наглядно показывает, насколько система из 9 кубиков, не разбитая на подсистемы, сложнее, чем система, содержащая 9 кубиков, но прошедшая декомпозицию. Отношение сложностей этих систем составляет 10 077 696 к 52 (для неспециалистов: очень-очень(!) много).

Вывод, который можно сделать на основании таблицы 1, понятен: чем выше совокупная сложность системы, тем сильнее ее можно уменьшить с помощью декомпозиции.

Итак, декомпозиция — это первый метод борьбы со сложностью.

Итерации

Уменьшив сложность системы с помощью декомпозиции, мы сталкиваемся еще с одной проблемой. Как проанализировать оставшуюся сложность? Существует два подхода: итерационный (слева направо) и рекурсивный (сверху вниз). Чтобы понять отличия этих походов, давайте еще раз рассмотрим модель сложности системы из кубиков, прошедшей декомпозицию (см. рис. 4).

Рис. 4. Система из кубиков после декомпозиции

При использовании итерационного подхода мы анализируем каждую подсистему по отдельности. Например, сначала проанализируем подсистему 1, затем подсистему 2 и так далее.

Итерационный подход основан на анализе горизонтальных уровней каждой подсистемы. Например, сначала мы должны проанализировать ситуацию, в которой на всех кубиках выпало значение 1, затем — ситуацию, в которой на первом кубике выпала единица, а на остальных — двойки, и так далее, пока не переберем все возможные состояния для всех подсистем.

Какой метод лучше? Итерационный или рекурсивный?

Для ответа на этот вопрос вернемся в 1950 год, к любознательному полковнику военно-воздушных сил по имени Джон Бойд (John Boyd) [Boy]. Бойда не интересовали вопросы создания сложных ИТ-систем. Скорее всего, он даже никогда не слышал ни про корпоративную архитектуру, ни вообще про ИТ-системы. Он хотел понять, как побеждать в воздушных дуэлях.

Воздушная дуэль — это воздушный бой между двумя пилотами истребителей, каждый из которых старается попасть в соперника раньше, чем соперник попадет в него. Теперь вы понимаете, почему полковник ВВС хотел научиться побеждать в таких боях.

Управление истребителем в воздушном бою — сложнейшая задача. Пилот должен анализировать информацию из множества источников. А в это время противник пытается его сбить. Чтобы понять, насколько сложную задачу должны были решать пилоты Бойда, посмотрите на рис. 5, на котором показана кабина истребителя

Рис. 5. Кабина истребителя

Бойда интересовали не любые воздушные бои, а воздушные бои между самолетами МИГ-15С и F-86s. Бывший пилот и опытный авиаконструктор Бойд очень хорошо знал особенности этих самолетов. Он знал, что МИГ-15 был более совершенным самолетом, чем F-86: он быстрее набирал высоту, быстрее поворачивал и имел большую дальность обзора.

Однако существовала одна проблема. Хотя Бойд и большинство других авиаконструкторов считали МИГ-15 великолепным самолетом, пилоты предпочитали F-86. Причина была очень простой: в одиночных воздушных дуэлях F-86 выигрывал у МИГ-15 девять поединков из десяти.

Эта ситуация заинтересовала Бойда. Почему отличный самолет полностью проигрывает самолету с худшими характеристиками?

Чтобы разрешить эту проблему, Бойду надо было понять, каким образом пилоты действуют в воздушном бою. У Бойда было существенное преимущество — в прошлом он был не только пилотом, но и одним из самых умелых мастеров воздушных дуэлей, и имел опыт ведения воздушных боев.

Давайте представим себе пилота, участвующего в воздушной дуэли. Назовем его Питом. Бойд предположил, что для Пита воздушный бой состоит из четырех этапов. На первом этапе Пит наблюдает за окружающей обстановкой, включая самолет противника. На втором этапе Пит ориентируется в соответствии с этой ситуацией. На третьем этапе Пит планирует дальнейшие действия, а на четвертом действует.

Таким образом, Пит сначала наблюдает, затем ориентируется, составляет план и действует. Бойд назвал эту последовательность OOPA (observe, orient, plan, act).

Те, кто читал работы Бойда, могут заметить, что Бойд называл этот цикла OODA — observe, orient, deploy, act (наблюдение, ориентация, развертывание и действие, или НОРД). Однако в этой статье термин “развертывание” заменен термином “планирование”. Это сделано по двум причинам. Во-первых, чтобы не создавать путаницы для читателей, знающих, что аббревиатура OODA расшифровывается как “объектно-ориентированное проектирование и анализ”. Во-вторых, читая работы Бойда, я пришел к выводу, что используемый в ИТ-отрасли термин “план” по значению близок к тому, что Бойд называл “развертыванием”.

Однако, и это очень важно, Питу приходится выполнять эту последовательность действий снова и снова. То есть Пит все время циклически проходит этапы OOPA. И, разумеется, то же самое делает его противник. Кто же победит? Пит? Или анти-Пит? Мы знаем, что если Пит летает на F-86, он, вероятно, победит. Но почему?

Кажется, что анти-Пит, управляющий МИГ-15, сможет выполнить этапы цикла OOPA лучше, чем Пит. Поскольку он дальше видит и может сделать более точные наблюдения, а поскольку он быстрее поворачивает и набирает высоту, он должен и быстрее реагировать. Однако анти-Пит проигрывает, а Пит побеждает!

Бойд решил, что основным фактором, от которого зависит победа в воздушной дуэли, является не способность точнее наблюдать и лучше ориентироваться, планировать и действовать, а возможность выполнять эти этапы быстрее. Другими словами, насколько быстро пилот может выполнить тот или иной этап. Бойд предположил, что скорость выполнения важнее качества.

После этого Бойд задал вопрос: «Почему пилоты F-86 выполняют эти этапы быстрее?» По мнению Бойда, причина крылась в факторе, которому никто не уделил особого внимания — на F-86 устанавливался штурвал с гидравлическим усилителем, а на МИГ-15 — ручной.

В результате перемещение штурвала требовало от пилота МИГ-15 несколько больших усилий, чем от пилота F-86. Поэтому, хотя после движения штурвалом МИГ-15 мог быстрее поворачивать и набирать высоту, само перемещение штурвала давалось пилоту МИГ-15 труднее.

При каждом повторении цикла пилот МИГ-15 уставал немного больше, чем пилот F-86. И чем сильнее он уставал, тем больше времени тратил на выполнения цикла OOPA. Таким образом, пилот МИГ-15 проигрывал не потому, что противник имел перевес, а потому, что отставал в выполнении цикла OOPA.

Я изложу открытие Бойда в виде закона повторений Бойда: в сложных условиях быстрые повторения почти всегда обеспечивают лучшие результаты, чем углубленный анализ.

Итерации с декомпозицией

Итак, теперь мы знаем два принципа, позволяющих лучше управлять сложностью корпоративных архитектур. Изучая кубики, мы увидели, что декомпозиция — один из основных способов уменьшения сложности, а из работ Бойда, посвященных воздушным боям, узнали, что лучший способ анализа подсистем сложных систем — последовательные итерации, при выполнении которых необходимо уделять основное внимание скорости, а не полноте.

Теперь давайте посмотрим, как можно применить эти принципы к
сложным корпоративным архитектурам. Представьте себе крупномасштабную систему управления бизнесом (например, такую, на безуспешное создание которой компания Макдоналдс потратила 170 млн долларов). Я буду называть эту систему СКСУБ (сложная крупномасштабная система управления бизнесом). Предположим, что СКСУБ должна предоставлять следующие возможности:

Как выполнить декомпозицию такой системы? Приведенный выше перечень уже содержит подсказку. Не надо создавать единый гигантский проект СКСУБ. Необходимо создать архитектуру управления кадрами, архитектуру ведения платежных ведомостей — и так далее. Другими словами, не пытайтесь разработать единую, сложную, крупномасштабную систему — создайте несколько небольших и простых систем. Спроектируйте одну систему, разработайте ее и переходите к следующей. Декомпозиция снижает общую сложность. Итерации повышают вероятность успеха.

Можно предположить, что в упомянутых выше неудачных попытках создания корпоративных архитектур (таких как разрабатываемая ФБР система управления виртуальными делами и создаваемая Макдоналдс система управления бизнесом) использовались стандартные методики разработки корпоративных архитектур (такие как FEAF , TOGAF и модель Захмана). Все этим методики не являются итерационными. Поэтому неудивительно, что эти попытки потерпели неудачу. Также неудивительно, что на эти проекты были потрачены очень большие средства.

Во всех методиках разработки корпоративных архитектур сказано, что процесс создания корпоративной архитектуры должен включать следующие этапы:

Традиционные методики предполагают, что каждый этап выполняется один раз и полностью завершается до перехода к следующему этапу. Эта ситуация проиллюстрирована на рис. 6.

Рис. 6. Подход на основе создания единого проекта

Как видно по рисунку 6, создание архитектуры в соответствии с традиционной методикой начинается с углубленного проектирования бизнес-архитектуры конечной системы (например, воображаемой системы СКСУБ, о которой говорилось выше). После этого создается техническая архитектура, а затем выполняются реализация, тестирование, отладка и развертывание. Обратите внимание, что пока полностью не завершится этап развертывания, проект не имеет никакой коммерческой ценности.

Данный пример позволяет также понять, что должны были сделать эти организации. Они должны были использовать итерационный подход с декомпозицией.

Итерационный подход с декомпозицией в корне отличается от традиционного подхода. Действия при использовании этого подхода показаны на рис. 7. Обратите внимание, что приведенный выше порядок выполнения этапов не изменился, однако сейчас мы выполняем каждый этап с разбиением на подсистемы.

Рис. 7. Итерации с декомпозицией

Результатом такого подхода является постоянное расширение функциональности. Мы не начинаем работу над следующей подсистемой, пока не завершена работа над предыдущей. Хотя одновременное выполнение нескольких проектов — достаточно распространенная ситуация для крупных организаций со сложной структурой, число таких проектов необходимо свести к минимуму, поскольку их одновременное выполнение требует более эффективной координации.

Анонс:
26 марта в Москве пройдет первая Enterprise Developers Conference.
Если вы архитектор предприятия или разработчик в крупной компании, не пропустите это событие.

Всем, кто на практике работал с европейскими айтишниками, приходилось поначалу (уверен – не раз) сталкиваться с тем, что они просто 2+2 не могут сложить из того, что Вы им объясняете. Проще всего, конечно, окрестить европейцев необразованными, узко мыслящими тупицами. Отдельные работы российских юмористов способствовали укоренению этого стереотипа. Корень этого явления лежит в другом, и этот «Профессиональный Стандарт» показывает это как нельзя ярче.

В России и в Европе под одними и теми же терминами, описывающими организацию работы, зачастую понимают диаметрально противоположные вещи. Поэтому разницу в восприятии (а в некоторых случаях – зияющую пропасть) надо учитывать как при общении с европейцами, так и при адаптации европейского опыта для российских реалий. Я не хочу обидеть как заказчиков, так и уважаемый авторский коллектив российских «Профессиональных Стандартов». Однако этот «Стандарт», будучи переведенным на английский язык как есть и выданным европейскому менеджеру, последним будет воспринят скорее всего следующим образом:

• Это набор шаблонов должностных инструкций, который почему-то назван «Профессиональным Стандартом», хотя он таким не является;
• Этот набор шаблонов был разработан в рамках государственной программы, которая не определила четких целей и, скорее всего, не достигнет реальных положительных результатов из-за плохой организации программы;
• Набора шаблонов не имеет понятно определенного статуса;
• Преимущества, внедрение, и оперирование этим набором шаблонов внятно не описаны;
• Текст, которым написаны документы, включая сопроводительные, указывает на недостаточный трудовой стаж авторов для реализации задач такого рода.

Итак, обо всем по порядку.

Профессиональный Стандарт

Что европеец хочет сказать фразой «Это не профессионально»? То, что предмет, о котором говорится, не соответствует писанным или неписанным ожиданиям поведения человека или результатов его работы. Т.е. с европейской точки зрения Профессиональный Стандарт обсуждает вопросы этики, ценностей, убеждений в том, что правильно, а что нет. Цель такого стандарта в развитии, продвижении, признании профессии – как коллективно, так и индивидуально. Немаловажно так же, что авторы Профессиональных Стандартов применяют их к себе в первую очередь и призывают всех остальных следовать их примеру.

Государственная Программа и Ее Цели

В предисловии Министра информационных технологий и связи буквально во втором параграфе находим следующий текст: «… Однако отрасли не хватает еще около 190 тысяч квалифицированных работников. Именно поэтому в июне 2006 го на заседании Совета по ИТ в Министерстве  информационных технологий и связи Российской Федерации было принято решение о разработке профессиональных стандартов.»

Постановка проблема и ее решение снесет европейцу крышу по самый фундамент. Как этика и ценности могут с толкомзаполнить 190К вакансий? Закидывание телами в краткосрочном периоде приводит еще к большим задержкам и, следовательно, к усугублению ситуации относительно текущей – об этом еще Брукс писал. В долгосрочном периоде возникает вопрос, что делать с людьми при очередных колебаниях рынка.

Как раз здесь полезным будет обратиться к Европейскому опыту. В начале 2000х Германия открыла программу «зеленой карты» для ИТ специалистов. Было определено, сколько рабочих мест в ИТ необходимо заполнить методом ввоза специалистов из-за рубежа для поддержания устойчивого экономического роста немецкой экономики. Разницу уловили? А вот результаты этой программы оказались достаточно неоднозначные, и в целом немецкое общество отнеслось к ней не очень позитивно.

Статус «Профессионального Стандарта»

В «инструкции по применению» находим , что «… каждый профессиональный стандарт – это нормативный документ рекомендательного характера…». У среднестатистического европейца на этом месте расплавляется мозг: так какой же статус имеет этот «стандарт» : он стандарт или рекомендация?

В работе над конкретным проектом мы руководствуемся тремя группами документов:

1. Законы и контракты. Обязательны к исполнению – и точка;
2. Стандарты. Внедрение зависит от массы обстоятельств. Но если принято решение соответствовать стандарту, предписаниям стандарта следуют.
3. Рекомендации и лучшие практики. Полезны в качестве пищи для размышлений.

Применение стандартов (кстати, слово «норма» является синонимом) невозможно без понятия «соответствие стандартам». Стандарт может содержать требования, от внедрения которых можно отказаться при определенных стандартом обстоятельствах. Стандарт может так же содержать и рекомендации, не обязательные к реализации. Что не меняет предписывающего характера стандарта: соответствуете стандарту означает соответствие всемпредписаниям. Стандарт рекомендательного характера является рекомендацией.

Преимущества от внедрения

В заключении раздела «инструкции по применению», посвященному полезности «Стандарта» для работодателей, находим: «В заключение остается добавить, что какой бы подход к формированию своей модели компетенций ни использовала компания, хочется верить, что данные профессиональные стандарты будут ей полезны.» Европейский менталитет транслирует это маркетинговое бла-бла в следующее: «Я понятия не имею, как заставить это работать и что вам это даст.»

Допустим, что я владелец бизнеса. У меня есть проблемы; у меня всегда будут проблемы. Какие мои конкретные проблемы это «Стандарт» может решить? Получу ли я более качественных программистов? Найду внутренние резервы? Смогу удержать тех, кто думает о смене места работы? Улучшится климат в коллективе? Улучшится мотивация? Снизятся издержки? Европейский образ мышления не видит в этой «инструкции» ничего, что могло бы дать не заставляющий думать и догадываться ответ на простой вопрос: «Что это все дастлично мне?»

А Вот Текст… Обнять и Плакать!

В Европейских организациях не редкость такое явление как сотрудник-иностранец. Поскольку уровень владения языком у всех разный, существует простой способ быстро определить профессиональный уровень кандидата без скидки на трудности перевода. Он основан на глаголах, которые используются в CV. Когда кандидат пишет, что он:

• участвовал в чем-то, то с высокой долей вероятности это начинающий специалист;
• делал что-то,  то с высокой долей вероятности это специалист среднего уровня;
• заделиверил (delivered) что-то, при этом указывает на смысл и место результата работы в проекте, то с высокой долей вероятности это топ-специалист.

Начинающие же делятся на две категории: просто начинающие и продвинутые начинающие. Разница между ними в том, что продвинутый начинающий уже умеет делать все, что умеет специалист среднего уровня. Кроме одного: продвинутый начинающий не видит целостной картины того, что происходит.

Теперь сравните два описания одной и той же должностной обязанности:

1. Участие в разработке различных типов требований к программному продукту
2. В состоянии разработать в течение 2х недель требования к программному продукту, не являющимся критическим для функционирования бизнеса заказчика, имеющего не больше 15ти ключевых функций, требующего не больше 3х человеко-лет трудозатрат при бюджете разработки не более $150,000.

Уверен, все понимают, какой из этих вариантов лучше описывает, что конкретный ресурс может, а чего нет. В том числе для конкретного ресурса – дает ему SMART цель того, что он должен уметь, чтобы дотянуть до квалификационного уровня. Европейский менталитет поставит не задумываясь диагноз: текст шаблонов писали Advanced Beginners.

Заключение

Начинание в общем и целом хорошее. Получилось – как всегда. Если это первый блин, неудивительно, что он получился комом. Проводим работу над ошибками, выпускаем версию 2.0. Могут ли авторы этого блога что-то сделать в этом направлении? Разумеется, можем. Правительство РФ, обращайтесь!

Источник