Блог:Максима Цепкова

В начале года я обнаружил интересную вещь для описания архитектуры и бизнеса в одном флаконе - Archimate, написал об этом в блоге, начал пропагандировать и пытаться использовать. И в некоторых проектах диаграммки на нем мы делали. А сам язык за это время несколько заматерел, отдельный домен archimate.org стал перенаправлением под крыло родителей - The Open Group, появились ссылки на другое их детище - TOGAF. Что, однако, не отменяет его использования в легком стиле эскизного проектирования, а не моделирования.

А сегодня в блоге Анатолия Левенчука обнаружил, что он тоже заинтересовался Архимейтом (как он его называет), начал применять и, что очень ценно - сделал хороший рассказ метода в целом и творчески перевел основные понятия. Что я всячески рекомендую. Потому как "Архимейт является одним из первых архитектурных языков, который поставил задачу совместного описания по единым принципам и в едином языке как архитектуры деятельности, так и архитектуры IT-решения." ((с) Левенчук), а нам - это очень близко.

Весной на REQ-Labs я услышал в докладе Пауля Тернера о картах компетенций в IT, которые применяются в Англии. Там была ссылка на ассоциацию SFIA (http://www.sfia.org.uk), которая этим занимается. Я тогда еще посмотрел на сайт - оказалось, материалы можно выкачать, если зарегистрироваться. И совершенно свободно использовать в своей организации, нельзя лишь оказывать коммерческие услуги на их основе без соглашения с ассоциацией. А сама ассоциация занимается стандартизацией карты компетенций в IT-отрасли в Великобритании - чтобы была общая терминология в этой области. А сама аббревиатура расшифровывается как Skills Framework for the Information Age.

На днях я зарегистрировался и выкачал материалы. 90 компетенций (skill) в 6 категориях и 20 подкатегориях, определенные по 7 уровням ответственности (впрочем, пара младших и самый старший уровень не слишком заполнены). Для компетенций и категорий есть определения, а сами уровни ответственности определены по 4 параметрам - Autonomy, Influence, Complexity, Business skills. Все это сведено в большой Excel, а также представлено в нескольких pdf-документах.

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

В прошедшую субботу был и выступал на конференции ЛАФ-2011. Было около 100 человек, из Москвы, Питера, Иваново. Самары, Краснодара, Минска и других мест. Три трека - доклады, круглые столы и мастер-классы. Как и в прошлом году, впечатление - крайне позитивное, конференция живая. Люди активно общаются, по этому признаку ее вполне можно сравнить с AgileDays. Доклады были достаточно высокого уровня, вполне сравнимы с другими хорошими конференциями.

Я выступал, снова о DDD, но с другими акцентами. Мой доклад был принят с интересом. А еще - построение учетных моделей с помощью диаграмм учета постепенно овладевает умами. Поезд из Москвы приехал в 6 утра и пока мы ждали открытия конференции, несколько человек спрашивали меня о деталях и подробностях этого подхода. В том числе - спрашивали о схемах управленческого и бухгалтерского учета расчетов с клиентами, которые были недавно опубликованы в журнале Бухгалтер и Компьютер №5 Когда всем понятно.

Из идей, интересных в контексте нашей компании стоит отметить следующее.

• Доклад Ирина Левенец - о поддержании взаимоотношений с заказчиками в условиях длительного сотрудничества. Правда, у них продуктовая разработка. а у нас - заказная. Но все равно, много общего, особенно если рассматривать различные группы пользователей как отдельных заказчиков.
• В докладе Михаил Мочалoв рассказывалось о подготовке аналитиков у них в компании. Из интересного - на входе новичкам сообщают набор блоков (об организации процессов и т.п.), по которым они должны подготовиться и сдать зачет - в форме теста или беседы. Дальше - инициатива на них, хотя есть куратор который поможет. Если не сдал - готовишься и пересдаешь, за это не отсеивают. Я тут подумал, что таким образом самого человека настраивают на активную позицию, снимают барьер, когда он стесняется задавать вопросы. Поэтому, возможно, стоит присмотреться к идее и организовать нечто подобное у нас.

Отчет о конференции ЛАФ-2011

Читая книгу, иногда записываю мысли как пост для блога, а потом - забываю опубликовать. Сегодня вот наткнулся на тезисы по мотивам Черного лебедя Талеба...

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

Был вместе со многими сотрудниками компании на встрече Стратоплана. Вообще мы там обеспечивали массовость, хотя никоим образом не составляли большинства. Встреча и доклады для меня была интересны. Правда, в ряде докладов важно было понять не то, что докладчик сказал, а то, что он хотел сказать. Потому что обобщающая формулировка интерпретировалась правильным образом только после смещения акцентов, которые возникали из примеров и пояснений. Зато это будило собственную мыслительную активность, вызывая мысли и ассоциации. И у меня появился ряд мыслей по своей работе и организации. А еще - я узнал про сервис remember the milk - надо будет посмотреть, возможно, он подойдет мне для ведения дел. К сожалению, я не взял ноут и писал на бумажках, так что отчета, скорее всего, не будет. Но я готов поделиться с интересующимися, а если их будет много - то, может, напишу отчет.

Был на тренинге Нила Мейдена. Понравилось. Тренинг - больше по различным общим креативным техникам, нежели их применению в ИТ. Мы в эту сторону активно движемся, примером чему Стратегическая сессия. И на этом пути полезно осваивать современный опыт. Написал отчет SoftwarePeople-2011 тренинг Мейдена.

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

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

Мой доклад прошел хорошо, вызвал достаточно много вопросов, пожалуй, больше, чем на других конференциях. И потом обсуждали. В целом практики вызывают интерес. Еще в обсуждении был интерес и к нашему ORM cis-uni.net - я свел людей с Игорем Беспальчуком.

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

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

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

Я попробую не только публиковать впечатления о конференции в реальном времени, но и сделать отчет. Может, он получится write only, как написали о моем отчете по REQ-labs, зато сразу. Тем более, что на 2 недели уезжаю в отпуск.

Итак, SoftwarePeople 2011, день первый.

Общее впечатление — конференция удалась. Она наиболее профессионально организована из всех тех, на которых я был за год. AgileDays-2011 и ADD-2010 мне показались более живые в части общения участников, но профессионализма им не хватает. Правда, они моложе и более дешевые, а профессионализм — он не бесплатен.

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

На конференции попробовали практику пленарных докладов, принятую на зарубежных конференциях. Она очень хороша, когда доклад — достоен. Как у Книберга на Agile Days. Реально достойный пленарный доклад — это очень сложно, потому что он должен быть комбинацией общего смысла, ценного для новых слушателей, но содержать интересные моменты, которые оценят специалисты, свободно владеющие основами. Здесь реально достойный доклад был у Мейдена, но сильно не все на таком уровне абстракции мыслят и восприняли идеи. А вот у Ютты — наоборот, популяризация, ликбез, и там нет новых мыслей и идей, которые бы были интересны специалистам. Более того, с моей точки зрения, у нее вообще не было конкретики, и шли очевидные вещи. Но в перерыве некоторые участники говорили мне, что услышав в докладе в очередной раз известную ранее вещь, они поставили себе пометку — попробовать, сказано было своевременно и подтолкнуло. Доклад Коскелы — посередине между ними. А с докладом Кристенсена по HTML5 получилось совсем неудачно — он воспринимался как технический и, в общем, таким был, и как таковой — был не интересен приличной части участников. А альтернативы не было.

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

После 4 пленарных докладов пошло два трека, и я был на people management, а не technologies. На первом докладе — потому что на техническом треке продолжил Кристенсена, пленарный доклад которого мне сильно не понравился. А потом — были очень креативные докладчики, их было интересно слушать. Возможно, на технической секции доклады тоже были креативные, то область технологий, которых они касались лично мне не слишком интересны, в то время как вопросы организации менеджмента и обучения, о которых говорили на секции менеджмента — интересны.

Отдельные мысли.

• Программисты, ваш собственный feedback на MS или Яндекс — вы просто их меньше ненавидите :) Кто хоть раз написал благодарность за новый функционал? Будьте готовы к тому же от пользователей…
• Как известно, сон разума рождает чудовищ. А коллективный разум бюрократии спит беспробудно. Ergo, стандарты — чудовищны.

