Slider Background

мая 2011

Отчет о поездке на девятую ежегодную конференцию SQADays-2011

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


О конференции
  • Программу и тезисы докладов можно посмотреть на сайте конференции - http://it-conf.ru/ru/content/366.htm
  • Сама конференция проходила в довольно необычном здании "it-парк". Снаружи - весьма футуристичное здание из стекла из бетона. А внутри... такое впечатление что дизайн интерьера дизайнеры придумывали по мотивам фильма "трон", причем его новой версии - светящиеся изломанные полосы по стенам и потолкам, микросхемы по стенам [1] [2].
  • как уже ведется по традиции на подобных мероприятиях, второй день был интереснее и динамичнее первого, хотя и первый был не плох (по сравнению с SoftwarePeople).
  • Основных трендов докладов было три:
    1. 1) Автоматизация тестирования. Люди рассказывали о своем опыте, своих граблях и конфетках. Признаюсь, это было одной из важных причин почему я туда поехал. В принципе, каких-либо откровений там сказано не было, но какие-то кирпичики встали на место. Основные тезисы:
      • Автоматизируя тесты, тестировщикам все равно придется становиться программистами, дело не ограничится тупым рекордом и воспроизведением. Хорошие тесты надо продумывать и программировать.
      • Важно, чтобы инструмент хорошо работал с тем ГУИ, которое используется в приложении, даже самый клевый тул будет бесполезен, если он не видит половины контролов.
      • Это дело дорогое.
      • ... но полезное, почти необходимое, когда проект перешагивает свой второй день рождения. Или по количеству тесткейсов - когда их становится больше ста, есть повод задуматься об автоматизации.
    2. 2) Всякие разные гибкие методологии. Были и откровенно детсадовские доклады - вот мы внедряли скрам и внедрили и стало нам клево. Были средненькие - общий обзор подходов Lean - бережливого производства, но без особой конкретики, то есть я понял, что люди читали по Lean, но не понял, почему они считают, что у них Lean. Но были и очень интересные и прикладные доклады - например про Канбан. Что это такое и с чем его едят я знал давно, но в теории. Теперь мне кажется что я постиг глубокий смысл. Был еще доклад про Кайдзен [3]. Сам не ходил, Катя хвалила.
    3. 3) Человеческий фактор. Методики методиками, но софт пишется людьми, и надо уметь эффективно взаимодействовать, договариваться, решать конфликты. Мне понравилось 2 доклада:
      • Управление командой в пляжных шортах. Про шорты, сознаюсь, я не усёк, но по смыслу было интересно. Пересказывать не буду - см. [4].
      • Мастер-класс "Работа с неконструктивными моделями поведения сотрудников". Это просто высший пилотаж. И хотя он шел довольно долго, и начало объективно было унылым, потом, когда слово взяли докладчики, начался драйв. Который я надеюсь всем нам передать на одном из ближайших семинаров. Тезисы см. [5].
  • Одним из докладчиков была Рита Сафарова (для читателей не из СМС-ИТ и просто новеньких – это наша бывшая коллега, которая уехала в Москву). Рассказывала про аудит процессов тестирования, например при смене проектной команды. Довольно интересно, нам, пожалуй, подобный аудит был бы в тему. Передавала всем привет (ПРИВЕТ!), и мы с ней даже сфоткались около дерева с квадратными мандаринами (видимо от эл/магн излучения).
О Казани
  • Город мне понравился. Мы жили в исторической его части, нет машин, почти нет людей, очень романтично. От отеля до мероприятия мы ходили пешком, по красивой пешеходной улице, типа нашей Ленинградской. Кстати, она называется Петербургская.
  • В Казани очень необычная архитектура. Помимо старинных зданий, очень много новых, и все каких-то невообразимых стилей. Полный беспредел архитекторов, при этом все очень стильно и современно.
  • Кремль - ну это просто кремль. Совсем другой чем в Москве. Мне все время казалось что я попал в фильм про Ивана Васильевича. "..Казань брал, Шпака не брал"
  • Одним вечером мы пошли искать казанский собор. Увидели замечательно красивое здание, напоминающее Исаакиевский собор в Питере - полукруглые купола, колонады. Подошли вплотную - оказалось мин. сельского хоз-ва Татарстана :) Но зато какое там дерево у входа!
