В IT чудес не бывает

< "This is hard (or slow) to test" typically also means hard (or slow) to use, learn, interpret, understand, or fix. In other words: a bug. > Michael Bolton
#testing #quality

"На соседнем, на заводе,
При честном при всём народе,
Старый мусор и навоз
Превращают в паровоз." (с) Воинов В. Петроградские чудеса, 1922

Все из тех же запчастей
Изменив чуть-чуть рецепт
Поменяв чугун на код
Мы все с вами пишем софт
(с) @maxbeard12 2024

недобрые пятничные #it_memes

— Когда релиз?
— На горизонте.
— А что такое горизонт?
— Горизонт — это воображаемая линия, которая удаляется от нас по мере приближения.
(с) tproger

#it_философия

Про карты гипотез - как методе стратегического планирования.
В целом, как и говорит сам Александр, все базируется на Impact Mapping Гойко Аджича (горячая тема лет 10-12 назад, но и сейчас еще мелькают статьи про нее, в реале использования я не видел).
Сам я пока не узнал в чем же фишка именно карты гипотез, но может кому зайдет. Интересно.
Особенно про ошибки при создании карты.

Here are the secrets of high-performing teams…

Creating A Team. (Or Maybe You Shouldn’t.): Ask the unasked question: do you really need a team? And if you have more members than a 90’s boy band, you’re in trouble. Every time a team is unnecessarily expanded, a productivity fairy dies.

Team Effectiveness: 60 percent of a team’s success is “Who’s on the team?” 30 percent is clarifying roles. And 10 percent is leadership. So get A-Players. The difference between the best and worst performers is the difference between a firecracker and the Big Bang.

Team Interaction: They need to like each other. Social skills, not average IQ, is what makes smart teams. And you need a disagreeable person. Somebody more Wednesday Addams than Mary Poppins. They might not be the hero you want, but they’re the hero you need; the one who’ll pull the emergency brake on the runaway train of groupthink.

Team Leadership: Even in the Navy, the best squadrons are led by commanders who are less like Captain Bligh and more like Mr. Rogers. Create an environment with safety (Does everyone feel they can speak?), vulnerability (good old-fashioned emotional nudity) and purpose (“This is who we are. This is what we stand for.”) and you’re most of the way there.

#management #процессы

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

Why I'm Not Writing a Productivity Series - Jacob Kaplan-Moss
“They were feeling stuck. Their job was fine but not great – good enough that they didn’t want to switch jobs for a simple lateral move, but bad enough that they were mildly unhappy much of the time. They didn’t have the skillset they needed to land a new job at a higher seniority and pay grade, and there were no opportunities for advancement at their current job. They had been trying to spend time leveling up, but hadn’t made any progress.” (отзывается 🙂)

А вообще статья про то, что все материалы про личную продуктивность это "за все хорошее и против всего плохого", их читаешь, как перлы Капитана Очевидности.
Я в этом плане достаточно прямолинеен и категоричен:
- ты или воспитан так, что не можешь безответственно относится к работе (и даже как-то страдаешь, если не по каким-то причинам что-то не получается), и поэтому просто херачишь
- или регулируешь свою продуктивность в зависимости от внешного контекста, чтобы крышу не сорвало
- или думаешь, что все зашибись, а про обратное узнаешь практически случайно
- всегда заниматься только тем, что нравится - крайняя редкость
- все остальное - воля случая 🫠
- личные таск-трекеры - это писец 🙈
#развитие

Народная примета: если команда или компания во время найма ищут себе волшебника - они обязательно найдут. Только сказочника.

сегодня просто #байки без пятничных #it_memes

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

Подробнее в исследовании "Cooperation, Competition, and Team Performance: Toward a Contingency Approach".
Немного картинок оттуда в комментах.

PS сам я ни разу не любитель соревнований, в любом их проявлении.
#процессы #management

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

За каждую победу команде давали наклейку, которую клеили на дверь комнаты, где работала команда. Геймификация...

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

Были действительно ли все наклейки на всех дверях по делу, можно ли было без соревнований такое делать мы уже не узнаем.

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

#байки про соревнования

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

Продолжение про соревнования обязательно будет. Вы вчера хороших мыслей накидали. Спасибо 🤝

Хотя-я-я, как начинать день без умных мыслей из газет интернетов, поэтому вот:

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

#мысли_вслух #байки

Cоревновательные моменты на работе.
Помогают, мешают?
Чему и как именно?
Что думаете?
#процессы #management

Тема недели в #it_memes

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

#мысли_вслух #it_философия #test_automation

Понятно, что надо плясать вокруг "не пытаются выравнивать свои активности с релизами, продуктовыми задачами и проблемами".
1. Работающий вариант распространения контекста (в обе стороны, кстати говоря) - это "командировки" инженеров в продуктовые команды и наоборот.
2. Донесение мысли о том, что все они тут нужны не для того, чтобы свои задачи работать, а чтобы продукты деньги зарабатывали, кажется очевидным, но почему-то обычно самым сложным :)
3. Повышение прозрачности работы "общих" команд для всех остальных. Бывает такое, что они реально дело делают, а со стороны выглядит как... "херней страдают".
4. Распространение знаний/экспертизы в продуктовые команды

Но в целом, иногда основной причиной лежит недоверие всех ко всем :)
Разрабы не могут тестить, никто кроме безопасников не может давать апрув... ну и тдтп.
Это сложнее всего "чинить", а многие считают это чуть ли не фундаментом работы, а значит это в принципе нечинибельно.