Еще из любопытного. С моим докладом в печатной программе опять некоторые проблемы. Не такие, как на Agile Days-2011, где на его место сдублировали информацию по докладу из другого дня и другой секции — здесь всего лишь перепутали фамилию. Ну и бейджика докладчика на регистрации не было. Бейджик оперативно изготовили. Но вообще я бы сказал, что это энтропия бушует, потому как уже второй раз…

Дальше желающие могут посмотреть текущую версию отчета, где есть аннотации по всем сегодняшним докладам, а могут подождать полного отчета.

Причесал и опубликовал свои впечатления о ReqLabs-2011.

В целом конференция мне понравилась, подробности - читайте.

Опубликовал отчет AgileDays-2011.

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

Оценка в SP.

• Почему перешли на оценку в SP (story point)? Это — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать им подходы к оценке. А точность — не уменьшается. Для рефлексии о причинах падения скорости SP обычно хватает, если какая-то одна-две задачи несоразмерно выросли.
• Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала — чтобы они не влияли на оценки отдельных задач. Но в случае расхождений — разбираться, вопрос в подробностях задачи или более систематично что-то поплыло.
• Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как «похожую на ту» легче, чем прикинуть часы.

О SM

• Если кто не разделяет цели — гнать из команды. Движение должно быть сонаправленным. Размер шага (скорость) — не так важны, это тренируется, если человек разделяет цели. Ответственность за фиксацию таких проблем — на SM.
• Про SM, не смотря на много «управляющих» функций по процессу, явный акцент Книберга на самовыдвижении и отсутствии формальной власти. И SM создает условия для самоорганизации, а не управляет. Основне средство — вопрос «А что вы думаете о …» (а не «Давайте решим такую проблему…»).
• Если есть персональные проблемы, например, кто-то систематически не соблюдает стандарт кодирования и на review это вылезает, то задача SM — это выявить. Хотя на ретро об этом могут не говорить. Поговорить до ретро с членами команды, а дальше по обстановки — можно индивидуально, можно на ретро. То, что это в компетенции SM — «по умолчанию».