... и вообще
  • Про дорогу. когда я, сидя в автобусе, не попадал пальцами по кнопкам нотебука, я радовался что поехал не на своей машине. Дороги - УГ.
  • Наши люди ни с одной конференции не возвращаются без подарков. Кате повезло - ее анкета оказалась счастливой (особенно повезло что мы ее всунули в руки тетеньке когда она уже сказала - а сейчас мы будем разыгрывать призы по анкетам), так вот, Катя выиграла какую то страшно умную книжку от Хьюлета Паккарда, наверное что то про тестирование.
  • Рита, кстати, тоже что-то выиграла, как молодой, но перспективный докладчик.
Резюме
  • Очень правильно что мы там были
  • Надо обязательно быть на осенней, 10-й конференции...
  • .. при этом очень реально быть там в качестве докладчиков. По уровню многих других докладов - мы потянем. Главное найти интересную тему. (бонус - для докладчиков участие бесплатное)




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

  • бесполезно идти к менеджеру и тупо просить больше денег. "Хочу получать больше". Вопрос - за что. Не просто требовать денег, а узнать, что можно и нужно делать мне в этой фирме чтобы получать больше.
  • американцы о нас: "русские предпочитают догадываться там, где надо просто знать". В диалоге не надо угадывать. если что-то важно, то надо просто спросить. "Ага, вот тут он заволновался, что то тут не так". Не надо ловить подрагивание века и потение ладоней, мы все такие блин психологи.
  • болевые точки в диалоге - страх, вина, будущее.
  • выяснять истинные причины ситуации, а не лежащие не поверхности. 5 почему.
  • четко ставить задачу. а потом переспросить - правильно ли нас поняли. "Иди там посмотри ХМЛ парсеры". Через 3 дня результат - сравнительная таблица производительности парсеров. Ожидалось - найти бесплатный компонент и прикрутить к проекту.
  • дело может подвиснуть, потому что человек не умеет сделать. А потом не умеет сказать об этом.
  • техника эффективной переписки - писать в subject четкую просьбу. (не "стул", а "новому сотруднику Иванову нужен стул, к понедельнику)
  • наблюдая поведение человека в точке, нельзя сделать никаких выводов. Непонятны причины. Нужно смотреть историю, и найти момент когда поведение изменилось.
  • людям важно понимать, зачем им делать что-то по правилам. Иначе неприятие.
  • слишком частый контроль раздражает - для одной стороны он может и не частый, а для другой он неоправданно частый. Нет договоренностей об ожидаемой частоте.
  • Мысли лидера транслируются на команду. "... заказчик сам не знает чего хочет...", или "... ну мы по любому не сделаем это к марту...". Люди ведут себя неконструктивно, так как берут с кого-то пример.
  • Самая жесткая критика - критика прошлого ("Посмотрел я ваш код - полное ..."). Прошлое поменять нельзя, остается только защищаться ("да ты сам это слово"). Для решения проблемы надо смотреть не назад а вперед.
  • Решать не человека а проблему. 
  • Прежде чем решать надо определить проблему: - влияет на работу? - если не решить то будет ли хуже? И решать только в этом случае.
  • Иногда человек может быть поглощен своими глубокими, может быть личными, мыслями, и не воспринимать никакие посторонние, для него менее важные. Просто нет свободного места в голове, мозг пухнет. Это надо вовремя замечать, и перенести разговор на попозже, когда давление ослабнет.
  • когда идем к шефу и несем свою проблему, мы не знаем о его проблемах и его ограничениях. ! сюрприз. и начальники работают в рамках своих ограничений - бюджет, законы, проектные соглашения.
  • иногда лучшая техника переговоров - заткнуться и слушать.
  • люди будут делать не то, что вы ожидаете, а то, что вы проверяете
  • контроль может быть и позитивный. Дать понять человеку что все сделано ОК и он молодец.
  • техника оценки идей - perfection game. Каждой идее даем оценку от 0 до Х баллов. Если оценка меньше Х, то надо предложить (Х-N) улучшений для этой идеи, чтоб она стала идеальной. Нечего предложить - считаем идею идеальной.
  • Книга - Эрик Берн. Лидер и группа

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

Подробнее

Мы на SoftwarePeople 2011

C 7-9 апреля в столице нашей Родины прошла конференция "Software People 2011" (http://softwarepeople.ru/2011/).
От нашей фирмы там была делегация из четырех человек: Парфенов, Липатов, Маурин, Трешников Паша.

Программу семинаров и тезисы докладов можно посмотреть тут: http://softwarepeople.ru/2011/program/
Скоро ожидается публикация видео докладов и презентаций.

Личные впечатления

  • Первый день был скучноват. Высокие иностранные докладчики рассказывали азбучные истины или лили воду. Или это мы стали такие умные что все это уже знаем, или проблема в докладчиках.
  • Апофеозом первого дня был заключительный доклад тетеньки из UsabilityLab про взаимоотношения в команде. Ждем видео чтобы показать его всем у нас.
  • Другим сюрпризом первого дня стал восходящая звезда Самарского и Российского программирования - Кирилл Маурин, который в неравной борьбе (он всех делал как котят) ответил почти на все вопросы в викторине по функциональному программированию, и получил 3 из 10 ценных приза - книжки по языку F#. (дали только три, потому что под конец ему стали давать уже через одну, чтоб досталось и другим)
  • Второй день был более насыщенным и интересным, было много хороших докладов, так что мы порой разрывались - куда бы сходить. Временами даже бегали туда-сюда между залами чтобы урвать от двух докладов сразу.
  • Хронометраж выдерживался четко - реально было успеть сменить зал между докладами
  • Кормили много и вкусно :)
  • Мы очень здорово пообщались с нашими Самарскими коллегами, у которых уже несколько лет используется скрам, и даже позвали их к нам в гости обменяться опытом
Записки из блокнотов
Почти записки на манжетах, те важные мысли из докладов, которые мы фиксировали чтобы не забыть.
  • Автоматизация тестов - необходимо готовить код к тестам. Возможно выделять собственное АПИ для тестирования логики.
  • Статический анализ кода надо делать. В Дельфи ХЕ есть встроенные средства. Пока не перешли - надо найти аналоги для 2007.
  • В больших продуктах (читай заявки) полезно разделять команды на две. Первая занимается развитием ядра продукта. Вторая - выпуском и доводкой релизов, багфиксом-поддержкой. Для разных команд разное планирование.
  • Creately - онлайн тул для рисования всяких диаграмм (вместо визио). Интеграция с вики
  • Любой программист должен уметь подхватить проект.
  • Необходимо постоянно "жить" с командой, а не только работать
  • Нет плохих заказчиков, отношение к заказчику должно быть всегда исключительно хорошее
  • Чем более работа руководителя "незаметна" в команде, тем эта работа лучше
  • Команду тестирования необходимо интегрировать с командой разработки
  • Крайне желательно осветить подробно ограничения популярных методологий (Agile) и методик (TDD). Очень уж много некритичной рекламы.
  • Чтобы команда лучше работала, главное ей ... не мешать
  • Людей полезно раз в полгода-год переводить на другой проект
  • Большие проекты надо бы пилить на общие библиотеки и конкретные приложения
  • Аналитика-разработка-тестирование должны выполняться одной общей командой в одном помещении, а не тремя разными
  • Функциональное программирование уже скоро может оказаться не экзотикой, а мейнстримом.
  • Работать с требованиями – это как ходить по воде. Удобнее, когда и то и другое заморожено. Но замораживать требования в нашей работе не всегда получается. Необходимо использовать итерационный и инкрементальный процесс разработки. Это позволяет избегать высоких рисков,связанных с "непониманием" клиента, бизнес-процесса и т.д.
  • При постановке задачи необходимо:
    • описывать что достичь, а не как
    • четко оговаривать время выполнения задачи и доступные ресурсы
    • объяснять что произойдет если задача не будет решена вовремя
    • контроль поставленных задачи должен быть неизбежным, так же как восход солнца
  • Пул задач команды, который находится в разработке должен быть соизмерим с пулом задач находящимся в тестировании и в аналитике. Не более и не менее, иначе одна из активностей (аналитика, разработка, тестирование) начинает простаивать(задач нет) либо из за перегрузки тормозить вес процесс(задач много).
  • При решении задачи отвечать на сначала на вопрос "что должно быть сделано?", "зачем это должно быть сделано", а после этого уже на вопрос "как это должно быть сделано?"
  • Не надо увлекаться методологиями(agile круто!) и пытаться их внедрить полностью если это тормозит общий процесс разработки. Надо выборочно использовать полезные практики из различных методологий.
  • Поискать описания использующихся бизнес процессов в компании Toyota - бережливая разработка и канбан пришли именно оттуда






Подробнее