К основному контенту

Впечатления от Software People 2012 - день 1

В этом году в первый раз посетил конференцию Software People. Что могу сказать? Мне понравилось. Постараюсь приехать и на следующую встречу.

Большое спасибо организаторам за их труд!
Организация на уровне, качество докладов тоже. Много знакомых по онлайну лиц :)
Первый день. Утро. Народ только подтягивается. (с) Г. Грубский

Единственный недостаток, это зал № 2 (он же 3, если начинать считать с "главного"). Я не понял зачем там были столы, но они очень мешали и съедали много места. Собственно из грустного - все :)
Всю программу можно посмотреть здесь, организаторы обещали выкладывать слайды и видео по мере обработки. Надеюсь мои комментарии к докладам помогут немного сориентироваться при выборе темы для просмотра.

И так, коротко о тех докладах, что мне удалось посетить.

1. Первый день открылся докладом Джеффа Де Люка, попытавшимся ответить на вопрос "Why we fail". Я, если честно, ожидал большего, интересные моменты были, но терялись на общем фоне.
Доклад можно спокойно посмотреть просто слайдами, не теряя времени на видео. Я честно исчиркал 2,5 страницы блокнота из комплекта участника, но думаю зря.
Зацепившие вещи (в виде твит-сообщений и с моим переводом :)
"Знаем что надо делать просто, но делаем сложно"
"Сконцентрируйся на маленьком кусочке задачи, чтобы выполнить всю целиком"
"Консенсус - это то, с чем каждый может жить, работать, поддерживать. Но это не означает, что это  тебе нравится."
Прозвучал интересный термин "боязнь успеха". Видимо мой английский меня подвел, но из общего у менеджеров и подчиненных - это "возможное уменьшение влияния и статуса при успехе"... (Странно. Надо будет пересмотреть что ли, думаю упустил какой то момент.)
"процесс это вторично, важно уделять внимание проблемам людей"
В общем все достаточно очевидно, возможно именно это и зацепило :) Повторюсь, все есть на слайдах, который сделаны в "лучших" традициях: много текста.

2. Вторым докладом для меня было выступление Сергея Высоковского про проектные карты.
Сергей попытался придумать еще один способ визуализации хода IT проекта.
Первая моя мысль через 5 мин: было сравнение IT проектов и их участников с лечением и врачами (знаменитый доклад Иван Селиховкина на первой Стратоконфе, автора практического курса  PMBOK за 5 дней), а тут сравнение с военными действиями. Проект - это война! Ужас :) Обычно для контроля за состоянием проекта используют диаграммы Ганта. Но на них сложно отобразить дополнительную работу, которую потребовалось сделать члену проектной команды, для доведения функционала до релизного состояния. Сергей предложил использовать для отображения объема первоначальной работы разноцветные фигурки, площадь которых соответствует временным затратам. Для каждого типа работы (аналитика, разработка, тестирование) используется свой цвет. Соответственно, если возникла доработка - в соответствующей области появляется более темное пятно, отражающее эту доработку и ее объем. И простой паттерн: чем больше темных пятен, тем хуже дела идут на проекте. К недостаткам можно отнести абсолютно ручной способ отображения работы в палитру :) Но в целом интересно и главное - Сергею это помогает.

3. Третий доклад я себе не смог выбрать, о чем нисколько не жалею, потому что здорово пообщались с Ромой Юферевым в кулуарах. За что ему большое спасибо :)
Владимир Иванов (Рутокен), я, Рома Юферев (VIA Code) (c) Г. Грубский


4. После вкусного обеда был классный доклад Асхата Уразбаева (@zibsun). Думаю тут реклама будет излишней - это просто ОБЯЗАТЕЛЬНО надо посмотреть в видео. Слайды можно посмотреть уже сейчас. Не буду заниматься плагиатом, ИДИТЕ и СМОТРИТЕ :) Небольшие пояснения к слайдам (пока нет видео): вордкаст :)
"Надо перестать обсуждать проблемы, а начать обсуждать возможности"
"Скорость вашего улучшения зависит от скорости вашего изменения"
"Нам не выделяют на это время" (о, как часто я это слышу) = скорость улучшения равна 0!
"Слайды 30->31: заводим область Code Review на доске"
"Слайды 32->33: ограничиваем количество задач в области Code Review"
"Слайды 34->35: пишем оценки на обратной стороне карточки"
"Слайд 36 - no comments :)"
"Слайд 37 - чек-лист сына Асхата, по подготовке в следующему учебному дню. Круто, 3-й класс!"

5. Комменты к следующему докладу Влада Балина уже написал @COTOHA Идем и читаем, зачем я буду дублировать? :)
Интересные цитаты из доклада


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

Немного из кулуаров
После моего комментария после доклада Де Люка, про очередное отсутствие "серебряной пули" @vov_ivanov (Владимир Иванов) мгновенно выдал "зато бывает серебряная дуля" (с)  @vov_ivanov

Стас Фомин (@belonesox) "Джоел Спольски любит программистов, они любят его. Но код они пишут дерьмовый" :)

Продолжение следует... уже есть

Update: появилась возможность посмотреть доклады в записи 

Комментарии

  1. Максим! Супер! Рада, что понравилось!
    Теперь ждать супер-результатов? ;-)

    ОтветитьУдалить
  2. А есть сомнения? ;) Это же уже известная тема: отправишь сотрудника на конференцию - жди рационализаторских предложений :) Поэтому многие и не пускают =)

    ОтветитьУдалить
  3. Ну Ваши то не такие, раз "пустили"))

    ОтветитьУдалить

Отправка комментария

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

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

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Полезные ресурсы для молодых (и не только) тестировщиков

Уже 3 месяца провожу собеседования тестировщиков.
Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.