Процесс в целом

• Практика, когда задачу заранее готовят к выполнению, например, постановка силами той же команды или согласование с заказчиком — распространенная. И хорошая техника — вместе с DoD сделать Definition of Ready — check list, что должно быть у задачи, чтобы ее можно было запускать в спринт. Пример DoR: есть bug, grade S/M/L, есть acceptante test.
• Еще раз сформулировали — кросс-функциональная команда — не значит, что каждый заменяет каждого. Но значит, что нет критичного для процесса человека, и в целом компетенции сбалансированы с потоком задач с учетом отклонений. Техника: матрица деятельность (DB/Java/Design/Test, например) — сотрудник, на пересечении — оценка: пусто/точка/звездочка. Должно быть минимум две звездочки и несколько точек, если нет, то включаем в цели их прокачку у конкретных участников в ходе спринта за счет выполнения задач (например).
• Project Manager в смысле CMMI поделен в SCRUM примерно так:
  • release plan — PO
  • build team — SM
  • архитектура — команда
  • раздача задач — task board
  • набор персонала — за рамками команды
• Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе — тем быстрее новое дело, вкинутое на вход, появится на выходе. И это — без узкого горла. Если стадий 5, то в работе оптимально 7 начатых дел. Практически это мощное ограничение, особенно с учетом дорогого переключения контекста, и надо этим пользоваться, и того, что люди не могут одновременно держать много целей.
• Working smart more important than working hard. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит.

Две команды на одном продукте.

• Итерации — рекомендуется синхронно, и общий релиз. Иначе сложно с кодом.
• Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO — отдает. Как вариант — в каждой команде свой «локальный PO», который берет задачи от общего, так тоже можно.

Разные техники.

• Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов».
• Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины.
• Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным.
• Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку.

