SECR-2014 - срез отрасли

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

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

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

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

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

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

На этом я заканчиваю общую часть и перехожу к конкретным темам, после которых будет рассказ о докладах, тоже сгруппированный по темам. Обычно я называю эту часть обзором, но в данном случае это неправильно. Я был на 25-30 докладах из 120+. Поэтому репрезентативность выборки - очень маленькая. А качество докладов - совершенно не стимулировало к переходам между ними в процессе - хотелось дослушать автора, даже зная, что параллельно идет другой потенциально интересный доклад. Плюс зал блицев был переполнен, да и в других залах люди часто сидели в проходах. Тем не менее, мне хотелось бы отметить ряд докладов, на которых я был лично. Доклады отсортированы по темам, а внутри - в том порядке, в котором я их слушал на конференции.

Кстати, по докладам сразу после конференции выложили презентации и уже начали выкладывать видео. Доступ - через сайт конференции, а обсуждать все это можно в группе на FB CEE-SECR - конференция "Разработка ПО". Собственно, видео докладов сейчас - стандарт для продвинутых конференций. В России, в мире этого нет. А на конференции все равно стоит быть лично, потому что там помимо докладов - есть живое общение, и у меня есть достаточно много знакомых ИТ-шников из разных городов, с которыми я общаюсь на конференциях. И это общение - не менее ценно, чем доклады, а может и более.

Тренд отрасли, который я зафиксировал на этой конференции - переход от споров и холиваров на тему Agile vs Waterfall к вполне прагматичному формулированию места того и другого, и управлению этим в своих проектах, определению метода, адекватного условиям. В принципе, то, что метод управления должен соответствовать проекту - это старая новость. Но людям-то хочется серебряной пули и универсального рецепта, хотя они знают, что их нет. Долгое время серебряной пулей был Agile, на западе, который трепетнее относится к универсальным рецептам, он и сейчас таков - об этом говорят и пишут мэтры, тот же Ники Мантл на конференции об этом говорил. А в России - нет. полтора года назад я отчетливо зафиксировал разочарование Agile на AgileDays-2013 и даже писал в отчете "конференция разочарованных" - про тех, кто на фронтире развития. Но с тех пор - пришло осознание и активное управление. И, что интересно, это сочетается с освоением Agile более консервативной частью, он пришел в крупные корпорации, даже банки - Альфа, ВТБ24. Это было заметно и на весенней AgileDays этого года (мой отчет).

На SECR эта тема звучала в ряде докладов, я упомяну минимум о трех: об этом говорили Сергей Дмитриев (в фойе, доклад на SECR был о другом, а про это он рассказывал на AgileDays) и Дмитрий Безуглый, а Антон Семенченко вообще назвал свой доклад провокационно: "Когда стоит переходить от Agile к Waterfall". Конечно, единого мнения - нет, но при этом авторы не ведут теоретические споры, они рассказывают о своем опыте. Все сходятся к тому, что когда в проекте нет неопределенностей, то Agile не нужен - потому что можно спланировать и идти по плану, и избежать накладных расходов, которые влечет за собой Agile. Правда, тут стоит отметить, что в ИТ-проектах помимо компьютеров зачем-то существенно задействованы люди, которые склонны преподносить неожиданности и представлять собой фактор неопределенности :)

А дальше возникает неопределенность и тут начинаются расхождения. Дмитриев говорит, что неопределенность связана с возрастанием сложности, по мере увеличения которой сначала можно обращаться к экспертам, а потом - эксперты не справляются и начинается область эксперимента. Надо "тыкнуть и посмотреть реакцию", и Agile с его короткими итерациями и практикой обратной связи для этого хорошо предназначен. А Безуглый различает неопределенность и сложность, связанную с людьми и с техникой, и говорит, что Agile хорошо борется с неопределенностью, связанной с людьми, а вот с техническими аспектами неопределенности надо бороться другими методами. При этом, что интересно, оба используют Cynefin framework статья Дмитриева, но рисуют его по-разному, и по-разному определяют место Agile там. Сам фреймворк, кстати, придумал Dave Snowden и представляют его как готовый артефакт, но Дима говорит, что в основе его лежат наработки по теории сложности (complexity) и обещал прислать мне ссылки.

