Блог:Максима Цепкова — различия между версиями

Сегодня, 21.03, прошла очередная встреча Клуба директоров по разработке, посвященная эффективности внедрения ALM. На встрече получилось заглянуть в ведение проектов крупными компаниями разработчиками - KasperskyLab, который сейчас активно внедряет TFS, ABBYY, которая использует ALM на основе систем собственной разработки на пока на TFS переходить не собирается, и других разработческих компаниях. С другой стороны, был обмен мнениями и опытом по проблемам ALM в inhouse-разработке - в банках Райффайзен и ВТБ24, в ВымпелКоме, и других. И именно этим было интересно мероприятие. Понятно, что определенная маркетинговая составляющая, касающаяся TFS тоже имеется, поскольку встречи организует Microsoft. Однако прежде всего это площадка для общения и обмена практическим опытом. К тому же то, что Kaspersky выбрал именно TFS - тоже показатель уровня решения.

В пятницу был на Enterprise Developers Conference, которую проводил CareerLab. Конференция была весьма нетипичная, участники преимущественно представляли inhouse разработку. Впечатления от конференции очень позитивные, на ней было несколько неожиданных докладов. Местами получилось заглянуть во внутреннюю кухню корпоративной разработки, которую не так часто представляют на конференциях, а еще - посмотреть на развитие тренда ALM-средств, которые предоставляет Microsoft не в виде презентаций самих средств (хотя это тоже было), а на опыте их внедрения в крупных разработческих компаниях.

Теперь подробности. Не полные - я был только на одном треке конференции, а их было два. Второй касался мобильной разработки, которая сейчас занимает важное место в отрасли, но все-таки находится вне сферы моих интересов. Пока?

→ продолжить чтение…

Конференция http://www.modelsward.org/ - International Conference on Model-Driven Engineering and Software Development - закончилась. Впечатления первого дня - здесь. Но второй день - изменил впечатления первого дня о преимущественно недоработанных прототипах или рассуждениях общего уровня от специалистов. Это просто первый день оказался так скомпонован. А во втором - пошли вполне себе нормальные доклады про модели, кодогенерацию по ним конечных приложений, а также верификацию и тестирование моделей, которые в этом случае реально нужны. И это продолжилось на третий день.

Кроме того, в конце второго дня была poster session. Она реально отличалась от стендовых докладов у нас на конференциях, аналогов я не видел и опыт можно использовать. Суть в том, что у автора есть плакат с достаточно подробным изложением идеи, а дальше - ты с ним можешь общаться, задавать вопросы. Этот формат хорошо подходит для представления новых идей и продуктов, которые в докладе объяснять не очень хорошо, потому что нужен интерактив и рефлексия по восприятию. А в таком формате - самое оно. Еще это хорошо подходит для представления идей, заложенных в большие фреймворки и inhouse разработку. В докладе этого не сделать - надо передавать много контекста, либо поднимать уровень абстракции так что получается рекламный доклад. А в этом формате основные идеи - пишешь на плакате, их видят. А в интерактиве собеседник расспрашивает о тех аспектах, которые именно его интересуют. Что интересно, на этой сессии были так же докладчики, которые делали доклад на основных сессиях - то же плакат с кратким изложением презентации, и дальше - общение. И это позволяет более подробно пообщаться с ними. У нас это во многом заменяет общение с докладчиком после его доклада, но, во-первых, ты теряешь следующий доклад, а, во-вторых, вопросы часто должны созреть. И за 1 час такой сессии пообщаться с 5-6 докладчиками - вполне успеваешь. В общем, надо брать на вооружение.

Общение на конференции - достаточно активное. Плюс, в среду был ужин, на котором тоже можно было пообщаться.

Из конференции я вынес для себя, что генерация по моделям сейчас является эффективным инструментом и ее надо осваивать. Собственно, отдельные фрагменты у нас используются, но как разовые вещи. Что характеризует ситуацию? Моделеров и генераторов реально множество. Видел сравнение из 20-30 наименований. При этом утверждается, что они работают над моделью с совместимым XMI-описанием, то есть можно использовать совместно: для бизнес-логики один, для интерфейса - другой, а диаграмму классов (например) можно свободно переносить. Наверняка есть open source разработки, от университетов - точно, их представляли. Они ограниченные по функционалу и могут быть сырые, зато в текстах, можно развивать и вносить вклад. Главное - не тотальная генерация конечного приложения, а только его однородной части. Да, казалось бы, с ней особых проблем нет - берешь и формально реализуешь. Но дальше каждое изменение - согласованные правки в 5+ местах - а это уже дорого, играет человеческий фактор. В общем, буду сюда активно смотреть.

Модели применяются достаточно широко. Конечно, это автомобильное, самолетное и прочее подобное обеспечение, которое работает на железе в жестких режимах, и где важна надежность и стабильность. Там модели были всегда. Для меня было определенной неожиданностью, что модели с кодогенерацией конечного приложения достаточно широко применяются в enterprise-разработке. Это inhouse, примером чего служит Tata. Но не только. Был доклад об испанском проекте, который первоначально делался при гос.поддержке, но сейчас решения на его основе применяются для реальных коммерческих фирм и банков. Был доклад об аналогичном мексиканском проекте. Это - что запомнилось и о чем я выяснял подробности. И это - не единичные вещи. Модель сейчас, как правило, имеет графическое представление. Но это не обязательно, бывают чисто метаданные, по которым идет генерация или интерпретация - как у нас в технологии ядра. Кстати, общаясь с заказчиками и разработчиками я это встречал и в России - и в inhouse, и в продуктовой разработке. При этом применение есть как для приложения в целом, так и для фрагментов, например, для интерфейса.

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

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

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

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

На этом все. Обзора доклада не будет - все равно подробных публикаций материалов нет. В заключении поделюсь цитатой от Oscar Pastor (University Valencia, keynote): CASE tool should help designer to solve problem instead of adding new problem - how to use it properly! Очень характерно.

Я еще 3 дня в Барселоне, буду гулять по городу. Впечатления и фотки, кому интересно - в личном блоге.

Конференция http://www.modelsward.org/ - International Conference on Model-Driven Engineering and Software Development. О моделях, поэтому и поехал посмотреть.

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

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

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

На этом на сегодня все.

Пост http://a-str.livejournal.com/524554.html говорит об обучении творчеству, и автор имеет ввиду писателей, художников и другие аналогичные профессии. Но все это очень применимо к проектированию программ. Редко кому из нас удается встретить учителя, и поэтому мы - преимущественно самоучки. И проблема легкой выбраковки - реальна. В проект вкладываешь много своего умения, он - дорог, и критика слушается очень тяжело...

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

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

Правда, требует упаковывать свои мысли в 140 символов и для меня лично - это часто сложно. Даже отдельная мысль укладываетя не всегда, надо 200-250 символов, чтобы отметить нюансы и акценты. Но вообще для меня это - интересный опыт. На SPMconf я поймал мысль, что реплики по поводу выступления хочется бросить в твиттер. Или процитировать (но это-то как раз многие делают). Но - не успеваешь, вернее, это отвлекает внимание от восприятия доклада, а это - жалко. Особенно, когда мысль не влезает на десяток символов - их-то точно можно ужать. Но, думаю, это - тренируемый и полезный навык, так что буду практиковаться. Во всяком случае. на круглом столе у меня получалось :)

А еще - хочется отметить организаторов. Геометрия места проведения была не слишком удачная, только один большой зал. Но на второй день (после второго слота) организаторы поставили у зала Б не только монитор с камеры (он был сразу), но и монитор с презентацией, и доклад можно было слушать из коридора, получилось расширение зала. Еще не помешала бы такая же конструкция (монитор с презентацией) в залах С и D, но я понимаю, что ресурсы не безграничны.

А теперь - обзор докладов второго дня, начиная с тех, которые больше понравились.

Игорь Любин, News360. Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестирования!

Великолепный доклад о проактивной позиция тестировщика.

Дальше - фактически содержимое слайдов. Я его переписал, потому что хочу иметь под рукой, а не лазить в презентацию.

1. Тестирование начинается с прихода в компанию. Вопросы на интервью.
   • Определить цели
   • Задать как можно вопросов о проекте
   • Узнать какие проблемы надо решить.
2. Горячие точки. Поговорить с ключевыми участниками, составить список горячих точек
3. Фишки. Пообщаться с командой, собирать идеи.
4. SMART-анализ целей (горячие точки, фишки). Выписать цели, выбрать цели на месяц.
5. Добиться прозрачности. TOP-5 задач на неделю. Таблица Задача, исполнитель, срок, комментарий.
6. День золотого духа. Влиться в проект. Стать junior-тестировщиком на 1 день.
7. feedback. Взять обработку отзывов от пользователей в свои руки.
8. Разделение обязанностей. Мотивация: выявить склонности тестировщиков и предложить им задачи по специализации.
9. Функциональные карты. Сделать тест-анализ по модели Объект-Действие-Параметр-Значение. Выявить основной функционал. Оценить покрытие.
10. Особенности платформы. Усилить покрытие.
11. Чит-листы (не чек-листы). Готовые проверки, их масса в сети - и не надо придумывать самим.
12. sitechko.ru. Там много готовых листов. Руководитель Наталья Руколь.
13. Понятие критического бага. Составить критерии, согласовать.
14. Критерии выпуска версии. Процесс тестирования на выпуске. Когда надо выпускать. Набор чеклистов.
15. Build Verification Tests. Составить, прогонять регулярно.
16. Волны тестирования. Соорганизоваться, продумать итерации тестирования.
17. Стратегия тестирования. Сделать документ на 1 (одну) страницу. Поддерживать его.
18. Шаблон баг-репорта. Сделать. Научить всех пользоваться.
19. Анти "Протестируйте". Организовать процесс передачи версии в тестирование. Антипаттерн: разработчик собирает билд, пишет "протестируйте" - тестировщик день нечто делал, пишет "протестировано" - получается "выпущено" и огребаешь баги. Нужны новости версии и понимание, что трогали.
20. Ежедневные статус-репорты. Ежедневно. А еженедельно - сообщать об успехах.
21. Post morten. После выпуска версии - провести анализ, выявить сильные и слабые стороны.
22. Минтуки встреч. Вести протоколы-минутки, рассылать участникам и другим заинтересованным.
23. Полчаса на автоматизацию. Выделять каждый день. Пусть одному человеку из команды. За это время - пишется один тест. И за мессяц - их уже 20.
24. Все в teamcity (или аналог). Включить запуск автотестов на регулярной основе. А не хранить их где-то локально.
25. Инженерные практики. Быть QA. Поговорить с разработчиками о качестве, об используемых практиках.
26. Roadmap тестирования. Выписать даты выпуска версий, нарисовать карту.
27. Трындеть. Никогда не кушать в одиночку. Ежедневно общаться с разными коллегами.
28. Сплотить команду. Поддерживать ритуалы в команде.
29. Начинаем рабочий день. Никогда с утра не открывайте почту! Первый час - для другого. Для разумного планирования и общения.