Повсеместная работа с карточками меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом — в сделанное в рамках спринта может быть полезна на собраниях с повесткой дня. Я, во всяком случае, буду пробовать — если не забуду. Приоритеты — тоже через них. И bring down на планировании — user story на доске, пишем task и вешаем.

Общение с другими.

• Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum — разный, в том числе в варианте, когда scrum master близок к менеджеру. У других — упор на PO, есть те, у кого он в команде.
• Была практика, когда один SM ведет две команды, и это — его полная загрузка, а задача его — именно наладить процесс. При этом он знает разряды сотрудников и следит за адекватным вкладу разрядом, говоря о проблемах индивидуально. На ретро или эскалируя.
• Планирование 2-недельной итерации вместе с декомпозицией story на task — полдня, 4 часа.
• SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story — пишем acceptant test (пишет или утверждает PO), который развертывают в test case. И все это делает команда.
• Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами.
• Понимание терминов — разное. Не все считают, что DoD — это общее для всех задач, некоторые используют его скорее как HowToDemo или Acceptante Test. Это надо иметь ввиду, когда общаетесь.

PO в команде, как это у нас. Не отрицается, что это возможно. И ряд участников рассказывали о положительном опыте, они тоже так делают. Почему сам Генрих не делает, мне понятно — у него основной профиль — работа с проблемными проектами, бизнес-часть там разная, соответственно, он ей не занимается, а обеспечивает процесс за счет SM. Поэтому ничего определенного на мой вопрос не сказал. Что касается моих собственных мыслей об этом (с учетом тренинга и прочего), то, думаю, для нас нынешний вариант неизбежен. Потому что заказчик хочет PO у нас, в том числе согласовывающего позиции разных stakeholder’ов с его стороны. А для этого PO должен разбираться в архитектуре и уметь давать оценки, для чего, в общем-то быть в команде. И естественно им оказывается самый сильный член команды. Теоретически это не мешает появиться еще сильному SM, и команде будет только лучше, но практически в этом случае фирма просто сделает две команды — потому что дефицит руководителей проявляется наиболее отчетливо. Однако все это не мешает работе в SM для их роста, как будущих PO, управляющих процессом, или просто сосредоточенных на тех аспектах, на которые PO не хватает.

От тренинга остались 2 книги, напечатанные и на пружинке.

• SCRUM и XP из окопов с автографом, так что только на почитать.
• SCRUM и Kanban: выжимаем максимум.

И авторский checklist по SCRUMу с градацией bottom line/core/recommended/scaling/positive indicators, он есть на его сайте.

Засим — все.

По горячим воспоминаниям хочу зафиксировать впечатления от тренинга Генриха Книберга, на первом дне которого я сегодня был. То, что я дальше напишу — отчасти материалы тренинга, а отчасти — услышано в беседах и ответах на вопросы.

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

Первое — роли и их разделение.

• Product Owner отвечает за продукт, а SCRUM Master — отвечает за процесс в команде. И это бьется очень четко и всеобъемлюще.
• PO — продукт целиком, его интересует общая скорость и другие характеристики. Ответственность включает ROI и экономические составляющие, включая выход и стоимость команды. Но внутрь команды он не смотри, для него команда — целиком, в том числе с точки зрения стоимости.
• SM — ответственность за процесс, внутренняя (coach) и внешняя (коммуникации с внешними людьми). Именно он представляет реальный вклад сотрудников команды, смотрит кому и где надо помочь и это организует. Не административно, а предлагая, но в целом — его scope. В том числе — может организовывать привлечение экспертов, если это повысит производительность — согласовав с PO, так как стоимость команды тоже возрастет.
• Деление PO-SM, помимо прочего, позволяет сделать явным поиск компромисса и вовлечь в процесс команду.
• Новые члены — с учетом мнения команды, интервью все или хотя бы один (это уже после HR, естественно).
• За технические решения отвечает команда. Она может инициировать включение в PBL задач, касающихся архитектуры, рефакторинга и прочего, высказывать мнение по приоритетам, которые следуют из техники реализации. Но принятие решения по приоритетам — за PO, он команду слушает, но решает сам.
• Еще есть менеджер, но он — один на много команд. Его задача — зарплата, контракт с сотрудником и подобные вещи. При этом для обратной связи о вкладе человека, его эффективности — он общается со SM. Плюс — может приходить на DSM и прочие мероприятия, беседовать и так далее — для получения нужной ему информации.
• Полной взаимозаменяемости нет, все люди — разные, с разным опытом и по-разному решают задачи. Разделение труда в команде есть или может быть. Жесткость — зависит от конкретного проекта. PO и/или SM могут стремиться к увеличению опыта членами команды за счет непрофильных задач или наоборот, пренебрегать рисками и ориентироваться на то, чтобы каждый брал профильные задачи. В зависимости от этого меняется стратегия оценки при планировании: могут брать оценку для профильного сотрудника, или среднюю, но команда должна договориться. Плюс, когда спринт не сбалансирован с опытом команды — она это учитывает при оценке.

