Я сам рассказывал про Прозрачность движения к результату в Agile для руководства на секции управления. Может показаться, что проблема надумана, ведь и Scrum и Kanban включают средства, которые делают работу прозрачной. Но они хорошо работают только когда у тебя есть лишь несколько команд, за которыми ты плотно следишь, а когда команд становится много, то необходимо делать над ними надстройку. Особенно если речь идет о разнородной среде, в которой не все команды работают по Agile или способы организации сильно отличаются, например, о командах подрядчиков. И я собрал в своем докладе спектр методик и подходов, на которые можно опираться, конструируя собственную систему прозрачности - потому что, как обычно, тут нет типового решения на все случаи жизни, надо отталкиваться от ситуации. Как, собственно, во всех случаях - почему-то никого не удивляет, что для разработки сайта универсального инструмента и шаблона нет, а вот в области управления многие почему-то ждут универсальных решений, хотя управление ни разу не проще, чем разработка сайтов :)

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

Пост на FB Sander Hoogendoorn, keynote. Наверное, я - не релевантный слушатель, слишком много знаю. Но вот правда, совершенно не интересно слушать доклад от основ, да еще с известными образами, что MVP - это эволюция от скейта через самокат, велосипед, мотоцикл до автомобиля, а не колеса - кузов - автомобиль; что нужен roadmap, а не план; с картинкой scrum - не интересно. Во второй половине пошло немного более современное, но тоже известное. Фреймворки масштабирования, но только SAFe и Spotify из 6-7, со словами "не используйте, они сложные". Антипаттерн Red Spring - не превращайте каждый спринт в мини-проект, на котором команда выдыхается, а переходите к continious delivery, и автотесты вам в помощь. Stop doing projects. И потому - не используйте Scrum Guide. А ключевая штука - ясная коммуникация. А чем больше команда - тем она сложнее, каждый с каждым.

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

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

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

Пост на FB Илья Комса, Wargaming. У гитхаба - contitnous integration, commit - на продакшн. Есть боты, которые мониторят твиттер и при жалобах - откатывают версии. Это - круто. Они к этому идут, но есть сложности... Например, выкатка только в ночной минимум игроков - а значит если появятся проблемы утром в пик игроков, то откатить или быстро починить нельзя будет. Впрочем, они работают над тем, чтобы использовать в продакшн горячую перезагрузку модулей. И оперативно переключать режимы через feature toggles, в том числе - для бета-пользователей, платных пользователей, A/B-тестирования и откатов новых фич. А в целом, почему Wargaming рассказывает в секции frontend - потому что они часть функционала делают на встроенном браузере на основе chromium для быстрой разработки новых фич.

Пост на FB Мысль после доклада Ильи Комса. К вопросу о continious integration, за который ратовали на общем докладе как must. Фишка в том, что continious integration сейчас - лишь техническая проблема. Да, не нулевая, да, с определенной стоимостью, но - решаемая. Но при этом реальный релизный цикл для многих проектов должен быть не просто непрерывным, а управляемым. Например, у wargaming он ограничен циклом маркетинга. И надо проектировать и закладывать в процессы именно управляемый, а не непрерывный цикл, что сильно сложнее, и, если честно, я не слышал хороших докладов об общих подходах для этого. Предпочитают рассказывать простые случаи, а со сложными - пусть каждая компания разбирается по своему. Компании, конечно, разбираются - но кто будет делать обобщение опыта?

Пост на FB Михаил Шатихин. Как можно сделать контроль типов на JS? Есть хипстерские вещи - #Kotlin, #Closure. А в enterprise - #Typescript (2.8.1) и #Flow 0.69. Это на заметку авторам Kotlin - о том, как его воспринимают :) А в целом доклад - о том, какие проблемы устраняет типизация, и какие альтернативы. Типизация позволяет устранить проблемы опечаток, правильных аргументов функций, нормальный автокомплит с типизацией. А так эти проблемы вылезут только на бою, ну или надо плотно покрывать автотестами.

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

Пост на FB Михаил Шатихин. Anders Hejlsberg автор Turbo Pascal, Delphi и C#: большие кодовые базы на JS становятся readonly, а ведь их надо развивать :) И это подвигло Андерса написать поверх JS нормальный типизированный TypeScript :)

Пост на FB Михаил Шатихин. В ответ на вопрос про разные способы сборки: "У меня все быстро собирается, я даже не успеваю за кофе сходить" :)

Пост на FB Сергей Рыжиков 1С-Битрикс. Доклад о стратегии развития продукта: позиционирование без прямых конкурентов, но занимая их области как комплексное решение; суперкомфортная лицензионная политика - на компанию, а не на разработчика; многое другое. И успех - развитие только за свои, с окупаемостью за год и переходу к генерации прибыли. Важная мысль - думайте о своей аудитории и выводе продукта сразу, а не через долгого кодирования, и смотрите за стратегиями конкурентов - ее достаточно легко отследить и достроить по публичным маркетинговым сообщениям, и тогда их новые повороты не будут неожиданностью. В общем-то, мысль кажется очевидной, но ей часто пренебрегают. Я слушал только кусочек доклада, потому что в перерыве зацепился за коммуникацию. Что мне понравилось - это доклад "просто о сложном", без навороченных моделей история успеха. Впрочем, понятно, что простота - кажущаяся, вряд ли на материалах доклада можно повторить успех битрикс. Тем не менее, направления входа - обозначены.