Михаил Субоч, ЭПАМ Системз. Построение Keyword-driven фреймворков. Это был доклад об архитектуре тестового фреймворка, воплощенного во фреймворке TAF Core. Фреймворк был создан в EPAM и выложен в open source под LGPL. Но рассказ был именно об общих принципах.

Основной принцип архитектуры - Keyword-Driven. Строгое отделение логики от реализации. Достижимо как на своих фреймворках, так и на готовых - Fitness, Cucumber. Только надо соотвествующим образом использовать, сохраняя указанное разделение. Оно дополняется отделением данных для теста от его логики. В результате получается архитектура с 5 слоями.

1. Данные
2. Логика
3. Шаги
4. Утилиты
5. объекты (ui-локаторы, таблицы БД, web-сервисы)

В презентации есть конкретная схема: Ядро, инструменты, агент для распараллеливания и запуска. И так далее.

И в конце - были общие рекомендации.

• Быстрая смерть - программирование в Excel вместо шага проверки. Нарушение разделения.
• Незапускаемые тесты бесполезны.
• Ломаем утром, строим ночью. Утром - техническая реализация, вторая половина - дизайн. И лучше эти активности не смешивать - разное мышление
• Составление сложных шагов из базовых. CreateProduct и другие подпрограммы. Чтобы вспомогательные шаги, обвязку - убирать из теста. Например, просто Login всюду, кроме автотеста формы логина. И это должно быть доступно тестировщику, а девелопер - пусть ревьюит.
• Важна независимость от технологии. TAF Core - был до Selenium. Но может с ним интегрироваться, равно как с телериком. Низкий порог входа.

Максим Гриневич, Colvir Software Solutions. Промышленный подход к автоматизации тестирования или Keyword-driven testing в жизни. Рассказ был о внутреннем устройстве тестовых сценариев для тестирования большой банковской системы. Как я понял, это касается той же самой системы, о которой накануне говорил Алексей Надененко, впрочем, я могу ошибаться.

Тесты устроены так.

• Разработчики - предоставляют стандартные операции, действия и проверки, которые представляют шаги тестирования, реализуемые как банковские keyword
• На их основе тестировщики реализуют сценарии тестирования.
• Необходимо видеть, что именно делает автотест. По шагам. Для Заказчика и руководства. При этом то, что написано должно соответствовать. И это - важное требование у них. Хотя часто автотесты воспринимают как черный ящик.
• Тестовые сценарии - в xml. Версионность и прочее.
• Для работы используют ALTOVA. Отображение и редактирование в формах. При этом - несколько видов просмотра, из которых можно редактировать ограниченную информацию.
• Верхние узлы - дают пошаговую инструкцию тестирования, и руководители ее смотрят через xml/web
• При прогоне - лежат конкретные значения. Но подставляются они - отдельно.
• По xml - генерируется исполняемый сценарий. Его не правят, при изменении - меняют исходный xml
• Тестовый план или цепочка сценариев тестирования. На вход ему готовят данные. Первый из них - готовит данные - выводит документы в нужное состояние и прочее. Пускается параллельно. Распараллеливание надо учитывать сразу, тогда оно не составляет проблем.
• Ошибки теста бывают трех видов: Данных, Автотеста и Приложения. И с этим надо разбираться.
• Начальный въезд в xml - два дня, и уже может писать, пусть ошибаясь.
• Программисты планируют устроить перегенерацию на лету, или интерпретацию - чтобы исключить хранение сгенеренных автотестов.
• Будут расширять набор стандартных операций. Пока половина автотестов через операцию "другое", но они над этим работают.
• Хочется связать автотесты с функциональностью, чтобы понимать что прогонять. Сложно, потому как структура приложения непроста.
• Текущее приложение - desktop, будет версия под web.
• Вопрос про версии. Ответ: все очень сложно, у них около 30 клиентов, каждому из которых дано право вносить в код.

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

Ирина Тузикова, Grid Dynamics. Простой взгляд на автоматизацию или Как не изобретать велосипед. Доклад о комплекте инструментов Web-тестировщика и особенностях установки и настройки их. Казалось бы, в чем проблема? Но тут - как с администрированием: у одних админов все настроено и тикает, а другие - непрерывно лечат. Так вот, были моменты, которые надо настроить сразу, чтобы не лечить потом. Может быть и очевидные, но наверняка на эти грабли наступает куча народа. В докладе упомянуты были Java, Maven, IDEA, Selenium, Thuсydides, Броузер и Web-драйвер к броузеру.

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

И остальные доклады.

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

Кстати, у Дорофеева на SPMconf была аналогичная модель, касавшаяся прогнозирования сроков завершения обработки. Тоже с обратным потоком дел от программистов в бэклог как одним из факторов. Но - посложнее (и изложена более живо).

Сергей Талалаев, Exigen Services. Oracle-based тестирование. Теория и практика. Это вовсе не про БД-Oracle. Это оракул, предсказания. Основанные на мнениях экспертов - людей, мнения которых близки к истине.

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

Так вот, Excel в данном проекте - и есть ото самый оракул.

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

Виталий Шульга, EPAM Systems. Особенности автоматизации с помощью скриншотов на платформе .NET. Дальнейшее развитие темы автоматизации тестирования приложения, запускаемого под Citrix, для которого недоступна внутренняя структура объектов и потому надо опознавать элементы по их изображению. На прошлой SQA days рассказывали об успешном использовании Sikuli для этих целей. Но дальше они захотели интегрировать эти тесты с другими своими тестами, которые для WPF-приложений. Sikuli - это Java, стыковки с .Net не получалось. Они пару недель помучились, а потом за день написали мини-движок, который умеет опознавать картинки и дергать примитивный WinAPI для мыши и клавиатуры - и дальше можно писать тесты, основанные на скриншотах, однородно с другими на платформе .Net. Там пришлось помучиться с эффективной реализацией алгоритма опознания изображения - сначала сравниваются 5 точек, раскиданных по картинке, и только когда совпали - идем дальше. А первая версия с простым сравнением - была очень долгой.

Конференция SQAdays-12 в Минске - очень удачно. Много хороших и дельных докладов. Более 500 участников и много общения. Постоянный кофе и перекус в фойе также способствует общению. А вечером - затянувшееся afterparty. И все эти замечательные штуки - традиционны для SQA Days.

Общие темы, которые были в большом количестве докладов.

• Архитектура конструкции для автоматических тестов. Наиболее полно - в докладе Лянгузова, но у других тоже звучала. Отделение тестов от данных и так далее.
• Разделение уровней тестирования: UI - бизнес-логика комплексно (API сервисов) - unit-тесты отдельных частей. Выстраивание пирамиды.
• Доклады о распространенных ошибках и проблемах. Да, это все - известные грабли. Но почему-то по ним любят ходить.
• Об организации тестирования, сотрудничестве разработчиков и тестировщиков, которое необходимо.

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

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

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

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

Телеграфные записи основных моментов, остальное - смотрите презентацию и видео.

• Библиотеки. Важно поставлять тех же версий, что и в проме. У них Мавен.
• Фреймворк. Обеспечивает отчеты. Определяет формат тестов, это надо учитывать при выборе. Обеспечивает запуск тестов. Обычно начинают с Junit, а так - Fitness и Cucumber совместно.
• У Fitness тесты - Fixture, в других - есть аналоги. Это привязка тестов к исполняемому коду.
• Тестовые данные. От тестов отделяются. Повторное использование, структурирование и систематизация.
• Окружения. Запуск тестов в разной среде - FF и IE
• Конфигуратор. В приложении обычно статические настройки. Но их не всегда достаточно. Например, при запуске тестов под виртуалками с динамическими ip-адресами может быть нужно разбираться с сертификатами и подхватывать эти адреса.
• Важно, чтобы вся внешняя среда ушла из fixture
• Менеджер данных. Тесты не должны говорить "дай мне данные из этого файла, они должны говорить "дай мне данные такого типа в таком количестве". У них совсем умный менеджер не получился, но они туда идут.
• Еще важно контролировать связи между разными компонентами, архитектура зависимостей показана.
• Пример-1. Структура каталогов. Для Java-компонентов. Это - отражение логической архитектуры в структуру реализации, и со своими дополнениями.
• Вопрос уровня тестирования. Можно работать на UI, можно на бизнес-логике. Тест нового пользователя. Запрос пользователя, которого нет - создание - проверка, что есть. Вообще говоря, этот тест можно пускать на UI, можно на веб-сервисах, можно глубже. И в идеале мы должны иметь возможность переключения уровней. В принципе, это не очень сложно - если заранее подумать. Тут что важно - если есть не UI-вход. Потому что UI не может подсунуть неправильные значения - ограничения сверху. А тестировать сервисы - надо.
• Признак нехороше архитектуры - появляются папочки "разное" или классы, которые некуда приткнуть. Я: очень правильно!

Игорь Хрол, ЭПАМ Системз. Автоматизация тестирования: почему умирают проекты? Очень хороший доклад о том, почему умирают проекты автоматизации тестирования, и как поступать, чтобы это не произошло. По его ощущениям 80% таких проектов - провальные, и его это очень волнует. А вспоминая первые проекты - сейчас он видит, что они были мертворожденные. Этим и вызван доклад.

Типичные причины провалов.

1. Запись тестов (recording). Еще 5 лет назад была книга, что это не работает. Но до сих пор продают и покупают именно это.
   • Перестает работать на чуть более сложных проектах, чем демо
   • Невозможно поддерживать по изменениям. Представьте, что recording продают бухгалтеру.
   • Простой выход - не используйте
   • Чуть более сложный: обеспечьте, чтобы работало для вашего приложения. Это доработка. И смиритесь, что когда поменялось - надо перезаписать тест, не пытаемся читать и модифицировать. И под это - заточите методику.
2. UI-автоматизация теста - медленная.
   • Потому что поднять с нуля через интерфейс - тяжело. По данным. Плюс - мы работаем через посредника.
   • Решение: Нормально пишите код. Не используйте sleep для синхронизации
   • Решение: Запускайте тесты параллельно. И сразу стройте архитектуру для этого. Включая разделение данных.
   • Фокусируйтесь на других видов автоматизации тестирования. Комплексно. UI-тесты - верхушка, а под ними - уровень бизнес-логики, API, там больше тестов. Под ними - unit-тесты (здесь: по логическим фрагментам).
3. А еще - UI-тестирование нестабильно. 2-3% fail-тестов просто потому что асинхронно.
   • Тоже не тестируйте все через UI. Я: из зала - неправда. Да, потому что там тоже может быть асинхронность
   • А еще - перезапускать после падения, и анализировать только повторные падения.
4. Слишком дорого разрабатывать и поддерживать.
   • Потому что выполняются медленно, а тестировщик - просто ждет
   • Потому что неверно выбран инструмент. Разработка тестов - тоже разработка ПО. И надо применять технологию.
   • Потому что недостаточно знаний у команды. Для хороших тестов - нужно сотрудничество разработчиков и тестировщиков, по-отдельности получается хреново.
     • Простой механизм от разработчиков, чтобы тест понимал, что все отрисовано
     • Чтобы найти кнопку попросите разработчиков добавить id, а не ищите полчаса как обойти.
   • Используйте хороший фреймворк
   • Отделите фреймворк от скриптов
