Ретроспективы в командах: Общие моменты

А еще вчера вечером я был на CodeFreeze с Борисом Вольфсоном про ретроспективы и думаю что я напишу ряд постов про эту практику.

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

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

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


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


2. Про регулярность.
Рекомендую как минимум для начала пользоваться простым правилом:

конец итерации = ретроспектива.

Даже если интерации недельного размера?  Да, даже если так. Хотя бы первое время. Команда сама должна рассказать вам на ретроспективе почему ее нужно делать реже.
Я не рекомендую делать ретроспективы реже чем раз в 2 месяца - в условиях интенсивной разработки это огромный срок времени, за который проект может перейти уже в предтерминальную стадию и пользы вы уже не извлечете.
Второй момент - некоторые вещи за  2 месяца могут вполне себе забыться, зато всплыть потом, еще через полгода и лечить вы их будете уже с большими усилиями.

Каким бы коротким не был ваш проект, если вы хотите проводить в нем ретроспективы вы должны еще и заложить время на реализацию решений принятых  на ретроспективе.

Ретроспектива, которая делается в конце проекта называется Post Mortem и помогает как вскрытие грудной клетке при насморке.

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

Если вы практикуете любое из течений Agile, то список задач по улучшению становится частью вашего бэклога на следующую итерацию. Обязательно становится. Тут никаких отмазок быть не может. Ввиду этого в вашем маленьком уютненьком agile мирке все должно быть устроено так : итерация - демо - ретроспектива - планирование  - и никак иначе. Ретроспективы до демо быть не может - все надеюсь понимают почему.
Планирования до ретроспективы быть не может - потому что вы еще не подумали как вы на следующей итерации будете делать свою работу лучше.

Тут можно попробовать возразить, сказав что заказчик или его product owner порежет любые таски которые не входят в скоуп разработки. И, да - порежет если вы ему такую возможность дадите. То как вы выпускаете ему софт  - это зона вашей компетенции. То как вы планируете объем задач на итерацию - это тоже зона вашей компетенции. Если не вы его планируете, а заказчик/менеджер/владелец продукта - то у вас уже есть серьезная проблема, которая заключается в доверии между вами и заказчиком.
Я не призываю  вас делать улучшения партизанскими методами, хотя и про такие случаи я слышал, я призываю вас договариваться.  И договоренность эта очень проста: "каждую итерацию мы тратим 1/5/10/20% времени на улучшение процесса".

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

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


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

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

По той же инерции мышления ретроспектива не бывает менее чем на 1,5-2 часа  - люди приходят на нее с какими-то своими мыслями в головах и им нужно их аккуратно сложить, включить "режим ретроспективы", вспомнить и подумать.
Моя рекомендация  - планировать не меньше двух часов - больше можно.
Вполне себе допустимо что после того как вы провели ретроспективу в офисе вы полным составом отправитесь пить чай-кофе/пиво/ужинать все вместе и там она продолжиться в более неформальной обстановке.  Это нормально и даже хорошо, главное не забыть с собой ручку и бумагу :).

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

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

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

Напочитать: 17 мгновений Java-зимы

1. Фреймворк для фаззинга.  Обрадовались? Рано - только Linux и Mac OS :)
2. Интересный пример обвязки для JUnit для тестирования рубильников (feature toogles).
3. 04.12.2014 в мир вышел JUnit 4.12. Куча изменений - у меня были тесты которые помогли быстро адаптироваться.
4. Заморозьте версию браузера и Selenium, иначе ай-ай-ай-чтоможетпроизойти. Имхо - способ огораживания - у ваших клиентов тоже браузеры обновляться не будут, да ? 
5. Безопасность для REST-сервисов - очередная "детская болезнь" отрасли. Есть 6 способов лечить, по крайней мере на Java.
6. как узнать хоть что-то про плагин в  maven ? Просто mvn help:describe -Dplugin=
7. О том как идеи тестовых фреймворков вдохновляют разработчиков на великие дела. Осторожно - внутри Java, Reflection и агонь!
8. .NET заопенсорсило!!!! Не могу сказать что прям рад, просто лучше поздно, чем никогда. Момент упущен.
9.  Docker рвет вперед сумашедшими темпами: репозитории образов под языки, machine+swarm+compose, и это все несмотря на попытки CoreOS выстроить свою альтернативу докеру. А что же будет после Docker? Immutable Servers и Unikernels. 
10. Robot Framework обзаводится lint.
11. Google зарелизил свою версию типа удобных ассертов (not invented here синдром, дада) под названием Truth.
12. О небольших нюансах жизни с GSON и сопособах их решения.
13. Как с помощью JMeter тестировать ненагрузочно.
14. Пожалуй самый лучший HelloWorld-пример использования ZooKeeper. А Netflix за его Curator  - еще один плюс в карму.
15. Ребята из 2GIS дают дельный и очень простой совет как протестировать верстку - используй одинадцатиклассниц :) 
16. Etsy взяли и просто начали ротацию кадров - чтобы понюхали как у соседа в окопе пахнет. Молодцы,чо.
17. Замечательное ревью книги, которое лично для меня вовсе не ревью, но сублимат правильных мыслей о том чем ты должен заниматься в своей профессиональной жизни. Все так, скажу я вам. И просто  нацитирую

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

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

