Ретроспективы в командах: Артефакты ретроспектив

Это предпоследний пост в данном цикле.

Итак, вы провели ретроспективу, но радоваться рано.
Реально процесс встанет на (какие-то) рельсы когда вы будете делать в интервале между ретроспективами делать все те улучшения/изменения, которые захотели сделать.

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

Вернемся к артефактам.
Артефактов у вас будет (условно) три типа:

1. Список задач и/или карта их выполнения - это из предыдущего поста.
2. Конфликты и социальные игры в процессе ретроспективы - про них я первоначально писал тут.
   
   Социальные игры и конфликты являются для вас довольно ценным материалом. Вообще, наблюдение за людьми в процессе того, как они делают ретроспективу для фасилитатора этой самой ретроспективы является ценнейшим материалом, особнно если фасилитатор проводит ретроспективу с командой не в последний раз.
   
   Ретроспектива сама по себе является дополнительной нагрузкой. Люди, на уровне подсознания, довольно быстро запоминают что это труд, поэтому "внутренний лентяй" каждого человека старается максимально быстро и жестко уйти от вопросов и тем на ретроспективе которые могут нагрузить его, лентяя, какими-то улучшениями. Мне даже кажется что это один из отличных примером того как работает быстрое и медленное мышление описанное Каннеманом в Thinking Fast and Slow и Талебом в Черном Лебеде.
   
   Социальные игры и прессинг могут рассказать вам о том, как на самом деле обстоит рабочий процесс в команде (не сваливают ли разработчики недоделанные таски на тестирование ? все ли хорошо с требованиями и декомпозицией задач?).
   Процессные и организационные "дырки" и костыли, которые всплывают на ретроспективе безусловно нужно обсуждать и решать сразу - это и есть улучшения.
   Но вот игры и взаимоотношения порешать на ретроспективе не получится - это то, что должно выстраиваться в процессе ежедневной работы. И это вполне возможно может стать вашей работой за рамками ретроспективы.
   
   Еще один нюанс  - социальные игры происходят не только на ретроспективе, но и за ее пределами, поэтому не стоит удивляться что команда пришла к вам на ретроспективу "перейдя на следующий уровень игры". 
3. Нежданчики - задачи и мероприятия, проведение которых не планировалось на ретроспективе, однако в процессе проведения улучшений/изменений оказалось необходимым - это, пожалуй, самая интересная категория, особенно для тех кто только начинает.
   
   Неожиданно может всплыть все что угодно. Правда чаще всплывает то, что все старались забыть. но не исправить :).
   Краткая типология нежданчиков:
   
   Нежданчики-задачи.Плаинровали сделать А, но выяснилось что это блокируется B и С, которые  в свою очередь упираются в задачу D соседнего подразделения.  Или А увеличилась в размерах на порядок. Вывод: плохой анализ на ретроспективе, плохое понимание взаимосвязей в проекте.
   
   Нежданчики-люди. Таск поручили делать Васе, но Вася не понял что нужно делать, впряг в это Колю. Коля мог сделать или не сделать свои задачи по результатам ретроспективы, попутно выполнить Васины. В общем с точки зрения внешнего наблюдателя задачи могут быть выполненными или не выполненными, но явно не теми людьми, которыми планировалось. Такое вот неожиданное поведение от людей может сыграть как в лучшую так и в худшую сторону. Все, что оно дает вам как фасилитатору - лучшее знание о команде и способностях людей. Бывает так что самый молчаливый и забитый интроверт в команде является самым суровым "real fuckin do'er-ом" - это нужно знать и использовать во благо.
   
   Нежданчики-информация. Решили что-то улучшить, но нашли такое, что не знаем что делать дальше. Тут ве очень зависит от контекста. Встречал такую ситуацию пару раз в жизни когда приваливал проект который до этого делали другие люди и оставляли за собой "мины". Вообще, любой "угловое знание" о том, что вы делаете обычно идет в плюс нежели в минус. Другой вопрос - почему вы этим знанием не обладали ранее ?