5. Автоматизация не используется. И, блин это проблема
   • Мы не доверяем автоматическим результатам, лучше проверим руками. - Надо учить работать по-другому, работа с людьми. Интегрировать автотесты с ручными, в общей системе. Userfriendly: ручные писали в Excelб а тут будет какой-то xml. И запуск одной кнопкой.
   • Слишком долго и сложно анализировать автотесты. Это реально, и надо продумывать. Пример: (а) автотест упал - прогнали вручную - внесли дефект на систему при повторении, или на автотест, если ручной прошел.

Подводя итоги

• Выберите правильный фреймворк. Это - разработка
• Внимательно отнеситесь к организацию процесса и разделению обязанностей
• Налаживайте коммуникацию между командами.

Аяз Ашрапов, Fujitsu. Базы знаний на службе у IT-аутсорсеров. Про процессы ведения базы знаний в Fujitsu. Они включены в процесс работы над проектом. Между проектами идет обмен знаний, несмотря на потребность в дополнительном обезличивании для этого. Это касается, например, базы про KPI, например по времени вхождения человека в проект, эффективности выполнения проектных задач и т.п.

Про инструменты.

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

Рекомендации напоследок.

• Сделайте обязательным использование базы знаний. Чтобы в ней все было, искать в одном месте.
• Автоматизировать рутину. Ее все ненавидят. Например, поиск устаревших статей. Рейтинги. Поиск. Аудит - отчеты что плохо. У нас тут хорошо. Пример: как только в Project-сервере меняют проект сотрудника, он получает письмо со ссылками на статьи, и он - должен ознакомиться, это тоже контролируют.

По инструментам - они используют микс. Часть - требует заказчик. Используют медиавики. Где-то sharepoint.

Любовь Аверина, Ново-Плей. Пример эффективного управления тест-кейсами при помощи Google docs. Основная идея доклада в том, что Google Docs таблицы представляют собой коллективно и совместно используемый Excel. В таблицах - удобно вести тест-кейсы, но вот совместно работать с Excel-файлами тяжело. А google docs - позволил эффективно работать. И докладчица подробно показывала, как у них это сделано. К сожалению, не видя экрана (а он далеко) это посмотреть не получалось. Но я надеюсь на презентацию.

Елена Андреева, Grid Dynamics. Грабли автоматизации. Учимся на чужих ошибках. Либез по правильной организации кода. Популярные грабли. Коротко и по делу. И, вроде всем известно и очевидно. Но мусорные куски закомментированного кода при этом встречаются повсеместно. И у разработчиков тоже. Плюс - тестовые фенечки, например, логи вместо системного вывода. Великолепная фраза "Результаты проверяйте просто, иначе в проверках - будут ошибки".

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

Проблема в том, что в compile-time не достаточно информации. Например, cast object к конкретному типу. В общем случае - ошибка, но в конкретной программе архитектура может гарантировать, что на вход идут только объекты нужных типов. И чтобы преодолеть это - используют дополнительную разметку, и специальные тулы, которые, опираясь на эту разметку проверяют правильность. И таким образом можно гарантировать, что строка-номер кредитной карты по всей программе имеет правильный формат, который на входе из простой строки - будет проверен. Или поделить все строки, используемые для динамического sql на те, которые заведомо корректные, и те, где нужен контроль sql injection, и обеспечить, чтобы этот контроль был проведен до исполнения. Получаются Pluggable types, дополняющие систему типов. Как средство упоминали Checkit framework.

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

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

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

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

Еще интересно про обработку ошибок. Есть onerror, но он не ловит на загрузке страницы. А еще - вопрос хостов. Для хостов можно делать доверенные узлы - если есть доступ. Второй метод - плагин JSErrorCollector, ловит ошибки браузера. И со списком можно взаимодействовать. Но только FF.

Илья Кацев, Яндекс. Проект Роботестер Робот как тупой юзер. Умный юзер - пусть будет тестировщик. Но тупая часть работы у него уходит. Краулер - ходит по сайту. По мотивам поиска, только внутри страниц, смотреть состояния и действия. Тут важно, что страницы очень динамические, содержимое сильно меняется. И надо заполнять формы и активировать. И там еще java-script логика, активизация кнопок. В целом интересно.

Наталья Руколь, Лаборатория качества и Андрей Мясников, Undev.ru. Диалектика созидания: курс на сотрудничество. Последний доклад дня, шоу с интерактивом. Четыре миниатюры взаимодействия тест-менеджера Наташи и тестировщика Андрея. Все идеи понятные, но сценки все равно классные, особенно вечером.

Миниатюра где "все не так" и разборка с мест - что именно не так. А потом - разбор ошибок. И рекомендации по исправлению.

1. Собеседование
2. Первый рабочий день
3. Испытательный срок
4. Рутина. В последней сценке менеджер окончательно демотивировал тестировщика, а потом - уволил.

Записывать не было смысла, так - отдельные фразы.

• Нет глупых вопросов, есть глупые люди, которые не задают вопросов.
• Нечеткое задание "познакомься с продуктом"...
• Если свободного времени нет сейчас, то его не будет и потом.
• Менеджер - не чайник, потому что его нельзя выключить.
• Соответствие слова и дела.
• Завел больше всех багов - к кулеру без очереди :)

А теперь - про остальные доклады, на которых я был.

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

Михаил Матвеев, T-Systems. От ручного тестирования к автоматическому: опыт внедрения в крупном проекте. Была конкретная задача - перейти от ручного тестирования к автоматическому, без дополнительных требований к квалификации того, кто разрабатывает сценарии тестов. Ручные тест кейсы вели в Itorg. Для автоматических выбрали два продукта (от экрана далеко, поэтому не записал, но презентация - будет), один из которых обеспечивает визуальное конструирование тестов из набора шагов, а второй - генерит по этому некоторый исполняемый скрипт. Успешно.

Ольга Киселева, HFLabs. В моем коде багов НЕТ! Странный доклад. Про автотесты, которые делают большим количеством копи-пастов, и их надо вычитывать. И тесты, которые проверяют count, а не содержалку и так далее, слова правильные, но не структурировано. С другой стороны, проблемы-то воспроизводятся во многих случаях. В общем доклад про множественные проблемы плохоорганизованной разработки (тут - тестирования), и о частных решениях, которые надо обеспечивать через человеческий фактов (надо подумать, постараться...). Наверное, так бывает, но решения все-таки нужны более промышленные, процессные по-моему.

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

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

Владимир Примаков. Мастер Тест План / Тестовая Стратегия К сожалению, доклад оказался методологической инструкцией в буллетах. Без кейсов, обучение истине от скучного лектора. Жаль.

Татьяна Зинченко, Inter Technology Group. MindMap - в мире интеллектуального тестирования. К сожалению, доклад не удался - потому что не получилось поставить тулу, которая рисует mindmap вживую, потребовалось обновить Java, что затянулось на неопределенное время. А доклад был про mindmap как средство работы для тесткейсов. Лично я - это слышал и, по-моему, именно от Татьяны. С другой стороны, на каждой конференции - много новых людей и они-то не слышали :) Зато я быстро нашел сервис http://drichard.org/mindmaps чтобы рисовать через web. Сохраняет в Json, на сайте написано, что может в googledocs но не работает.

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

Была большая лекция Стива (Stephen Mann) про командную работу, во многих аспектах.

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

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

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

Кстати, дам некоторую врезку о тех самых деталях вариантах, которые упущены. Это полезно и мне самому - я их вспомню.

• Команды, ведомые лидером - не единственный вариант. Второй эффективный вариант - команды, руководимые опытным координатором. Просто он - существенно сложнее и требовательнее к составу. Согласно исследованиям Белбина, они обладают примерно равной эффективностью, и оба широко распространены. Собственно, эти варианты были сформулированы Белбиным в ходе своих исследованиях. Прочитать об этом можно в его книгах "Команды менеджеров Как объяснить их успех или неудачу" (это - первая, с нее стоит начинать) и "Типы ролей в командах менеджеров" (это - дальнейшее развитие). А две недели назад на SPM-conf-2012 я делал доклад с кратким изложением основных аспектов - что можно вложить в 40 минут. На сайте есть презентация, и скоро (в течении месяца, думаю) появится видео.
• Работать при развитии человека, конечно, надо с сильными сторонами, и надо подбирать ему позицию с адекватным кругом обязанностей. Однако, при этом организационное разделение обязанностей - штука весьма устойчивая, и важно, чтобы человек закрывал большинство аспектов определенной позиции. И если слабые стороны в этом мешают, то их надо подтягивать. Иногда можно сместить разделение обязанностей по позициям, но суть в том, что обязанности одной позиции часто сильно связаны между собой, и их перераспределение может сильно уменьшить эффективность. Можно, конечно, все организационное деление на позиции переиграть под способности конкретных людей, но это - сложная работа, потому что требует учесть много аспектов. Как в футболе - есть несколько типовых способов разделения обязанностей между игроками команды, роль игрока определяется его способностями, но слабые стороны для роли - надо подтягивать. А сделать полностью оригинальный рисунок взаимодействия могут только очень сильные тренеры.
• По Мотивации - есть разные люди. Теория мотивации Герчикова делит людей на пять категорий, в зависимости от типа их мотивации. И с разными людьми надо работать по-разному. Подробнее о теории почитать здесь, а здесь - пост практика на ту же тему (с продолжением). И это - не единственная теория. На ADD-2010 Антон Овчинников рассказывал о применении упрощенной модели Юнга для правильного донесения до сотрудников конструкции оплаты персонала.
• С формированием культуры компании проблема заключается в достаточно быстрой смене персонала в современных условиях. В основном человек работает на одном месте год, два, реже три. Привить культуру за это время - очень сложно. А дефицит кадров - не позволяет отбирать людей с учетом культуры. Плюс надо учитывать, что чрезмерная однородность - она ослабляет команду. Отчасти, ответ был дан - через формирования общей культуры в рамках сообщества, из которого набирается основной состав команды.

На этом про команды закончим.

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

Кроме того, Маданмохан Рао учил часть участников методам управления знаниями. Правда, это было без меня, подробности - неизвестны.

Так что второй день был очень креативным и практически-нацеленным. А конференция в целом - прошла хорошо и лично мне дала новые знания о работе со знаниями :) Фотки - смотрите в ЖЖ, благо блогеров было много.

Сегодня в третий раз был на KM Russia-2012. В этом году мероприятие проходило в весьма любопытном формате, и концептуально и по исполнению. Если предыдущие два года это весьма напоминало обычные конференции с докладами спикеров и интерактивными мастер-классами, то в этот раз организаторы поставили весьма необычную и амбициозную цель - свести вместе бизнес, власть и блоггеров вокруг рамочной темы управления знаниями, и попытаться заложить предпосылки конструктивного сотрудничества. Надо сказать, что с профессиональной точки зрения эти цели - далеки от моей работы, однако на форуме ожидались эксперты мирового уровня, и в частности Рон Янг, а также выступления от крупных корпораций, применяющих у нас практики управления знаниями - IBM, JTI, Сбербанк, РЖД, что для меня - интересно. И ожидания тут оправдались. А еще - было просто любопытно, что выйдет из столь разнородной тусовки.

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

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