И на этот год наверное все.

Напочитать: Напосмотреть: Подарочный выпуск.

Предновогодний. Чтобы вам было чем заняться с первого и по тринадцатое.

1. Никита Сальников-Тарновский легко и непринужденно показывает напаркуа вам в Java нужно иногда пользоваться off-heap. Код на гитхабе.



2. Еще один рассказ о том что может или скоро сможет Google Chrome
3. Вот вы все говорите "Нас спасет Model-based testing". Вот теперь сходите и посмотрите что такое MBT на практике а потом подумайте еще раз. Да, я понимаю что это ваще  Clojure Conf речь идет про Ruby а сбоку еще и кложа. Но докладчик все равно все раскладывает по полочкам. Смотрите и впитывайте.

4. Ansible, mon amour. На самом деле я очень люблю декларативный подход, потому прусь от maven. Фраза докладчика "Инфраструктура выросла в два раза, админ пишет на Ruby, а пользователя все нет" меня порвала, но я с ней полностью согласен - Chef он такой.


devclub.ee_32 from devtraining on Vimeo.



5. Рассказ об опыте внедрения холократии в процессы управления "на горячую".



6.Роботы. Везде. Совсвем скоро. Осталось только придумать куда деть людей.



7. Чем дальше живу, тем больше понимаю, что евангелисты/адвокаты в технических  компаниях  - вещь нужная.
Глядя на такое вот выступление, прямо хочется взять и тискать-тискать-тискать этот Docker.

Естественно не все так безоблачно, вот второе видео от того же спикера - там с кровушкой и кишочками докера.

8. 6 этапов, 5(!!!) лет. Если честно то после просмотра этого видео  я как-то даже подуспокоился - если у Atlassian на такие трансформации ушло 5 лет, то мои 2 года на обучение тестировщиков автоматизации тестирования в принципе нормально.
Смотреть всем.

Напочитать: Гуманитарный выпуск

Следующий - технический.Обещаю.

1. Хорошими оргнизациями двигают не ништяки, а Миссия+Прозрачность+Глас народа. Ну мы то знаем что ништяки тоже важны.
2. Мысли Сергея Мартыненко о прокрастинации "В организм человека встроены защитные механизмы, предотвращающие использование разума постоянно. "
3. Очередной сборник вредных советов про то к чему готовится если ты вдруг становишься менеджером. Be Prepared to Fire who you Hire - и впрямь вед.
4. *Полезняшка*. Генератор фоновых шумов - реально полезная вещь. Прочитал я об этом вот тут, но так как хабр то комменты доставляют больше самого топика. Лично у меня мурчит котик. И еще 29 генераторов.
5. Про эмоциональное выгорание. Длинно, но по делу. Мне думается захлестнет нашу отрасль в ближайшие годы.
6. Другого места этой статье я не нашел, только в этот выпуск ее. Все про людей. Про нас с вами. Даже не статья - конспект лекции.

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

P.S. Для тех кто еще не видел

Встраиваем тесты в приложение или интеграционное тестирование с хохломой и гимназистками

Преамбула.

Как-то летом один персонаж сказал, что он собирается встроить тесты внутрь самого приложения. Тогда я молча поржал про себя.
Спустя 3 месяца на Agile Testing Days я побывал на докладе, где рассказывалось о том что Runtastic делал так для того чтобы выявить багу на устройствах пользователей.

The developers decided to build a unit test into the app where they could check the result of the device’s calculation for a well-known distance between two coordinates.