В том, что Agile снимает неопределенность (даю не всю) и именно поэтому его используют - сходятся все. У Антона была интересная метафора пациента.

• Waterfall: Вы через 3 года или умрете, или выздоровете. И так - 3 года без изменений, а потом бах - и какой-то результат. Или никакого, и врач говорит "ну, еще подождите..."
• Канбан: нас никому не сбить в пути - нам все равно куда идти. Анализы все лучше, а вот выздоровете ли - неизвестно.
• Scrum - помимо пути - показывает прогресс, движение к здоровью. За это и готовы платить - накладные расходы минимум 22%, а могут доходить и до 50%.

В общем, кому интересно - смотрите и разбирайтесь. И мне напишите, если что интересное нароете.

А я хочу заметить, что практики для работы с технической сложностью, со сложными предметными областями в Agile есть, просто они не столь распространены - ибо сложных проектов меньше, чем простых. Это Domain Driven Design (DDD), разработка на основе модели предметной области, в которой практики технического проектирования сложных систем, очень развитые в IT, перенесены на аналитику предметной области и, на мой взгляд - весьма успешно. И Feature Driven Development, включающий в себя довольно сложную конструкцию управления ответственности за код програмной системы, что, в соответствии с законом Конвея должно приводить к хорошо структурированной и слабосвязанной архитектуре системы. А еще Use Case 2.0 Ивара Якобсона о которой он рассказывал на прошлом SECR (в отчете - есть ссылка на книгу). Да, распространено это меньше - не только потому что, что сложных преоктов мало, но и потому, что без этого - проще и дешевле, а негативные последствия носят отложенный характер. Но это уже вопрос выбора.

В заключение замечу, что Essence of Software Engineering (OMG стандарт, инициатива SEMAT) как раз и был создан для того, чтобы технологично работать с индивидуализированным процессом проекта, добавляя и исключая практики. При создании были проанализированы используемые методы разработки, выяснено. что в них в том или ином виде комбинируется несколько более двухсот практик, и разработан простой формализм, позволяющий такие комбинации строить представлять по необходимости. На сайте Ивара Якобсона представлена много практик - ссылка ведет как раз на страницу практик, но можно и вокруг походить, там много интересного.

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

Следующее о чем я хочу рассказать - мастер-класс Мики Мантла (Mickey W. Mantle), на котором он представлял свою книгу Managing the Unmanageable. Мики выступал с докладом и на самой конференции, в той части, которую я слышал он говорил о корпоративной культуре разработке. Собственно, Мики - яркий представитель культуры разработки софта как совершенного инженерного изделия. Таким оно было до эпохи персоналок, которые существенно снизили планку, потребовав много большего количества софта, чем было возможно создать в такой культуре. И таким остается сейчас в сложных проектах.

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

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

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

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

Да, и еще я писал про Agile. Так вот, на Западе он - стандарт де факто, Мики был удивлен малым количеством участников мастер-класса, практикующим Agile, и сказал, что если б знал заранее - то сократил эти части. расширив другие. А добавлены они были именно по опыту проведения мастер-класса, по запросу слушателей. И "никуда вы от него не денетесь". потому что как инструмент Agile, Scrum - это как раз способ работы с неопределенностью, повышения прозрачности хода проекта, а это - крайне востребовано. При этом Мики подходит к делу прагматично, его не очень интересуют теоретические основания для построения инструментов (хотя он их знает), его интересуют практики применения.

На конференции было много докладов об архитектуре и enterprise-разработке в разных аспектах. И про архитектуру вообще, и кейсы конкретных систем в банке и телекоме, и про такие аспекты, как BigData и 1С.