Теперь подробнее о содержательной для меня части мероприятия, собственно об управлении знаниями. К сожалению, формат мероприятия предполагал достаточно поверхностное изложение. Доклад Рона Янга с обзором процессов управления знаниями в прошлом году был куда более глубоким и с большим количеством подробностей, интересующиеся могут посмотреть мой прошлогодний отчет. Зато в этом году в нем была дана впечатляющая картина наступления Эры знаний, сменяющей Эру информации, которая подходит к критической точке. Собственно, в IT эти изменения очень чувствуются, потому как мы тут во многом на переднем крае.

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

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

Еще было интересно узнать, как продвигаются проекты в Сбербанке и корпоративном институте РЖД, и других, о которых я слышал в прошлом году.

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

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

Это - то, что наиболее запомнилось. Другие доклады - тоже были интересны, но наложившись на информацию прошлых лет - не несли для меня существенно нового. А интересующиеся - могут заглянуть в мои отчеты KM Russia-2010 - конференция по Управлению знаниями и KM Russia-2011 - конференция по Управлению знаниями.

Завтра - продолжение.

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

А еще - был приятный для меня сюрприз, мой доклад о командах Белбина вошел в тройку сильнейших вместе с докладом Николая Фролова "Gamification" и докладом Максима Дорофеева.

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

• Инструменты для GTD из доклада Татьяны Беловой. Саму методику я представляю и легкую ее версию в целом использую. Просто у меня не так много дел, и на оперативном уровне точно обходится простым текстовым списком. Но разнообразных активностей становится больше и, возможно, уже стоит перейти на более серьезные конструкции, например, Remember The Milk. А еще - подумать об использовании EverNote для фиксации идей и материалов, мысль о том, что идею можно просто продиктовать на телефон, и она запишется, да еще с распознаванием представляется заманчивой - в метро, вечером.
• Модель для видах обучения в зависимости от контекста, прозвучавшую у Дмитрия Башакина. Я понял, что стоит оценивать и позиционировать взаимодействие с другими, в котором есть аспекты обучения, передачи знаний относительно этой модели. Без этого способы могут переключаться, а это сильно снижает эффективность.
• А еще - знания и модели, полученные из докладов Максима Дорофеева и Дмитрия Безуглого останутся у меня в памяти и в деятельности по связанным темам будут использованы. Но это не к исполнению, а просто как накопление базового уровня картины мира.
• Еще я взял на заметку опыт hack days. У нас в компании были в эту сторону идеи, но не столь оформленные, и до практического применения дело не дошло. Организовывать я лично - не готов, но поспособствовать при случае - это да.
• Доклад Марии Бондаренко привел к мысли о сознательной работе в квадранте эмоций "Восхищение" - делать неожиданные вещи заказчику. На внедрении и обучении ГБК эта практика была, Алена держала фокус: мы делали разные недорогие, но важные заказчику вещи как реакция на замечания на обучение. Но есть подозрение, что как практика - она утеряна. Стоит ее пошевелить, наверное. И подумать о том, как вписать это в процесс в рамках проекта СУПП. В принципе, ответ есть - через список хороших практик относительно этапа проекта. Они не обязательны к использованию, но, подобно спискам GTD, "если ты что-то не делаешь, то хотя бы поступаешь так сознательно".

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

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

А третье - гораздо более интересно. На этой конференции достаточно много упоминались "витамины Адизеса", причем в весьма поверхностной конструкции. Это же касается и ряда других упоминаемых схем, но их просто меньше. При этом такой рассказ можно услышать и от менеджеров высокого уровня или владельцев небольших компаний, молодых и увлеченных. И можно говорить о том, что "они просто не понимают". Но они - успешно действуют, активно интересуются новыми концепциями, применяют их в своей работе, зовут других тоже применять. И действуют успешно. Все это наводит меня на подозрение, что им - и не нужно больше. Они воспринимают конструкцию как мем, и именно как мем ее используют. И это может быть характерно для современного общества, где именно мемы служат не только средством формирования общественного сознания, но и средством координации и согласования действий структур властного и экономического управления обществом - как на уровне государств, так и на уровне мирового сообщества. Сами мемы - представляют широкий спектр, от доктора Хауса, сформировавшего у громадного количества людей, включая детей выбирающих свое будущее, представление о содержании профессии врача, и кончая экологичным обществом с гримасами глобального потепления и вреда ГМО, которые оказывают реальное воздействие на глобальную экономику и служат орудием политической и экономической борьбы. Об этом говорил Песков на KMRussia-2011, желающие могут почитать мой отчет (к сожалению, публикации я не нашел). Так вот, возвращаясь к конференции. Вполне возможно, что для более молодых, выросших в обществе. управляемом мемами, восприятие таким образом и более сложных концепций и моделей, например, модели Адизеса - органично и достаточно для эффективного применения. И именно поэтому они транслируют вокруг - именно в виде мема. Это довольно спонтанно возникшая мысль, об этом мне еще надо подумать...

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

А теперь - обзор докладов.

Начну я с замечательного, превосходного доклада Максим Дорофеев. Гигиена количественного управления.

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

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

1. Определяем цель. Цель должна быть одна, а не много - иначе ты в ситуации Буриданова осла.
2. Строим или находим модель объекта управления. Модель явления обычно содержит множество показателей, но Цель позволяет нам отделить важное от неважного, и ограничится малым числом понятных параметров.
3. Отделяем общее от особенного. Вариация показателей может быть системной, обусловленной общими причинами, и тогда надо работать с процессом управления или самим объектом. А может быть результатом влияния некоторого особенного фактора, вызывавшего провал или успех. Отличить это сложно, но есть модели. Карты Шухарта (6 сигма), критерий Бэрра, и правила Нельсона для тренда. Есть еще, но этих - хватает. А интересующиеся могут читать ГОСТ 50779.42 или ISO 8258 (если я верно списал номера).

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

Этот процесс был показан на двух конкретных примерах

1. Мониторинг срока в разработки. Цель - успеть к сроку. Модель - наблюдение за бэклогом в итеративном инкрементальном адаптивном процессе разработки. Модель была замечательно визуально нарисована! А еще - по ней есть программка, выдающая предсказание срока при загрузке среднего и среднего квадратичного отклонения по измеряемым величинам.
2. Обеспечение максимальной производительности. Модель - на основе производительности по ролям, опять-таки в итеративном инкрементальном адаптивном процессе разработки.

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

И в заключении - шедевры, записанные за докладчиком. Можно также посмотреть твиттер - народ активно постил.

• Я надеюсь, что к концу доклада кто-то поймет, что все делал неправильно. Потому что, по моему опыту, почти все все делают неправильно.
• Цифры - это то что любят менеджеры. Люди, мотивация, креатив - сложно. Зато цифры - они говорят "сколько заплатить премию Коле". А это, по наблюдениям, главный вопрос менеджмента.
• Менеджеры верят, что если недовольным премией сотрудникам показать формулу расчета, то они поверят в справедливость и смирятся.
• Менеджеры любят цифры, только цифры их ненавидят.
• Буриданов осел. Много целей для проекта - то же. Не стесняйтесь ставить ОДНУ цель.
• АвтоВАЗ. Богаче комплектация - больше приключений! Кстати, их настоящий слоган.
• Ставьте цель. Например, скорость. Да, будут ныть про качество. Но реально я не видел ни одного удачного способа сделать быстро, принеся в жертву качество. Потому что чтобы быстро сделать проект - там надо мало багов и прочее.
• Менеджеры обожают графики больше, чем порнуху программисты.
• Картинка. Человек с завязанными глазами идет по граблям - общая причина. А если одна грабля с топором - там особая причина.
• Люди-снежинки. Руки из жопы. Дорофеев вместе с сыном - автор этой метафоры. Он - рисовал, сын - увидел и назвал.
• Если к людям относиться как к идиотам, они оправдывают ожидания.
• IT - единственная область, где с костылями мы только быстрее.

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

Алексей Харюков. Hack Days в рамках компании. Результаты эксперимента. Практический доклад. Как они устроили в компании Hack Days в мае и результаты превзошли ожидания. И они повторили в ноябре. Рамка: команде надо за краткое время (2 дня) выдать идею и с нуля сделать прототип. Они делали в выходные. Результат презентуем за 10 минут, голосование тайное по номинациям: Навороченность, Завершенность, Оригинальность, Лучшие презентации, Открытие HackDays, Best of the Best.

Участники: в первом 27 чел. 8 команд из 100, во втором - 40 чел 12 команд из 120 сотрудников из разных городов. Во втором участвовали дистанционно из штатов, невзирая на часовые пояса. Идею - подхватили. Сильно меняются представления о том, что можно сделать за два дня. А еще - были сделано два проект, которые будут пускать в промышленную разработку.

Понравилось и содержание доклада, и манера изложения и представления.

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

Но именно из этого доклада я вынес модель соответствия уровней обучаемого стилям обучения

• Уровни: Начинающий энтузиаст - Разочарованный новичок - Способный, но осторожный исполнитель - Профессионал.
• Стили обучения: Директивный - Наставничающий - Поддерживающий - Делегирующий

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

Мария Бондаренко. Управление впечатлениями или как наладить контакт с клиентом. Мария в своем докладе говорила именно об эмоциональных впечатлениях клиента, а вовсе не ожиданиях. Рассказывала о модели Ожидания - Впечатления - Эмоциональный контакт - Доверие - Успех. Квадранты в осях Выполнено - НЕ выполнено; Ожидалось - НЕ ожидалось. Сознательная работа в этих квадрантах. На то, чтобы были точки "Не ожидалось, НО выполнено". Другое дело, что местами это манипуляция, и вопрос - насколько допустимо? А еще - нельзя с клиента требовать, чтобы он обязательно восхитился, тут риски. И нельзя, чтобы клиент привыкал. Об этом надо думать, но, в общем, это не повод для того, чтобы вообще отказываться от такого аспекта работы. А ряд вопросов задавали именно с таким настроем.

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

Рекомендовала книги

• Джозеф Пайн "Экономика впечатлений."
• К.Сьюэлл "Клиенты на всю жизнь".

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

Николай Фролов. Gamification или Менеджмент 80го уровня. Доклад был признан лучшим на конференции. Актуальная тема, она интересует многих. Доклад был хорошо сделан. И был геймифицирован - в процессе доклада работал сайт, где сначала надо было регистрироваться и получать очки, а потом - задавать свои вопросы, на которые докладчик планировал отвечать в конце. Правда, оба раза сайт успевали сломать к тому моменту, как докладчик планировал использовать результаты.

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

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

Только вот, по-моему, что реальный мир - это не игра ни разу. Поэтому мы имеем частное проявление старой идеи: пусть менеджеры как-нибудь экранируют реальный мир, чтобы программистам был фан. Было - через agile, сейчас - через gamification. И движение с двух сторон: программисты хотят фан, а менеджеры в очередной раз надеются на серебряную пулю, которая позволит простым образом заставлять программистов работать как одержимые. Я думаю, что ничего не получится - серебряной пули не существует. Но конкретные полезные средства и практики - безусловно появятся.

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

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

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