(Чуть более подробно можно прочесть тут, но большая часть отводится рекламе)
Собственно с того самого доклада мысль зудела в голове и вылилась в пару часов  пляски с кодом.

Амбула.

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

Если вам не достаточно кейса Runtastic приведенного выше, то отвечу.
Если у вас все хорошо, production вам подконтролен, конфигурация зафиксирована и проблем нет - оно вам не нужно.
Но не у всех и не всегда оно так.
Примеры когда оно не так:

1.  Вы разрабатываете что-то что будет ставится в непонятное окружение или контейнер и вам нужно понимать что окружение соответствует.
2. Окружение в которое вы ставите свое поделие может динамически меняться и об этом тоже было бы неплохо знать.

В общем и целом оба вопроса выше сводятся к вопросу о доверии к reference implementation чего-то что вам дают снаружи ( в случае с Runtastic таким reference implementation-ом было API  по работе с GPS видимо).
В зависимости от того насколько большому куску мы не доверяем может захотеться написать как Unit-тест, так и интеграционный.
Рассмотрим оба случая :).
Естественно я буду рассматривать это все на Java потому что режиссер так видит (с)  мне так нравится, но все показанное ниже также справедливо и реализуемо для всех остальных промышленных языков программирования.

Покажи мне свой код.

Да детка, обнажи свой свежий, горячий код и я сделаю тебе ревью! 
Давай делать это бесстыдно! Давай делать это на гитхабе!

Код собственно на гитхабе.
Клонируем, в консоли запускаем mvn exec:java, видим такое.

Дальше идем в браузере идем на урлы:
http://127.0.0.1:8080/runUnitTests - для запуска Unit тестов

Видим такое


http://127.0.0.1:8080/runIntegrationTests - для запуска интеграционных тестов.

Видим такое
Посмотреть в код под капотом (кому и если будет интересно) вы сможете сами.

Мысли вслух.

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

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

Второй интересный момент который я нашел именно в такой реализации заключается в том, что подключение реальных кусков бизнес-логики к интеграционным тестам может помочь ловить баги, которые воспроизводятся только в определенных условиях.
Минусы тоже имеются - если в ваши слои бизнес-логики можно вносить изменения в runtime, то запуск таких  интеграционных тестов может положить вам ваш production.
Еще более просто и конкретно - такая штука может положить нафиг весь ваш prod и данные.
И да - подобного рода трюки не предусматривают никакой защиты от этого кроме code review.


Третье - такой подход тянет за собой все зависимости необходимые для тестов в основной продукт - то есть всякие junit, mockito, hamcrest. Ну и код тестов конечно.
Избежать этого можно - в своем примере я развел это через профили сборки maven.
Единственная корявость которая есть - приходится указывать значение свойства по умолчанию для исключаемых при компиляции пакетов.

При обычной сборке (mvn clean package) с такой настройкой содержимое архива будет выглядеть так.

А при релизной (mvn clean package -P release) вот так

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


P.S. Как и обещал.
Хохлома.
Гимназистки.

Напочитать: 12 Java подвигов.

На самом деле не все про Java.

1. Библиотека от  Google для парсинга телефонных номеров
2. Linux shell на Windows. Только не Cygwin и легче.
3. Генерировать красивый equals() и hashCode() в IntelliJ IDEA  с помощью Guava - вот так.
4. Нейронные сети на Java  в виде библиотечки - Encog.
5. Анализ и моделирование графов - GraphStream - библиотечка на Java.
6. Визуализация зависимостей в коде - я не понял работает оно или нет, но все же. Spoiklin.
7. Еще один тул по визуализации зависимостей. Для тестов. Для тестов на Scala. Degraph.
8. Если вам нужно подебажить json-path против куска json то это можно сделать онлайн. Тут.
9. Сравнение производительности Pure Java и Groovy - тут. Сухое резюме ниже.

Method	Java [ns]	Groovy [ns]	Factor
Fork/Join	22.132	181.018	8.18
Pojos	117.914	856.337	7.26
Quicksort	68.728	330.159	4.80
Quicksort with @CompileStatic	67.752	147.792	2.18

10. Хабракейс - это когда комменты и срач в них инетереснее чем сам пост. Вот вам про тестирование.
11. Про всякие разные дебаггеры в Java - обзорная статейка.
12. почему разработчики не тестируют свой код? - очередная порция суровых, но честных рассуждений от Максима Шульги.

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

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

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

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

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

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

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

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

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

