К сожалению, длились только один день, <tt>2010-02-22</tt>.
К сожалению, длились только один день, <tt>2010-02-22</tt>.
−
Гриша Печенкин вел видеосьемку, однако из-за случившихся обстоятельств, неясно, когда она будет опубликована, и будет ли вообще. Поэтому я изложу свое краткое понимание прошедших докладов.
+
Гриша Печенкин вел видеосьемку, <s>однако из-за случившихся обстоятельств, неясно, когда она будет опубликована, и будет ли вообще. Поэтому я изложу свое краткое понимание прошедших докладов.</s>
+
Появилось видео, Гриша не подкачал!
Строка 77:
Строка 78:
Кстати, самая интересная тема связи внутренних и внешних метрик осталась нераскрытой и заявлена как открытый вопрос для последующих исследований.
Кстати, самая интересная тема связи внутренних и внешних метрик осталась нераскрытой и заявлена как открытый вопрос для последующих исследований.
А это реально интересно, плюс далеко не каждая компания может похвастать такой огромной базой пользователей и собранных с них оценок — уверен, если порыться в богатом наборе данных ''Datamining''-oм — наверняка можно нарыть нетривиальные зависимости.
А это реально интересно, плюс далеко не каждая компания может похвастать такой огромной базой пользователей и собранных с них оценок — уверен, если порыться в богатом наборе данных ''Datamining''-oм — наверняка можно нарыть нетривиальные зависимости.
Вывод — такие обобщенно-религиозные темы надо запрещать, как оружие массового поражения.
Вывод — такие обобщенно-религиозные темы надо запрещать, как оружие массового поражения.
Вернее разрешать то можно, но с максимальной конкретикой — «в компании AAA мы/они пытались делать <tt>XXX</tt> (цели, размер, ограничения), были проблемы <tt>YYY</tt>, помогло <tt>ZZZ</tt>, а вот <tt>WWW</tt> совершенно не работает». Т.е. надо сразу отвечать на вопросы «Что? Где? Когда?», и только при наличие нескольких конкретных кейсов делать аккуратные обобщения.
Вернее разрешать то можно, но с максимальной конкретикой — «в компании AAA мы/они пытались делать <tt>XXX</tt> (цели, размер, ограничения), были проблемы <tt>YYY</tt>, помогло <tt>ZZZ</tt>, а вот <tt>WWW</tt> совершенно не работает». Т.е. надо сразу отвечать на вопросы «Что? Где? Когда?», и только при наличие нескольких конкретных кейсов делать аккуратные обобщения.
Прошлую неделю провел на мероприятии достаточно оригинального формата — гибриде конференции и отдыха.
Называлось все это 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 оставлял желать лучшего).
Предложения по улучшению
Отсюда конструктивные выводы для организаторов подобного мероприятия (особенно в Египте):
Время
Не стоит копировать стандартную конференцию — «работа днем»/«afterparty вечером» — днем в Египте не работается, пляжи, бассейны и море ждут (ибо работают они до 17:00, а далее резко темнеет) — днем надо отдыхать, а собираться на толковища можно спокойно вечером (вместо стандартного «околоалкогольного» времяпрепровождения). Зато вместо 2-х выделенных дней можно с толком использовать все дни! Кстати, думаю нужно минимизировать экскурсии занимающие весь день целиком, чтобы не выбиваться из ритма «литературных вечеров».
WiFi должен быть обязательно. Можно конечно исследовать задачу «создать локальную WiFi-сеть на пустом месте», но связность с глобальным Интернетом очень важна (ссылки на ресурсы, гугление, заход в корпоративные сети, возможно даже присоединяться удаленные участники) — так что лучше требовать «чтобы было!».
Тематика и атмосфера
Ожидается взаимное доверие (сильно большее, чем между случайными участниками на конференции). Отсюда хочется исключить флеймогонные темы «о сферических конях в вакууме», о которых можно спорить бестолку и до бесконечности, основанные не на практике, а на «прочитанных книжках» и собственных домыслах — ведь это первейший способ стать даже не астронавтом от архитектуры, а вовсе «астральным методологом/архитектором/PMом». Лично я ожидал бы максимальной конкретики, местами инсайда:
Рассказ об инструменте — покажите его. Минимум — скринкасты, лучше — живьем.
Методология? Процессы? Поделитесь живыми кейсами. Цифры рулят — нарисуйте структуру компании/проектных групп, покажите сколько, где и каких специалистов. Покажите размер проекта. Да, метрики конечно условность, но не поленитесь померить проект CLOCом — хотя бы с точностью до порядка. Уверяю, проекты размером в десяток тысяч строк и несколько миллионов, рулятся по-разному.
Архитектура или практики кодирования? — Show me your code!
Usability? — показывайте интерфейс живьем. И т.п.
DA-DA — NDA зачастую имеет место быть есть, но можно, можно быть сильно конкретным, без заступа за красную линию.
В награду за такую открытость, все участники должны быть очень доброжелательны, и если критиковать, то очень конструктивно. То есть этот «IT-нудизм» должен (и думаю, будет) обязательно вознагражден конструктивным фидбеком, а уход в темы без конкретики «Почему все плохо?» или «Agile vs. NonAgile» будет легко пресекаться, также полечится проблема с «захватом микрофона» за счет дерзости и риторики («оффтоп? — спасибо, послушаем более конкретные предложения»).
Проведенные доклады и обсуждения
К сожалению, длились только один день, 2010-02-22.
Гриша Печенкин вел видеосьемку, однако из-за случившихся обстоятельств, неясно, когда она будет опубликована, и будет ли вообще. Поэтому я изложу свое краткое понимание прошедших докладов.
Появилось видео, Гриша не подкачал!
Quality metrics
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
Tiit Paananen («Главный в Skype по тестированию») рассказал о внутренних и внешних метриках качества, используемых в Skype.
И если с внутренними было примерно все понятно — все это можно взять из добротного учета в багтрекере (у них используется Jira) и из анализа репозитория кода, то основная интрига была с внешними метриками — то есть метриками удовлетворенности клиента, замеряемыми как самим продуктом (все наверное помнят регулярные опросы Skype — «Как прошел звонок? Всем ли довольны?»), так и независимыми организациями, проводящими опросы Net Promoter Score, где в кратце, всех участвующих озадачивают вопросом «Готовы ли рекомендовать XXX друзьям по 10-бальной шкале» (вот только что мне такой вопрос от альфабанка пришел) и делят на три группы («Продвигатели», «Так себе», и «Ворчуны»), вычитают процент последних из первых, и пытаются интерпретировать полученный результат (в разбивке по группам, странам и т. п.). Так например, они видят тренд, что платные пользователи в целом более довольны (то ли интернет у них лучше, то ли пользователь платит когда понимает, за что он платит, и меньше необоснованных ожиданий, то ли вообще эффект любви к купленным вещам).
Кстати, имхо (Стас Фомин), это не самая лучшая метрика удовлетворенности — ибо это показывает только есть ли экспоненциальное развитие пользовательской базы или нет (например, я, платный пользователь Skype, в целом доволен, но не занимаюсь рекомендациями, ибо все кто мне нужен и так уже пользователи Skype), да и вообще, это нужно бизнесам с очень большой эластичностью — нерегулярной зависимостью удовлетворенности пользователя от сервисов (покупка гаджетов, банковские услуги) — то есть когда будет возможен большой gap между текущим финансовым потоком от пользователя и будущим (то есть сейчас платит, но уже решили все свалить). У Skype же микротранзакции, и проще не использовать достаточно спорные метрики, а плясать непосредственно от пользовательской базы, активности использования, и да, PROFITа в деньгах.
А то ориентируясь и оптимизируясь в сторону NPS, они привлекут и сделают счастливыми всех тех, кто никогда не платит, ну и счастливо закроются.
Впрочем, и без меня хватает и критики NPS, так и корпораций ориентирующихся на эту метрику, а сам докладчик уверял, что Skype еще сидит и намеревается сидеть дальше на экспоненциальной кривой роста пользователей.
Кстати, самая интересная тема связи внутренних и внешних метрик осталась нераскрытой и заявлена как открытый вопрос для последующих исследований.
А это реально интересно, плюс далеко не каждая компания может похвастать такой огромной базой пользователей и собранных с них оценок — уверен, если порыться в богатом наборе данных Datamining-oм — наверняка можно нарыть нетривиальные зависимости.
Отдел Качества в Крупной компании
Владислав Орликов предложил для мозгового штурма следующую задачу:
Есть компания, состоящая из нескольких проектных групп (то есть не функциональное деление по отделам, а проектное), каждая из которых включает кроме разработчиков и тестировщиков. Проекты-продукты этих групп имеют, как правило отдельных заказчиков, но при этом достаточно тесно связаны (это кастомизации базового продукта).
Есть нарекания на качество. Похоже, большая часть проблем связана с недостаточным интеграционным тестированием.
Есть небольшой отдел обеспечения качества (полдесятка тестировщиков), которому поставлена проблема радикального улучшения качества.
«Феодальные» проектные группы сами не идут на сотрудничество с «федералами».
Что делать?
Дмитрий Безуглый предложил внедрить классические практики автоматизированного интеграционного тестирования:
Continuous Integration, и далее собирать метрики сломанных сборок, и точечно разбираться с наиболее проблемными группами.
Отдельно стояла задача мотивации проектных групп к сотрудничеству, и обосновании необходимых изменений перед топменеджментом. Тут согласились в необходимости ретроанализа трекера дефектов, для выделения проблем интеграции и обоснования необходимости новых практик, внедрением которых и займется отдел качества.
Немало тупиковых ветвей было и откинуто при обсуждении — например, привязка финансовых штрафов-бонусов к метрикам качества[3], личная ответственность разработчика за прохождение интеграционной сборки и др.
На мой взгляд, это прекрасный пример конкретной и практической задачи, решать которую было и интересно, и полезно всем участникам — отхода от темы не наблюдалось.
Весь софт — отстой
Софт — отстой! Почему мы материмся на большинство программ и думаем «я бы сделал эту программу удобнее и понятнее». А приходим на работу и делаем софт на который кто-то другой (наш клиент) будет ругаться, при том что мы, совершенно искренне, считаем эту программу удобной.[4]
Ведущие — Алексей Лянгузов, Дмитрий Безуглый.
Ну уже из названия понятно, что это была взята слишком широкая тема, неизбежно приведшая и к флеймам и к оффтопикам.
«Почему все плохо?» и «Кто виноват?» — это все-таки риторика и тематика обсуждения металась аки «стрелка осциллографа»™.
Я взял на себя труд вести майндмап обсуждения, дабы хоть как-то структурировать и конспектировать обсуждаемые темы,
как я обычно делал на аналогичных обсуждениях (см. например, открытые встречи сообщества AgileRussia.ru).
а юзабилити-специалисты, часто растут из веб-дизайнеров, которые и под юзабилити понимают не базовые принципы, основанные на психофизиологических законах, изложенные например, в «Humane Interface» Джефа Раскина (см. кстати, наш семинар по теме), а колористику и прочую гламурность.
новые интерфейсы (тачпады, малтитач) тоже бросают challenge.
Но тема была настолько широка, что обсуждение скатилось несколько вбок и Дмитрий Безуглый попробовал свести ее к своей архитектурной теме[5], а именно,
безграмотности проектировщиков, не читавших книги «Архитектура программного обеспечения на практике», и не знающих о неразрешимых противоречиях групп атрибутов качества.
Например, заявлялись противоречия:
security vs. usability
из-за которых, вроде как WebMoney теряет аудиторию, сделав ставку на security. С другой стороны, успех Яндекс.Денег, не сказать, что сильно проигрывающий по security, явно этому противоречит.
performance vs. usability
вроде как не существует массовых порталов, удобных (и в частности, персонализируемых под пользователя). Опять таки сервисы Яндекса служат антипримером.
Ну, что тут сказать. Если бы можно было переиграть, я бы на месте ведущего сузил тему юзабилити, адаптировав ее к аудитории — «Usability и Тестировщик. Несовместимость или синергия?».
Ведь с одной стороны популярены взгляды, выражающиеся мифологическим «треугольником Дениса Бескова»,
где тестировщик томится в гоблинском тупичке (или вернее тролльском углу?), а юзабилист — несравненно прекрасный эльф
(да и по любым другим типологиям личности, Маерс-Бриггс/Белбин/Адизес… — «контроллеров» всегда сильно отделяют от «криативщиков»).
С другой — часто пользователей достает не общее, концептуальное несовершенство юзабилити системы (человек фантастически адаптивен, см. например заметку об адаптации пилотов вертолета Apache к dual-view шлему[6]), а мелкие несовершенства интерфейса, которые даже им, непрофессионалам, очевидно как улучшить, и наличие таких «заусенцев» воспринимается пользователем как выражение неуважения. Вот тут-то, правильный прокачанный в юзабилити тестировщик смог бы не только примитивно проверять тест-кейсы, но и выполнять юзабилити-аудит.
Звучит вроде как банально, но в большинстве крупных интернет-проектов вообще тестирование принято перекладывать на пользователей[7].
Вот такую тему точно надо поднимать, если мы не хотим, чтобы «весь софт был отстой».
IT-методологии и разработчик
Ведущие — Александр Кондаков, Дмитрий Безуглый.
На самом деле тема изначально заявлялась, как «Модели, методологии, стандарты и пр. или как «убить» ИТ-шника», но опять таки, пала жертвой широкой флеймогонности — не успел только Александр Кондаков ввести классификацию методологий («от инструмента», «тяжелые», «модные» — см. майндмап), немедленно начался классический срач «СMMI vs. Agile» (причем все присутствующим, думаю было понятно, что противопоставление CMMI с Agile некорректно, тему «CMMI не враг Agile» уже мусолят несколько лет — однако смысл понятен, в один угол ринга упали все методологии жесткого, инженерного типа, процессы которых прописаны в жирных XXX-BOK[8]ах, ГОСТах, корпоративных регламентах или забиты гвоздями в инструментах, а в другом — относительно неформализованные процессы, органически вырастающие в успешных командах.[9].
За «процессный угол» стал активно играть Дима Безуглый, за «Agile» играл зал, страсти были настолько накалены, что тема вырвалась из под контроля ведущего, Александра Кондакова, хотя он успел рассказать пару интересных и разнородных кейсов[10] из своей практики CMMI-оценивания европейских компаний.
Каюсь, даже я (Стас Фомин), сорвался с нейтральной функции секретаря-майндмаппера — «не могу молчать!» — ибо звучали утверждения противоречащие всему моему практическому опыту.
«Agile — это борьба с симптомами вместо болезни?» — Помилуйте. Это скорее итерационное лечение с диагностикой и экспериментами (по методу доктора Хауса) в противовес «лечению» от врача-чиновника-мудака, который не глядя на больного, выполняет набор предписанных Минздравом инструкций. И вообще, если притягивать медицинские метафоры к процессам разработки, то лучше сразу смотреть выступление Асхата Уразбаева «Процессные заболевания и методы их лечения» (по ссылке слайды со звуком).
Успешные Agile-команды не могут передать свой опыт и масштабироваться? — Опять мимо. Отлично работает и масштабирование, и «митоз» — деление команд с добором «новичков». И т.п.
Вывод — такие обобщенно-религиозные темы надо запрещать, как оружие массового поражения.
Вернее разрешать то можно, но с максимальной конкретикой — «в компании AAA мы/они пытались делать XXX (цели, размер, ограничения), были проблемы YYY, помогло ZZZ, а вот WWW совершенно не работает». Т.е. надо сразу отвечать на вопросы «Что? Где? Когда?», и только при наличие нескольких конкретных кейсов делать аккуратные обобщения.
Резюме
В целом удачное мероприятие, идеи по улучшению для организаторов я уже излагал, стоит только добавить пару советов участникам — сохранять скорее рабочий настрой и не зря на отдыхе не рисковать — ибо медицина в Египте не шибкая, стандартная туристическая страховка, как обычно отстой и не работает (в группе случилась травма). Т.е. спасение утопающих — дело их самих и с собой нужно тащить полный набор антибиотиков наружного и внутреннего применения. Я вот недостаточно собрался и не взял Левомиколь — и в результате, вот уже неделю после балансирую на грани приемной отделения гнойной хирургии.
Ну а теперь — благодарности:
Владиславу — организатору
идея новаторская, да и собрать даже пару десятков взрослых, географически распределенных, слабознакомых и неподчиненных людей — задача не из простых. Получилось! Спасибо!
Вообще надо подумать, как сделать задачу подобной организации легче, менее загружающей организатора, чтобы все происходило силами коммьюнити (через соцсети там, с использованием электронных денег), в несколько итерационных шагов — рекомендации участников, отбор-подбор, окончательная заявка об участии с внесением залога, окончательная оплата… Надо подумать.
Tiitу
Отличный специалист, свой парень, и кстати, ценный вид иностранца — говорящий на легко понимаемом английском с одной стороны, и при этом понимающий русский! Для меня, увы, не могущего на английском даже связно мычать (увы, без практики все атрофировалось), это было очень ценно.
Молодые девушки-тестировщицы
Отлично украсили и оживили все общество, мотивировали к интеллектуальным дискуссиям, и вообще, сильно, скажем так, поднимали настроение. Надо запомнить (к черту запомнить, запишу) — молодые девушки в теме, нужны и в проектных командах, и на собраниях, и на конференциях.
Всем участникам
Я отлично провел с вами время! Надеюсь, и вы тоже!
↑Впрочем, любой, кто захочет поднять тему «нет дихотомии CMMI vs. Agile», пусть сначала объяснит это Микрософту, с его четким делением Microsoft Solutions Framework-а на «MSF for CMMI» и «MSF for Agile»
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
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