Павел Обод. Бизнес мышление у сотрудников IT сферы. Докладчик - увлеченный новым. Энтузиаст-новичок. Он сам это прошел и открыл, и несет в массы. При этом он - владелец небольшой компании. И честно признает, что у себя использует 15% рассказанного, но хочет - больше. А рассказ был про витамины Адизеса. И их мапинг на IT-роли в команде. И про непрерывное улучшение процесса. Про вебинары как инструмент.

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

Было некоторое количество забавных тезисов.

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

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

Валерий Бирин. Что тендер грядущий нам готовит Рассказ человека, который помогает заказчикам готовить тендеры. О правильных подходах и организации процесса, о том, как они к этому подходят. К сожалению, не попал в аудиторию: Заказчиков, которые готовят тендеры, тут нет, а разработчикам и менеджерам все-таки интересен взгляд на тендеры с другой позиции.

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

Владимир Горшунов. Смешиваем Scrum и Канбан Докладчик тролил аудиторию, а аудитория - наезжала на докладчика. Что оживляло, но особого интереса для меня - не добавляла. Потому что автор говорил о некотором виртуальном и жестком SCRUM, о котором думали, а на самом деле он не столь догматичен и его надо адаптировать под реалии, плюс местами упростить в сторону Канбан. Как пример такой псевдопроблемы: "Как заставить SCRUM работать, когда T&M а не Fixed - у нас же при этом нет Product Backlog". Я: T&M - это ж почти идеал. В общем, то на нынешнем этапе развития agile-практик мысль - очевидная. Но пока - не для всех, ибо лучшие практики развиваются быстрее, чем многие люди это воспринимают.

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

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

На этом - все.

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

На конференции - я выступал, рассказывал о модели командных ролей Белбина. В свое время мне эту книгу посоветовали, я прочел и проникся. Потому что это - качественная экспериментальная работа с командами, наблюдение за ними и выявление соответствия между позициями, которые занимают люди их умственно-психологическими характеристиками, определяемыми по тестам. И этим оно отличается от ряда других моделей, которые основаны больше на некоторой классификации деятельности, после чего заявляется: раз деятельность нужна - пусть ее выполняют. Здесь деятельность поделена и распределена не умозрительно, а на основе научно поставленных экспериментов и наблюдений. И, собственно, мне хотелось рассказать об этом людям, тем более, что модель применима для IT-команд и о ней явно пишет Йордан в "Смертельном марше". Если я вас заинтересовал - смотрите презентацию и доклад, а лучше - первоисточник, книги Белбина "Команды менеджеров. Как объяснить их успех или неудачу" и "Типы ролей в командах менеджеров".

После выступления посмотрел твиттер по своему докладу. Люди пишут заметки, как я на ноуте, только публично, в твите. Может, начать? Хотя резать на короткие сообщения - это очень сложно...

А теперь - обзор докладов первого дня, на которых я был. Начну с тех, которые больше понравились.

Безусловной звездой первого дня, по моему мнению, был Дима Безуглый. Сначала он экспромтом заменил заболевшую Наталью Руколь, прочитав доклад Кто такой менеджер продукта и что он может дать компании-разработчику. Содержание доклада сильно не соответствовало достаточно скучному названию, оно было гораздо шире и описывало роль и ответственность Product Manager и сопутствующие активности, много сопоставляло это с Project Manager'ом. Главное - что в продуктовой разработке классический треугольник Бюджет - Деньги - Сроки - сильно теряет значимость, хотя сами понятия остаются.

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

Главный рынок для IT-компании - рынок рабочей силы. Если не найдешь персонал - вылетишь. Раньше разработчики гуляли между заказной (интересно) и внутренней (есть деньги) разработкой, все. А сейчас приходят продуктовые компании. Там хорошо с деньгами и неплохо с интересно. И они ломают рынок кардинально. Единственное, часть продуктовых компаний - они не разрабатывают сами. а заказывают разработку.

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

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

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

• Что разрабатывать просто, миф потому как много фейлов и нет уверенности результата.
• Что сложно. Потому что год поучил Java - и вполне способный программист. Не то, что в космической отрасли.
• Что разработка ПО прохожа на производство. Факт - разработка ПО это только проектирование. Говорит, что статистика по миру по НИР и ОКР примерно соответствует статистике Standish group по успеху программных проектов.
• Разработка ПО - инженерная дисциплина. Факт - гуманитарная. Я: он тут противоречит предыдущему факту. Ну или надо все НИР и НИОКР объявить гуманитарными.
• Говорит, что Коберн (Коуберн?) исследовал корреляцию между успехом проекта и применяемой методологии. Обнаружил, что корреляции нет.
• Миф. Разработку ПО можно ускорить.
  • Реально есть формула расчета оптимальной длительности, и сократить можно только на 20% максимум.
  • В ответах на вопросы он формулу продиктовал. Длительность проекта в месяцах = 2.5 * корень кубический из трудоемкости в человеко-месяцах.
• Миф. Проблему можно закидать денигами.
• Миф. Проблемы решаются процессом
• Миф. KPI мотивирует
• Миф. Работу программистов нельзя измерить.
• Миф. Незаминимых людей нет. Факт: есть цена замены. Выход нового - 2-12 месяцев. Цена замены порядка годовой зарплаты.
• Миф. Программисты антибюрократичны. Факт - они антиидиотичны.
• Миф о железном треугольнике. Опровергается разработкой Word :)
• Миф: программистами невозможно управлять. Факт - управлять можно, но не как МакДональдсом, а иначе.

Позитив. Правда тоже много известных тезисов.

• Теория W Барри-Боэма. Использовать теорию корпоративных игр с ненулевой суммой. Общение, взаимовыгодный процесс и взаимовыгодный продукт.
• Выбрать правильный продукт - тот что приносит 500% прибыли, а не 10%. Ссылка на Демарко. :) Я: это из серии, что правильный человек сидит на берегу и ждет, когда проплывет труп врага.
• Правильный персонал
• Маслоу в развитии. Первые 4 уровня - дефицитарные потребности, насыщенные на 80% они перестают интересовать. А потом, верхние, самореализация - идут бесконечно.

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

• Формула E=IQ*EQ*EQ и баян про IQ и EQ
• Эшби, Введение в кибернетику 1959. Для хорошего управления число состояний управляющего объекта должно быть не меньше количества состояний объекта управления. Я: следствие: население (государства), рассматриваемое как объект правления имеет очсень малое количество состояний.
• Цикл Наблюдать - Общаться - Анализировать - Синтезировать - Пробовать - Обобщать Я: сомнительно, если честно, что цикл такой.

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

• Многие обламываются на внедрении сразу - не могут свести много своих списков в один. Не надо сразу. Главное - освободить голову от жужжания дел, а то, что в ежедневнике - не жужжит, его можно позднее перенести, работая пока на нескольких списках. Чтобы выписать все дела из головы, достаточно пары часов. Результат вас удивит - у нее получилось около 100 пунктов.
• Потом - сортировка на списки по Аллену и перенес в средство, где будем вести (если выписывали отдельно).
• А дальше - приучаем себя на регулярной основе совершать действия со списками.
  • Раз в день, 10-20 минут, просмотреть список и выгрузить лишнее из головы. Она этим занимается в метро, по пути на работу и с работы. Еще иногда внутри дня выгрузку делает.
  • Еженедельно - список отложенных и когда-нибудь. Вдруг пора переносить.
  • Еще - приучила себя ловить идеи. Задачи - о них напомнят.
• Следующий этап, ТОЛЬКО когда предыдущий пройден, списки - ведутся и с ними работаешь. Тогда делаешь приоритеты, Напоминалки, делить списки по контекстам. У нее контексты конкретного человека - "заодно спросить, уточнить".

Грабли

• Есть грабли - начинаешь беспокоиться о системе дел. Постоянно. Это неправильно.
• Излишняя фокусировка на инструменте. Он должен быть удобным, но не должен брать много мыслей.
• Сложная система связей
• Внедрить сразу
• Два списка Рабочее/Личное
• Невнятная формулировка. Ловушка для тех. кто использует outlook - кидают письмо и не пишут. что по нему надо сделать. Надо писать, не не делают.

В докладе был краткий список инструментов. Она использует Remember The Milk. Плюс задачи из писем в течении дня - в Outlook. Но по концу дня - все переносится в Remember The Milk, послать можно Fwd письма.

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

Помимо прочего фиксация дел обеспечивает, что "если вы чего-то не делаете - вы точно знаете, что именно вы не делаете".

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

Любопытная моделька по видам управления.

• Поппендик: у каждого работника должно быть два менеджера: Профессор (do things right) и Предприниматель (do rights things).
• Product Owner = Product Manager. do rights things.
• do things right - команда, а для качества возникают менторы по ролевым специализациям (программирование, тестирование)
• А scrum master - это третье, сотрудничество, фасилитатор. Do things fast.
• Нужен баланс между всеми составляющими менеджмента. Если перекос к Предпринимателю - дерьмовый процесс и продукт, если к Профессору - хорошо делаем ненужное. И так далее.

Получился хороший рассказ как работает scrum of scrum и делится ответственность.

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

• знание цели - PO
• автономность - SM
• мастерство - Mentor

Ирина Виноградова, Владимир Ли. Планируем релиз играючи. Игры не получилось, речь шла о средстве визуализации на Excel для планирования релизов, написанном под ту митодику, которая применяется в Касперском (оценка фич в разрезе ролей). Средство - хорошее и правильное, но игры - все-таки нет. А форма доклада - хорошая, местами как диалог между Product Manager и Project Manager + Team.

Александр Орлов, Слава Панкратов. Восприятие неконструктивной критики. Мастер-класс в большом зале на сотню с лишним человек. Через работу в парах, реально. Новые кейсы. Уважаю. Хотя Юра Юрченко сказал, что реальный Заказчик его троллил куда жестче, чем на тренинге, там очень интеллигентно было. Ну, не все ж с такими жесткими заказчиками работали.

Конференция Req-Labs в Киеве прошла хорошо. Есть мелкие проблемы, которые я перечислю сразу - чтобы организаторы их учли, если прочтут мой отзыв. WiFi практически не работает, так что за докладчиков - я так и не голосовал. Залы - очень длинные и экран сзади видно плохо и мелко, можно, наверное, было попробовать повернуть расположение, повесив 2-3 экрана. А еще - не хватало указателей на улице к конференции для новичков в Киеве - в парк Пушкина в первый день и к нужной двери бизнес-центра во второй. А так - организация достойная. Два трека, большие перерывы для общения. Отдельный зал для общения с докладчиками, правда там было не слишком много народа.

А главное - достойное качество докладов. Много практических докладов, мало теоретиков. При этом, что характерно, эти авторы практических докладов теорию знают на высоком уровне. Поэтому рассказ практик идет в контексте современных теорий. Или наоборот, теории сильно иллюстрируются практиками. Что на современных конференциях встречается не так часто, как хотелось бы. О ценности докладов говорит то, что я очень много конспектировал на ноуте. Может быть, кончено, что я просто был на лучшей половине докладов. Но, с другой стороны, лучший по итогам голосования на facebook в день конференции докладе я пропустил. Это "Бизнес-аналитик или бизнес-синтетик? Или как сделать бизнес-анализ чуть менее унылым" Артёма Сердюка (ISM Ukraine, Украина), который шел параллельно с докладом Пола Тернера. Буду будет смотреть видео.

