28 ноября 2014

Грех геймификации

Для начала короткометражный фильм, чтобы настроить вас на нужный лад.
В течении последнего месяца по утрам я посвящал 40-50 минут своего времени просмотру курса геймификации (слово игрофикация меня разбирает на запчасти) от Coursera.

Вообще тема геймифиации стала для меня актуальной почти год назад когда перед моей командой встала задача обучения соседнего отдела автоматизации тестирования.
Именно тогда - то есть год назад - первый раз мы подумали с моим коллегой, что просто так заставить людей делать что-то не получится и решили давать за небольшие достижения маленькие сладкие ачивки.Для себя мы тогда разделили процесс обучения на три уровня (дада, levels) - естественно никаких уровней на практике у нас не получилось.
Механика вознаграждения сладким - работала, но геймификацией это было назвать нельзя.

Вернусь к теме - курс который вы можете посмотреть на Coursera не сделает вас гуру геймификации. И даже специалистом - тоже не сделает. Скорее он даст вам хорошую обзорную картину того что это такое на самом деле.

А вот обращаться с этим, пусть даже и обзорным знанием, нужно очень аккуратно.
Потому что если у вас получится зацепить людей и заставить с помощью игровых механик делать то что нужно бизнесу (ну или конкретно вам:)), то остановится уже вряд ли получится.

Геймификация  - это не тимбилдинг, который начался и закончился.
Это то что нужно поддерживать, отслеживать, вовремя улучшать, а иногда и вовсе менять на лету.

Вы вряд ли найдете хороший учебник по геймификации, хороший тренинг или курс. Это все только нарождается. И мне кажется что люди которых называют гейм-дизайнерами знают об этой области больше, чем профессора из Уортона (курс вел Кевин Вербах из Уортона).

Курсере спасибо за неплохой курс.

P.S. Мы сейчас как раз находимся почти на пике гартнеровской кривой хайпа по теме геймификации. То есть скоро будет много вони на тему "Геймификация мертва", "Как геймификация убила мою компанию", а вот уже после - начнется реально интересный период использования ее во многих  сферах.


24 ноября 2014

Напочитать: Важнейшим из искусств для нас является YouTube

1. Mob Programming от автора концепции


Mob Programming, A Whole Team Approach from Øredev Conference on Vimeo.


2. Ольга Павлова про обучение. Тончайший, я бы даже сказал прецезионный, троллинг. Умница.



3. Роман Сальников срывает покровы с мощи Chrome Dev Tools. Тестировщикам вэб-проектов обязательно к просмотру.
Роман Сальников, 2GIS | Суперсилы Chrome Dev Tools | FrontTalks 2014 from FrontTalks Conference on Vimeo.

4. Борис Вольфсон про ретроспективы.



Презентация c выступления на slideshare


5. Kristian Karl  о том как команда вписывалась в Continuous Delivery. Отедельно хочу заметить, что ближе к концу видео есть схемка процесса которая четко показывает (да и спикер сам говорит) что delivery pipeline у них начинается уже после того как прошло тестирование.


Testing in Continuous Deployment from Øredev Conference on Vimeo.

6. Евангелись web performance про нововведения на уровне стандартов

18 ноября 2014

Мероприятие: Agile Te(Wa-)sting Days 2014

Больше никогда.
Эдгар Аллан По.

Это была первая и, наверное, последняя конференция по тестированию в Европе,которую я посетил. Это не Testing Days - это Wasting Days.

Место. 

отель Dorint, Потсдам, Германия.
Место проведения - хорошее. В отличии от всех отелей в округе в этом есть интернет, и не просто интернет,а  нормальный интернет - поверьте мне, в Европе найти нормальный интернет в отеле и не за деньги - непросто.

Конференция шла в 5 потоков, а воркшопы  - в 10 (!), в связи с чем приходилось много перемещаться по отелю.


Организация.

на 4+. Сказать что ребята делают что-то из ряда вон нельзя, но все что нужно - есть.
Самым большим косяком на мой взгляд было то, что организаторы конференции полностью упустили что люди могут захотеть пообщаться около whiteboard-а или flipchart-а. То есть встать и поговорить с интересным тебе человеком на интересную вам обоим тему, порисовать что-нибудь или организовать большое обсуждение было сложно. Но, это все мои придирки :).

Что еще хочется отметить - это то, что наверное большая часть бюджета была вложена в то чтобы кормить (на убой)  и поить (вусмерть) участников конференции. Этого было пожалуй слишком много - я туда за знаниями приехал, а не пожрать.


Доклады.

А вот тут самый большой промах и полное фиаско всего мероприятия.
Первое - keynote-доклады в очень редких случаях действительно несли какие-то значимые мысли. Мы уже Agile, давайте будем еще более Agile, пусть все будет Agile... 
Единственным человеком который сделал хороший keynote был Joe Justice из ScrumInc. , но про него отдельно.
Очень мало технических докладов, больше пропаганды и говорильни.

Те что понравились:
1.Clean Test Code by David Voelkel - хороший доклад с демонстрацией того как писать чистый тестовый код. Докладчик работает в Codecentric AG всем советую обратить внимание на их технический блог.
2. Performance Quality Metrics for Mobile Web and Native Applications Andreas Grabner - классный доклад о том зачем вам нужны метрики и какие именно. Очень ярко рассказал о кейсе Runtastic - чтобы поймать баг  с неправильным подсчетом расстояния по GPS ребята встроили в приложение запуск юнит-тестов и только так им удалось выяснить что баг  есть только на определенной версии Android от определенного вендора.
3. Test First Saves the World, Joe Justice - пожалуй самый живой из всех спикеров.  Отличный доклад о применении практик TDD при разработке железяк - автомобилей, комбайнов, самолетов.