Понятие архитектуры и управление архитектурным проектированием. Игорь Беспальчук, CUSTIS

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

Игорь говорил о том, что работа с архитектурой в компаниях с точки зрения управляющих часто представляет собой такую алхимию. Настраивание мыслей, заклинания и прочее. Уверенность, будет ли золото, или скажет что у соседнего алхимика заклинания сильнее - неизвестно. А король ничего не может сделать - только уволить, но другой ведь - такой же будет. А золото - нужно. Потому что тема - очень замыленная, отделить архитектуру от всего остального не получается.

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

В докладе были приличное количество ссылок, паттернов и антипаттернов (правда, антипаттернов - больше). Но manage - or be managed!

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

ES6: будущее здесь. Себастьяно Армели, Spotify

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

Разработка приложений на основе DSL и генерации кода. Игорь Ткачев, Дойче Банк

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

Используется для этого Eclipse Xtext, который дает возможность описывать DSL, а потом порождает поддержку его в среде разработки - подсветку, подсказки и прочее. И проще xml и xslt. Применяется на разных платформах, например, в системе управления рисками - kdb базу, python, mathlab. И связывание всего этого ушло в DSL. За счет чего работает и сопровождение, и сильно упростилось развитие новых фич.

Проблемы такого подхода.

• Как, собственно, писать генерацию. Потому что в текстах генератора - смесь исходного и целевыого языка, и там такие плюшки, как подсветка синтаксиса или intellisense - не работают.
• Баланс ручного и автоматического кода. Полной генерации никогда не достигаем.
• "Повреждение мозга" генерацией кода. Этот стиль отличается от обычных программ. Результирующего кода может быть много. И потмо начинаешь это писать.
• Сложно убедить Заказчика в правильности подхода. Протипы, презентации - лечат.

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

Прямая выгода BigData для бизнеса. Алексей Лустин, Silver Bulleters, LLC

Доклад был о том, как влиять сервисы BigData и какой в этом можно получить профит, если у вас основная автоматизация - на основе 1С. Фишка в том, что классическая конструкция, при которой начинают с olap-хранилища, пробуют туда посадить аналитиков и строить отчеты, маркетинговые вещи, обследование целевой аудитории - катит плохо. потмоу что в Утеукзкшыу основные данные - это вовсе не обычные данные о персонализированных пользователях, это операционные транзакции. Которых немало - Алексей рассказывал про кейс, когда база данных 1С на 5Т и с вычислительным кластером и 9к пользователей. А у географически распределенного предприятия таких баз еще много, по всей стране.

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

И технически поставить это - не слишком сложно, заодно - будут освоены новые технологии, это интересно программистам. А еще - вы выведете их из узкого 1С-мира, чем повысите уровень разработки. И им интересно будет - не всем, но туда и звать правильных надо. А что полезно - он говорит, что реально смотрел, как выросла скорость разработки обычных проектов после этого.

В докладе было много информации по конкретным технологиям, на которых все это делается - MQ, например, RabbitMQ для сбора логов, Linux-контейнеры - AMPQ и LCX (AMPQ Federation). Дальше Elastic Search River JDBC - Hadoop HiVE.

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

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

Итого, задача распадается на три, и все - понятные.

• Как продать бизнесу
• Как сделать бизнес-аналитику
• Как самим посмотреть новые технологии

Быстрая разработка GUI для больших объёмов данных с использованием CQRS парадигмы. Алексей Рагозин, Дойче банк

Архитектура трейдинговой системы. Поперек современных подходов: никаких объектов, данные в реляционке плюс UI.