Планирование и организация.

• Есть release plan (на 8-10 спринтов, 20-30 недель), который в крупном, в feature или user story, и он предварительно, в крупном, оценен командой.
• Поскольку есть оценка — то достижение результата в крупном, скорость реализации — контролируется.
• Но спринт — тоже, естественно, оценивается. Оценка может совпасть или нет, по разным причинам. Может быть особенность задачи, а может быть ситуация, когда команда набрала опыт и научилась точнее оценивать. Во второй ситуации PO может понять о коррекции начальных планов и что-нибудь предпринять по этому поводу.
• Исходные данные для формирования SBL итерации — не только PBL, но и цели: business, learning, risk, technical dependencies.
• Важно ограничивать число тем итерации, переключения контекста — дорого. В идеале — один основная тема и одна фоновая. От итерации к итерации темы можно менять.
• Есть мероприятие — Backlog workshop, проводится каждую неделю, PO + команда, оценивается текущее состояние, могут вноситься изменения.
• Окончательно перешли к оценке в попугаях (story point). В них меняют velocity на спринт, а при планировании из нее получают объем спринта в SP (с учетом фактических человеко-дней). Если есть фиксированные по времени мероприятия, то их надо вычесть из длительности спринта. SP оценки спринта и релиза, в общем случае — разные, коэффициент уточняется по прошедшим спринтам.

Обо всем понемногу.

• Варианты с 2-3 командами на одном продукте с общим кодом и нескольких продуктов для одной команды — вполне рабочие.
• Команды должны быть стабильны. В цифрах это означает устойчивое существование 3-6 месяцев.
• Новая команда по опыту выходит на плато скорости за 1-2 месяца.
• В презентации есть интересные ссылки на исследования психологов — как оценивает команда одну спецификацию в зависимости от разных факторов. Например, от числа листов, полученного увеличением размера шрифта (коэффициент 1.5) или предварительно высказанной оценки стороннего эксперта. Первичку, кто интересуется, думаю, можно найти — ссылка была на Simula research lab, Еstimation …, Oslo 2006.
• «Не бывает низкой скорости, бывают нереалистичные планы». Потому что скорость сама — не поднимется, над этим надо работать.
• Что мотивирует (это известно, но, тем не менее):
  • Autonomy = свобода, самоопределение (да. в рамках, но рамки — они везде есть)
  • Mastery = передовые технологии
  • Purpose = понятные, осмысленные и ценные задачи, которые делаем

Метафоры и образы.

• Водопад как последовательные выстрелы из лука: облако заказа, Req стреляет — получает требования, Designer — получает проект, разработчики — результат. Все как-то промахиваются, естественно — наводят на одно, получают другое. Ну и Заказчик реально хотел не то, что заказал.
• Водопад как стрельба из пушки по движущейся мишени. Agile (SCRUM) как самонаводящаяся на цель ракета вместо этого.

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