4. Любые рисунки, схемы, описания процессов - все что создается на ретроспективе руками участников - должно быть тщательно (но не навязчиво!!!) задокументировано и сохранено. Я обычно использую для этого телефон и забираю с собой листы флипчарта. Результаты любой из ретроспектив могут пригодитя вам при проведении следующей. поэтому лушче хранить их в электронном виде и структурировано.  

Данный список и классификация никоим образом не претендуют на истину в какой бы то ни было инстанции - дополняйте, расширяйте , переделывайте под себя.

Буду рад ответить на вопросы.

Напочитать: Тестируй меня полностью

1. Google выпустила ARC - App Runner for Chrome, который позволяет запускать Android приложения на Windows, Linux, Mac. Угадайте при чем тут тестирование.
2. Еще один мануал по PowerShell. Тестировщикам и иже с ними будет полезно.
3. Давеча я тут расписался в сторону ROI в тестировании да так что графики посещения бложека пошли вверх. Вот тут есть более менее внятное объяснение почему ROI к тестированию не приклеить - на сей раз не мое.
4. Подписываться на должность менеджера за зарплату QA  - грешновато! Почему - разжевано тут.
5. Жирное - опрос про автоматизацию тестирования. Читать тут. ИМХО: этот опрос характеризует отрасль чуть более чем полностью. И в хорошем. и в плохом смысле. В хорошем  - потому что 620 ответивших человек  - это реально показывает масштаб распространения автоматизированного тестирования. А вот первые же циферки по части того кто же на самом деле этим занимается - уже удручают - более половины опрошенных людей являются QA-инженерами или инженерами по автоматизации тестирования. Это значит что бизнес предпочитает выделять это в отдельную компетенцию, а никак не перепрошивать мозги разработчикам (что нужно уметь тестировать, хотя бы минимально) и тестировщиками (что нужно уметь автоматизировать и понимать архитектуру приложения которое ты тестируешь).
6. Некий молодой человек при поддержки дедушки Фаулера нарисовал infodeck про тестирование и тестируемость микросервисов. Из этого самого infodeck-а вы узнаете про то куда совать mock-и и стабы, in-memory базы данных, что такое синтетические транзакции и прочее.
7. Интервью с Джеймсом Бахом. Зато про тестирование, чо.
8. Автоматизация бывает не только тестирования но и других вещей, с тестированием непосредственно связанных. В случае с андроидом все не так плохо, а вот в случае с iOS может быть сильно хуже. Но вот люди сделали да - Pythonista. Питон внутри, естественно.
9. Один из главных помоников многих тестировщиков  - VirtualBox обновился до 5.0.1 beta.

И на этом все. А все потому что в области тестирования интересный контент генерируют мало и редко.

Книга: Питер Фердинанд Друкер. Менеджмент. Вызовы XXI века

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

Данная книга не является монолитной, хотя и хорошо структурирована. Эта книга - сборник из 6 довольно больших эссе, темактика которых довольно широка:

1. Новая парадигма менеджмента
2. Новые реалии и стратегия и организации
3. Лидер перемен
4. Задачи в сфере информации
5. Производительность работников умственного труда
6. Роль менеджмента в карьере и жизни

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

Друкер наверное одним из первых понял и смог раскрыть силу сущности "организации" в ХХ веке, но согласится с ним на XXI век уже сложно - Интернет и глобализация бизнеса так сильно поменяли ландшафт за последние 15 лет, что сила отдельно взятого специалиста в скором времени может сравняться с силой организации. Также следует вспомнить и о законе Конвея, который угнездился в организациях и не никуда оттуда не хочет выходить.

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

Оценка 8/10.

Напочитать: В копилку гуманитариям

1. Асхат Уразбаев рассказывает об особенностях национальной культуры разработки.


