|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
SEG-2010 (отчет Стаса Фомина)Материал из CustisWikiКороткая ссылка: Seg-2010-report
Прошлую неделю провел на мероприятии достаточно оригинального формата — гибриде конференции и отдыха. Называлось все это Software Engineering Gathering 2010 «…слёт специалистов в области инженерии ПО … любые темы, связанные с инженерией ПО… февраль, Египет…». Идея достаточно здравая — в свое время, рефлексируя над неудобством обычных московских IT-конференций для немосквичей (дорого, неудобно, уныло), мыслил на тему слетов зимой в Турции — зимой там бросовые цены, от тыщи за сутки, при простаивающей инфраструктуре отелей, позволяющей участникам общаться круглосуточно, наслаждаясь экологией и обслуживанием с одной стороны, и не сильно отвлекаясь на пляж-купания с другой. Ну, а это был более скорее более пляжный вариант, ибо Египет в самое свое холодное время, вполне купабелен и всяко теплее Москвы-Питера-Минска в самые свои теплые деньки[1]. СодержаниеУчастники и форматХотя заявлялся полный спектр тем и профессий, нижеприведенный список основных участников[2] показывает, что это была в основном тусовка тестировщиков, со всеми из этого вытекающими последствиями (темы/проблематика/язык/подходы).
Изначально, насколько я понял, план был таков: два первых дня — дневные выступлений в конференц-зале, остальное — отдых. Задним числом, стоит признать, что это был не самый удачный вариант. И дело даже не в том, что конференц-зал нам не достался, выступать приходилось в незатемненном помещении ресторана, с слабым проектором, дохлым WiFi, жарким днем (когда кондиционер не спасал, а пляжные радости сманивали нестойких участников), и в результате, организованных выступлений было всего четыре, и заняло это всего один день. Лично я старался с пользой использовать любое время, и вечерами nonstop рассказывал от трендах и последних наших изобретениях — системы контроля версий (DVCS vs. CVCS, визуализация работы), тестменеджмент, оптимальный набор вебсистем в компании (Bugzilla, MediaWiki и все ее ништяки, ViewVC, и т. п.), системы корпоративной социализации (блоги и RSS-агрегаторы), юзабилити, полезные инструменты (Mindmapping), секреты правильных информационных презентаций, культурные коды ITшников в сериалах и мультфильмах, и многое другое (по сути, то, что рассказывал на конференциях SECR-2007/2008/2009, SEF-2009, ReqLabs-2009, и т. п. см. [1], например, [2], [3], [4], [5], [6], [7], [8], плюс кучу всего недосказанного). Рассказывал это микрогруппам (от одного до трех человек), собрав их вокруг своего ноутбука, без жесткого таймфрейминга, достаточно неторопливо и методично, отвечая на вопросы и демонстрируя примеры — то есть не кормил людей голыми слайдами, а погружался внутрь корпоративной сети компании через OpenVPN, и показывал все «живьем». Так сказать индивидуальный тренинг и даже коучинг ^_^. Было интересно (хотя WiFi оставлял желать лучшего).
Предложения по улучшениюОтсюда конструктивные выводы для организаторов подобного мероприятия (особенно в Египте):
Проведенные доклады и обсужденияК сожалению, длились только один день, 2010-02-22. Гриша Печенкин вел видеосьемку, однако из-за случившихся обстоятельств, неясно, когда она будет опубликована, и будет ли вообще. Поэтому я изложу свое краткое понимание прошедших докладов.
Quality metrics
Tiit Paananen («Главный в Skype по тестированию») рассказал о внутренних и внешних метриках качества, используемых в Skype. И если с внутренними было примерно все понятно — все это можно взять из добротного учета в багтрекере (у них используется Jira) и из анализа репозитория кода, то основная интрига была с внешними метриками — то есть метриками удовлетворенности клиента, замеряемыми как самим продуктом (все наверное помнят регулярные опросы Skype — «Как прошел звонок? Всем ли довольны?»), так и независимыми организациями, проводящими опросы Net Promoter Score, где в кратце, всех участвующих озадачивают вопросом «Готовы ли рекомендовать XXX друзьям по 10-бальной шкале» (вот только что мне такой вопрос от альфабанка пришел) и делят на три группы («Продвигатели», «Так себе», и «Ворчуны»), вычитают процент последних из первых, и пытаются интерпретировать полученный результат (в разбивке по группам, странам и т. п.). Так например, они видят тренд, что платные пользователи в целом более довольны (то ли интернет у них лучше, то ли пользователь платит когда понимает, за что он платит, и меньше необоснованных ожиданий, то ли вообще эффект любви к купленным вещам).
Кстати, самая интересная тема связи внутренних и внешних метрик осталась нераскрытой и заявлена как открытый вопрос для последующих исследований. А это реально интересно, плюс далеко не каждая компания может похвастать такой огромной базой пользователей и собранных с них оценок — уверен, если порыться в богатом наборе данных Datamining-oм — наверняка можно нарыть нетривиальные зависимости. Отдел Качества в Крупной компанииВладислав Орликов предложил для мозгового штурма следующую задачу:
Дмитрий Безуглый предложил внедрить классические практики автоматизированного интеграционного тестирования: Continuous Integration, и далее собирать метрики сломанных сборок, и точечно разбираться с наиболее проблемными группами. Отдельно стояла задача мотивации проектных групп к сотрудничеству, и обосновании необходимых изменений перед топменеджментом. Тут согласились в необходимости ретроанализа трекера дефектов, для выделения проблем интеграции и обоснования необходимости новых практик, внедрением которых и займется отдел качества. Немало тупиковых ветвей было и откинуто при обсуждении — например, привязка финансовых штрафов-бонусов к метрикам качества[3], личная ответственность разработчика за прохождение интеграционной сборки и др. На мой взгляд, это прекрасный пример конкретной и практической задачи, решать которую было и интересно, и полезно всем участникам — отхода от темы не наблюдалось.
Весь софт — отстойСофт — отстой! Почему мы материмся на большинство программ и думаем «я бы сделал эту программу удобнее и понятнее». А приходим на работу и делаем софт на который кто-то другой (наш клиент) будет ругаться, при том что мы, совершенно искренне, считаем эту программу удобной. Ведущие — Алексей Лянгузов, Дмитрий Безуглый. Ну уже из названия понятно, что это была взята слишком широкая тема, неизбежно приведшая и к флеймам и к оффтопикам. «Почему все плохо?» и «Кто виноват?» — это все-таки риторика и тематика обсуждения металась аки «стрелка осциллографа»™. Я взял на себя труд вести майндмап обсуждения, дабы хоть как-то структурировать и конспектировать обсуждаемые темы, как я обычно делал на аналогичных обсуждениях (см. например, открытые встречи сообщества AgileRussia.ru). В целом тема вертелась вокруг юзабилити, почему его так мало и в чем его причины:
Но тема была настолько широка, что обсуждение скатилось несколько вбок и Дмитрий Безуглый попробовал свести ее к своей архитектурной теме[4], а именно, безграмотности проектировщиков, не читавших книги «Архитектура программного обеспечения на практике», и не знающих о неразрешимых противоречиях групп атрибутов качества. Например, заявлялись противоречия:
Ну, что тут сказать. Если бы можно было переиграть, я бы на месте ведущего сузил тему юзабилити, адаптировав ее к аудитории — «Usability и Тестировщик. Несовместимость или синергия?». Ведь с одной стороны популярены взгляды, выражающиеся мифологическим «треугольником Дениса Бескова», где тестировщик томится в гоблинском тупичке (или вернее тролльском углу?), а юзабилист — несравненно прекрасный эльф (да и по любым другим типологиям личности, Маерс-Бриггс/Белбин/Адизес… — «контроллеров» всегда сильно отделяют от «криативщиков»). С другой — часто пользователей достает не общее, концептуальное несовершенство юзабилити системы (человек фантастически адаптивен, см. например заметку об адаптации пилотов вертолета Apache к dual-view шлему[5]), а мелкие несовершенства интерфейса, которые даже им, непрофессионалам, очевидно как улучшить, и наличие таких «заусенцев» воспринимается пользователем как выражение неуважения. Вот тут-то, правильный прокачанный в юзабилити тестировщик смог бы не только примитивно проверять тест-кейсы, но и выполнять юзабилити-аудит. Вот такую тему точно надо поднимать, если мы не хотим, чтобы «весь софт был отстой». IT-методологии и разработчикВедущие — Александр Кондаков, Дмитрий Безуглый. На самом деле тема изначально заявлялась, как «Модели, методологии, стандарты и пр. или как «убить» ИТ-шника», но опять таки, пала жертвой широкой флеймогонности — не успел только Александр Кондаков ввести классификацию методологий («от инструмента», «тяжелые», «модные» — см. майндмап), немедленно начался классический срач «СMMI vs. Agile» (причем все присутствующим, думаю было понятно, что противопоставление CMMI с Agile некорректно, тему «CMMI не враг Agile» уже мусолят несколько лет — однако смысл понятен, в один угол ринга упали все методологии жесткого, инженерного типа, процессы которых прописаны в жирных XXX-BOK[6]ах, ГОСТах, корпоративных регламентах или забиты гвоздями в инструментах, а в другом — относительно неформализованные процессы, органически вырастающие в успешных командах.
За «процессный угол» стал активно играть Дима Безуглый, за «Agile» играл зал, страсти были настолько накалены, что тема вырвалась из под контроля ведущего, Александра Кондакова, хотя он успел рассказать пару интересных и разнородных кейсов[7] из своей практики CMMI-оценивания европейских компаний. Каюсь, даже я (Стас Фомин), сорвался с нейтральной функции секретаря-майндмаппера — «не могу молчать!» — ибо звучали утверждения противоречащие всему моему практическому опыту.
Вывод — такие обобщенно-религиозные темы надо запрещать, как оружие массового поражения. Вернее разрешать то можно, но с максимальной конкретикой — «в компании AAA мы/они пытались делать XXX (цели, размер, ограничения), были проблемы YYY, помогло ZZZ, а вот WWW совершенно не работает». Т.е. надо сразу отвечать на вопросы «Что? Где? Когда?», и только при наличие нескольких конкретных кейсов делать аккуратные обобщения. РезюмеВ целом удачное мероприятие, идеи по улучшению для организаторов я уже излагал, стоит только добавить пару советов участникам — сохранять скорее рабочий настрой и не зря на отдыхе не рисковать — ибо медицина в Египте не шибкая, стандартная туристическая страховка, как обычно отстой и не работает (в группе случилась травма). Т.е. спасение утопающих — дело их самих и с собой нужно тащить полный набор антибиотиков наружного и внутреннего применения. Я вот недостаточно собрался и не взял Левомиколь — и в результате, вот уже неделю после балансирую на грани приемной отделения гнойной хирургии. Ну а теперь — благодарности:
Отчеты других участников
ВидеоВряд ли понадобиться кому-то, кроме участников, но пусть тут повисит.
Примечания
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». Репликация: База Знаний «Заказных Информ Систем» → «SEG-2010 (отчет Стаса Фомина)» |
 |
 |
 |
WiFi должен быть обязательно. Можно конечно исследовать задачу «создать локальную WiFi-сеть на пустом месте», но связность с глобальным Интернетом очень важна (ссылки на ресурсы, гугление, заход в корпоративные сети, возможно даже присоединяться удаленные участники) — так что лучше требовать «чтобы было!».
DA-DA — 
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