Напочитать: Важнейшим из искусств для нас является 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 про нововведения на уровне стандартов

Краудфаундинг-проект: Еще одна книга от издательства Дмитрия Лазарева

Однажды я уже участвовал в таком проекте.
Дмитрий Лазарев запускает еще один.
Я уже участвую, присоединяйтесь.

Мероприятие: 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. Не все так плохо в нашем королевстве.

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

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

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

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

Каждый (ну или почти каждый) человек переживал потоковые состояния, и лишь единицы психологов проанализировали его.
Итак, самая суть.
Потоковое состояние у человека наступает при наличии как минимум 4 условий:

1. Задача по силам
2. Есть возможность сосредотачиться на задаче
3. Можно чётко сформулировать конечную цель задачи
4. Можно немедленно получить обратную связь

А  признаки этого потокового состояния таковы:

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

Есть еще пара хороших и глубоких мыслей, к сожалению не развитых.

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

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


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

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

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

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

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

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

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

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

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

Оценка 6/10.

Напочитать: Хабарок

В этот раз очень уж много с Хабра скопилось.

1. Мой добрый друг  и коллега Максим Шульга поведал о том как они делают интеграционное тестирование vGate на базе Jenkins и FitNesse.
2. Про то как быть реактивным с Project Reactor и чуть-чуть Java 8.

Going Reactive - High Performance JVM Code with Reactor from JAX TV on Vimeo.
3.  Не помню было или нет, но вот вам штукес, который используется при отладке High-Frequency Trading систем (биржевые роботы то бишь) и позволяет сбрасывать на диск кучу всякого. В связке с предыдущим пунктом может быть  ого-го-го!.

4. Все начаали страдать API. И как следствие все начали думать над тем как его версионировать. Про способы, их преимущества и недостатки - раз и два.
5. Перевод часов случился, так что тем кто еще (а таких поверьте мне много) - курите.
6. Quick Start Guide по Robot Framework - no comments.
7. Продолжая тему Fault Injection которую я поднимал не так давно - ребята из Netflix тоже делают хитрые декораторы.
8. Как сделать расширение для Chrome если вы хипстер.
9. Десктопное приложение с блекджеком и шлюхами с видео и звуком внутри Docker-контейнера - да, можно.

Ну и на гуманитарные темы.
10. Про то как вставить группу тестирования в SCRUM
11. Еще раз про холократию.  - ну не готовы вы еще к этому, и не будете , если не попробуете :) 

А еще вчера вечером я был на CodeFreeze с Борисом Вольфсоном про ретроспективы и думаю что я напишу ряд постов про эту практику.

Книга: Роджер Сайп. Развитие мозга.

Прочитал. Точнее осилил. 
Книга представляет собой весьма странный винегрет. 
Начнём с того что само название книги в оригинале (Train Your Brain for Success. Read Smarter, Remember More, and Break Your Own Records) отражает суть винегрета внутри, однако МИФ почему-то (и действительно, почему ж это) это название переиначили. 

Книга действительно расскажет вам о том как запоминать больше. Это пожалуй самая большая её ценность. Техника тренировки памяти описанная в книге лично для меня заработала.
Вот только одно но - зачем мне помнить столько всего ненужного? 
 
Также книга претендует на некое вводное пособие по освоению скорочтения. 
Может быть это тоже кому-то пригодиться. Я лично пока никакую технику скорочтения не освоил и не планирую, судить не могу.

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

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

Оценка 5/10. Не рекомендуется к прочтению. Рецензент по чьей рекомендации была куплена эта книга отхватил минус в карму до нуля.

Напочитать: пред-SQADays-ное

1. Интереснейший полет мысли от Сергея Мартыненко

При наличии идеального тестового набора и идеального процесса отладки, автоматизация тестов  после написания кода – бессмысленная трата времени. Вредительство.И, да, рекордер не нужен.
С другой стороны, написание кода тестов до написания кода приложения вполне себе хорошая практика, прекрасно уживающаяся с идеальными тестовым набором и процессом отладки.
«Чем более хороша команда, тем от большего числа автоматизированных регрессионных тестов они должны отказываться. Написание кода тестов после написания кода приложения – удел …»