Что интересно - организаторы говорят, что при организации Конференции были воплощены многие идеи, высказанные участниками мозгового штурма на мастер-классе в рамках AnalystDays в Минске.

Дальше - краткий обзор докладов.

→ продолжить чтение…

Второй день 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

1. Яйцеголовые (у них - в inhouse)
2. те кто им снаряды подносят;
3. Commodity
4. Support

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

Классификация от Стаса:

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

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

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

Нескромно начну с доклада от нашей компании Трансформируем автоформы в качественный интерфейс с помощью DSL. Иван Гаммель, CUSTIS. Предметом был достаточно оригинальный подход к построению интерфейсов, промежуточный между автоформами и ручным созданием: сначала порождаем автоформу на основе метаданных. которые и так обычно имеются, например, за счет применения ORM, а затем - трансформируем ее к хорошему виду с помощью DSL. Автоформа порождается в динамике, поэтому если модель изменилась - то изменения подхватятся автоматом, править надо будет только тогда, когда изменения затронут модифицированную вручную часть. Зал - слушал с интересом. Несмотря на накладку с головным микрофоном - докладчик не смог одеть, он не налез, и пришлось держать в руках - звук был очень тихий.

Новые языки программирования для JVM: Kotlin и не только. Светлана Исакова, JetBrains - самый яркий доклад первого дня. Вообще про Kotlin я слушал на ADD-2012, так что идеи мне известны. Но они интересны, так что я пришел послушать- и не ушел. Сначала смутила эмоциональность, она внушила ложное впечатление поверхностности доклада. Но оно быстро ушло - рассказ был хороший, структурированный. А языки, о которых шла речь - докладчица знала хорошо и уверенно отвечала на сложные и с подколками опросы зала.

А сама идея Kotlin - это язык для индустриальной разработки на Java-платформе, включающий все преимущества, которые появились в современных языках (C#, Scala и др), и которые в Java отсутствуют. Нацеленный на легкость чтения кода, потому что при коллективной многолетней разработке код больше читаешь, чем пишешь, при чем это чужой код. Полностью совместимый с Java и JDK в обе стороны - чтобы на нем можно было писать новые функциональные куски в старых проектах. Но обладающей отличающейся системой базовых типов, исправляющей косяки Java, например, решающий проблему null pointer и неизменяемых коллекций на уровне статического контроля.

В докладе не только рассказывали про Kotlin, но и сравнивали с альтернативами - Java8, Groovy, .xtext, Ceylon, Scala. Собственно там и было много вопросов, и ответы были - со знанием фактуры и деталей, свидетельствующие о профессионализме.

Язык доступен в OpenSource как prerelease, JetBrains планирует сначала использовать внутри, а потом выкладывать 1.0, но даже внутреннее использование пока не началось, увы. Ждем.

Интересные доклады

В первой половине дня очень большой интерес вызвали доклады про Agile, они были в переполненном зале, правда не самом большом - тот в это время почти пустовал, это не угадали с интересом с докладом, быть может, считая что тема agile - поднадоела. Так вот, это не так. Доклады:

• Epic перехода к Agile. Павел Ходалев, Deutsche Bank
• SCRUM vs. СКРАМ. Как вести Scrum-проекты с российскими заказчиками? Илья Блаер, First Line Software

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

Павел Ходалев в своем докладе ответил на основной вопрос - зачем он внедряет agile. Главная причина - он так сокращает свои издержки как менеджера. Ему важна прозрачность работы команды, а agile ее дает. А еще - руководители команд рассказывают ему о проблемах, и он по опыту знает, что многие из них решаются внедрением определенных agile-практик - и советует их руководителем команды. В вопросах спрашивали, есть ли у него в подчинении не agile-команды. а, например, waterfall. Ответ - есть, и они требуют очень много его времени, он много с ними общается, чтобы понять, что все-таки там происходит. А идеи распространяются быстро, как вирус. Но внедряются тяжеловато. Процесс идет, Epic - не зря, еще года на три по его оценкам.

Илья Блаер рассказывал, как быть с теми проектами, которые по отношению заказчика и процедуре не являются agile - тендеры, документация, ГОСТ и так далее. Практики - в принципе известны, proxy product owner и другие, и докладчик говорил о конкретных вариантах применения. Важно, что First Line Software - применяет agile на таких проектах, его преимущества больше, чем дополнительная работа по адаптации.

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

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

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

Еще важная идея - про культуры (control, collaboration, cultivation, competence). Реально культура должна быть сбалансирована. Agile тяготеет к collaboration и cultivation потому что их не хватает крупным организациям. Но чрезмерно - тоже вредно. И надо правильно заходить, например, если control-культура, то стоит говорить про burndown chart, как инструмент этого, а collaboration - оно само появится из соответствующих практик, его не надо продавать.

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

Эффективная разработка сложных облачных бизнес-приложений. Михаил Щелконогов, Acumatica. Интересный доклад, жаль что я пришел в самом конце. О разработке платформы для облачных enterprise-приложений, поверх MS. С девизом: используйте только базовый уровень библиотек, всю надстройку типа MVC - делайте сами. Иначе с очередного релиза у вас все рассыпется. Выбрали MS потому что там уровень ядра - развивается согласованно и централизованно, в отличие от Java, где пришлось бы использовать библиотеки от нескольких вендоров, и они бы рассыпались с новыми версиями. Сторонние библиотеки - не запрещены, но не в ядре, а в функционально изолированных фрагментах. например, построение графиков - они перешли уже на третью библиотеку, и без проблем. В целом обеспечить устойчивость им удалось.

Организационная метрическая программа: Как избежать измерения среднего цвета фруктов. Елена Беляева, Александр Бабкин, Motorola Mobilitу. Хороший доклад, в отличие от вчерашнего рассказа Кертиса про метрики - современно и по делу. Про то, как строили систему метрик, пригодную для весьма разнородных проектов Моторолы. Пока делили по типу проектов - число метрик сильно возрастало. Поэтому они перестали сравнивать проекты по типам. Выделили активности в проектах по типам деятельности, например, разработка фич или тестов; Запуск тестирования; Автоматизация тестирования; Bug fix; SCRUM как отдельный вид проектов :) И для каждой активности - использовали свой базовый набор метрик. Если активностей в проекте несколько -применяют все метрики. От базового набора - можно расширяться. Если базовый набор нельзя собрать (например, доисторический трекер) - обоснуйте. Надо будет посмотреть слайд с примерами метрик - на предмет идей практического применения у себя.

Размышления о программировании: от Аристотеля к Витгенштейну. Сергей Архипенков, Гильдия менеджеров программных проектов. Я слушал только конец - потому что был на рассказе про метрики в Мотороле. Сергей говорил о том, что ООП - он концептуально моделирует мир статических объектов Аристотеля, и этим ограничен. А правильно использовать более сложные концепции, в частности онтологию Витгенштейна. В целом идея понятна, о движении от объектных подходов много пишет пишет Левенчук, правда он опирается на более современные конструкции - ISO 15926 с факт-ориентированным описанием мира, современные направления лингвистики и философии, работающие в практической плоскости, для примера можно почитать это. Но у Сергея все это - гораздо более приземленно на программистские реалии, и в целом - более понятно.

Оптимизация защиты изобретений в программных продуктах. Дмитрий Платонов, Центр Интеллектуальной Собственности «Сколково» Неожиданно для меня, весьма содержательный доклад о патентной защите программных продуктов и связанных проблемах. Много конкретики и историй, хотя и зарубежных - но я только кусочек слушал. Полный зал, хотя и небольшой.

И кратко про остальные доклады, которые я слышал. Докладчикам же интересна обратная связь :)

Разработка ПО как бизнес — прошлое, настоящее, будущее. Аркадий Добкин, EPAM Systems. Вступительный доклад на открытие конференции. Это мог быть замечательный доклад. Но не получилось, сначала было слишком много цифр и статистики, причем не впечатляющей (6% роста отрасли - о чем оно), потом был рассказ про историю компании, это было веселее и более содержательно.

Отсылка к книге Yordan Decline and Fall of the American Programmers - которая подтвердила решение делать собственную компанию - очень интересно. Потому что это частный случай концепции посткапитализма, как общества, в котором конкурентное преимущество Запада обеспечивается знаниями, которые невозможно скопировать, об этом рассказывал Рон Янг на KMRussia-2011 (мой отчет). Думаю, надо будет почитать.

500-700 человеко-лет, вложенных в собственную экосистему - впечатляет.

Но все-таки, рассказ был не слишком системным. Я уверен, что тот же материал можно было подать гораздо лучше. Отдельных фактов.

Борьба за микросекунды. Дмитрий Труб, Deutsche Bank. Разочаровал. В 2010 на банковском дне SECR я слушал доклад Алексея Сприжицкого на эту тему. там было хорошее сочетание достижений и технологических аспектов, которыми это обеспечивалось. У Дмитрия технологий не было совсем, а без них достижения - не слишком интересны.

Прототипирование финансовой системы рассуждений для принятия решения о выдаче кредита. Юрген Хёнигл, JKU. Идея - понятна, выдавать решения на основе предыдущих кейсов. При этом используется открытый движок Waikato Environment for Knoledge Analisys? и это - тоже интересно. Но пока все это - лишь прототип.

Аналитический модуль автоматизированной системы управления инкассации коммерческого банка. Иван Кауров, DeCoSp LLC - реально только пополнение банкоматов. Уже вроде достаточно проработанная система, но пока - тоже не внедрена, и конкретного заказчика - нет. А идея сама по себе не слишком сложная - взять прогнозы, учесть остатки.

Командная разработка современных приложений с Visual Studio 2012. Александр Яковлев, Microsoft. Практически демонстрация TFS, в общем-то для новичков. Таковых среди слушателей было много, так что доклад, думаю, востребован. А я - так, зашел в серединке.

Взгляд со стороны на проблемы интеграции ПО в Банковском секторе. Александр Аристов, Auriga. Тоже кусочек. Понятный доклад об особенностях банковской разработки, взаимодействия с заказчиком - не только про интеграцию. Я это знаю, мы с банками работаем, но тем. кто не работает - наверное, интересно. В противоположность Дойчу, у Auriga нет SCRUM, XP и другим экспериментам. Промежуточные демоснтрации рулят, а остальное заказчик не понимает.

Круглый стол по электронной коммерции. Модератор: Адриан Хенни, EWDN Получилось кисло. Статистика, с повторениями - в стиле западного телевидиния для тупых :) Про великие перспективы российского рынка. Они - есть.

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

Поставка решений по дисциплинированному Agile в двух словах. Марк Лайнс, Scott W. Ambler + Associates. Рассказ - по книге Disciplined Agile Delivery, некоторая комбинация разных методов, ничего существнно нового. И мне - не понравилось, потому как теория - она известна, а сам рассказ - длинный на каждом слайде, не впечатляет совершенно, увы.