UI основан на pull модели и continious queries. Никаких объектов! Все забрали в in-memory реляционку на Java. И UI тоже работает на continious query от UI: если UI что-то запросил, то он получает результаты запроса в моменте и изменения в течении дня все. Запросы - linq. Непрерывная обработка данных. Унификация источников данных за счет реляционной алгебры. Но! Данных может быть много. Continious query, который передает миллион записей на клиента - не работает. Поэтому у них расширение: они на сервере знают окно просмотра (50 строчек), обновления посылаются только к ним, сдвиг ползунка фиксируется, сортировка и фильтр тоже обрабатываются на сервере.

За счет избавления от доменных объектов система стала по-настоящему переиспользованная. Логика представления - вся на UI, и они по полной использовали мультипарадигмальность C# - linq. При том, что сервер - Java. Быстрый старт разработки, простая конфигурация тестового окружения, повторное использование, производительность на сервере. Одна команда оптимизирует серверную платформенную часть на Java. И по памяти и по производительности.

Что в случае подъема сервера? Все источники так или иначе поддерживают recovery. При подъеме они выдают shapshot и потом выдают изменения. Для устойчивости - у них несколько реплик. Именно поэтому persisternt server - на уровне real-time database, а не на уровне in-memory database.

Любопытно.

Практика архитектуры предприятия в операторе связи. Александр Уланов, Yota

Очень интересный взгляд на проектирование ИТ-ланшафта предприятия сверху, в крупном. Стартовой точкой была продукт доступа в интернет от Yota. Уникальный продукт - тариф "бегунок". Вы сдвигаете бегунок скорости переключения - и тариф меняется мгновенно. За 3 секунды сигнал пролетает от сдвига бегунка через все гейты - смена тарифа, информирование контроллера сети и меняется скорость обслуживания. И это была практически полностью собственная разработка. Дорогая, 80 программистов - но за 1.5 года вывели. Александр рассказывал - за счет каких архитектурных конструкций у них получилось это сделать, управляя разработкой такого большого проекта.

• Canonical schema
• Design by contract
• Loose-coupling
• Composition and reuse
• Canonical protocol

А потом встала совершенно другая задача - вывести нового мобильного оператора. 4G Скартел + 2G/3G Мегафон. Концепция к концу ноября 2013, тестовый запуск - конец апреля 2014, продакшн в августе по 15 регионам - состоялся. Продукт стал намного сложнее, чем интернет. Делать с нуля - бессмысленно. Но зато сами продукты - типичных для для телекома и потому можно взять готовые продукты. Что они и сделали. Начали с проектирования модели данных. Схема есть, простая - сущности и связи. В предыдущем продукте была сделана приличная часть предметной области. За время эксплуатации - подключили CRM, подключили централизованное хранение персональных данных и так далее. А далее - взяли коробочные системы. Управление счетом - в биллинг, Персональные данные - стали мастер-хранилищем. PLM - оставили свой и его переработали. Потому что именно в нем - суть маркетингового предложения, гибкость. Но ареал стандартных систем - расширили и каноническое представление данных оставили. Справилась с этим собственная разработка < 10 человек.

И в заключении - 5 вспышек прекрасного, о том. что ему нравится в архитектуре.

1. Сквозной мониторинг запросов. Стандарт заголовка - корреляционные параметры, он передается. Асинхронная отсылка сообщений, система хранения и представления событий.
2. Централизованная служба уведомлений. Раньше было распределено, здесь - в одном месте, сервис. Все системы отсылают события, а она управляет всеми уведомлениями. Включая изменение провайдеров sms и прочее
3. MDM-интеграция данных клиентов. Централизованное хранение.
4. Единое окно клиента. Они это было, сейчас это остается. Один оператор может все решить - за счет того, что у оператора единый интерфейс, куда все сведено из разных приложений.
5. Аналитика - сбор и хранилище. Своевременность, точность и гибкость доступа online. Забрать не напрягая - не poling sql-запросов. а change data capture - разбор redo/archive logs. Хранилище: и реляцонная и Вертик - hadoop БД, поколоночная СУБД. В момент расчетов - отображается клиентский трафик за последние полчаса со всех базовых станций.