2. Прекраснейшая няшка для определения того что дольше всего грузится на странице.
3. Один из немногих рассказов про то как строили автоматизацию тестирование встройки. А вот тут уже кровушка, кишочки, все как мы любим.
4. Про то как Netflix начал тестировать своей Chaos Monkey хранилища на Cassandra.Круты, чо.
5. Ansible теперь кстати умеет Windows.
6. Длинная портянка от Twitter о том как они тестируются.
7. Никакой современный фреймворк или  библиотека нафиг никому не нужны если к ним нет нормальных  примеров и/или документации , а лучше когда есть все.
Robot Framework интенсивно таковой обзаводится - отличный гайд.
8. Наверное о том как надо преподавать тестирование. Хотя конечно хрен его знает как его надо преподавать - чем дальше живу, тем больше понимаю что это ремесло. В любом случае - автор статьи молодец, хотя бы уже потому что попробовал.

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

Книга: Henrik Kniberg. How to run an internal unconference

Доступна на LeanPub.
Прочитал за 2 часа.

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

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

И еще один нюанс на который хотелось бы обратить внимание - в книге есть отсылка на law of 2 feet и транзитом на http://en.wikipedia.org/wiki/Open_Space_Technology#Guiding_principles_and_one_law.
Почитайте внимательно. И запомните - Whatever happens is the only thing that could have

Оценки не будет потому что за книжку я ничего не заплатил.

Напочитать: постотпускное

Высебедаженепредставляете сколько я выдавливал из себя этот выпуск. 

После отпуска очень тяжело взять себя в руки.

1. Небольшой пример как тестировать accessability с помощью Selenium
2. Отличная презентация про Model-Based Testing 
3. Navigation Timing API теперь няшно и на node.js. Смотреть на гитхабе.
4. Небезызвестная компания Crisp (это там где Хенрик Книберг и Матиас Скарин) запустила свой канал на YouTube.
И продолжая тему Crisp вообще и Книберга в частности.
Два видео про инженерную культуру в Spotify
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/
5. О том почему не нужно запускать ssh-сервера в Docker-контейнерах. Честно я даже до такого не додумался бы, но кого-то уже видимо прижало.
6. MySQL обзаведется REST API  - возрадуемся же этому.
7. О том как расово-правильно писать сообщения к коммитам в Git - отличная статья.
8. Хороший пример того что такое testability - Firefox позволяет подставить значения геолокации и как это делать с помощью WebDriver.
9. Очень многие люди в один день прокричали про эту вот вики с паттернами автоматизации тестирования как будто там прям сокровенное знание. Хотя может и сокровенное.
10. Мои коллеги  - Олег и Саша - взяли и прикрутили ACID к Cassandra.  Молодцы, чо.
11. MapDB. Занимательная хрень, которая видимо должна хорошо вписываться в задачи миграции данных между хранилищами.
12. Запустить десктопное приложение внутри Docker - можно. Мсье знает толк в извращениях.
13. Вот прям просто процитирую

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

Что такое Fault Injection с картинками и примерами

Теория.

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

(так выглядят сервисы внутри twitter, источник) 

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

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

1. Естественно у вас такая защита должна быть. А вот всунуть ее в legacy-код или продукт дизайн которого таких возможностей не предусматривал не так просто.
2. Уровень и с которого "падаем" и глубина падения. Если говорить про стандартную трехзвенную архитектуру, то тут фантазии особо разгуляться негде.
   Все намного интереснее  - често говоря просто эта задача актуальнее - когда у вас SOA или микросервисы. Здесь и уровней больше, типы и глубина падения тоже могут быть разными. Про типы хочется написать отдельно - это может быть как и просто генерация исключения для тестирования того что приложение стабильно его обрабатывает, проглатывает и снаружи ничего не видно, так и внедрение более изощеренного поведения - эмуляция неправильной конфигурации приложения, изменение диапазна типовых значений для экспериментов над поведением. Про банальности типа потери соединения с БД во время работы  - молчу.
3. Крушение приложения. Отдельная тема для распределенных систем особенно для тех что занимаются in-memory вычислениями (Storm, Kafka, Mesos, Suro). Что произойдет с блоком данных отправленным на in-memory обработку если обработчик сдох? Крушения опять же могут быть разными, но тут очень много специфики у каждого. 

Довольно теории, перейдем к практике.

Практика.

Для практики я построил на коленке простейшее вэб-приложение на Java (Jetty inside).
Приложение отзывается на три урла.
http://127.0.0.1:9090/doWork - отдает рандомное целое число от 0 до 1000.