Достаточно регулярно, когда читаешь хорошую книжку, то прочитав где-нибудь 1/3, а то и 1/5, и осознав полезность твердо решаешь написать потом в блог и поделиться. А когда прочитал и начал писать пост - как-то не пишется. Осознав это некоторое время назад, я понял, что причина в том, что теряешь остроту восприятия, ценные мысли из книги проникают внутрь, становятся частью тебя и перестают восприниматься как новые. Ты забываешь, что было интересно именно в этой книге. Книгу Дэвида Аллена Getting Things Done (на русском) я прочитал на 2/3 и, возможно, уже утратил ту самую новизну впечатления, но, тем не менее я подумал, что лучше написать сейчас, чем дочитав.

Возвращаюсь к книге. Книга понравилась и вызвала процесс сопоставления и погружения в картину мира. И первая мысль, которая возникла - это о клиентах Аллена, которым он проводил тренинги. В них четко опознавались сенсорики-решающие (SJ) по Майерс-Бриггс, которым важно составление детальных планов и следование им. Планы - рушатся и люди испытывают дискомфорт и стресс. Таких людей - устойчивое большинство среди руководителей (50-60%), а если добавить сюда интуитов-решающих (NJ), для которых данная проблема тоже актуальна, то их будет более 3/4 (75-85%). А планы - они будут рушиться принципиально, потому что руководители имеют дело с людьми, а это - слабо предсказуемая субстанция, область Крайнестана по Талебу. Кстати, за книгу Черный лебедь Талеба - отдельное спасибо Стасу Фомину. Так вот, Аллен учит, показывает способы ведения планов, при которых не возникает стресса и дискомфорта. Потому что ты ведешь списки, а не намечаешь даты. И, что важно, способы очень легкие, простые, без накладных расходов и излишней нагрузки. Такие, что будут комфортно восприняты и второй половиной человечества, воспринимающими (P) - ведь это только среди руководителей решающих (J) - большинство, а так их половина. Таким образом, методы из книги получаются психологически пригодны для каждого, и это - замечательно.

Что касается собственно предлагаемых в книге методов, то они действительно полезны. Я не могу сказать, что они открыли мне глаза или перевернули сознание. Прежде всего потому, что по крупному у меня нет проблем с организацией дел. Отчасти из-за занимаемой позиции, а отчасти - потому что моя нынешняя система весьма похожа на GTD (тут я не хвастаюсь, типа, сам додумался, а объясняю отсутствие проблемы). Однако, в целом под влиянием книги у меня возникло достаточно много частных идей, которым я буду пытаться следовать. Потому что сейчас я пробую эффективно работать по 3-4 принципиально разным направлениям, и широта деятельности способствует потере контекстов. А еще - думаю, это полезно при организации домашних дел и проектов. Конечно, с одной стороны - просматривать список за ужином для выбора темы разговора с женой и детьми - это некоторый перебор, но, с другой - я регулярно по нескольку дней забываю нечто сказать. В последнее время, если мысль приходит на работе, то иногда даже пишу письмо :) Но в метро или когда идешь или гуляешь это недоступно, а мысли - они приходят.

Так что читайте, оно того стоит. Хотя, конечно. есть очень много книг. достойных прочтения, а времени не так много...

Участвуя в различных наших конференциях и смотря их материалы часто думаешь о том, как бы конференция выглядела в идеале. Тут три части: подготовка конференции, формирование секций и докладов, собственно проведение и, возможно более важное - последействие, фиксация результатов конференции. Почему результаты могут быть важнее? Потому что они - долгоиграющая составляющая. А еще, хотя общение - безусловно ценно, результаты при хорошей публикации - доступны широкому кругу лиц. Однако, на на большинстве конференций "спасение утопающих - дело рук самих утопающих": докладчики сами публикуют свои доклады или выкладывают презентации, благо это несложно, и тем дело кончается. Хотя необходимо отметить, что есть продвинутые конференции, например, ЛАФ-2010 или ADD-2010, на которых заботятся о фиксации результатов докладов.

