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

Впечатления от 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 under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

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

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