http://127.0.0.1:9090/fault?mode=enabled - включает fault-режим
http://127.0.0.1:9090/fault?mode=disabled - выключает fault-режим

После включения режима падения генератор случайных числе начинает отдавать 0 или 1. Это и есть наше падение.
http://127.0.0.1:9090/crash?time=15 - падение приложения через  указанное время (опционально, если не указано, то упадет сразу).

Как оно организовано изнутри.

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


Код приложения выложен на github.

Хочется более приближенных к реальности примеров - их есть у меня.
Вот например ключи запуска Chromium

Книга: The "A" Word

Небезызвестный Alan Page (http://angryweasel.com/blog/angry-weasel/) систематизировал свои блог посты и издал книжку про автоматизацию на Lean Pub.

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

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

Что мне в книжке не понравилось так это то что любое приближение к практическим примерам сползает к фразам, которые часто упоминают Web или даже напрямую WebDriver. Задачи рассматриваются очень академически, реальность намного грубее и прозаичнее.

WebDriver - это конечно хорошо, но далеко не все, что есть в природе (и еще раз привет Максу и Ивану :) которые не дадут соврать, что это точно не все что есть в природе).

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

Рекомендуется к прочтению, оценок не будет так как ни копейки я за нее не заплатил.

Напочитать: 10 заповедей

1. Встала проблема тестирования с использованием системных свойств Java. Нашлась отличная библиотека.
2. Иногда процессы покупки лицензий затягиваются, а жить как-то надо. Выход есть. По крайней мере для VmWare ESXi.
3. Пишем свой простенький Java Agent. Для чего это нужно ?  Ну например потестить как себя ведет система при изменении времени, или остановить это время насовсем.
4. Кроссплатформенное тестирование Android и iOS приложений - на такую задачу пока замахнулся только Sauce Labs со своим Appium. Правда еще одни ребята решили что сделать это можно на Jython и Sikuli. Посмотреть что получилось можно тут и тут.
5. Длинный, но живой рассказ от J.B.Rainsberger про то что интегрированные тесты есмь гавно не есть гут. Рассказ с конференции DevConFu которая проходила в Риге  в прошлом году в ноябре и в этом году тоже будет.


J.B. Rainsberger - Integrated Tests Are A Scam from devtraining on Vimeo.

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

6. Еще один добрый (без шуток) человек выложил набор видеоуроков в сеть. Все что вам нужно приложить  - это (как обычно самое сложное) силу воли и самодисциплину.

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

8. Как взять и обосраться с микросервисами - правдиво зато!

9. Контейнеры грядут на смену виртуальным машинам в продакшене. В связи с чем у людей возникает вопрос "А так ли хороши контейнеры???" на который просто обязаны были ответить маркетологи из IBM. Большой отчет для тех кому интересны детали и выжимка для всех остальных.

10. Отличный наброс от качественного набрасывателя

But a lot of everyday programmer’s activities fall into the same category. Dependency management, for example. If you spent a day setting up compilation workflow and getting dependencies right, it’s not a day of good work. It’s a day lost. You haven’t created new value, you haven’t enabled a single person to do anything that wasn’t possible before. You were satisfying other programs’ demands. Even the fact that this activity has its own name indicates there’s something wrong with it. I hope there isn’t an actual job title like “Dependency management engineer”, is there? I probably don’t want to know.

На этом все. Блог уходит в отпуск до середины сентября.

Напочитать:Людо(в)едческое

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

Первый эксперимент стал следствием «Дня свиданий вслепую», когда на OkCupid на один день отключили все фотографии в поддержку выходу мобильного приложения для свиданий вслепую. Результатом этого хода стало падение всех метрик сайта, но вместе с тем, оставшиеся на сайте пользователи обнаружили удивительные вещи: они стали отвечать на входящие сообщения на 44% чаще, разговоры длились дольше, время до обмена контактной информацией уменьшилось.  

2. Длинный но весьма полезный рассказ о том, что "качество нужно встраивать в процесс".

we initially planned a duration of 12 months: 10 months of actual feature development and 2 months of freeze code / Integration testing.

It actually took 12 months to develop the features and deliver them to Integration Testing: two months delay. But then we had a supplementary 11 months (instead of 2) of Integration Testing / stabilization phase to go through before being able to release. Not to mention another 7 months to deliver two Service Pack versions.