Это была преамбула. Теперь предмет поста. Блуждая, точнее, целенаправленно изучая проторы инета на предмет изучения IT-отрасли на западе наткнулся на весьма интересную конференцию WICSA (Working IEEE/IFIP Conference on Software Architecture). Интересна она тем, что помимо сайтов конференции поддерживается wiki, в которую собираются материалы конференции. И не только статьи участников, каждая сессия - продумывается на предмет целей и вопросов, результаты круглых столов и обсуждений - кратко фиксируются. Пример такой фиксации можно посмотреть здесь по конференции, и здесь по отдельной сессии, и в других статьях. Заметим, что в публикациях - статьи, связный текст, а не презентации. Это определяется форматом конференции, который, в отличии от наших - весьма жесткий, докладчику дается 10 минут на презентацию своей работы. Это, кстати, характерно и для других зарубежных конференций. Зато регламент сессии предусматривает, помимо презентаций докладов, еще дискуссии в группах по этим докладам, с фиксацией результатов.

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

P.S. Кстати, сами материалы тоже интересны, читайте. Я, когда подробнее посмотрю - напишу.

В блоге Левенчука появился очень качественный обзор Стандарты представления требований.

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

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

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

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

Во-первых, что есть сам процесс стандартизации вокруг методологий — ISO 24744 (metamodel for development methodologies). Это методологи (западные) в очередной раз резвятся. Они разочаровались в объектно-ориентированном подходе и объектно-ориентированных моделях и вместо этого придумали новую концепцию — онтологического моделирования. Объекты их разочаровали тем, что они не могут провести границу между атрибутом класса и другим классом, с которым есть отношения. А еще — атрибуты плохо отражают динамику изменений и вообще жизнь объекта. Поэтому в новой концепции нет атрибутов, равно как и самих объектов, а есть «факты».

Ну а раз такая смена парадигмы, то эти самые факты надо же как-то по-новому уметь записывать и под это дело — порождаются новые стандарты. Они хотят сделать их полностью самоописанными: ведь это — стандарт на представление знаний, а сам стандарт — безусловно знанием является, значит его должно быть можно представить в стандартной форме. Получается у них плохо, я, кстати, читая где-то на заднем плане испытал гордость за саморефлексивное ядро CustisUniversal.

Вся эта история и текущее состояние прилично освещена. Стандарт непрерывно переписывается, в новых частях — реализуются новые идеи, плохо совместимые со старыми, при этом старые части — не модернизируются, в результате, например, есть две слегка не совпадающие системы базовых типов, примеры не соответствуют описаниям и много другого знакомого и веселого. А еще — в принципе это все должно сопрягаться с ISO 24774 (life cycle management/process description) и ISO 15926 (data integration), но нормального сопряжения нет.

Что касается полезности стандарта — она сравнима с полезностью стандарта XML, или SWIFT или EdiFact. Причем тренд идет именно в эту сторону — описывается внешний формат представления, а семантику накладываешь ты сам, соответственно, всяк желающий представить свои знания в стандарте сможет для начала описать свою форму — произвольную — форму представления, а потом ей следовать. Конечно, стандартизаторы рассчитывают, что будут библиотеки стандартных форм, и никому не надо будет придумывать свою. Но я думаю, что будет как с EdiFact: Гера рассказывал, что для передачи любых документов, например, накладных там есть приличное множество форм, и если ты с каким-то поставщиком хотите обмениваться, то вы, во-первых, должны между собой договориться о конкретной форме, а дальше — каждый должен запросить своего провайдера, и это есть лишнее звено, поэтому на практике этим не пользуются… Левенчук это тоже высказывает, только по-другому, оптимистичнее. Кстати, есть другой пример — SWIFT — тоже множество форматов передачи различной финансовой информации, только когда мы делали работу с ним для Собина, выяснилось, что почему-то используется формат, где содержательных полей не хватает, поэтому многое пишется в структурированном текстовом комментарии, а вовсе не в полях.

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