Апрентис: разработка без программирования. Дмитрий Завалишин, DZ Systems

Дмитрий Завалишин рассказывал про систему, которую сделал Антон Чижов. А они пару лет назад нашли, оценили, и теперь делают на ней свои enterprise-проекты. Платформа в облаке, но можно поставить локально. Много функционала из коробки - и горизонтальные, как рассылка уведомлений или разнообразная интеграция, и вертикальные, как бюджетирование. Хорошо ориентирована на разработку по модели предметной области - на уровне платформы возможность делать свои классы, из коробки есть машина состояний и ту не только делаешь бизнес-логику, но и получаешь из коробки интерфейсы и для объектов и для переходов. И очень удачные точки расширения.

Технологически очень современное и интересное: .Net, in-memory, persistent в базу данных - из коробки. И кодогенерация на лету: бизнес-классы транслируются в классы .Net с методами-переходами, и происходит это все прямо в run-time, непосредственно с изменением в базах данных. А точки расширения пишешь на VisualBasic (а если надо, то и на других .Net языках), и это линкуется на лету с остальным кодом. Существенное ограничение - пока вся обработка в памяти, сущности туда загружаются по обращению и живут там. Но пока им это не мешает...

Вообще именно за такими платформами - будущее. По моим сведениям, в Штатах сейчас происходит достаточно интенсивный процесс, когда банки и корпорации (не все, и не самые крупные, наверное) переходят от своих 50-70 систем на 1-2 облачных платформы с приличным количеством виртуальных модулей из коробки, которые можно под себя кастомизировать скриптами. А тут мы имеем не какие-то скриптовый язык, а вполне себе объектно-ориентированный VisualBasic, да еще - быстрый за счет компиляции. В общем, мне было интересно послушать.

Ключи к формированию высокоэффективной программистской культуры. Мики В. Мантл, Wanderful, Inc.

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

Заказчиков не выбирают. Stakeholder Management глазами бизнес-аналитика. Евгения Петрова, Return on Intelligence

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

Разрыв шаблона: Lean Product Management и MVP в большой компании. Илья Кузнецов, Лаборатория Касперского

Очень интересный доклад на основе разработки бесплатного security scan. Проблема - известная: для продвижения продукта приходит в голову много идей, которые делать - дорого, отклик - неясен, поэтому надо быстро попробовать. И как они это делали. Через Minimum Viable Product - MVP. Который НЕ прототип и НЕ дешевая реализация, хотя так думают многие. Прототип - (классически) проверяет технические риски. А MVP - работает на маркетинговую целесообразность.

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

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

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

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

Каждому проекту своя методология разработки. Роман Алёшкин, Acronis

В готовом продукте надо было сделать облачную версию - backup в облако. Путь развития

• Водопад классический
• Agile 1.5-2 месяца
• SCRUM 2-3 недели
• Kanban

В каждом есть свои особенности и накоплен опыт применения. О котором и был доклад. Сам проект - довольно сложный, освоение новых технологий, работает две команды.

Ретроспектива проектов (версия Норма Керта). Максим Дорофеев и Дмитрий Лазарев, Институт фасилитации

Максим как обычно рассказывал про большие ретроспективы - те, которые проходят раз в полгода-год и в которых участвует не только команда проекта, но и внешние стейкхолдеры, пользователи и смежные подразделения. Максим с Дмитрием их сейчас готовят и проводят, а потом - сопровождают до результата: интервью 2-4 недели, 3 дня ретро, 2-4 недели сопровождение. Рассказ, как всегда у Максима - замечателен. Так что смотрите видео, когда появится.

Наблюдения по большим ретрам

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

Модель льдинки. Разморозка, Перемещение, Заморозка. Чтобы изменить любую сопротивляющуюся среду - надо разморозить, потом переместить размякшее, а потом - заморозить. Этап "разморозить" - обычно пропускают. А это - самый сложный этап.