2. Эпический тред на Quora с довольно тупым набросом "Как заставить программеров работать 60-80 часов в неделю", но эпичными  ответами почему так сделать низзя.
3. Увлекательно о химии геймдева.
4. Весьма интересный инструмент подвернулся под руку - смесь покойного Google Wave и принципов GTD Аллена.
5. Недавнее социологическое исследование в США показало, что современное общество в целом готово к подобным манипуляциям. Взрослым задавали вопрос — согласны ли они на то, что с генами их ребёнка будет выполнена генетическая модификация с тем, чтобы он стал «умнее» и был бы менее подвержен серьёзным заболеваниям. Значительное число респондентов высказались положительно - ну вот, генетические модификации людей уже не за горами. Самое главное - общество готово.
6. Когда-то давно я старался прочитать Эрика Берна. До конца не осилил. Зато теперь есть видео "для самых маленких".
7. Сумбурно. Но про "Эффект Наблюдателя" наверное. Раз, два и три.
8. О том почему резюме женщин хуже. Никакого сексизма, голая статистика (чорд!).
9. Странная статья про ретроспективы, но куча полезных ссылок в ней.
10. Непростая тема "Как ты себя чувствуешь когда тебя уволили?" в исполнении Zach Holman из GitHub.
11. Еще один ambient-noise генератор - никогда не думал что лучше всего код пишется под звук дожда и раскаты грома.

И самое сильное пожалуй.

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

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

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

1. Весьма странная смесь, но тем не менее - кому-то может оказаться полезной. Jodd.

2. Удивляетесь что вышла новая версия либы в maven central а вы не в курсе?  Я тоже. Но мечты стали реальностью - artifact listener.
3. Сравнительная таблица Dropwizard vs. Spring или что вам большу подходит для микросервисов. Dropwizard конечно же :).
4. Отличный и короткий гид по заголовкам кэширования  в HTTP. Люблю такие,
5. RoboVM - это чтобы на Java под iOS. Правда платно, и наверное даже стремно.
6. Про стратегии герметизации, mock-анья и за-stub-ливания для тестирования Android приложений от гугла.
7. Maven теперь может не только XML. Хипстеры, хуле.
8. Старинное от Влада Балина

Создать свою структуру и пришлепать ее сбоку может любой дурак. Квалифицированный инженер-программист (с упором на первом слове, не путать с "программером") умеет проводить анализ "чужой" подсистемы, восстановит мысль и идею автора, сможет мысль автора развить, продолжить ее, и эффективно решить свою задачу в рамках чужого подхода к проблеме. Все это - работая с кодом. Это отличительная компетенция архитектора, высший уровень инженерного мастерства. И это имеет весьма отдаленное отношение к "рефакторингу". 
Толу на самом деле было все равно, есть документация или нет. В совершенстве владея reverse engineering, он в уме потрясающе легко умел переходить от кода к архитектуре, и наоборот. В результате, проектируя, он всегда детально представлял, в какой код превратятся его мысли, и поэтому был способен быстро прокручивать в голове огромное количество вариантов, отбрасывая "плохие". В его понимании, архитектор, не умеющий читать чужой код с "листа", и не пишущий своего - подобен инвалиду, пытающемуся бегать на костылях. Он довольно быстро закончит очень плохим архитектором - вопрос нескольких лет.
Второй важный аспект этой философии - понимание того, что код пишется в первую очередь для человека, и только во вторую - для компьютера. Это приводит нас к идеям, близким по духу к literate programming, за которое ратует Кнут. Как может человек, который не в состоянии внятно выразить свою мысль на неформальном, знакомом ему с детства естественном языке, выразить эту же мысль понятным образом на существенно более формальном языке программирования? Но это уже другая история.

9. Куча статеек про то как правильно пользоваться JUnit, но я обратил внимание только на пару и те про Rule-ы - первая и вторая. И еще вот тут хоршее-архитектурное про JUnit.
10. Одна из десятков тысяч статей про няшки в Guava - UnsignedInts, CHarMatcher, MurmurHash, InternetDomainName,ClassPath utils.
11. Google заопенсорсил свой внутренний билдтул bazel.io. Найдите 10 отличий от buck в исполнении Facebook, который пилит бывший инженер Google :D Пожалуй разрожусь-ка я статейкой про Not Invented Here синдром.