На самом деле, способ однозначной фиксации — есть. Это — реализация в информационной системе. Если в информационной системе есть понятие «товарная группа» и у товара обязательна ссылка на группу, то все пользователи точно знают, какая группа у конкретного товара. При этом они могут возмущаться неправильным назначениям групп для конкретных товаров, но это уже — второй вопрос. Если они влиятельны, они могут или добиться изменения значения, и товар перейдет в другую группу, или потребовать завести еще один атрибут «товарная группа-2» и назначить его по другому, и тогда у товара будет сразу две группы. Аналогично, если система считает исполнение плана и бонусы по нему, то мы точно знаем, на сколько каждый менеджер исполнил свой план. Опять-таки можно говорить про несправедливость или дебилизм системы, факт измерения плана не изменится. Это, кстати, очень важная роль информационной системы, мне в свое время это на примерах показывал Гера и я проникся.

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

Но все это не отменяет нового тренда — онтологического моделирования, который пытается подвинуть объектно-ориентированный подход. Стоит к нему приcмотреться, вдруг он случайно похож на то, что делаем мы — тогда можно поднимать на флаг. А если нет — понимать, чем отличаемся. И, в любом случае, в основе наверняка лежат хорошие идеи. Только не очень понятно, откуда это извлечь, из стандартов точно не получится…

На просторах инета (и кто бы мог подумать - в msdn) найдена статья по сравнительному анализу различных методов выработки архитектуры - Zachman, TOGAF, FEA, Gartner. Весьма интересно. Во вводной части там отсутствуют слова, но они есть в английском оригинале. Если совсем кратко, то суть в следующем.

1. Zachman framework - на самом деле, это таксономия, то есть классификация области архитектуры предприятия на 30 клеточек (5x6), к которым надо относить артефакты, и утверждается, что в идеале все клеточки должны быть заполнены, а каждый артефакт должен быть в одной клеточке.
2. TOGAF - это стандарт на процедуру, процесс порождения архитектуры. При этом он не гарантирует качественной архитектуры в результате.
3. FEA - порождение бюрократических попыток стандартизовать структуру автоматизации для агенств и подразделений правительства США. В целом - оказалось практически мертворожденным.
4. Gartner Methodology - скорее похож на набор успешных практик, нежели на методологию или стандарт.

А в подробностях - там приведена история, основные идеи и проиллюстрировано использование каждого подхода в гипотетическом проекте автоматизации. В целом там много интересного и полезного для общего развития.

Зато - выскажу мысли, которые возникли, когда метод, процедуру делают стандартом. Ведь TOGAF, например - именно стандарт от OMG для процесса получения архитектуры. Он, правда, не гарантирует правильность и качество архитектуры. На SECR-2010 мэтр от OMG вещал про важность стандартов и начал от пожара в Балтиморе, когда выяснилось, что шланги разных пожарных машин нельзя состыковать, чтобы получить длинный шланг. Такие стандарты безусловно важны. Но когда стандартизуют процесс, то получают совсем другое - получают правила, регламентную процедуру тужения пожара. А это уже перебор. Безусловно, в тушении пожара существуют правила, которым надо следовать - какие вещества чем тушить и тому подобное. Наверняка существуют также хорошие практики, которые полезно знать. Но все это никоим образом не образует стандарта или регламентной процедуры, место стандартов тут - ограничено, в области шлангов, которые должны сопрягаться...

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

Я тут по наводке Майка Кудряшева (для тех, кто знает) обнаружил такую весьма перспективную штуку - ArchiMate. Это произведение OMG, предназначенное для описания систем в виде диаграмм с единой нотацией. В описании выделяется три уровня - бизнес, приложение и технологии, и дихотомия структуры против поведения. Есть еще две другие оси: внешний и внутренний взгляд на систему и индивидуальное против комплексного, но это менее ясно. Для всего этого сделана единая нотация диаграмм, в некотором смысле - весь UML в одном флаконе, ну - почти весь. Есть примеры использования, которые теперь принято называть best practice. Под это еще подложен язык моделирования, как же без него :) и стандарт-спецификация, но это уже не так интересно, как и в случае с UML. А вот смешанных диаграмм мне лично - не хватало. Понятно, что я все равно рисовал, используя разные символы на одной диаграмме, но теперь это можно будет делать, используя новую прогрессивную нотацию - это стандарт 2008 года :) В общем, рекомендую взять на вооружение.

P.S. Для рисования - есть шаблоны Visio

Наконец, дописал отчет по SECR-2010