Если в компании есть инженерные отделы, основной задачей которых является “как бы” помощь продуктовым командам делать/выпускать их продукт(ы), обеспечение процесса разработки и тп, а эти команды не пытаются выравнивать свои активности с релизами, продуктовыми задачами и проблемам, то рано или поздно (скорее рано) все они превращаются в “вахтеров” со своими правилами, регламентами, "best practices" и системой разрешений.
Работа продуктовых команд при этом превращается в увлекательное преодоление множества препятствий к релизу…

Что это могут быть за команды? Те самые “общие” devops, отдельные внешние команды тестирования, безопасники, разработчики типа “общих” компонентов.
И в итоге у каждого есть понимание смысла своего существования, целей и пользы, но на выходе сплошной output вместо outcome и, эммм, напряженные отношения….

Варианты "че с этим делать"

#байки #мысли_вслух #holywar

Если оценку задач делает не "специально обученный быть крайним человек" лид, а решение принимается на командной встрече, то предлагаю такой вполне рабочий процесс:

Работу над оценкой задач на следующий спринт начинаем в текущем спринте.
Встреча 1 (30-45 мин):
• смотрим на ожидаемый список историй/задач (формирует PO исходя из целей спринта, но возможно участие команды, особенно по техническим задачам)
• определяем задачи, по которым недостаточно информации для их оценки (по остальным сразу делаем оценку)
• у каждой такой задачи появляется ответственный, который до проведения следующей встречи собирает нужную для оценки информацию (корректность проработки, место(-а) в коде, которые надо изменить/дописать, синхронизация со смежной командой и тд) и делает на базе этого предварительную оценку* (см дальше пояснения)

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

Встреча планирования спринта (15 мин**):
• если за время после 2й встречи ничего нового не прилетело, то в спринт просто берутся задачи согласно текущей “скорости прожевывания сторипойнтов” (ака velocity) и их приоритетов
• если что-то прилетело и оно важно, то это обсуждается уже на планировании. Но лучше бы конечно это все же сделать предварительно, иначе оценка будет скорее “пальцем в небо”.

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

*По опыту, самая холиварная тема - это “а как я буду что-то ресечить, если у меня куча задач по текущему спринту?”. Все просто - время на ресеч “закладывается” при планировании через анализ текущей скорости прожевывания сторипойнтов командой. Речь не про то, что этим надо заниматься по ночам. Для трепетно относящихся к учету времени для такие ресечей на оценку можно заводить задачи с фиксированными значениям сторипойнтов.
** вторая по популярности тема "это ж нафига столько встреч?"
Ну, во-первых, суммарно по времени получается не больше, чем одна большая встреча планинга (где большей частью все "играют в покер", а не планируют). Во-вторых, обычно в этом случае мы получаем более осознанную и точную оценку, часто выясняются неочевидные вещи, требующие дополнительного ресеча и задача в этом случае просто не берется в работу в текущий спринт. Что, в конечном итоге, тоже экономит время. Ну и в третьих, первую встречу вполне можно проводить "заочно" и асинхронно.

Почему такой процесс редко можно встретить в реале? :)
Да фиг его знает, я ставлю на "лень-матушка раньше нас родилась...". Всегда ведь проще погадать на планинге не делая предварительного исследования.

#процессы #оценка

В четверг в комментах обещал побухтеть про оценку.
Мое определение оценки:
“Процесс в рамках которого, мы разбираемся, что от нас ждут, что нам для этого надо сделать и в каких частях нашего приложения, какие у нас зависимости, готовы ли они к нашим задачам, какие риски и тдтп. А "оценка времени" - это лишь один из артефактов процесса оценки.”

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

Тут будут просто советы, а завтра про собственно процесс, как я его вижу.

1. У всех, кто участвует в процессе, должно быть одинаковое понимание того, что именно они оценивают и с какой точностью эта оценка делается (подробнее смотри совет 1 отсюда )
2. Важно понимать, что ошибки оценки все равно будут. И поэтому должны быть:
• процесс работы над этими ошибками (расширяем базу знаний и подходы для следующих оценок) с тем, чтобы в следующий раз оценка была точнее
• процесс информирования о возникающих из-за этого рисках (не тянем до последнего)
3. При запуске/перестройке процесса оценки очень помогают эталонные (референтные) задачи, сравнивая с которыми мы пытаемся оценить наши текущие задачи
4. Оценка в сторипойнтах - это в том числе способ избежать необходимости точной оценки: когда оценивается, например, в часах, сразу возникает ситуация, когда было запланировано например 3 часа, а задача сделана за 3.5.
Это хорошая оценка или продолб? А 4 часа? А как это время измерялось и что в него входило?
5. Не бывает “копеечных” задач. Вообще не используйте это обозначение. Оно мешает запускать в голове комплексный процесс оценки задачи, зато помогает забыть про важные вещи.
6. БОльшая декомпозиция помогает точности оценки
7. Постепенный уход в сторону простого кол-ва задач, тогда можно просто считать кол-во задач и меньше думать про их оценивание.

Кстати, в очередной раз “эффект инфополя”: пишу заметку, а в рассылке в пятницу пришла хорошая статья по теме оценки.

И еще тут у меня было про этой теме.

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

#процессы #оценка

Результат #codereview на 50 строк vs 100500 строк

Сделал дело и идешь смотреть пятничные #it_memes

Есть ложь, наглая ложь и "тут всего пара строчек, оценю задачу в половину сторипоинта" (байки из интернетов)

#metrics #байки

"20% теории управления достаточно для 80% результатов. Если конечно принцип Парето работает" Ryan Lilly

Вся мякотка в том, что далеко не все менеджеры знают и 5% этой теории. А если и знают, то не используют.

#мысли_вслух #management