Technology Radar - Январь 2015, итоги 2014

Вышел очередной Technology Radar - пожалуй единственный дайджесn того что происходит в мире технологий.

Ниже мой субъективный обзор последнего радара (то за что зацепился глаз).
1. Канареечные билды (Canary Build) как техника интеграции с новыми версиями зависимостей.
2. ATOM-фиды для передачи как средство асинхронной передачи цепочек событий  - отличная оригинальная идея, надо пробовать.
3. Упор на local storage и синхронизацию - очень большое поле для граблей.
4. Использование механизмой заложенных в криптовалюты как proof of work для банковских и прочих приложений.
5. Лютый buttheart  у меня вызвал тренд на использование языков программирования (давайте честно - Python!) как средство допиливания CI/CD - сколько боролись, а оно все живо. Тваюмать!
6. Mesos - пожалуй это будет buzzword следующего года.
7. Jackrabbit Oak  - непонятно зачем и откуда идет тренд.
8. Netflix OSS - ну так как его пиарили, совершенно неудивительно что поперло.
9. Software Defined Network - а вот это да, сурово, страшно, но видимо нужно.
10. Nashorn... Пусть говорят. Пока только Netflix показал напаркуа оно.

Что бросилось в глаза еще - попытки воскресить Haskell и набор странных инструментов (Postman, Retrofit, Dashing, Balckbox, бла-бла-бла), которые проще сделать самому и под себя чем опиливать готовое.

Прямой линк на скачивание.
Почитать онлайн.

Напочитать: Человеколюбивое

1. "Несколько недель спустя мы поняли, что этот подход не имеет ничего общего с реальностью." -  том как "Кнопка" внедряла холократию.
2.  Математики все-таки пытаются описать кашу в головах людей. Получается у них, честно сказать, хреново, но подвижки есть.
3. Эксперимент "Вселенная-25".  Я просто процитирую.

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

4. "We have no managers, not even a CEO, None of the 30+ consultants are actually employed by Crisp" - О том как одна из самых успешных консалтинговых фирм управляет собой - теперь в open-source.
5. Очень большое интервью о религии и теологии. Быть атеистом  - это тоже самое что каждое утро вставать и тащить себя в тренажерный зал и заниматься там - тяжелая работа над собой, с травмами, растяжениями и полным отсутствием гарантий увеличения продолжительности жизни. А быть верующим - это просто и естественно, как валятся в кровати.
6. "Для начала оплатить конференцию самостоятельно.Ехать одному или максимально отделиться от коллег.Победить социофобию - подойти и спросить.Не уходите сразу после последнего доклада." - Максим Захаров простыми словами о том как ходить на конференции

Напочитать: React-ивный однострочный выпуск.

1. Отличный крэш-курс по началу работы с PowerShell.
2. Виртуалка из VirtualBox в VmWare - да, теперь легче.
3. React... каждый  год в мире фронтенда появляется очередной "убийца" всех предыдущих достижений. Но в этот раз все серьезно - Netflix и Facebook как бы одобряют. В связи с чем и нам пора бы посмотреть в ту сторону. Раз и два (на мобилках,но нативный)
4. Тесты на JavaScript в Java... Netflix Test Studio - читать тут. Естественно Nashorn и Java 8.
5. Тормозит Android приложение????  Может быть это потому что его написали на Groovy 2.4, который теперь официально поддерживает Android-разработку (вот и примеры уже подоспели). Правда теряет контрибьюторов.
6. В Microsoft родили первый Docker image. И с чем бы вы себе думали??? С ASP.NET 5.
7. О том почему не нужно шарить код между микросервисами. И это  имхо правильно - грабли и баги должны быть в одном месте, нефига их шарить в виде библиотеки.
8. Джери Вайнберг о том во что превращаются хотфиксы - от 42 миллонов до 1,1 миллиарда долларов.
9. Отличный вводный курс про Annotation Processing в Java.
10.  Microsoft заопенсорсило свою сериализацию  - Bond - правда с компилятором на Haskell :)
11. BTrace...Я о нем уже когда-то писал, но он до сих пор не сдох и выглядит няшно. А еще ведь есть Byteman.
12. О том как искать долгоиграющие потоки в Java простым кодом - тут.

P.S. Гуманитарный скоро.