Задачи разморозки

• Атмосфера безопасности. Иначе люди не говорят о проблемах.
• Построить полную картину. Надо сложить. Типично - смотрят только с одной стороны.

Из интересного

• Как 4 слона спорили, как выглядят слепцы? Они сошлись - это что-то плоское и мокрое.
• В большинстве случаев если вы считаете человека упырем - это зайка в неудобной позе. Это основная установка Керт.

Техника: как разговаривать с интровертами? Вообще или с Вами? Реально много кейсов, когда не готовы разговаривать с менеджерами. Они используют афишинг - молчаливый мозговой штурм. Замолчали, взяли стикеры, пишем идеи и клеим. Помогает, чтобы говорить.

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

Слагаемые хорошего курса подготовки бизнес-аналитиков в среде Agile Scrum. Виктория Пилипцевич, ООО Рекленд

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

Да, Виктория говорила, что на сайте компании - есть входные тесты и маркеры. Не найдено, нашел примеры компетенций, есть ссылка на европейский фреймворк. Конечно, может, я не там смотрел (it-career.by)...

Когда стоит переходить от Agile к Waterfall. Антон Семенченко, ISSoft / CoherentSolutions

Про доклад Антона я уже упоминал. В докладе - исторический обзор пути развития менеджмента в ИТ - в интерпретации автора. Упрощенно: сначала был waterfall, а потом, в ИТ импортировали Scrum и Kanban, появившиеся в других отраслях, обернув в Agile manifest как рекламную обертку. Произошло это с персоналками, потому что выросли потребности в разработке ПО и исполнители стали некомпетентными - потребовалось научиться с этим работать.

А еще был подробный разбор функциональных подразделений и их недостатков. Их нельзя мотивировать и сплачивать. Иначе будет иррациональная цель и превосходство. Например, Мы и Ламеры. Поэтому для них нормальные методы управления - сплотить против начальства, против зама или против белой вороны.

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

Психология разработки ПО. Владимир Прус, Mentor Embedded

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

Из интересного было про обучение нейронных сетей на аттракторах. Хорошие аттракторы - заставляют прогонять тесты перед коммитом. А плохие - коммитить перед deadline. Как же формировать хорошее? Должна быть повторяемость. А повторяемость дает положительная обратная связь - которой обычно пренебрегают. Отрицательная тоже важна, она не дает сформироваться плохому - но хорошее она не формирует.

QUESTions – как получать простые ответы на сложные вопросы о проектах и продуктах. Ирина Виноградова, Лаборатория Касперского

Проблема о взаимодействии между бизнесом и разработкой. В комиксах. Бизнес: "Ну когда же?" Разработка "Раслабься". Бизнес решил попробовать эту проблему решать, создали команду экспертов, чтобы сделать для бизнесу прозрачность. Бизнес - хочет знать риски и ожидаемые сроки, online и в понятной форме. И, собственно, у них получилось это обеспечить.

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

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

Сквозной процесс безопасности, интегрированный в жизненный цикл разработки ПО: фантазия или реальность? Слава Мучник, EE Ltd

Интересный рассказ про опыт телекома. Компания EE - крупнейшие телекоммуникаторы Британии. 28 млн customer - по телефонным контрактам. 15к сотрудников, 700 магазинов. При этом вопросы безопасноссти - стоят жестко. Начинали они это все с сертификации для PCI DSS - стандарт для платежных карточек. Но сейчас у них поставлены процессы в разработке, а сертификация - только побочный эффект.

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

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

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

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

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

Методы сокращения ЖЦ цикла разработки на основе принципа Системы - Систем. Дмитрий Безуглый, ООО Системный Подход

На самом деле, основное я уже все написал в #Agile и Waterfall. А рассказ Димы - интересный и содержательный. Как всегда. Пересказывать его - занятие сложное и неблагодарное. Смотрите презентацию и видео.

[ Хронологический вид ]Комментарии