Однозначная интерпретация JSON. Милослав Средков, Sofia University JSON становится более и более популярным - много лучше XML. Но с ним есть неоднозначности по реализации. Они проанализировали спектр реализаций, и дают результаты, в том числе - выделили некоторое ядро. Вообще это забавная гримаса современного мира - ученые начинают изучать артефакты программирвоания подобно тому. как раньше изучали объекты неживого мира.

Круглый стол Российские компании-разработчики ПО в свете мировых трендов ИТ-рынка Интересно, потому что участники - руководители ведущих компаний. Но мутно, они были не слишком готовы к обсуждению темы.

Психологическая подготовка программных инженеров: миф или реальность? Елена Мандрикова, ВШЭ Рассказ о курсе ВШЭ, где они преподают программистам психологию. Там индивидуальная психология, взаимодействие, организационная психология. Учат анализировать фильмы, видеть в них шаблоны поведения, конструктивно давать обратную связь и так далее. На западе - есть, норма. У нас - они первые, и они - молодцы. Но как доклад - оно мне показалось не очень интересным.

Сегодня прошел день тренингов на SECR-2012 и я был на курсе Билла Кертиса "Современные методы измерения программных продуктов и процессов разработки ПО". Я пошел не него, потому как различные метрики для отражения хода разработки активно применяются сейчас и реально обеспечивают эффективность. Об этом рассказывают практики, в качестве примера можно привести доклад Максима Кузькина из Parallels Использование метрик в разработке ПО на прошлом SECR. B хотелось узнать, что думает по этому поводу современная наука.

К сожалению, меня ждало большое разочарование. Потому что рассказ был совсем не о современных методах измерения, а о классике времен становления CMMI, 90-х годах уже прошлого века. И основной массив графиков и историй был из той эпохи, когда была надежда обеспечить предсказуемость процесса разработки и успех проектов за счет регламентных процедур. включая различные измерения. Реальный результат, который был достигнут в то время - это осознание необходимости различных практик раннего обнаружения дефектов в виде проверки требований, design review, code review, раннего тестирования и многих подобных. Раннее обнаружение дефектов было показателем хорошего процесса. А метрики - ориентированы на мониторинг этого, включая сравнение различных проектов - для чего применяется нормировка по числу строк или другому измерению размера проекта.

Под это тогда была разработана определенная теория. А дальше она - законсервировалась, принимая новые понятия, методики и подходы разработки исключительно с целью обеспечить свое псевдосовременное брендирование. Поэтому число use case, story point, functional point - это просто альтернативные способы изменения размера, и вы можете мерить в них, а не в килостроках. А Lean - ну это процесс непрерывного мониторинга показателей (мы всегда говорили, что это нужно!), и их улучшения. И Lean излагается со ссылкой на книгу Поппендик (2007) и иллюстрируется графиками 1995 года. А Agile - это просто когда проект состоит из итераций, каждая из которых - отдельный проект. Список можно продолжать. При таком подходе новые идеи - неизбежно упрощаются и выхолащиваются, увы.

Надо отметить, что это - системная проблема, присущая части современной IT-отрасли, связанной со всякой стандартизацией и сертификацией. Достаточно почитать SWEBOK 3 версии (2004) и PMBOK 4 версии (2008), которые формально вписали agile в старый водопадный процесс, без реального согласования коротких итераций, практически непрерывности процесса, со старыми фазами. Кстати. у Билла на слайдах agile culture - это CMMI-5. Биллу задавали вопросы о том, изменилось ли что в мире, почему графики и примеры столь старые. В его мире - не изменилось.

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

Это же относится к статическому анализу кода, который измеряет интеллектуальная тула CAST (где Билл - Chief Scientist). Она анализирует код почти на любой платформе и ищет дефекты. Только, опять-таки, эти дефекты - из прошлого: buffer overflow, sql injection и подобные. Не в том смысле, что в современных разработках они не встречаются, а в том смысле, что сейчас их надо не измерять, а устранять, и там, где для этого есть желание - этот процесс организуют. Плюс современные платформы и фреймворки - просто обеспечивают на базовом уровне, в них проблемы статического анализа и сложности кода возникают совершенно на другом уровне - сложные generic-классы, лямбда-выражения с замыканием и тому подобное. B вокруг этого - разрабатываются современные средства, хотя они - четко не успевают за развитием мультипарадигмальных языков.

Однако, такие мероприятия напоминают нам о реальном мире и отличительных особенностях его устройства, в частности бюрократизации. Кроме того, из подобных обзорных докладов можно извлечь пользу в части взаимоотношений с бюрократизированной частью мира, особенно выступающей в роли заказчиков - крупных государственных или коммерческих структур. Например, продажа рефакторинга и реинжиниринга, который вроде как не имеет business value. На самом деле, в этом случае имеет место быть Real Option Valuation: вложи сейчас 100 рублей, чтобы не вкладывать через год 300. Правда. 300 еще надо показать, но это уже ловкость рук и никакого мошенничества :) Или метафора технического долга (technical debt) - способ объяснить менеджерам и финансистам, почему низкое качество кода является проблемой, подлежащей решению путем рефакторинга и реинжиниринга.

А еще - широкий и относительно плотный обзор на высоком уровне даже не концепций, а ключевых слов, мемов в их взаимосвязи - является полезным. Он добавляет в твой арсенал те концепции и ключевые фразы, которых там, возможно. раньше не было, например, концепцию Application Health, которая дополняет (должна дополнять) концепцию Business Value, и объясняет, почему работа над качеством - вовсе не waste и muda, а необходимая и полезная деятельность. На сей позитивной ноте я закончу свои впечатления о курсе.

Поднятый недавно пост Стаса Блог:Стас Фомин/2010-07-02 Бибичев жжот! (Стас туда дописал ссылки и он поднялся в вики-форуме) навел меня на забавную аналогию. Взаимоотношения гиков и менеджеров напомнили мне взаимоотношения певцов (музыкантов) и их продюсеров. И певцы и гики отличаются коммуникативными особенностями разной степени, с которыми менеджерам и продюсерам надо работать. А еще - отличаются талантом, который, собственно, и обуславливает стремление менеджеров с ними работать, не смотря на эти особенности. А дальше - понятно, что продюсер (менеджер) делает многокритериальный выбор. Учитывая талант и потенциальную выгоду, учитывая свои накладные расходы, учитывая возможность получения аналогичного результата от менее талантливых, зато менее особенных творческих людей.

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

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

Какая-то такая конструкция получается...

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

В пятницу Microsoft проводил P&P Summit, посвященный разработке под Windows8, а накануне прошло заседание клуба IT-директоров по разработке, на котором также участвовали докладчики P&P от Microsoft - Эухиньйо Паче, Кристофер Бенаж, Блейн Вастелл. Впечатления от обоих событий я расскажу в этом посте.

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

А, кроме того, и это, на мой взгляд, самое ценное - в беседе участвовали докладчики из Microsoft, которые делились устройством разработки и практиками у них внутри. У них - agile и он разнообразен, и ответы были достаточно конкретными, с подробностями как вариаций практик, так и основаниями для этого. А посмотреть внутрь ведущей компании - это очень интересно и полезно. И, надо сказать, MS расценивает agile как средство обеспечения быстрой и качественной разработки, и ставит перед собой амбициозные задачи, исходя из этого. На будущий год эта задача - перейти от 2-летних релизов Visual Studio к квартальным, и она поставлена достаточно конкретно, в виде roadmap проектов - их на следующий день показывал Эухиньйо Паче на пленарном заседании.

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

Во-первых, это VS ultimate с многочисленными архитектурными средствами проективрования и, что важно, средствами контроля за соблюдением этой архитектуры. А также средствами трассировки архитектурных артефактов в work items, что позволяет прослеживать их реализацию, а потом - позволяет найти соответствующий им код. Об этом рассказывали на прошлом заседании клуба директоров и были доклады на P&P. Конечно, VS ultimate стоит бешеных денег (300К рублей за 1 лицензию). Но, она не нужна всем - только архитекторам, а, по моим ощущениям, средства, заложенные в нее позволяют одному архитектору успешно контролировать разработку достаточно больших проектов, группой 30-40 человек, и если рассматривать стоимость в этом контексте, то она уже не выглядит запредельной. Кроме того, при успешном применении может существенно повысится эффективность разработки и снизится требования к квалификации части исполнителей.

Правда, следует подчеркнуть важную оговорку - VS ultimate лишь может это сделать, а вовсе не обязательно сделает - потому что дальше вопрос применения, организации процесса и разделения ответственности, которое заведомо представляет собой непростую задачу. Это - лишь средство, а не серебряная пуля. Тем не менее, MS играет всерьез и в июне получил первое место в магическом квадрате Гартнера для ALM-приложений, оттеснив с него IBM с линейкой Rational.

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

Второе принципиальное изменение местности, которое стоит на пороге - это сам Windows8. Здесь, помимо многочисленных технических докладов P&P о различных аспектах разработки, надо отметить доклад Константина Кичинского "Шаблоны дизайна новых типов приложений", в котором были не только общие положения, но и примеры, хотя не так много, как хотелось бы. А пример, если он противоречит тому, как ты каждый день поступаешь - хороший побудительный мотив для изменения мышления, в отличие от общих положений, с которыми куда легче прийти к согласию. Так вот, принципиальное изменение hardware состоит в том, что сейчас имеется непрерывная линейка устройств с диапазоном экрана от 5 до 30 дюймов, при этом больших экранов может быть несколько: смартфоны, планшеты, нетбуки, ноутбуки, десктопы. И эта линейка плохо кластеризуется, она непрерывна - шаг размеров экрана 1-2 дюйма, возможности тоже нарастают постепенно, просматривать почту, документы, интернет можно почти на всех, и с тем или иным удобством можно редактировать, использовать офисные приложения. И, самое главное, один человек в течении дня переключается между устройствами: на основном месте работает на десктопе или ноуте с подключенным большим экраном или без него, на совещание берет маленький ноут или планшет, где-то пользуется смартфоном - и набор любимых устройств у разных людей тоже различается. Все эти конструкции освоены не только IT-шниками, менеджеры всех уровней, включая топов, тоже ими пользуются. И потому задача разработки корпоративных приложений, создания корпоративного IT-ландшафта предприятия, способного успешно работать в столь гетерогенной среде, становится все более востребованной.

И MS в Windows8 делает два шага в этом направлении. Он радикально меняет шаблон приложения, переходя от классических десктоп-приложений к web-образной верстке, включая горизонтальные перемещения и многие наработки, примененные сейчас в планшетах. А, вдобавок, он, по-сути, объединяет web и desktop разработку, позволяя разрабатывать desktop приложения на HTML5 и JScript. При этом, пока ты используешь его шаблоны, библиотеки и следуешь его guideline, ты можешь быть уверен, что твои приложения будут более-менее адекватно работать на всей линейке устройств, пусть под Windows8, независимо от управления тачскрином с жестами, мышью, клавиатурой, документы и формы можно будет напечатать и так далее. Да, нестандартные решения будет сделать сложно, guideline наверняка будут жить и меняться, и в новой версии best practice может таковым не оказаться - но это нормальная жизнь. Зато ты получаешь достаточно много типовых решений с низким порогом входа, включая достаточно сложные конструкции, типа асинхронных решений, провязываемых в цепочку вызовов. Докладчики из MS показывали это в течении всей конференции, демонстрируя много примеров кода.