Ретроспективы в командах: Начало и сбор данных

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

Итак вы собрали своих коллег или подчиненных в одной комнате, отрезали им путь к отступлению и вот-вот начнете ретроспективу.

С чего начать это действо?
Я рекомендую с подготовки самого себя и мероприятия.
Что нужно сделать:

1. Забронировать переговорку
2. Листы А3 и больше, маркерная доска или флипчарт тоже подойдет.
3. Маркеры
4. Можно стикеры, можно без них.
5. Если есть возможность - вода в бутылках 
6. Пара явных проблем или хороших моментов, которые уже можно повесить на доску
7. Результаты улучшений с предыдущей ретроспективы (если они есть и если положительные)

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

Начало.

Вот теперь точно все - все кто нужен все в комнате, доска или листы на которых можно визуализировать подготовлены, можно начинать. А с чего начать? Этот вопрос стоит еще более остро если вы делаете ЭТО в первый раз.

Лично я задумался над этим вопросом тогда, когда пригласил на ретроспективу  команды сторонних людей.
И вот тут встала задача: с одной стороны у меня есть команда которая уже знает и понимает что к чему, с другой - люди которые вообще в этом вот первый раз, и надо быстро привести мозги вторых к состоянию мозгов первых - вопрос как ?

В таком случае я рекомендую начать с мантры.

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

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

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

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

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

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

Сбор  данных.

Существует тьма приемов собрать и структурировать информацию на ретроспективе.
Сколько я их не крутил у меня наибольшую эффективность показывает обычная классическая доска.

У нас она выглядит так.

Названия колонок мы обычно не пишем, а рисуем смайлики.
Почему именно такие колоки? Выработано методом проб и ошибок. В настоящий момент команда является географически распределенной, поэтому есть специальная колонка "Просто  было" которая позволяет свести  воедино видение всех членов команды о самых значимых событиях за рассматриваемый период. Иногда из этой колонки удается узнать что-то интересное.

Про колонку "Хорошо" рассказывать особо нечего. Если команда не видит у себя ничего хорошего - то это с одной стороны проблема которую уже надо решать, а с другой стороны у нормальной команды эта колонка всегда самая "худая" - в колонке "Плохо/Улучшить" всегда больше.

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

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

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

При сборе данных нужно соблюдать несколько рекомендаций:

1. Каждый может написать то, что считает нужным в любую колонку
2. Мнения могут расходится и это нормально (такая халява для фасилитатора бывает, но редко :)). Расхождение мнений как раз отличный материал для дальнейших обсуждений. 
3. Каждая записанная мысль должна быть понятна всем участникам (и переформулирована так чтобы была понятна )
4. На ретроспективе нет никаких "Они плохие", есть только "Что мы можем с этим сделать?"

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

Теперь хочется рассказать немного о том чего следует избегать при сборе данных.

Социальные моменты при сборе данных.

В ретроспективе у вас участвуют люди, между ними есть какие-то связи, и не всегда положительные. Можно свято верить в то что все на ретроспетиву приходят с чистой головой и холодным разумом, но контролировать процесс все-таки нужно. Первое место - сбор информации.
Что бывает:

1. Конфликт между двумя и более участниками команды. Обостряется когда один из конфликтующих вывешивает проблему на доску, а оппонент(-ы) начинают "запинывать" проблему в обсуждении пытаясь убедить всех что это не проблема.
2. Решение проблемы большинства. Ситуация: в команде 5 разрабов и 1 тестировщик. Вполне естественно что 5 разрабов видят может быть в 5 раз больше проблем в разработке, чем один тестировщик в тестировании. Но это совершенно не повод не обсуждать и не решать проблемы связанные с тестированием.
3. Проблема-беспризорник. Вся команда знает что существует проблема, но никто не хочет вешать ее на доску чтобы потом самому же ее не решать.  Обычно это признак глубокого технического долга и не первой стадии морального разложения коллектива. Частный случай данного паттерна - решение только "удобных" проблем или переформулирование проблемы тактм образом чтобы не касаться ее действительного решения.  
4. Проблема не на нашей стороне. С наличием проблемы все согласны в ходе сбора данных, но она вдруг становится "не нашей" проблемой, в ходе ее более глубокого рассмотрения.
5. Нытье. К сожалению это так -  если вам удалось внести людям в голову ощущение безопасного места для анализа происходящего, то они могут начать ныть. Это бывает, можно даже сказать что бывает со всеми время от времени. Мой рецепт тут прост - дать время наныться, а потом методично загонять в сторону решения проблем. Просто "нажать" на одного конкретного "нытика" или "нытиков" нельзя - таким простым движением вы показываете внутренним нытикам каждого человека  (а они есть у каждого в той или иной степени)  что здесь ему - нытику - не безопасно.
     