3. Руководителям нужно думать. И им для этого нужно время.

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

Поэтому важно, чтобы руководитель в течение рабочего дня мог просто сидеть (или стоять) и думать. Если менеджер весь день пишет письма, разговаривает, анализирует материалы, т.е. РАБОТАЕТ, то увы, времени на ПОДУМАТЬ у него не остается. А это означает, что очень многие сложные решения он не будет готовить, глубоко прорабатывая, а будет принимать тяп-ляп. И другие сотрудники это будут чувствовать.

4. Презентеизм - бич российской (и не только) экономики.

В новом офисе число рабочих мест решили сократить на 30% и изменить подход к управлению временем. Сейчас ни у кого из сотрудников, включая генерального директора, нет закрепленного за ним рабочего места. Каждый проводит в офисе столько часов, сколько требует самый короткий путь к результату. За счет внедрения концепции Workplace Innovation во всех своих офисах Philips планирует экономить 28 млн евро в год.

5. О прокрастинации в сотый раз. На этот раз позитив.

Ты не можешь взглянуть большой проблеме прямо в глаза. Ты вынужден делать это наискосок. Но что можно — так это постепенно спрямлять угол: нужно посмотреть на задачу достаточно прямо, чтобы ухватить исходящее от неё вдохновение, но недостаточно, чтобы тебя парализовало масштабом. И дальше ты сможешь с каждым разом смотреть всё более и более смело, по аналогии с тем, как корабль переставляет паруса всё ближе и ближе к ветру по ходу движения.

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

7. Шпаргалка для менеджеров "Почему люди не меняют работу". Она же шпаргалка для сотрудников "Почему я держусь за это место". Собственно, шпаргалка.

8. О том как говорить про деньги от команды Стратоплана - раз, два, три.

9. 50 стандартных отмазок почему не нужно ничего менять.

10. Еще раз про холократию, радужное с пони и бабочками (кишочки и расчлененка по ссылке, конечно же)
Где-то на 5-6 месяце команда превращается в машину по производству тасков. Причем управлять машиной не нужно, она едет сама, просто кладешь user-story на одной стороне и вынимаешь продукт с другого конца. 
Многие члены команды “раскрываются”. Например, извечные молчуны оказываются достаточно здравомыслящими людьми, они молчали, просто потому что нафига говорить, когда никто не слушает. Завзятые перфекционисты начинают обучать отстающих коллег и получают от этого удовольствие. Страдающие прокрастинацией выходят на путь выздоровления, потому что не выпадают из процесса. 
Все сами ходят вместе на обеды/боулинги, без начальника и без корпоративов. 

Книгоблиц: Государь, Дейл Карнеги, Виктор Фарнкл

В этот раз не про одну книгу, а сразу про три.
Начну с главной.

Это замечательная книга, сейчас объясню почему.
В большинстве (я имею ввиду IT-шные) компаний процветает культура колаборации.
Даже если это так не выглядит. Привыкнув к наличию такой культуры вы можете испытать когнитивный диссонанс при встрече с другой культурой. Однако это не является чем-то новым. Такая культура долгое время процветала, и оставила свои артефакты. Одним из которых является "Государь" Маккиавели.

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


Еще пару книг, а точнее их кратких изложений я прочитал с легкой руки Тимофея Евграшина, который поведал о новом проекте издательства "Манн-Иванов-Фербер" - http://www.smartreading.ru/ .

Сначала о формате - редакторы издательства делают краткую выжимку из сложной деловой литературы, "рафинад".

Идея заманчивая - оценивая размер книги и ее практическую полезность я бы никогда не подступился бы к Дейлу Карнеги и Виктору Франклу.
А тут - полчаса чтения и самую суть ты уже понимаешь.  Это, конечно, не заменяет полноценную версию книги, но дает отличную возможность понять  - а есть ли ради чего ее читать ?

Я прочитал за вчера краткое изложение "Как приобретать друзей и оказывать влияение на людей" Дейла Карнеги и "Сказать жизни "Да!" Виктора Франкла - тема Карнеги теперь закрыта и табуирована, мне кажется он принес в этот мир больше дерьма, чем пользы; "рафинад" Виктора Фарнкла прочитал с удовольствием  - этот человек действительно обратил свой взгляд не в глубины человеческого Я, а к его вершинам. Тем не менее если бы я читал полную версию книги я  бы наверное исплевался.