Пост на FB Артур Бекеров из IBM. Knowledge-based Chatbots - медицинский помощник для self-assesment и для записи к специалисту минуя терапевта. Делают азу знаний, сопрягают с chatbot-платформой. В базе: Пациент - Заболевание - Симптомы, Заболевание - Части тела - Специалисты. На русском, поэтому отдельная проблема - с наполнением базы данных, на русском медицинской онтологии и связки с симптомами нет, поэтому исходниками были учебники из медицины, в pdf-виде. Которые обрабатывались не вручную, а автоматически, не только распознавание, но и выделение семантических связей для наполнения базы. Еще интересно, что многое делается стандартными решениями, проблемой проекта было наполнить базу знаний, а вот нормализация фраз пациента, чтобы по нему построить запрос к базе данных - выполняется стандартной библиотекой.

Пост на FB Иван Ямщиков. Развитие прикладного искусственного интеллекта. Великолепный доклад, обзор что уже есть, что будет завтра, что будет, но неясно когда. Из интересного для меня - что выделение объектов, связей и смыслов машины делают успешно, есть примеры обработки афиш большого театра с выделением смыслов и много другого. Успешные самообучающиеся системы в закрытых средах, которые самообучаются с нуля не зная правил, различным играм, и побеждают игроков-людей. Но вот команда на команду - пока не играют, слишком велика неопределенность, это действие в открытых средах, беспилотники, они развиваются. В будущем - естественный язык, проходящий тест Тьюринга - для полноценной коммуникации. Есть альтернативный способ - флешка в мозг, но по его мнению - будет позднее. Как и сильный искусственный интеллект, для которого, к тому же, пока нет операбельного критерия - как и для сознания и осознанности. А в заключении - 12 тем,которые можно взять и сделать, не надо исследовать. Например, голосовой душ, или словомер для детей, или офисный цветок, который по веб-камере контролирует осанку и многое другое. И темы для afterperty - что такое "умный", что такое "образ". Спасибо!

Пост на FB Уже после доклада Иван Ямщиков про развитие искусственного интеллекта у меня возник вопрос: чем он отличается от первого пленарного доклада Sander Hoogendoorn про Agile, что Иван мне понравился, а Сандер показался тривиальным? В принципе, то, что рассказывал Иван я тоже знал из разных источников. Но у Ивана оно собрано вместе, в единую карту, при чем с погружением, вернее, с наметками, для погружения нет времени. И неважно, что эти глубины не будут понятны для специалистов, и с намеченными мостиками между фрагментами карты. А вот у Сандера - были фрагменты вместо единой карты, разрозненные и в адаптированном "комиксном" виде, в котором соединения и погружения - не предполагается. Потому что комикс дает метафору, и метафоры между собой - не стыкуются, они придуманы именно для фрагмента. И целостная картина - не собирается...

Пост на FB Артем Каличкин. Почему вы думаете, что у вас Scrum, а там его нет и не надо. Доклад - борьба с идеей, что все методологии придуманы, и надо только правильно внедрить. Он еще помнит hipe RUP, когда тоже казалось, что все придумано. А сам доклад - детальный разбор внедрения методологий из позиции "делаем все, как гуру сказал, не отступая ни на миллиметр". Призыв к критическому мышлению к таким тезисам, и к отношению к методологиям как к набору практик, из которых применяешь что нужно. Подтвержденный разными кейсами проектов из собственной жизни, где применялись смешанные конструкции, адекватному проекту. Собственно, mainstream идет туда же, OMG Essence: каждому проекту - свой метод.

Пост на FB Артем Каличкин. Ожидания от методологии - в том, чтобы незрелую команду сделать зрелой, а методология только для зрелой команды - просто не нужна.

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

Пост на FB Алексей Натёкин. Откуда вырос и куда растет Data Science? Хороший комплексный обзор о том, как открытия и прорывы по разным из 5 основных направлений (статистика, математика, визуализация, data technology, computer science) с 1960-х (с ретро до открытия регрессии Гауссом в 1795) приводила к реальному прогрессу и параллельно - к смене hipe-бирочки, которую всем продают маркетологи. Такая история смены содержания и бирок.

Пост на FB Алексей Натёкин. Основная проблема - нельзя до анализа гарантировать результат от data science. Кейс - на двух очень похожих игрушках одной студии, по одной - плохо предсказывали уход игроков, зато получалось возвращать, а в другой - хорошо предсказывали, но зато без их возвращения.

Пост на FB #CodeFest Завершился вдохновляющим докладом. Александра Лысковского. Любой бизнес = IT, но ни бизнес, ни IT ещё пока об этом не знают. Об IT-шных компаниях, продающих традиционный товар и делающих вид, что там "то же самое", хотя внутри - совсем другое: Uber, Netflix, Додо-пицца, Тинькофф, Яндекс-здоровье. При этом целевая модель - не нынешняя, Uber ориентируется на то будущее, когда в такси вместо водителя будет робот, и это - 70% стоимости перевозок, а он при этом будет на первом месте. И именно под это получает инвестиции. А Netflix - это не кинотеатр, они реально анализируют поведение зрителей и учатся делать сюжеты лучше чем люди, запуск 700 сериалов в год, а в перспективе - следить за направлением взгляда и еще выстраивать сцены. И Яндекс-здоровье - это медицина, где основным диагностом будет не врач, а бот. А еще IT-шники идут и меняют другие отрасли, потому что лучше всех умеют планировать, делать распределенные команды, автоматизировать, а еще - привлекают самые большие инвестиции на ранних этапах - как Tesla, которая делает вид, что она - не производитель, а IT-компания. И IT-шники на самом деле делают это лучше других - поэтому призыв к IT - идите и меняйте мир.

В комментариях к посту - большая дискуссия о том, могут ли IT-шники поменять мир или нет.