2012-11-03: SECR, день второй
Второй день SECR-2012 был не хуже первого, и это - очень радует. Я по прежнему ходил между 5 треками, чтобы охватить побольше докладов, хотя и не столь активно, как в первый день: наверное, устал. Были пересечения по интересным докладам, из-за которых несколько хороших докладов я точно пропустил. Кроме того, я не ходил на технологические доклады, близкие к железу, и на доклады по мобильным устройствам - потому что это - не мой профиль. А там тоже было много интересного. Так что не надо думать, что мои отчеты исчерпывающе описывают конференцию.
SECR уже второй год проводит голосование слушателей по докладам, ич ерез несколько дней результаты появятся на сайте конференции, и можно будет посмотреть на мнение участников о докладах. выбрать то, что интересует - и посмотреть презентации и записи, которые тоже появятся. В этом году запись проводил Стас Фомин, так что они будут качественные.
А еще - хорошо, что организаторы экспериментируют с новыми формами, было много дискуссионных сессий. Правда, на некоторых это было похоже на телеобсуждения - спикеры говорят общими фразами, а из зала идут общие вопросы, но других действительно получились дискуссии и обсуждения темы. Этот опыт показал, что нужна более жесткая модерация таких панелей, нужно направлять обсуждение, выводить его на конкретику и прерывать холиварные темы, по которым участники из зала почему-то непременно хотят высказаться, часто просто повторяя предыдущих, и надо жестко ограничивать время самих докладчиков, оставляя для обсуждения больше времени. Но, думаю, в следующем году эти уроки будут учтены.
После этого вступления - обзор докладов. Для начала - что мне особенно понравилось.
Практический опыт применения eye-tracking для оптимизации интерфейсов и сегментации аудитории. Сергей Котырев, Umisoft Любопытный доклад о практическом опыте - оценка usability сайта на основе движения глаз. при этом испытуемым давались конкретные задания, например, скачать демо-версию или добавить новость, а они сайт видели впервые. Из очень интересного - оказалось, что мужчины и женщины сильно по-разному себя ведут, если мужчины при скачивании демо сразу обнаруживали кнопку "Скачать" - (подсвеченную оранжевым, но в углу), то женщины уходили в описание функционала, и только там, другим путем доходили до скачивания демо. А про добавление новости - там была контринтуитивная засада, для появления этой функции надо было глобально перейти в режим редактирования, и эту кнопку находили не сразу. Но! когда ее просто контрастно подсветили черным вместо серого - время сократилось до приемлемого, так что даже при не слишком интуитивных решениях можно многого добиться простой работой с выделением элементов.
Взаимодействие с архитектором из команды заказчика: cвященная война? Александр Калугин, PMARCOR Доклады Александра я слышал несколько раз, у него интересные доклады. В этот раз у него был небольшой зал и активный интерактив с аудиторией - вопросы, фиксация вариантов на флип-чарте. Кейс - заказная разработка, небольшой проект, их привлекли не как ресурс, но и как опыт. И на стороне заказчика помимо менджера был архитектор, со своим видением задачи и своей активностью. В целом это встречается достаточно часто, у ситуации есть свои плюсы и минусы, которые надо представлять, чтобы воспользоваться плюсами, сгладив минусы. Если кратко, то плюс в том, что архитектор заказчика обычно источник хороших знаний о предприятии, что особенно важно при интеграции. что с ним можно обсуждать технические составляющие решения. А минусы - в том, что интересы архитектора и менеджера проекта не всегда совпадают, а архитектор тянет в свою сторону. И у него есть свои представления о хорошем решении, которые не всегда совпадают с тем, что предлагает компания-разработчик, и с этим надо работать.
Чего хотят Заказчики?… Или особенности национальных «внедрений». Валерий Бирин, IBA На большинстве проектов есть жесткая ситуация со сроками, бюджетом, ресурсами. И если Yordan в Death March видит в этом проблему, и говорит о выживании на таком проекте, то DeCarlo в eXtreme project management видит возможности. В любом случае, на таких проектах для успеха важна психологическая и коммуникативная составляющая, и направление потока мыслей и эмоций заказчика и команды.
И доклад - о тезисах, которые он зафиксировал для сотрудников из своего опыта. Тезисы, во многом очевидные. Но от того не стали не актуальными. И он довел их до уровня памятки.
- Все заказчики хотят чтобы проект прошел спокойно. Хотя тут я бы поспорил: заказчик он же не дурак, и часто понимает. что проект спокойно пройти не может потому что сроки и деньги. А если вдруг может - значит сроки и деньги можно уменьшить. То есть он готов к жесткому проекту, и встречаются менеджеры, которые от этого получают фан. Не от проблем, конечно, но от их решения.
- Нельзя говорить заказчику, что он тупой. В принципе.
- "Вы нас считаете дураками, как мы можем с вами работать?" Как реакция на фразу в пылу спора "Ну, наше же ПО - для умных людей"
- Нельзя оценивать своих программистов перед заказчиком - хорошие, плохие и прочее.
- Заказчики - ранимые. Нельзя показать его чувствовать как ребенка, который привлекает внимание.
- Нельзя: "Я не смогу сегодня поработать, потому что есть важная задача от другого клиента"
- Нельзя: "У вас должно работать так, потому что так работает у вашего конкурента"
- В обратную сторону - тоже нельзя. Нужно собственное достоинство.
- Заказчика надо активно информаировать - что для него сделано!
- Нельзя сильно приукрашивать - надо помнить, что за свои слова надо будет отвечать.
Практика - семинар в начале проекта про взаимоотношения с заказчиком.
Если есть вопросы и истории - пишите, я обязательно отвечу. Блог http://vbirin.blogspot.ru/ (правда, это я поискал, данные из презентации я не записал, но можно там посмотреть).
Обучение коду в мире онлайн. Бенджамин Б. Бедерсон, University of Maryland Рассказывал о современном дистанционном обучении. Его идеи и те изменения, которые оно вносит в процесс, например, возможность прервать урок и продолжить с места, перейти на другую тему при непонтках, быстро заполнить ответы - они понятны. Но при этом в целом происходит переход в другое качество, и это - правильно учитывать при создании программы.
А еще при обучении компьютеру дистанционное обучение с ильно меняет картину, ддавая такие возможности как live coding. И сейчас есть множество площадок для этого.
- khanacademy.org - Live Coding
- pthontutor.com - live diagramming
Ворчуны на проекте – положительные и отрицательные стороны. Как эффективно работать с такими людьми с учетом психологического климата в команде? Владимир Железняк, Дмитрий Снисар, IT-Boost.com Рассказ - case study. Психология по конкретному поводу. По делу, поскольку проблема распространенная - интересно. Ну и докладчик - говорит живо. Да, если бы психология входила в базовую вузовскую подготовку программистов и менеджеров, то такие доклады были бы не нужны. Но у нас же это не так, только ВШЭ пытается - о чем вчера рассказывала Елена Мандрикова.
И - остальные доклады.
Как реализовать себя на глобальном рынке? Александр (Sasha) Галицкий, Almaz Capital Partners Доклад открывал день, и начало диссонировало: "слайды просто картинки, я плохой докладчик". Но в целом доклад хороший.
О том, что мир сейчас глобальный, и надо настраивать себя на жизнь в нем, код перетекает в любое место. Прерогативы на изобретение нет, во всем мире многие изобретают и повторяются. Поэтому идея - ничего не стоит, стоит - реализация. Советская наука умела делать прототипы, единичные экземпляры, а это 20% затрат/усилий.
Работа - командная, надо работать на дело, а не на амбиции. А этого - часто не умеют. В России - особенно, и как пример - в Силиконовой долине не образовалось русского сообщества, в отличие от Ирландии или Китая. Как только маячат деньги - ругаются.
Инвесторы - это сервис, который помогает вам строить ваше дело. И ваша задача - своей активностью побудить его помогать вам.
Дальше были слайды о перспективных направлениях. которые они рассматривают. Их - реально много, поэтому интересующимся - надо будет смотреть презентацию.
Управление проектами 80-го уровня, или размер имеет значение! Возможности и ограничения применения статистических моделей для управления проектом. Юлиан Ларионов, Николай Сокорнов, Reksoft. В общем-то в докладе оставляет смутное впечатление. Идет некоторое наукообразие, для меня - очевидное, которое надо решать практически, а не заботится теорией. Понятно, что есть грабли, на которые не надо наступать. Но их надо предъявлять конкретно. А то доклад получается на том уровне абстракции, который не интересен совершенно. И это - обидно, потому что за докладом точно стоит практический опыт, который был бы интересен, даже если размер там не 80-й (это для меня когда сотни человеко-лет).
Моделирование и облачные вычисления. Ричард Соули, OMG Ричард выступал на SECR в 2010, о необходимости стандартов, осознанном еще в Балтиморском пожаре (1904) :) А теперь иллюстративный ряд теперь - на множестве электрических розеток и вилок. А множество usb-разъемов, питания для телефонов и ноутов, думаю, тоже нашло бы отклик.
В общем-то, тема доклада по-крупному не изменилась - о спецификациях, которые должны быть открыты, для которых существуют реализации, и которые контролируются некоммерческими организациями. Миссия OMG. Направления, в которых сейчас идет работа над стандартами. Но, к сожалению, на мой взгляд представлены списком, без подробностей. А мне по-прежнему хочется больше подробностей, не миссии - я ее и так понимаю, а конкретики переднего края. Правда, я ушел, до конца не дослушал, возможно дальше детали были...
Разработка распределенных отказоустойчивых систем на платформе Erlang. Андрей Смирнов, Николай Сокорнов, Reksoft В общем-то учебный доклад о реализации на Eglang конкретных шаблонов в асинхронной работе, распределенной между нодами. С диаграммами последовательностей, отражающими взаимодействие. Думаю, было интересно тем, кто начал работать с асинхронными системами, не только Eglang, чтобы перестроить свое мышление, это важно.
Дискуссионная секция. Инструменты оптимизации исходного кода программного обеспечения Это начиналась как активная дискуссия при переполненном зале, а потом постепенно сдулась :( Я заходил фрагментами. Было много по делу - о guideline, который способствует пониманию кода не только из-за единообразия, но и потому, что избавляя программистов от необходимости думать о деталях позволяет им больше думать об общей организации, и она становится лучше. О различных средствах, которые позволяют поддерживать соответствие guideline. Но были и холивары, участники из зала очень хотели высказать свои мнения, иногда - и научить в дидактическом стиле.
Дискуссия. Peopleware: какие навыки и квалификации требуются для создания идеальной команды программистов Очень напоминает TV-дискуссия. Общие вопросы, общие ответы. Вот, студенты хороши в науке, но непригодны к коммерческой разработке, что делать? Ответ - комбинировать, плюс сотрудничество, связи. Но вот что спрашивающий ожидал услышать? Но, надо отметить, ответы более профессиональные, с цифрами.
Все-таки форму тут надо искать. Потому что когда люди высказываются по поводу, каждый свою точку зрения - это почти ни о чем. Все же еще политкорректны. В принципе, для этой темы формат, можно сказать, напрашивался: нарисуйте эту команды в виде конкретных человечков, ее составляющих. И менеджера, который ее собирает.
О требованиях к средствам автоматизации приемочных тестов при использовании подхода «разработка, управляемая описанием поведения». Евгений Пышкин, Максим Мозговой, Михаил Глухих, СПбГПУ Доклад про BDD и полуавтоматическое построение тестов от сценариев поведения. Авторы провели сравнение различных средств по разным характеристикам, правда, больше по описаниям и материалам, а не практически. В этой области они новички, в чем сами признались, и целью было не только показать результаты, но и получить отклик от тех, кто использует, потому как раньше на SECR тема не поднималась. Зал - откликнулся. А сама тема - новая именно для SECR, на профильной конференции SQA days про тесты от BDD я слышал в нескольких докладах.
Эволюция процессных и продуктовых метрик на основе информационных потребностей. Сенклер Якин, STM В целом доклад про эволюцию метрик в контексте развития официальных методологий. Начинали они с формальной системы, как она есть в CMMI, и там возникали искуственные бизнес-цели, а самих метрик было очень много, 52. И они эту систему творчески переработали, проведя трассировку от реальных бизнес-целей с видоизменением метрик, и выкинули много ненужного. На слайдах были примеры конкретных преобразований и они любопытны. Однако, новые метрики получались более сложные и запутанные, хотя и лучше соответствуют целям. И, что важно, дают лучшие показатели при том же процессе.
Автоматизация миграции динамически формируемых запросов. Семён Григорьев, Яков Кириленко, LANIT-TERCOM Я слушал небольшой кусочек в конце - потому что был на других докладах, так что, возможно, недооцениваю доклад. И, по-моему, я это слышал, хотя, может от другой фирмы. Перенос MS SQL -> Oracle, в системе много кода, который вызывает SQL, а запросы строятся по-разному. При этом надо было встроиться на уровень обращений к БД, не трогая коды системы (как я понял). Идея - интересная, автоматизированное преобразование, половину удалось перевести автоматом, в остальных автомат дает хорошую обертку, даже если сам запрос преобразовать не получается. И там приходится конвертировать уже сформированный запрос динамически. Реализация - порядка 20К на F#. И получился хороший рабочий результат, хотя с формальной точки зрения безошибочность гарантировать и нельзя. Подход в принципе может быть применен не только для SQL, но и для разных DSL, генерации HTML и т.п., m4, eval jscript.
Дискуссия. Сохранится ли профессия программиста? Это была определенная разрядка в конце конференции. Тем более, что на сцене были люди существенно разных взглядов. Андрей Терехов отстаивал профессию системного программиста, которому требуется хорошее базовое образование, знание алгоритмики и математики, а Стас Фомин, наоборот, говорил о том, что эти знания бессмысленны для основной массы программистов. С чем, кстати, были согласны многие, хотя и не столь явно. Были предложения посмотреть на развитие hardware - не того, которое компьютеры, а того, которое скобяные изделия - где основное производство ушло в программистов и наладчиков станков с ЧПУ, а люди с напильниками остались фрагментарно. Хотя мне эта аналогия кажется сомнительной.
Интересна классификация программистов, как это видит Павел Ходалев из Deutsche Bank
- Яйцеголовые (у них - в inhouse)
- те кто им снаряды подносят;
- Commodity
- Support
Между первыми двумя и вторыми двумя - колебания, перераспределение ответственности туда-сюда, каких-то длительных изменений - невидно.
Классификация от Стаса:
- при харде - будет жить (драйверы и т.п.)
- комп-общество (финансы и т.п.) - будет жить
- комп-человек - интерфейс, usability, тоже будут жить
- системные программисты - фреймворки, языки, параллельность - тоже, наверное, будут жить, хотя есть сомнения.
На этом я закончу отчет о впечатлениях. С надеждой, что в будущем году конференция будет не хуже, а еще лучше. Как участник Програмного комитета я буду этому всячески способствовать.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.