В общем формат интересный, пробуйте сами.

Напочитать: Дюжина

1. Прекрасное интервью, (извините , опять про микросервисность).
And the analogy for this is like if every car instead of having an airbag had a 6 inch steel spike pointing at the driver, there would actually be fewer accidents on the road because everybody would be driving along very, very slowly and carefully, and they would never bump into anything; because there is peril built into the system and the peril is very closely looped back to your actions. So the fact that if you build a system where you can do anything and there is no consequence to your actions, you are creating externalities: you just externalize all of the risk and all the problems.

2. Отгремевшая несколько лет назад тема - сплит-тестирование (A/B тестирование) пыль осела, теперь видна суть.

3. Интересный подход к тому как отлаживать приложения на продакшене - использовать Java-агент и BTrace. А ведь еще и ByteMan есть.

4. Прекрасный объяснение того что такое цепи Маркова.
5. Эй , node.js, давайдосвидания !  - говорит человек который для этой самой node.js сделал очень много. Кстати свливает он на Go.
6. В Java8 выпустили Nashorn, хотя Rhino был задолго до него.


7. Про геймификацию

8. Caja - встраивание чужого вэба к себе. Просто занимательная фигня.

9. Отличный рассказ Дмитрия Снисаря о том почему люди что-то делают именно так как они это делают.

10. MongoDB решили сделать level-up и уже начали рекламировать фичу с подключаемыми модулями хранения - помните при установке MySQL можно было выбрать каким DB engine пользоваться - MyISAM/InnoDB? :). Обещают legalize в версии 2.8.

11. Я использую подход, который использовал мой руководитель при найме меня. Прошу написать ожидания на три периода: первый год работы, второй, третий и далее. Я не использую слово «хотите», вместо это говорю «ваши ожидания». А такой подход к постановке вопроса позволяет соискателю фиксироваться вместо «как бы не продешевить и не отпугнуть» на «насколько же динамично в самом деле будут расти мои скилы». Тут же автоматом вскроются представления о справедливом ежегодном повышении. А еще как бы негласно заключается некий контракт на три года вперед по динамике зарплаты. Например, если через год он придет и, условно, попросит удвоения зарплаты, я смогу достать тот самый листок (резюме) и спросить, неужели скилы выросли настолько драматично значительно. Вот теперь я тоже буду так делать.
12. Тема Service Discovery не дает мне покоя. Отличная статья на эту тему.

Напочитать: Внезапный выпуск

1. Закон Конвея для айтишников - это тоже самое что закон спроса и предложения для экономистов.

Оригинал
"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." Conway, 1968
Разжевано про последствия до самой каши
Just deciding to staff the team with four developers rather than three will influence the architecture because work now needs to be found for the fourth team member.


2. Сервисы потихоньку захватывают мир. А чтобы в них не потеряться нужны discovery-системы которые бывают двух типов: первые рассказывают людям о сервисах (на сцене появляется Мартин Фаулер который расскажет вам всю правду) , вторые рассказывают сервисам о сервисах (Netflix Eureka, Zookeeper и иже с ними, Consul.IO). Третий тип вытекает из суммы указанных выше.

3. Интернет вещей (internet of things ) уже близко. Вот и протокольчик разработали.
4. Мне кажется что в ближайшие пару лет мы увидим кучу реализаций CQRS архитектур, и хорошие примеры event sourcing-а - тренд на то чтобы быть асинхронными на всю голову  взят не напрасно. В связи с этим вот вам занимательная хрень из мира CQRS и Event Sourcing - EventStore Database. Но есть один момент - пока только под .NET .

5. Еще одно специальное хранилище -  на этот раз для геоданных - CartoDB (github).
6. Тренд на тестирование API сервисов набрал обороты, теперь появляются и инструменты.
Pact
Pacto
WireMock и опыт его использования в Яндексе
Betamax
Mountebank

7. Документирование REST API всегда попаболь. Теперь есть Swagger. И для Dropwizard тоже.

Спонсором этого выпуска Напочитать стал очередной Thoughtworks Technology Radar

Наблюдение: Про стратегов

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

- Филин! Помоги нам, что делать: нас все обижают, съесть хотят, лиса уже  на пятки наступает.

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

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

- Ну-у мышки! Это уже не мой вопрос. Это уже тактика, а Я - стратег...


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

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

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

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