Просмотр исходного текста страницы SEG-2010 (отчет Стаса Фомина)

[[File:SEG-2010-logo.jpg|left|thumb|200px]]
Прошлую неделю провел на мероприятии достаточно оригинального формата — гибриде конференции и отдыха.
Называлось все это [http://www.it-conf.ru/ru/content/236.htm Software Engineering Gathering 2010]
«…слёт специалистов в области инженерии ПО … любые темы, связанные с инженерией ПО… февраль, Египет…».

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

Ну, а это был более скорее более пляжный вариант, ибо Египет в самое свое холодное время, вполне купабелен и всяко теплее Москвы-Питера-Минска в самые свои теплые деньки<ref>Возможно доступная «пляжность» это таки баг, а не фича</ref>.

== Участники и формат ==

Хотя заявлялся полный спектр тем и профессий, нижеприведенный список основных участников<ref>Который я вспомнил, возможно, кого-то и забыл, сорри</ref> показывает, что это была в основном тусовка тестировщиков, со всеми из этого вытекающими последствиями (темы/проблематика/язык/подходы).

;[http://orlikov.moikrug.ru/  Орликов Владислав]: Project Manager (тестирование), http://vldcorp.blogspot.com/
;[http://www.facebook.com/profile.php?id=781804809  Tiit Paananen]: PM (тестирование). http://parasiil.blogspot.com/,  [http://ee.linkedin.com/pub/tiit-paananen/1/21b/498  LinkedIn]
;[http://interface.moikrug.ru/  Хайруллин Тимур]: Project Manager (тестирование)
;[http://julia-nechaeva.moikrug.ru/  Нечаева Юлия]: Project Manager (тестирование)
;[http://polazhenko.moikrug.ru/  Полаженко Сергей]: Project Manager (тестирование), разработчик.
;[http://gpechyonkin.moikrug.ru/ Печенкин Григорий]: Аналитик
;[http://kondakov.ru/  Кондаков Александр]: методолог, http://russian-sla.livejournal.com
;[http://dbezuglyy.moikrug.ru/  Безуглый Дмитрий]: методолог, консультант-преподаватель-тренер.
;[http://aleksandr-burdeyniy.moikrug.ru/  Александр Бурдейный]: тестировщик.
;[http://www.facebook.com/profile.php?id=100000609788982  Твердохлебов Роман]: тестировщик, http://retverd.blogspot.com/
;Лянгузов Алексей: ведущий тестировщик Sun Microsystems
;[http://vkontakte.ru/id42170  Михайлова Виктория]: тестировщик
;[http://aleksandra-kursanova.moikrug.ru/  Курсанова Александра]: тестировщик
;[http://www.facebook.com/profile.php?id=100000609788982#!/profile.php?id=100000166729995&ref=mf  Ильичёв Павел]: тестировщик
;[http://belonesox.moikrug.ru  Фомин Стаc]: разработчик, PM, методолог.


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

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

Задним числом, стоит признать, что это был не самый удачный вариант.
И дело даже не в том, что конференц-зал нам не достался, выступать приходилось в незатемненном помещении ресторана, с слабым проектором, дохлым WiFi, жарким днем (когда кондиционер не спасал, а пляжные радости сманивали нестойких участников), и в результате, организованных выступлений было всего четыре, и заняло это всего один день. Лично я старался с пользой использовать любое время, и вечерами ''nonstop'' рассказывал от трендах и последних наших изобретениях — системы контроля версий (DVCS vs. CVCS, [[ShowTeamWork|визуализация работы]]), [http://team.custis.ru/2009/11/testopia.html тестменеджмент], оптимальный набор вебсистем в компании ([[Bugzilla]], [http://team.custis.ru/2009/06/sef-2009.html MediaWiki и все ее ништяки], [[ViewVC]], и т. п.), системы корпоративной социализации (блоги и RSS-агрегаторы), юзабилити, полезные инструменты (Mindmapping), секреты правильных информационных презентаций, культурные коды ITшников в сериалах и мультфильмах, и многое другое (по сути, то, что рассказывал на конференциях SECR-2007/2008/2009, SEF-2009, ReqLabs-2009, и т. п. см. [http://team.custis.ru/search/label/%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8], например, [http://team.custis.ru/2009/11/testopia.html], [http://team.custis.ru/2009/11/subversion-viewvc-svn-searcher-secr.html], [http://team.custis.ru/2009/10/humane-interface.html], [http://team.custis.ru/2009/10/blog-post.html], [http://team.custis.ru/2009/08/mindmaps.html], [http://team.custis.ru/2009/06/sef-2009.html], [http://team.custis.ru/2007/11/secr-2007.html], плюс кучу всего недосказанного). Рассказывал это микрогруппам (от одного до трех человек), собрав их вокруг своего ноутбука, без жесткого таймфрейминга, достаточно неторопливо и методично, отвечая на вопросы и демонстрируя примеры — то есть не кормил людей голыми слайдами, а
погружался внутрь корпоративной сети компании через OpenVPN, и показывал все «живьем».
Так сказать индивидуальный тренинг и даже коучинг <tt>^_^</tt>.
Было интересно (хотя WiFi оставлял желать лучшего).


Отсюда конструктивные выводы для организаторов подобного мероприятия (особенно в Египте):
;Время: Не стоит копировать стандартную конференцию — «работа днем»/«afterparty вечером» — днем в Египте не работается, пляжи, бассейны и море ждут (ибо работают они до <tt>17:00</tt>, а далее резко темнеет) — днем надо отдыхать, а собираться на толковища можно спокойно вечером (вместо стандартного «околоалкогольного» времяпрепровождения). Зато вместо 2-х выделенных дней можно с толком использовать все дни! Кстати, думаю нужно минимизировать экскурсии занимающие весь день целиком, чтобы не выбиваться из ритма «литературных вечеров».
;Место и технологии: Вообще не стоит бороться за то, чтобы собрать всю группу в одном помещении и с проектором. Это удел сборищ от 30 человек и выше, а когда речь идет об одном-двух десятках, можно формировать мобильные группы по интересам («''там, где двое или трое соберутся во Имя Мое, там и Я посреди них''» ©) — [[RuPedia:Birds of a Feather (информатика)|BOF]]-сессии рулят. Так можно от пары до полутора десятков участников рассадить вокруг стола, можно даже на открытом воздухе (коктейли, алкоголь, кальян-сигареты — по желанию), и транслировать визуальный поток используя не проектор, а ноутбуки (у каждого второго они были, и это достаточно) — пару лет назад для такой задачи я успешно использовал <tt>VNC</tt>, для тупой трансляции экрана в локальной сети можно использовать <tt>VLC</tt>, возможно есть что-то лучше, например, чтобы не париться с настройкой, можно использовать вебинарные сервисы-приложения, типа [http://habrahabr.ru/blogs/i_recommend/85833/ Mikogo] (todo:надо провести эксперименты в среде «локальная сеть с слабым WiFi»).
{{important}} WiFi должен быть обязательно. Можно конечно исследовать задачу «создать локальную WiFi-сеть на пустом месте», но связность с глобальным Интернетом очень важна (ссылки на ресурсы, гугление, заход в корпоративные сети, возможно даже присоединяться удаленные участники) — так что лучше требовать «чтобы было!».
;Тематика и атмосфера: Ожидается взаимное доверие (сильно большее, чем между случайными участниками на конференции). Отсюда хочется исключить флеймогонные темы «о сферических конях в вакууме», о которых можно спорить бестолку и до бесконечности, основанные не на практике, а на «прочитанных книжках» и собственных домыслах — ведь это первейший способ стать даже не [http://local.joelonsoftware.com/wiki/%D0%9D%D0%B5_%D0%B4%D0%B0%D0%B9%D1%82%D0%B5_%D0%90%D1%81%D1%82%D1%80%D0%BE%D0%BD%D0%B0%D0%B2%D1%82%D0%B0%D0%BC_%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D1%8B_%D0%B2%D0%B0%D1%81_%D0%B7%D0%B0%D0%BF%D1%83%D0%B3%D0%B0%D1%82%D1%8C астронавтом от архитектуры], а вовсе «астральным методологом/архитектором/PMом». Лично я ожидал бы максимальной конкретики, местами инсайда:
* Рассказ об инструменте — покажите его. Минимум — скринкасты, лучше — живьем.
* Методология? Процессы? Поделитесь живыми кейсами. Цифры рулят — нарисуйте структуру компании/проектных групп, покажите сколько, где и каких специалистов. Покажите размер проекта. Да, метрики конечно условность, но не поленитесь померить проект [http://cloc.sourceforge.net/ CLOCом] — хотя бы с точностью до порядка. Уверяю, проекты размером в десяток тысяч строк и несколько миллионов, рулятся по-разному.
* Архитектура или практики кодирования? — ''Show me your code''!
* Usability? — показывайте интерфейс живьем. И т.п.
{{caution}} DA-DA — [[EnPedia:Non-disclosure agreement|NDA]] зачастую имеет место быть есть, но можно, можно быть сильно конкретным, без заступа за красную линию.
В награду за такую открытость, все участники должны быть очень доброжелательны, и если критиковать, то очень конструктивно. То есть этот «IT-нудизм» должен (и думаю, будет) обязательно вознагражден конструктивным фидбеком, а
уход в темы без конкретики «Почему все плохо?» или «Agile vs. NonAgile» будет легко пресекаться, также полечится проблема с «захватом микрофона» за счет дерзости и риторики («оффтоп? — спасибо, послушаем более конкретные предложения»).

== Проведенные доклады и обсуждения ==

К сожалению, длились только один день, 2010-02-22.

=== Quality metrics ===

{{note}} ''This report about quality metrics, how to get test metrics, code metrics and service level metrics into sensible executive dashboard layout to show overall quality of products''

[[Image:Tiit  Paananen -  Quality metrics -  01.jpg|thumb|200px|right]]


[[Image:Tiit  Paananen -  Quality metrics -   02.jpg|thumb|200px|left]]

Tiit Paananen «Главный в Skype по тестированию» рассказал о внутренних и внешних метриках качества, используемых в Skype.
И если с внутренними было примерно все понятно — все это можно взять из добротного учета в багтрекере (у них используется [[Jira]]) и из анализа репозитория, то основная интрига была с внешними метриками — то есть метриками удовлетворенности клиента, замеряемыми как самим продуктом (все наверное помнят регулярные опросы Skype — «Как прошел звонок? Всем ли довольны?»), так и независимыми организациями, проводящими опросы [[EnPedia:Net Promoter|Net Promoter Score]], где в кратце, всех участвующих озадачивают вопросом «Готовы ли рекомендовать XXX друзьям по 10-бальной шкале» (вот только что мне такой вопрос от альфабанка пришел) и делят на три группы («Продвигатели», «Так себе», и «Ворчуны»), вычитают процент последних из первых, и пытаются интерпретировать полученный результат (в разбивке по группам, странам и т. п.).

{{note}} Кстати, имхо ([[Участник:StasFomin|Стас Фомин]]), это не самая лучшая метрика удовлетворенности — ибо это показывает только есть ли экспоненциальное развитие пользовательской базы или нет (например, я, платный пользователь Skype, в целом доволен, но не занимаюсь рекомендациями, ибо все кто мне нужен и так уже пользователи Skype), да и вообще, это нужно бизнесам с очень большой эластичностью — нерегулярной зависимостью удовлетворенности пользователя от сервисов (покупка гаджетов, банковские услуги) — то есть когда будет возможен большой gap между текущим финансовым потоком от пользователя и будущим (то есть сейчас платит, но уже решили все свалить). У Skype же микротранзакции, и проще не использовать достаточно спорные метрики, а плясать непосредственно от пользовательской базы, активности использования, и да, PROFITа в деньгах.
А то ориентируясь и оптимизируясь в сторону NPS, они привлекут и сделают счастливыми всех тех, кто никогда не платит, ну и счастливо закроются.
Впрочем, и без меня хватает и критики NPS, так и корпораций ориентирующихся на эту метрику.

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

=== Отдел Качества в Крупной компании ===

[[Файл:Орликов и Безуглый на SEG-2010.jpg|thumb|200px|right]]

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

Дмитрий Безуглый предложил внедрить классические практики автоматизированного интеграционного тестирования:
[[Continuous Integration]], и далее собирать метрики сломанных сборок, и точечно разбираться с наиболее проблемными группами.

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

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

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





=== Весь софт — отстой ===

''Софт — отстой! Почему мы материмся на большинство программ и думаем «я бы сделал эту программу удобнее и понятнее». А приходим на работу и делаем софт на который кто-то другой (наш клиент) будет ругаться, при том что мы, совершенно искренне, считаем эту программу удобной.''

[[Файл:Лянгузов-Безуглый-SEG-2010-usability.jpg|right|thumb|300px]]

Ведущие — Алексей Лянгузов, Дмитрий Безуглый.

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

Я взял на себя труд вести майндмап обсуждения, дабы хоть как-то структурировать и конспектировать обсуждаемые темы,
как я обычно делал на аналогичных обсуждениях (см. например, [[:Категория:Собрания_AgileRussia.ru|открытые встречи сообщества AgileRussia.ru]]).

[[Файл:Весь софт-отстой (SEG-2010).mm]]

В целом тема вертелась вокруг юзабилити, почему его так мало и в чем его причины:
* бесполезно доверять вопросы юзабилити как
** программисту (см. например [[Психбольница в руках пациентов]], [[Алан Купер об интерфейсе. Основы проектирования взаимодействия]])
** так и среднему пользователю (см. например, [http://video.yandex.ru/users/stas-fomin/view/60/?cauthor=stas-fomin&cid=5 краткую нарезку] из прекрасной [[RuPedia:Oh Brother, Where Art Thou?|серии симпсонов]])
* а юзабилити-специалисты, часто растут из веб-дизайнеров, которые и под юзабилити понимают не базовые принципы, основанные на психофизиологических законах, изложенные например, в «Humane Interface» Джефа Раскина (см. кстати, [http://team.custis.ru/2009/10/humane-interface.html наш семинар по теме]), а колористику и прочую гламурность.
* новые интерфейсы (тачпады) тоже бросают ''challenge''.

Но тема была настолько широка, что обсуждение скатилось несколько вбок и Дмитрий Безуглый попробовал свести ее к своей архитектурной теме<ref>Вот презентация Дмитрия по теме сценариев атрибутов качества http://www.system-approach.ru/downloads/09-QA-intro.pdf</ref>, а именно,
безграмотности проектировщиков, не читавших книги «[http://www.ozon.ru/context/detail/id/2456415/ Архитектура программного обеспечения на практике]», и не знающих о неразрешимых противоречиях групп атрибутов качества.

Например, заявлялись противоречия:
;security vs. usability: из-за которых, вроде как WebMoney теряет аудиторию, сделав ставку на ''security''. С другой стороны, успех Яндекс. Денег, не сказать, что сильно проигрывающий по security, явно этому противоречит.
;performance vs. usability: вроде как не существует массовых порталов, удобных (и в частности, персонализируемых под пользователя). Опять таки сервисы Яндекса служат антипримером.

Ну, что тут сказать. Если бы можно было переиграть, я бы сузил тему юзабилити, адаптировав ее к аудитории — «Usability и Тестировщик. Несовместимость или синергия?».

Ведь с одной стороны популярены взгляды, выражающиеся мифологическим «треугольником [http://denisbeskov.moikrug.ru/ Дениса Бескова]»,

[[Файл:Треугольник-Бизнес-Пользователь-Технологии.jpg|center|thumb|400px]]
где тестировщик томится в гоблинском тупичке (или вернее тролльском углу?), а юзабилист — несравненно прекрасный эльф
(да и по любым другим типологиям личности, Маерс-Бриггс/Белбин/Адизес… — «контроллеров» всегда сильно отделяют от «криативщиков»).

С другой — часто пользователей достает не общее, концептуальное несовершенство юзабилити системы (человек фантастически адаптивен, см. например заметку [http://a-lamtyugov.livejournal.com/476759.html об адаптации пилотов вертолета Apache к dual-view шлему]<ref>Сама книга знаменитого вертолетчика — [http://www.wikio.com/books/apache-inside-the-cockpit-of-the-world-s-most-deadly-fighting-machine-0802118941-806760,b.html  Apache: Inside the Cockpit of the World’s Most Deadly Fighting Machine — Ed Macy], частично доступна [http://books.google.ru/books?id=SZ9LsKOD4X0C  http://books.google.ru/books?id=SZ9LsKOD4X0C бесплатно онлайн].</ref>), а мелкие несовершенства интерфейса, которые даже им, непрофессионалам, очевидно как улучшить, и наличие таких «заусенцев» воспринимается пользователем как выражение неуважения. Вот тут-то, правильный прокачанный в юзабилити тестировщик смог бы не только примитивно проверять тест-кейсы, но и выполнять юзабилити-аудит.
Вот такую тему точно надо поднимать, если мы не хотим, чтобы «весь софт был отстой».

=== IT-методологии и разработчик ===

Ведущие — Александр  Кондаков, Дмитрий Безуглый.


На самом деле тема изначально заявлялась, как «Модели, методологии, стандарты и пр. или как «убить» ИТ-шника», но опять таки, пала жертвой широкой флеймогонности — не успел только Александр Кондаков ввести классификацию методологий («от инструмента», «тяжелые», «модные» — см. майндмап), немедленно начался классический срач «СMMI vs. Agile» (причем все присутствующим, думаю было понятно, что противопоставление CMMI с Agile некорректно, тему «CMMI не враг Agile» уже мусолят несколько лет — однако смысл понятен, в один угол ринга упали все методологии жесткого, инженерного типа, процессы которых прописаны в жирных XXX-BOK<ref>BOK — Body of Knowledge</ref>ах, ГОСТах, корпоративных регламентах или забиты гвоздями в инструментах, а в другом — относительно неформализованные процессы, органически вырастающие в успешных командах. 


[[Файл:IT-методологии и  разработчик.mm]]

За «процессный угол» стал активно играть Дима Безуглый, за «Agile» играл зал, страсти были настолько накалены, что тема вырвалась из под контроля ведущего (Александра).

Каюсь, даже я ([[Участник:StasFomin|Стас Фомин]]), сорвался с нейтральной функции секретаря-майндмаппера — «не могу молчать!» — ибо звучали утверждения противоречащие всему моему практическому опыту.

* «Agile — это борьба с симптомами вместо болезни?» — Помилуйте. Это скорее итерационное лечение с диагностикой и экспериментами (по методу доктора Хауса) в противовес «лечению» от  врача-чиновника-мудака, который не глядя на больного, выполняет набор предписанных Минздравом инструкций. И вообще, если притягивать медицинские метафоры к процессам разработки, то лучше сразу смотреть [http://www.slideshare.net/Askhat/ss-1232807 выступление Асхата Уразбаева «Процессные заболевания и методы их лечения»] (по ссылке слайды со звуком).
* Успешные Agile-команды не могут передать свой опыт и масштабироваться? — Опять мимо. Отлично работает и масштабирование, и «митоз» — деление команд с добором «новичков». И т.п.

Вывод — такие обобщенно-религиозные темы надо запрещать, как оружие массового поражения.
Вернее разрешать то можно, но с максимальной конкретикой — «в компании AAA мы/они пытались делать <tt>XXX</tt> (цели, размер, ограничения), были проблемы <tt>YYY</tt>, помогло <tt>ZZZ</tt>, а вот <tt>WWW</tt> совершенно не работает». Т.е. надо сразу отвечать на вопросы «Что? Где? Когда?», и только при наличие нескольких конкретных кейсов делать аккуратные обобщения.  

== Резюме и благодарности ==
;Владиславу — организатору: идея новаторская, да и собрать даже пару десятков взрослых, географически распределенных, слабознакомых и неподчиненных людей — задача не из простых. Получилось! Спасибо!
;Tiitу: Отличный специалист, свой парень, и кстати, ценный вид иностранца — говорящий на легко понимаемом английском с одной стороны, и при этом понимающий русский! Для меня, увы, не могущего на английском даже связно мычать (увы, без практики все атрофировалось), это было очень ценно.
;Молодые девушки-тестировщицы: Отлично украсили и оживили все общество, мотивировали к интеллектуальным дискуссиям, и вообще, сильно, скажем так, поднимали настроение. Надо запомнить (к черту запомнить, запишу) — молодые девушки ''в теме'', нужны и в проектных командах, и на собраниях, и на конференциях. 
;Всем участникам: Я отлично провел с вами время! Надеюсь, и вы тоже! 

== Отчеты других участников ==

* [http://retverd.blogspot.com/2010/03/seg2010-it.html Роман Твердохлебов] (много фото)
* [http://russian-sla.livejournal.com/16324.html Александр Кондаков]
* [http://www.system-approach.ru/2010/02/seg/ Дмитрий Безуглый]
* [http://blogs.mail.ru/mail/burger4you/133BC1C73D748196.html  Александр Бурдейный]
* [http://picasaweb.google.com/polazhenko/SEG2010 Фото Сергея Полаженко]

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

;Яхта-морская прогулка: http://narod.ru/disk/18401635000/seg-2010-yacht-video.zip.html
;Сафари в пустыне: http://narod.ru/disk/18409337000/seg-2010-safary.zip.html

== Примечания ==
<references/>

{{replicate-from-custiswiki-to-lib}}