Также Джо с командой притащили автомобиль который собирали в 4 спринта  4 команды. Автомобиль был без двигателя и ходовой, только большие узлы. На примере этого проекта очень хорошо было видно насколько сильно процесс зависит от квалификации людей - ребята из команды WikiSpeed были как раз проводниками в мир автомобилестроения для каждой из команд.
Также Джо упомянул об еще одном интересном проекте  - http://eduscrum.com/ - SCRUM для обучения старшеклассников.

4. We Are the Robots: Agile Testing for Future Robotics ,Daniël Maslyn - отличный доклад о том что в производстве робототехники никто не знает слова Agile но все его делают. Для этого большинству людей причастных к робототехнике приходится знать мехнику, элетротехнику и уметь писать код. И они не называют себя agile, а просто делают свою работу. Очень глубокий экскурс в робототехнику. С Дэниелом мы проговорили еще часа 2 =).

5. BRUTAL CODING CONSTRAINTS , Peter Koefer, Martin Klose - отличный воркшоп по TDD.  Авторы воркшопа практики - поэтому без лишних  объяснений тебе дают две бумажки А4 на которых написаны ограничения, и задачу - написать через  TDD крестики нолики, для начала просто кусок кода который проверяет выиграл ли кто-то партию. Если вы думаете что это так просто - то нет, не просто. Мне в пару дали Ruby-программиста (прикиньте, живой! Ruby(!!!)-программист) и мы стали думать над дизайном. Из группы в 12 человек никто не дошел до реализации самой игры. TDD - это сложно, но может быть полезно.

Это были те 5 лучших докладов которые я посетил за три(!) дня.
Посещал больше, но они все были мягко скажем не ахти.
Очень сильно разочаровали консультанты которые пытались провести воркшопы - просто отвратительная работа с аудиторией, даже продать себя как консультанта не пытаются.


Итого

При цене в 2000 евро, без записей докладов на которые ты не попал, и такими докладчиками я бы назвал эту конференцию переоцененной.
Многие с кем я общался на конференции, особенно из разработчиков (дада, разрабы посещают конференции тестировщиков) придерживаются того же мнения - overprice.


Был рад познакомится с кучей коллег из Риги, Питера и Москвы.
Вряд ли поеду еще раз, по крайней мере на эту конференцию точно.

P.S.  глядя на такое начинаешь по другому смотреть на SQA Days. Не все так плохо в нашем королевстве.

10 ноября 2014

Книга: Михай Чиксентмихайи: Поток. Психология оптимального переживания

Недочитал - надоел он мне.
Когда-то давно  я кинул свой взор в сторону психологии. И напоролся на Эрика Берна.
Его я кстати тоже недочитал - слишком уж глубоко Берн роет.
Это была попытка номер два, которая тоже провалилась. Но кое-какую пользу извлек.

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

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

Каждый (ну или почти каждый) человек переживал потоковые состояния, и лишь единицы психологов проанализировали его.
Итак, самая суть.
Потоковое состояние у человека наступает при наличии как минимум 4 условий:
  1. Задача по силам
  2. Есть возможность сосредотачиться на задаче
  3. Можно чётко сформулировать конечную цель задачи
  4. Можно немедленно получить обратную связь

А  признаки этого потокового состояния таковы:
  1. Увлечённость субъекта настолько высока что он забывает о тревогах и проблемах
  2. Ощущение полного контроля над ситуацией
  3. Исчезает осознание собственного я, человек становится частью процесса
  4. Изменяется восприятие времени - оно не имеет значение.
Есть еще пара хороших и глубоких мыслей, к сожалению не развитых.

Теперь печальное - все описанное выше намазано на первые 80-100 страниц. Далее книга изобилует примерами состояния потока, чтобы читательно ну уж точно понял что это такое.

Отвлекаясь от книги, могу сказать что гейм-дизайнеры освоили состояние потока куда лучше психологов, и не с теоритической, а с практической точки зрения.
Основная польза книги пожалуй сводится к двум нумерованым спискам выше по тексту.


Общая оценка: 6/10.

07 ноября 2014

Книга: Элияху Голдратт. Цель-2. Дело не в везении.


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

После прочтения первой Цели я ждал от этой книги дальнейшего объяснения теории ограничений, но данная книга посвящена гораздо более сложной области знаний и навыков - поиску конфликтов ,нахождению корня конфликта, поискам неверных предпосылок а суждениях и разрешению конфликтов.

Вся эта простыня знаний заключена в набор инструментов под названием "мыслительные процессы"... о которых вы не узнаете толком из этой книги :).

Цель-2 рассказывает и даже старается вам показать на примере главного героя книги (напомню, жанр - бизнес-роман) о том как этим можно пользоваться, но не расказывает конкретно про сами инструменты, про методику их использования.

Эта книга во многом про маркетинг в самом лучшем смысле этого слова (да, наверное таковой есть :)) и сама кстати говоря является фрактальным воспроизведением идей в ней изложенных - Голдратт точно также привлекает вас к теории ограничений и его мыслительным процессам, как и главный герой решает проблемы доходности вверенных ему фирм.

Прочитать стоит, вчитываться основательно - не думаю, что не сразу.
Для того чтобы познакомится с мыслительными процессами Голдратта и инструментами есть отдельная книжка Уильяма Детмера, обзор которой появится в моем уютненьком сразу же по прочтению. А вот после - может быть и следует вернутся к этой книге чтобы разобраться на примерах.

И в качестве постскриптума 
1. очень многое из того что описывается в книге можно натянуть не только на бизнес в целом но и на меньшие масштабы - взаимодействие отделов. 
2. Жанр-бизнес романа который я после прочтения первой Цели чмырил не так уж плох если убрать из него совсем уж розовые сопли.

Оценка 6/10.