30 декабря 2014

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

То что я когда-то пообещал начинаю претворят в жизнь.
Почему я об этом пишу?
Потому что за 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 дается все сложнее, требует все большего количества усилий, и начинает казаться, что потраченные усилия перестали себя оправдывать.
Поколение назад, удовольствие от работы не было решающим фактором при выборе места работы. Работа не должна была приносить радость, она должна была приносить кусок хлеба. Радость должна быть по возвращению домой с работы по вечерам и на выходных. Но если работа не приносит удовольствия, то скоро ты начинаешь понимать, что не можешь фантастически на ней работать. Не сказал бы, что многое поменялось с тех пор, но как минимум стал заметен сдвиг в лучшую сторону. Многие из нас поняли, что страсть ведет к совершенству 

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

23 декабря 2014

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

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


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 года на обучение тестировщиков автоматизации тестирования в принципе нормально.
Смотреть всем.

18 декабря 2014

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

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


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

15 декабря 2014

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

Преамбула.


Как-то летом один персонаж сказал, что он собирается встроить тесты внутрь самого приложения. Тогда я молча поржал про себя.
Спустя 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. Как и обещал.
Хохлома.
Гимназистки.


08 декабря 2014

Напочитать: 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 - тут. Сухое резюме ниже.

MethodJava [ns]Groovy [ns]Factor
Fork/Join22.132181.0188.18
Pojos117.914856.3377.26
Quicksort68.728330.1594.80
Quicksort with @CompileStatic67.752147.7922.18

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