Это те социальные моменты которые встречались мне, список естественно может меняться.

Самое главное от чего я хочу вас предостеречь - не нужно продавливать команде решение "настоящих проблем" по крайней мере на первых ретроспективах пока у вас этот процесс налаживается.

Пусть команда привыкнет к практике. Если все получится сделать правильно они сами со временем найдут и вытащат на доску "настоящую проблему" и будут ее решать.
Привычка анализировать и решать свои собственные проблемы  гораздо важнее решения конкретной проблемы.

Если вы менеджер или тимлид, то сбор данных на ретроспективе может быть для вас очень ценным источником информации о процессах взаимодействия и конфликтах в команде.
Проблема тут только в том, что неожиданные факты и нюансы взаимодействий вы можете увидеть только на ретроспективе, а проанализировать вы сможете их только потом.

Писать далее общие мысли на тему сбора информации лень, с удовольствием отвечу на вопросы.

Software Stories: Про ROI и смелость

- Деда, а что такое ROI ?
 - ROI... Это ты где такое слово-то услышал, внучок?
 - Это нам в школе на уроке Test Management-а сказали. Сказали, что когда планируете автоматизацию тестирования нужно сначала посчитать ROI.
 - Посчитать... - дед выплюнул кусочек табака из папиросы себе под ноги, поморщился так как будто у него прихватило спину, но на спину он не жаловался с утра, видимо слово ему не понравилось. - ROI, внучок, это такая цифра, которая иногда с жизнью не имеет ничего общего. Посчитать то его конечно можно, но кто ж тебе сказал что ты сделаешь это правильно.
 - А как же тогда ...? Как автоматизацию планировать?
 - Головой, Васька, головой. Планировать и перепланировать надо головой. И автоматизацию тоже.
 - Деда, а расскажи как вы планировали автоматизацию тестирования?
 - А мы, Васька, не планировали. У нас был приказ - автоматизировать. И мы автоматизировали.
 - Деда, но надо же как-то понимать что это эффективно или неэффективно?
 - Надо.
 - А как вы понимали?
 - По людям.
 - Это как ?
 - Служил я тогда еще в другом полку. Собственно в полк меня и взяли, чтобы я автоматизацией там занимался. Но ни про какие ROI там никто не знал. А если и знали, то не считали - если посчитать то очень уж мало получится. Но потребность все чуяли - люди в тестировании зашивались и гибли. Делали они софтину, которая садится на операционную систему, вставляет в нее свои драйвера. При том каждая следующая версия операционки  отличается в этом месте от предыдущей. Какая-то больше, какая-то меньше - но отличаются. Поэтому протестировать софтину нужно не только целиком на одной операционке, а еще хотя бы по чуть-чуть на каждой из семейства. Работа не сложная, но тупая. И вот эту работу мы автоматизировали. Поддерживать такую автоматизацию  - был еще тот адок, но поддерживали. Даже человека потом отдельного именно на саппорт этого отрядили.
  - А зачем, деда?
  - А затем, Васька, что люди имея такую автоматизацию у себя за спиной смелее стали. Потому что ты точно знаешь что если твой рефакторинг сломал  встраивание в систему - это найдут.  А остальные вещи - это люди искать должны. Там сложный софт был, такой автотестами сильно не накроешь.
  - Деда, так как вы понимали что вы эффективно автоматизировали?
  - А как ты Васька смелость померяешь ?
  - Не знаю.
  - Вот и я не знаю. Спроси у учителя своего в школе - может он знает. Они теперь все умные...

 Дед затушил папиросу, бросил ее в ведро, поднялся и пошел разворачивать тестовую инфраструктуру на Amazon-е. Приближался вечер,скоро соберут nightly-build...