Надо отметить, что последние несколько лет отрасли прошли под знаком интенсивного развития web-разработки. И достижением были не только крупные проекты, но и повсеместная разработка, включая достаточно сложные заказные сайты. Это в целом научились делать быстро, дешево и удовлетворяя потребности клиента. И реализация в Windows8 шаблона приложения на основе web-образной верстки с реализацией HTML5 + JScript потенциально открывает этим компаниям дорогу на рынок desktop-приложений. А вместе с архитектурными возможностями VS ultimate, вполне возможно, позволит достаточно быстро и дешево делать корпоративные приложения среднего размера, при чем с эффективной интеграцией с другими приложениями на той же платформе за счет заложенных базовых механизмов, типа Windows Azure Service Bus. Реализуется ли эта возможность, пока, естественно, никому неизвестно, но она видна.

В свете всего этого мне очень интересна реакция мира Linux-Android-Java на такое развитие. Возникнут ли там какие-либо альтернативные подходы, или будет продолжаться лишь догоняющее движение. Потому что переход к desktop на html5+JScript потенциально (при условии, естественно, реализации соотвествующих библиотек и фреймворков) может дать новое дыхание нынешней серверной Java-разработке с web-клиентом, которая очень распространена - клиентом сможет стать уже desktop-приложение, но разработанное в аналогичном русле. Что будет с рынком Android-планшетов, если MS реализует-таки свою идею однородной работы с приложениями под Windows8 на всей линейке hardware? Вопросов тут много. Но про ответы и тренды лично мне пока ничего неизвестно.

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

• Сейчас активно идет разработка библиотек WinClient, в это - вкладываемся. Если делать это без учета Windows8, то срок жизни таких конструкций будет крайне невелик, они умрут не успев родиться. А, насколько я представляю, радикально в сторону Windows8 - не смотрят.
• Следует трезво оценивать перспективы альтернативной платформы на Java с desktop-клиентом, которая сейчас развивается в отдельных проектах. Существующие фреймворки desktop-приложений на Java практически не развиваются несколько последних лет, и потому их можно расценивать как технологии вчерашнего дня. Создание новых фреймворков для desktop-приложений если и произойдет, то явно не быстро. С другой сторон, вполне может оказаться жизненной конструкция, при которой Win8 desktop на HTML5+JScript общается с серверной Java по HTTP-протоколу.
• Надо оценивать возможность использования в нашей разработке архитектурных возможностей VS Ultimate. Тем более, что у нас есть достаточно устойчивая модель приложения, которая на этой платформе может быть реализована недорого. А с архитектурой технической реализации приложений в компании наблюдаются явные проблемы.
• Надо учитывать возможность выхода многих компаний, которые сейчас занимаются web-разработкой, достаточно эффективно и в высоко конкурнетной среде, на рынок заказной разработки корпоративных приложений. Вроде как нашу нишу разработчиков действительно сложных решений с глубоким погружением в бизнес это не затронет и, более того, третий автоматизатор окажется еще более востребованной ролью, но варианты могут быть всякие.

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

Как обычно, в выходные в конце июня, двухдневный Летний аналитический фестиваль в Иваново. Организует сообщество системных аналитиков, площадку дает Консультант-плюс - поэтому в Иваново. Как обычно - это уже третий год, и в этом году было настолько много желающих, что регистрацию закрыли сильно рано, когда набралось 150 человек. Кстати, это становится тенденцией - рано закрывали регистрацию по переполнению на SQA days в Киеве, на devcon. Народ активно ездит общаться, обмениваться опытом. А ЛАФ выгодно отличается от всех конференций. И очень много людей ездят каждый год, а в промежутке - общаются на площадке сообщества, поэтому во многом - встречаются знакомые. Там очень теплая и своя тусовка, где люди друг друга знают и очень велика общность собравшихся. Поэтому на конференции очень много общения.

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

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

С докладами было несколько накладок, в основном из-за опоздания докладчиков, добирающихся из Москвы на машинах из-за пробок. Одного из них меня попросили заменить и совершенно неожиданно я сам оказался в числе докладчиков. Я рассказывал про Типы личности Майерс-Бриггс, семинар о которых читал в своей компании 2008 году, есть запись http://lib.custis.ru/2008-02-12-types-of-identity. И, забегая несколько вперед, во второй день я рассказывал про командные роль Белбина, тоже по мотивам семинара, который мы проводили в компании совместно с Аней Рид, и запись которого тоже опубликована http://lib.custis.ru/2010-01-19-belbin Оба рассказа были приняты хорошо, темы были актуальны и вызвали много вопросов и обсуждений.

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

→ продолжить чтение…

Сегодня был на AgileKitchen. Позитивно и весьма характерно: хотя я на подобных событиях бываю часто, и опыт у меня достаточно большой, три новые идеи - получены. Стоят ли эти идеи целого рабочего дня? Не знаю. Что они стоят моего выходного дня - я для себя решил.

А сами идеи вот.

1. Из доклада Андрея Реброва об инструментах автоматизированного тестирования - о том, что VS Test использовать скорее не стоит, чем стоит. Потому что скрипты он записывает, но результат сопровождать и изменять - весьма дорого, он плохо читаем. В общем-то услышав это явно я как-то вспомнил, что VS как инструмент тестирования на конфах не слышно, пользуются другим. Теперь узнал почему. А в целом в докладе был хороший обзор средств автоматизированного тестирования. Для меня лично других открытий не было, но многие участники - узнали для себя новое.
2. Из доклада Александра Тупикова узнал об интересном методе разбора фейлов - выученные уровки (не путать с вымученными уроками). Идея состоит в том, что в случае фейла он анализируется и формулируется как урок на будущее и фиксируется в определенном формате. И это - не наказание и не объяснительная, это именно уроки для предотвращения ситуаций. Ведется библиотека таких уроков, они классифицируются, выдаются новым сотрудникам и повторяются когда это уместно. А уж если люди упорно не учат уроки - тогда делаем выводы и наказания.
3. Еще из доклада Александра Тупикова - интересная практика самооценки. Все сотрудники регулярно (ежемесячно) пишут своим руководителям и HR свою самооценку. А дальше - получают по ней обратную связь. Очень эффективный инструмент (при нормальном климате) - так как позволяет работать с ожиданиями и оперативно реагировать. Только обратная связь должна быть искренней, и обязательно объяснять, если ожидаемое сотрудникам при высокой самооценки вознаграждение почему-либо не следует.

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

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

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

Будучи на Atlantic Systems Guild, я и Игорь Беспальчук были приглашены в Клуб директоров по разработке, который собирает Microsoft. На первое заседание клуба, на котором речь шла о тестировании, мы не попали, а вчера было второй заседание. На нем шла речь об архитектуре. Вели заседание Сергей Орлик, который и начал рассказ, Евгений Злобин и Денис Пасечник.

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

Дальше - отдельные тезисы, которых касалось обсуждение.

• В архитектуре различают три уровня: Enterprise architecture, Software architecture и Infractructure architecture. Организация работы на этих уровнях идет сильно по-разному, но при этом необходимо обеспечивать гладкую сшивку между уровнями, в частности между Software и infrastructure и организовывать это при выполнении проектов. Infrastracture влияет на software, особенно, например, при размещении в облаке. И это необходимо учитывать и формализовывать, создавая SLA (service layer agreement).
• Важно работать с софтом на полном жизненном цикле, не ограничиваясь разработкой и внедрением, а рассматривая эксплуатацию и последующую замену. На современных предприятиях IT-ландшафт включает множество систем и одновременно идет несколько (иногда 10+) проектов изменения.
• На больших предприятиях и, особенно, в банках, в том или ином виде существует архитектурный комитет, или отдел архитектуры, или главный архитектор, который работают с архитектурой при осуществлении проектов. Типичный пример - enterprise архитектор, архитектор инфраструктуры и архитектор по безопасности. Архитекторы подчинены непосредственно CEO или CIO, то есть занимают высокую позицию и имеют большое влияние, но должность не управленческая, а техническая. С удивлением узнал, что Главный архитектор есть в ГПБ (кто - не сказали).
• В банках вообще распространена ситуация, когда о новых решениях конкурентов бизнес узнает от IT :)
• Востребованы схемы, отражающие все уровни архитектуры в комплексе и позволяющие визуально переходить между уровнями. В качестве возможного инструмента называли связку SharePpoint+Visio, при этом для отражения актуального состояния желательно, чтобы Visio-диаграммы получают данные из внешних источников, например, из баз данных, отражающих состояние серверов и используемых для мониторинга.
• Как способ представления упоминался Archimate (естественно, мной), но Орлик достаточно резко сказал что в нем очень сложная академичная модель. С моей точки зрения, это странно, потому как им же активно упоминался TOGAF - а он более академичен, а TheOpenGroup сейчас активно перекидывает между ними мостики. После заседания ко мне многие подходили, интересовались archimate.
• Востребована также трассировка между верхним уровнем архитектуры (enterprise architecture) и архитектурой приложений. VS (ultimate edition) сейчас включает много возможностей для работы с архитектурой приложения, но вот архитектуру IT-системы предприятия в целом на ней пока не опишешь, архитекторы верхнего уровня работают в системах типа Enterprise Architect, и хотелось бы иметь трассировку между ними, в том числе - чтобы при решении задач интеграции разработчики одного модуля могли легко найти и познакомиться с архитектурой другого в необходимых им аспектам. Готового решения тут нет, но как идея была предложена перегрузка из EA в VS данных, которые при этом становятся доступны для ссылок из уровня VS.
• С точки зрения управления отмечена хорошая интеграция между Project Server, обеспечивающим управление верхнего уровня, и TFS, используемой для управления на уровне команд. Правда сам TFS не без недостатков, например, при списывании времени на задачу, время разных участников суммируется и история в разрезе участников не ведется. А это важно - хотя у задачи правильно иметь одного основного исполнителя, время привлекаемых экспертов и других участников надо фиксировать и отделять. Но в принципе можно доработать - и Ситроникс это для себя сделал.
• В VS (правда многое в ultimate) есть много различных средств для архитектора. Часть из них обеспечивают восстановление из кода, например, диаграмм последовательностей, что позволяет проследить реализацию метода. Есть Layer-диаграммы, позволяющие описать структуру приложения и возможные обращения. Далее разные классы можно относить к конкретным уровням и при нарушении структуры разработчик получает предупреждение. Существуют также средства автоматического контроля при check-in в версию, описываемые через политику. И это не просто возможность - ряд компаний (Ситроникс, ГазЭнергоБанк, Лидер-Инвест) этим пользуются в своей разработке. Кроме того, на механизме DGML можно описывать собственные диаграммы, нагруженные определенным смыслом и реализовывать механизмы генерации или контроля, с этим связанные, layer-диаграммы - использование этого механизма.

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

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