Рассказываю что такое SCRUM

*https://www.youtube.com/watch?v=TQkrPnSh3Uc
**https://300.ya.ru/v_q0VrVYkD

Таймкоды

00:00:01 Введение в проблему

  • Обсуждение деградации идеи скрама в корпоративных IT-структурах.
  • Проблема отсутствия контроля и удалённости от реальных решений в больших компаниях.
  • Лояльность менеджеров к существующим правилам вместо принятия новых решений.

00:02:00 Принцип водопада

  • Объяснение принципа водопада: требования от бизнеса проходят через несколько этапов: продуктовнер, аналитик, архитектор.
  • Каждый этап занимает определённое время, что приводит к задержкам и ошибкам.
  • Пример: требования могут быть искажены или упущены на промежуточных этапах.

00:04:14 Проблемы водопада

  • Задержки между получением требований и началом разработки.
  • Неточности в спеке и несоответствие требований бизнеса.
  • Повторение циклов доработки из-за ошибок на предыдущих этапах.

00:07:23 Гибкие методологии

  • Введение гибких методологий, таких как Scrum.
  • Совместная работа команды над проектом с участием бизнеса.
  • Итеративный подход: разработка небольших фрагментов функционала.

00:09:07 Преимущества и недостатки Scrum

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

00:10:00 Заключение

  • Подчёркивание позитивных моментов скрама, но критика текущей ситуации в разработке.
  • Критика состояния разработки в западных странах как «ада».

00:10:32 Проблемы корпоративной структуры

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

00:11:29 Основы взаимодействия бизнеса и команды

  • Обсуждаются правила создания созвонов, отчётности, приоритезации задач и их выполнения.
  • Упоминаются правила решения проблем, возникающих в процессе работы.

00:12:15 Начало взаимодействия

  • Бизнес объясняет свои требования, команда разбивает задачи на кусочки.
  • Команда определяет, кто что будет делать, и получает «зелёный свет» на выполнение задач.

00:13:14 Спринт и итерация

  • Объясняется понятие спринта и итерации, каждая задача должна укладываться в две недели.
  • Описывается процесс разбиения задач на мелкие подзадачки.

00:14:04 Оценка задач и стори пойнты

  • Стори пойнты используются для оценки времени выполнения задач.
  • Подчёркивается, что на практике стори пойнты конвертируются во время в часах.

00:15:44 Синхронизация оценок

  • Оцениваются минимальные задачи, чтобы определить разброс в оценках.
  • Участники должны объяснить, почему их оценки различаются, и синхронизировать их.

00:17:38 Ретро созвоны

  • Ретро созвоны проводятся раз в неделю или две для обсуждения успехов и неудач.
  • Цель ретро созвонов — выявить и решить проблемы, а не просто зафиксировать успехи.

00:18:10 Роль скрам-мастера

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

00:18:49 Проблемы с скрам-мастерами

  • Скрам-мастера могут вмешиваться в процессы компании, создавая лишний шум.
  • Реальные процессы должны быть доверены команде, а не внешним специалистам.
  • В США наблюдается тенденция к увольнению лишних специалистов.

00:20:26 Использование Jira

  • Jira используется для отслеживания прогресса задач и создания бэклога.
  • Система Jira может быть усложнена дополнительными процессами и статусами.
  • Избыточные процессы отвлекают от реальной разработки.

00:22:24 Проблемы с story points

  • Story points полезны только на этапе обсуждения задач.
  • Избыточное использование story points создаёт политические игры и отвлекает от работы.
  • Разные программисты по-разному оценивают задачи, что приводит к разногласиям.

00:23:29 Избыточные митинги

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

00:25:05 Проблемы с выполнением задач

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

00:27:46 Различия в подходах

  • В России больше шансов поднять реальные проблемы, чем на Западе.
  • На Западе часто обсуждаются вторичные вопросы, в то время как в России больше внимания уделяется основным проблемам.

00:28:10 Иллюзия менеджмента

  • Митинги не требуют участия всей команды.
  • Большинство людей не понимают основ управления проектами.
  • Скрам часто используется как «карго-культ», без глубокого понимания его принципов.

00:29:10 Проблемы с управлением

  • Споры о деталях процессов не влияют на реальную производительность.
  • Jira создаёт иллюзию управления, но не отражает реальную ситуацию.
  • Приоритизация важна, но не заменяет выполнение работы.

00:30:01 Снижение производительности

  • Команда может вводить менеджера в заблуждение, растягивая задачи.
  • Низкая производительность приводит к багам и хаосу.
  • Необходимо измерять эффективность другими метриками, кроме задач.

00:30:59 Роль скрам-мастеров

  • Скрам-мастера часто не справляются со своими обязанностями.
  • Корпоративные структуры с большим количеством сотрудников — рассадник проблем.
  • Рекомендуется однократное обучение от опытного специалиста.

00:32:02 Преимущества Jira

  • Jira позволяет отслеживать грубые нарушения и прогресс задач.
  • Можно увидеть, когда тестировщик не выполнял свои обязанности.
  • Дефинишн дан помогает чётко определить, когда задача выполнена.

00:33:40 Защита программистов

  • В нормальных компаниях нельзя менять задачи программиста посередине работы.
  • Программист может ссылаться на правила для защиты своих действий.
  • Соблюдение правил защищает программистов от необоснованных претензий.

Расшифровка видео

Поиск по видео
0:01
Катаны, всем привет. В этом видосе я расскажу про такое понятие, как скрам, и
0:07
расскажу, как это вроде как очень толковая идея, а, сильно деградировала и создала
0:16
такое болото в реалиях в реалиях IT и особенно в
0:25
корпоративных реалиях в IT. То есть, когда вы пишете код, находясь в больших
0:30
структурах, где тысячи сотрудников и большого контроля нет, и главное
0:37
нету, а расстояния между вами и между тем человеком, который может реально что-то сделать. Она огромная. То есть
0:44
чаще всего большинство менеджеров не понимают, что когда тебе
0:52
дают позицию менеджера, тебе дают по сути право, да, то есть у тебя появляются возможности принимать тяжёлые
1:00
решения. Чаще всего эти решения, они ассоциируются с тем, что нужно делать
1:06
что-то, что как не заведено, да, но большинство менеджеров получает своё
1:12
повышение ровно наоборот. они получают своё повышение, потому что они лойлисты
1:18
и директорам, то есть они делают очень часто анилингус
1:24
вышестоящим, и они очень, а, как сказать, доточно
1:32
следуют правилам, которые существовали до них. То есть независимо, какие правила это были. Если это был,
1:37
например, там одна среда разработки, там тефол, то они следует тефол его защищать. Если это было наоборот, то они
1:44
забира, ну, заселяет урон то, что было наоборот. У них как бы по сути они как бы заскриптованные боты. Можно вот прямо
1:51
писать. Ладно, значит, сначала мы начнём, поговорим про теall и про скрам. Я думаю, где-то уже видос рассказывал,
1:57
но я сейчас повторюсь, чтобы понять. Значит, что такое waterfall? Waterfall или водопад ещё называют. В чём его
2:03
идея? А вообще слово водопадки я понимаю, там, наверное, было изображение водопада, да? То есть его рисовали как?
2:11
Ну, давайте прямо порисуем немножко. То есть вы рисовали в виде Ну
2:17
давайте так, насколько я хорош в рисовании. Значит, ну вот как-то так,
2:23
да? Вот водичка падает со скалы. Значит, идея такая, что сверху вам приходят
2:29
требования. Это приходит требования от бизнеса. Значит, он говорит: «Я хочу написать какой-то функционал». Значит,
2:36
он падает на обычно продуктовнера, то есть человек, который общается с
2:42
бизнесом. Затем, а продуктовнер понимает примерно, что бизнес хочет, убирает всю
2:48
лишь информацию, оставляет только ту самую самую важную, потом он отдаёт. То есть, например, это занимает какое-то
2:53
время. Ну, так для условности поставим, что это, например, один, да, то есть 1на неделя, один месяц, неважно. Значит,
2:59
после того, как продуктовнер всё понял, он, ну, тратит какое-то время, например, тоже там неделю или две, например,
3:07
допустим, например, там 2 недели, он передаёт информацию аналитику, и
3:13
аналитик он, а, как бы транскрибирует, а, те бизнес-требования
3:19
в какие-то функциональные требования для программиста. Затем или, например, архитектору. То есть там можно
3:25
придумать, в принципе, ну, несколько таких ролей, которые, ну, в разных компаниях называются по-разному, но
3:31
смысл такой, что они является промежуточным звеном. Потом идёт следующее звено, например, там аналитик,
3:37
там тоже, например, одна один, одна неделя или там один день, который, а,
3:42
вот эти все какие-то верхний уровни функциональ требования уже переписывает
3:48
в конкретный. Например, если там было написано: «Сохраняем в базе данных». Он говорит: «Какая база данных?» там что-то
3:54
позгроз пишет, какие таблички, какие связи между этими, там есть табличками, какие колонки, какой формат, а там, ну и
4:02
так далее. То есть он всё описывает для того, для того, чтобы программист затем не парился, просто прочитал спеку. То
4:07
есть вот здесь где-то вот на этом этапе получается такая спека, которая понятна
4:13
программисту. Вообще спека — это прекрасная вещь. Давно у меня не было спек. Ладно. И потом идёт наш вот этот
4:20
вот, а, крестьянин, программист, который берёт эту спеку и пишет. Значит, в чём
4:26
проблема? Проблема в том, что вот между этапом, когда есть спека, которую можно писать, и, э, откликом между бизнесом,
4:35
он большой. То есть получается, в нашем случае, например, это если была по неделя, то получается месяц. Так вот, когда эта спека приходит, во-первых, она
4:41
получается как, знаете, как, ну, ну, как там разбитый телефон, я бы, конечно, назвал это более по-жёсткому.
4:50
Но то, что пишет, то, что написано в СПЕК, то, что пишет программист, зачастую не то, что требовал бизнес. Ну,
4:57
потому что, например, а, продуктовнер, да, может быть, умственно отсталый, либо функциональный аналитик какой-то упёртый
5:02
баран, а, либо аналитик обычный ну, точнее, как архитектор, да, упёртый
5:08
баран, либо, например, аналитик там прибухнул и что-то там упустил и где-то
5:14
потеряет, где-то вот эта информация теряется. И получается, что когда, например, программист делает, например, он это делает за там, допустим, там 3че
5:22
недели, да, всё пишет весь код и потом показывает бизнесу, наверх поднимается,
5:27
бизнес охреневает и говорит: «Вы что, мне написали, всех уволю». Хотя уже было оплачено, да? То есть были
5:33
было оплачено время. Более того, на первом этапе есть такой шанс, что программист
5:40
вообще ничего не делал первый первые 4 недели, потому что был занят продуктов, архитектор и аналитик. чем-то заняты
5:47
были, да, аналогичный аналитик ничего не делал 3 недели, потому что архитектор и
5:54
продуктовнер чем-то занимались. Ну и, соответственно, ещё, соответственно, архитектор тоже занимался 2 недели. То
5:59
есть есть такой простой, но это так, это обычно на первую неделю, ну, точнее на первую итерацию. Значит, так вот. А
6:07
когда приходит ответ, он говорит, что вы идиоты, что вы наделали, всё неправильно, этот цикл повторяется.
6:12
Опять нужна неделя здесь, 2 недели здесь, одна неделя здесь. И потом только опять переходит спека, и опять нужно 4
6:18
недели, и потом поднимается, и потом опять огодо идиоты, последний шанс. И получается огромный, ну, как бы всегда
6:25
огромное расстояние между тем, что ожидается и тем, что за что как бы
6:31
уплочено. А, но это не всегда так. Значит, ну это это была как бы ключевая проблема, потому что софту, когда
6:39
пишут программное обеспечение, можно сильно как бы отклониться от задумки.
6:45
Значит, поэтому, а если представлять терфол, да, то есть вот это
6:52
водопад, то он как бы условно может пристать в одним большим квадратом. То есть в самом начале вам что-то говорят и
6:58
в самом конце, через сколько там недель, через там 8 недель у вас всё готово. Проблема в том, что если здесь вы
7:03
накосячили, то тогда вам нужно ещё одну и торацию такую сделать, которая, ну,
7:09
возможно, решит проблему. То есть в идеале, если у вас спека идеальная, что
7:14
в некоторых случаях очень, ну, такое может быть, что спека не сильно отличается и там нужно минимальные
7:20
правки делать, тоfall — это идеальный сценарий. И есть такие сценарий, когда это лучше всего, когда всё чётко
7:27
прописано, всё понятно там, значит, но зачастую это не работает.
7:33
Поэтому придумали новый вариант, а этого ой, а как этот agile, да? Это у нас
7:41
гибкие гибкая среда разработки или там гибкий фреймворк разработки. Значит, идея в чём? В том, что садятся все вот
7:48
эти вот три аболтуса вместе. Значит, там, ну, po, да,
7:55
productр, архитектор. Давайте напим архитект, да, архитектор, аналитик и разраб, да,
8:04
крестьянин наш. Они все садятся вместе. Значит, вместе с ними садится чувак. Ну,
8:09
бизнес. Иногда бизнеса просто нет. Иногда сам PO является бизнесом. То есть у нас просто вот на эту же структуру
8:17
посмотрим, нужно просто как бы всех наверх, на уровень поднять наверх, а ПИО превращается в бизнесмена. Они все
8:22
садятся вместе, значит, и бизнес говорит: «Хочу там какую-то функциональность». Они все садятся,
8:27
говорят, что мы не можем написать всю функциональность, но мы можем написать там из там пяти штуковин можем написать,
8:34
например, там одну, да, или из десяти. Бизнес говорит: «Ладно, пишите одну».
8:39
Они за 2 недели делают какое-то значит, одну эту штуку пишут за 2 недели, и через 2 недели к нему
8:44
возвращаются. Он говорит: «Вы опять не то сделали». Но теперь разница
8:50
между между началом, ну, то есть в первом случае у вас было ожидание 8 недель, здесь ожидание в 2 недели либо
8:56
даже неделя, да? Если итерация маленькая, но тогда кусочек, который они сделает, он ещё меньше. И получается,
9:01
что так как есть дополнительная получается бюрократия, дополнительные созвоны и так далее, то есть тут много
9:08
по-настоящему всего появляются, а а то суммарное суммарное время на
9:16
разработку оно увеличивается. То есть, если мы возьмём идеальный случай, когда у вас один раз дали хорошую спеку, да,
9:22
поочерёдно, например, это займёт там, ну, не знаю, там там 4 недели, да, в сумме. А если мы сделаем тот же самый,
9:30
тот же самый трюк с гибкой свето разработки, там может не четыре быть недели. Ну, тут сколько у
9:36
нас? 1 2 3 4 5, например, пять, да? А это может занять больше. Это может занять, например, там,
9:43
ну, 13 недель. То есть в одном случае либо пть, либо 13. И вроде
9:49
как 13-то многовато, но на практике вот эти вот, э, в первом случае иногда вот
9:56
этих длинных штуковин их бывает много, да, их может вполне реально быть три. То есть здесь однозначно сказать
10:03
сложно, какой будет разброс. Ну, в общем, на практике показалось, что скрам, разработка, подход. И то есть там
10:10
сейчас, ну, я сейчас буду это объяснять, там набор правил. Они привнесли хорошие позитивные моменты, но, к сожалению, то,
10:17
что происходит сейчас в разработке, особенно в западных странах, это просто, ну, это не знаю,
10:24
это ад, ад, блевота, что там ещё, а, гулак.
10:32
Ну, в общем, можно перечислять дальше, но я думаю, суть вы поняли. То есть настолько извратили саму суть вот этих
10:38
простых идей, которые есть, что, ну, как бы вот это одна из причин, а почему я
10:45
ненавижу корпоративную структуру и почему я не терплю. То есть я, когда
10:50
захожу в какую-то компанию, если я вижу, что у них процессы, ну, они не понимают сути процессов, конечно, начинают у меня
10:56
очень сильно бомбить и бомбит от начала до конца. Ладно, значит, ну, давайте проговорим
11:02
про такие суперпростые основы. Значит, а,
11:07
есть ряд созвонов, да, то есть когда вот садятся вот эти вот ребята, значит,
11:13
бизнес и как бы команда, есть ряд процессов, как они взаимодействуют с
11:18
друг другом. Но чаще всего это значит, какие есть правила создания созвонов, отчётности, приоритизации
11:27
задач и процесса их выполнения. Значит, то есть, ну, на практике чаще речь идт про то, как,
11:33
значит, договориться, приоритизировать, ну, там, разбить задачи, потом их
11:38
приоритизировать и потом, а, их взять в работу. И когда они будут взяты в работу, когда программист будет ими
11:46
заниматься, есть правила, как, ну, как бы как делать в случае каких-то проблем,
11:51
которые могут появиться, потому что проблемы чаще всего появляются почти всегда. Значит, есть разные, то есть я то, что
11:59
сейчас буду рассказывать, это не всё, это моя, ну, то есть моя интерпретация. Просто настолько много шума сейчас, то
12:04
есть настолько много в своё время вообще скрамастера это прямо было как вот, знаешь, как, знаете, как у нас вот инфоцигане появились где-то там, может
12:10
быть, лет 10 назад. Такой пик их был такая что, ну, новая штука была. Вот также и в IT-разработке, я помню в 2000
12:18
где-то тринадцатом году у нас прямо из Америки чувак приезжал. И, кстати, он неплохой был
12:24
такой чувак. Я сейчас вот смотрю, у неё ретроспективно, он довольно ясно объяснял, то есть то, что сейчас происходит, там вообще это такой ужас.
12:30
То есть там так такие каши в головах и все себя строят каких-то там товарищей.
12:35
Значит, ладно, давайте поговорим по проще. Смотрите, значит, всё начинается с того, что приходит бизнес, а приходит
12:41
команда, и на этом созвонии бизнес объясняет, что хочет, и команда должна, по идее, разделить задачи на кусочки.
12:48
Потом, значит, там либо он с этого уходит, прямо с него же уходит, с этого
12:54
созвона и даёт какое-то время команде, и это как бы продолжается первый созн.
12:59
Команда внутри себя определяет какие, то есть он им даёт свет, например, зелёный свет на какие-то сдачи, да? Они говорят:
13:04
«Вот мы разбили на 10 задачу». Он говорит: «Ладно, там первую, третью, пятую». Значит, после этого у команда есть возможность, это сама определяет и
13:11
уже разбивает эти разбитой задачи она, а, ну, как бы определяет, кто что будет
13:17
делать. Хотя сейчас что-то проверяю, но не суть. Короче, главное, что вот из этого вот этот созвон спринпнинг, да, это созвоны.
13:24
Их можно там иногда чаще всего делать один. Никто не чаще никто не я никогда не видел, чтобы тот кто тот отследовал вот этом правила, что это должно быть
13:31
два. Просто один раз садятся и всё. И говорят: «Вот, вот список сдач». Да, и он говорит там, ну, эту, эту, эту
13:36
задачу. Это ну или приоритет расставляет. То есть там есть понятие бэклога, то есть это список задач, которые взяты на спринт. Значит, да, про
13:44
спринт, блин, я не сказал. Самое главное, да, то есть самое главное, что а нет, я говорил, я просто слова не
13:49
сказал, что есть срок вот этого одной итерации, когда задачи э выполняются,
13:56
да, то есть набираются задач не больше, чем на вот эту итерацию. То есть и вообще каждая задач, она должна влезать
14:01
в итерацию, то есть любая задача должна влезать в 2 недели. Есть целая наука, как разбивать задачу, потому что некоторые задачи как бы
14:07
сложновато разбить на итерацию, потому что я смотрю, если итерация недельная, то там получается работа остаётся там,
14:13
например, там, ну, 3 дня или 3 с по дня, потому что всё остальное митинги
14:18
занимают. Ой, бля, что-то, короче, я уже далеко ухожу. Давайте так поделаю. Значит, смотрите, есть, например,
14:25
созвон, когда разбивают задачи подробно каждую. Его называют по-разному. И называют иногда refймен meнг, иногда
14:31
называют гминтинг. Ну, груминг — это вычёсывание, refймен — это тоже там как бы, ну, вот распределение на мелкие там
14:38
подзадачки, вычисление, сколько каждая задача занимает сторипоинтов. Значит, что такое
14:44
сторипоинты? Сторипоинты — это некая просто такая относительная величина. И я вам скажу, в реалиях не это неко никогда
14:51
нахрен не относительная величина. Как только ты начинаешь поднимать эту тему, все у всех начинается евангелистов с
14:57
храма начинается лютый лютый такой батхёрт, который сразу можно, знаете, увидеть, что, мне кажется, детектируют
15:03
даже вот на радиолокаторах ядерных этих, знаете, взлётов сотни вот взлётов этих
15:10
пердаков каждый каждый, я не знаю, месяц по-любому, каждый день, наверное, блин.
15:15
То есть потому что в чём идея? Дело в том, что вообще идея создавать оценку
15:21
сдачи, а, чаще всего она связана с тем, чтобы, а, определить, влазит ли задача в
15:28
2 недели. Но получается, если оценка относительная, да, то получается это никогда не узнаешь. Но на практике все
15:34
всегда понимают, что это все конвертируют эти сторипоинты во время, да, в часы. То есть, что бы они там не
15:41
говорили, всё равно это, ну, это как бы, ну, это очевидно. Значит, а самая ценная
15:46
вещь, когда вы разбиваете задачку на вот эти сторипоинты, на кусочки, то есть на вы оценивае, вы берёте какую-то задачку,
15:52
да, и говорите, что эта задачка, она примерно в три раза больше, чем какая-то такая минимальная задачка. Вы сами
15:57
можете её придумать в три команды. Но дело в том, что самая минимальная задачка, она тоже имеет какую-то длину. Все понимают, сколько по времени она
16:03
занимает. То есть понятно, что кто можно сказать: «Ну, у джина это займёт больше времени там, а у медла там ещё меньше и
16:08
у синьор ещё меньше». Но всё равно у всех в голове примерно одна и та же картина. Так вот, самое ценное здесь это
16:16
в том, что если вы ставите сторипоинты, то, значит, если у вас будет большой разброс стори поинтов, кто-то скажет,
16:21
например, нужно там 15 сделать, кто-то там 10 скажет, то вы можете поднять и спросить: «А а конкретно, да, то есть
16:28
почему она занимает стоко?» И он должен сказать, какие там этапы есть. На этом моменте должны определить, а каких каких
16:35
что, короче, забыли упомянуть, да, во время созвоно какая часть задачи, она
16:40
присутствует, но вы её не проговорили. То есть кто-то кто-то просто это понял, что там, например, задача, например,
16:46
содержит, например, там авторизацию, там валидацию, что-нибудь ещё. А кто-то подумал, что там только
16:52
авторизация, забыл про валидацию. И тот, кто оценил побольше, он должен объяснить. И когда они все синхронизируются, да, то есть вот эта
16:58
вот оценка в сторипоинтах, она должна, по идее, привести не к тому, что вы ставите оценку, а к тому, что вы
17:04
правильно задачу прогрумили. То есть вы написали все её кусочки, но это
17:10
приходит, это приводит к такой такому одищу. Иногда вот эти вот refймен митинги, они вместо того, чтобы заранее
17:17
хорошо кто-то там, ну, там аналитик, когда эту задачу готовит или там, ну, там кто-нибудь, кто её готовит, значит,
17:22
а он должен прописать её хорошо. Чаще всего, если она хорошо прописана, она особо вот этого ничего и не
17:28
требует. Ну, это так, значит, а, ну, есть каждодневный созвон, да, который
17:33
длится каждый день, и, э, каждое утром вы отчитываетесь, что вы делаете, какого состояние по сдачи. Есть ретросозвоны,
17:40
причём это сейчас уже не связано с с у вас с крам или не скрам. Просто это созвоны там раз в неделю или раз в две
17:45
недели сам иногда там раз в месяц, когда люди пишут, что было хорошо, что было плохо. По сути, это способ пожаловаться.
17:52
Так вот, если очень коротко говорить, ретро — это по сути про то, что пожаловаться. То, что было хорошо, да, всем плевать, блин. Все и так знают, что
17:58
было всё хорошо, как бы. Ну, чаще всего это нерелевантно. Релевантно именно ой
18:03
реванда именно то, что, ну, плохо, да. Но почему это там, к чему это приводит, я чуть позже
18:09
расскажу. Есть ещё понятие респнинг. Я вообще его включил. Я его никогда не видел, никогда не слышал, но я у чат
18:15
бота спросил, он мне сказал, что да, такой тоже существует. Значит, ладно. Значит, вот примерно мы поняли. Значит,
18:21
так. Значит, что к чему это приводит вот в реалии? Значит, что мы получаем? Значит,
18:27
во-первых, в связи с приходом скрама появились так называемые скрамы, скрамастеры. Значит, скрамастер он
18:34
определяет правила, он определяет, чтобы все процессы были соблюдены. Дело в том, что он нахрен не нужен. Достаточно
18:41
команду один раз обучить, объяснить правила, и то потом команда может сама разобраться. Если она где-то застревает,
18:46
она может спросить её какой-нибуд GPT, он скажет. То есть это лишний человек, который чаще всего за счёт того, что он
18:52
по сути не нужен, он либо влазит и что-то говорит, какие-то совершенно,
18:57
знаете, очевидные вещи вот из этих, как называют вот это Джейсон Statхм, да, вот
19:02
вот как Jason Head Statement, то есть он пытается во время э там созвона, ну,
19:10
например, у меня там помню одного чувака, он всегда брал и добавлял, например, тут что-то говорит, да, он
19:15
говорил: «Ты помни, типа, что если у тебя есть вопрос, обращайся коман команде. Мы тебе поможем, Ты какое отношение имеешь? Ты не команда,
19:21
что ты за всех отвечаешь? Да то, что мы поможем, это и так очевидно. Зачем ты это говоришь? И каждый раз он
19:27
это говорил просто, чтобы создать видимость, что я вот здесь нужен, что мне за что-то зарплату платят. А когда
19:33
были к нему какие-то серьёзные вопросы, неочевидные, он начинал отвечать какой-то чуши там, типа, что команда
19:38
сама решит там типа а up to the team. И такого дерьма полно. Ну, то есть есть вообще как бы там космические
19:44
скроммастеры, которые потом а пытаются влезть в процесс вообще самой компании,
19:50
да, чаще всего таких лучше четвертовать. Они не нужны. Они не нужны. Они только, а, как бы,
19:57
ну, а как бы они создают видимость своей деятельности, да, создают лишний шум. То есть ээ реальные процессы нужно доверять
20:04
именно людям снизу, которые вот знают реалии. Ну, чаще всего. Понятно, не джунам. Джуны как бы только вкатились,
20:11
но вот тем, кто вот именно педалит, да. Кроме скамастеров, там ещё есть какие-то жалкочи там. Короче, вот
20:17
этого мусора И он он реально, ну, он реально не нужен. Сейчас вроде в Америке пошла движуха, наконец-то, что
20:23
стали просто их всех увольнять чертям. Значит, а так,
20:30
значит, на практике GR, да, Джира — это чаще всего используется в больших компаниях, это уделитель для того, чтобы
20:38
отслеживать прогресс, да, то есть разбивать задачи на там, ну, то есть создаётся бэклок — это список, где все задачи лежат. Потом каждая задача имеет
20:44
какое-то состояние там, например, что её, например, э берут в спринт или,
20:50
например, ну, там по-разному, то есть колонки могут быть разные. Ну, так я так условно примерно говорю. Потом, например, сдача в работе, потом сдача,
20:56
например, в тестировании и задача, например, закончена. Да. Значит, и даже давайте, давайте посмотрим, как она
21:02
выглядит. Сейчас. Ну-ка, сейчас давайте-ка картинку открою. Так, ну вот пример такой, да,
21:08
вот типа to progress, review и done там. Ну, можно добавить разные. А так вот, а
21:15
Джира, она сама по себе очень сильно усложнена. И плюс с наличием скрама, и плюс с наличием ненужных людей, типа
21:21
скраммастеров. Иногда продуктовнеры играют с кромастеров. Создаётся целый такой каргокульт ненужных действий,
21:28
которые нахрен никому не всрались. То есть там создание вот этих дополнительные сторипоинты ставят, создают какие-то лишние колонки, создают
21:35
какие-то сложные процессы, что там из прогресс, из прогресс можно перейти там в какой-то определённый статус, а обратно нельзя. И это доводит реально до
21:43
до как бы, ну, до клиники, то есть когда по сути никакой ценности это не прибавляет. То есть джира, она должна
21:50
просто иметь какой-то, ну, как бы как это, как утилита, которая помогает просто отслеживать процесс. Вместо этого
21:56
она она становится на первой на первое место. И сама разработка уже не так
22:02
важна. То есть важны сами скорее важны сами процессы какое там состояние у какого-то тикета. То есть и
22:08
это как бы это это самая вредная вещь. То есть как бы сам программист и то, что он делает, то, что он работает, как бы
22:14
это становится как бы уже так вторично. То есть вот именно вот эти тикеты, они становятся более важными, и это как бы
22:19
отвратительно. Это полное Ладно, это просто вот моя моё личное мнение. Значит, ну, просторипоинта, почему эта
22:26
шляпа, а знаете как, ну, а если говорить про какие-то такие моменты, которые как
22:33
там помогли бы, ну, вот помогли бы,
22:38
а, команде, я бы так сказал, то, возможно, это, а, только процесс, когда идёт
22:46
обсуждение, что какой-то кусочек забыли. Вот вот это самый лучший момент. Потом можно, в принципе, сторипоинты убирать
22:52
вообще, чтобы их не было. Ну и второй, наверное, момент, когда понимается, что
22:57
задача большая, да, если кто-то сильно очень оценил, что очень много стори поинтов, тогда нужно задачу разбивать.
23:02
Всё. В остальном я думаю, что это нахрен никому не надо. Но потом и это это очень создаёт политические игры, потому что
23:08
кто-то говорит: «Вот видите, мы оценили мало сторипоинтов». А ты говоришь: «Вдь сторипоинты — это ведь относительная
23:13
величина, относительно какой-то задачи. для разных, а там, ну, там разные программисты по-разному делают, кто-то
23:18
более опытный, это наоборот может закратить ещ худшую роль, да, и скажешь: «Ой, ты получается там, ну, то есть это
23:24
как бы это всё вот политическое дерьмо». Значит,
23:29
за счёт большого количества митингов, особенно если туда приглашают всю команду, такое бывает довольно часто,
23:35
почти всегда, и это очень плохо. Куча времени на это тратится, да? То есть можно привести, например, на какие-то
23:41
митинги, например, если это чисто фронтенд задачи, там никому не должен не должен присутствовать, то по-хорошему её
23:46
вообще только с фронтенд команда разрабатывать. И иногда там есть часто команда девопсов, тоже лучше чаще всего
23:53
отдельно делать. Так получается всё целая армия приходит, там человек восемь приходит с большой командой и сидят
23:59
обсуждают какую-то там задачу там, например, на бэкэнд и там сидят все тратят своё время.
24:05
Значит, а плюс, а когда скрамастера и там, ну, эти пиошники тоже сильно
24:12
погружаются в кра, это бывает очень часто, очень немного ненужных разговоров начинают сраться там, какой должен быть
24:19
статус, как там можно перетаскивать сдачу влево, вправо и так далее. То есть там столько, столько шлака появляется,
24:25
столько агрессии, столько кто-то там начинает апеллировать на какие-то книжки, там ещё какие-то правила, типа,
24:30
что это как-то поможет. И опять же главное, что чем чем больше как бы ну времени тратится, чем больше эмоций на
24:36
это тратится, тем дальше сама разработка уходит на второй план, да? То есть она уже переходит уже на второй, третий
24:41
план. Значит, какие тоже минусы? Значит, а с одной стороны одно из правил — это, например, если ты
24:48
взял задачу, ты не должен переключаться на другую задачу, да? То есть должна быть одна задача, которую ты делаешь, пока она там не перешла в крайний правый
24:53
угол, ты ничего не меняешь. Значит, проблема в том, что многие, это,
24:58
наверное, один, кстати, самый, да, мне вотне нужно увеличить по размеру, чтобы вы понимали, это одна из самых больших
25:04
проблем. Это очень хороший способ для тех, кто, ну, лентяев, да,
25:09
программистов, линтяев. Тут уже речь идёт именно про программистов, про тех, кто выполняет, значит, ну, или тестировщик или ещё кто-то. Значит, в
25:15
чём дело? Если, например, особенно много было сторипоинтов на задаче, это вообще это идеальное прикрытие.
25:21
Они берут одну задачу, которая, например, занимает, ну, там по расчётам, например, 3 дня на выполнение или 4 дня.
25:26
Они делают её за за один день и потом 3 дня ей отчитываются, и ты ничего особо с этим не сделаешь, да, там, а что ты мне
25:33
сделаешь, я в другом городе. Вот это ровно то же самое. И постоянно так делают. И причём иногда я даже, ну, есть
25:40
есть способы, как можно ну, отфильтровать на конченность. То
25:45
есть я, причём вот, ну, не раз, ну, не то, что разполь, я замечал, да, вот этот факт. Значит, как это делается?
25:51
Например, чувак делает какую-то задачу, она зависит от какой-то команды, а команда, например, там, ну, там конкретно чаще всего будет программист,
25:58
он, например, в отпуск ушёл, да? Какие есть варианты у человека? То есть он понимает, либо ему придётся весь день
26:03
прождать, пока этот товарищ не придёт с отпуска, а, ну, либо там, может быть, на найти ещё кого-то, либо он должен просто
26:10
поднять этот вопрос. То есть он должен во время созвона сказать, что это задача заблокирован, и подумать насчёт того,
26:15
чтобы взять другую. И если он просто ничего не сделает, то всё это как бы можно, ну, товарищ, лучше его уволить
26:21
сразу. То есть он будет использовать вот эту защиту, потому что я ещё раз говорю,
26:27
вот одно из хороших правил Скрама, то, что ты защищён программисту, не приходится во время одного одной
26:32
интерации, во время одного спринта брать и быть прерванным каким-то товарищем,
26:39
да? Кто-то пришёл там из какого-то отделения, какой-то важный чувак и сказал там: «Я там Вася Пупкин, значит, делаю вот эту задачу». И он говорит: «У
26:46
нас есть процесс добавляй задачу в бэклок. Мы, значит, неё там поговорим, значит, мы её там разобьём на кусочки,
26:53
мы её возьмём в работу. Если этого не ну сделано, то ты иди поговори с нашим там
26:58
ПИО или с на скраммастером, если он есть. Это, конечно, печально, если он есть. А и пусть они как бы тебе пояснят,
27:04
да, как у нас тут разработка идёт. Значит, но вот как минус говорю, минус — это очень классическая тема. То есть это
27:10
я такое поч, ну, постоянно вижу, когда берут какую-то сдачу, прикрываются и вот типа вроде делает и
27:18
делает. А ещё один из косяков на ретре не поднимает реальные проблемы, да? То
27:23
есть когда ретроспектива, а обсуждает совершенно нерелевантные вещи, потому что по сути у никого нет яиц, поднять
27:30
вопрос, например, что кто-то не педалит, искать, что вот это вот товарищ, он реально не педалит, да? То есть надо
27:36
что-то с этим делать. То есть он как бы использует, ну он фактически как, ну как
27:41
как этот нахлебник, да? А и он получает как бы все, то есть, ну, другие
27:47
трудятся, да, он типа там что-то там делает по минимуму или, например, какие-то процессы есть тут
27:53
бессмысленные, там слишком много созвонов, например. Ну, большинство просто суд это обсуждать, большинство
27:58
говорит именно какой-то, знаете, такие, ну, совершенно, ну, вторичные вещи. Хотя всё-таки я говорю больше про Запад,
28:04
наверное, в России. У нас относительно у нас есть больше шансов, что у нас поднимут реальный
28:10
вопрос. Так, про иллюзию менеджмента. Так, ну то, что митинги не требуют все команды, я упомянул. Значит, такое,
28:17
значит, а, да, а, ну, и вот вам расскажу такую
28:23
как бы, ну, такую такой факт. Я могу сказать, что тотальное большинство людей, с которыми я работал, тотальные,
28:29
да, они не понимают, а в чём вот основные моменты, да, то есть они не
28:34
понимают, что что первично, что вторично, то есть они у них есть какоя
28:40
такая каша в голове, они чаще всего используют крам скрам. Это вот для них такой каргокульт. То есть они просто
28:45
повторяют, они не понимают, в чём идея. А и за счёт того, что они не понимают, в чём идея, они не знают, на что
28:52
ориентироваться. То есть за счёт того, что у них нет опыта, особенно если мы говорим про людей, у которых нет реального, ну, хотя бы там 5 лет
28:58
разработки, да, ну, это не обязательно может быть разработка, может быть, там тестировщик. То есть именно в виду инженерных процессов, которые вот
29:05
поработали и на руках поняли вот какие плюсы как работают. Да, большинство не понимает,
29:12
да? То есть я уже не раз видел, когда идут какой-то холивар за какую-то хрень,
29:17
там можно нужно перетаскивать или не нужно, там это никак в реальности не влияет, но ладно. А также джира, да, ну
29:26
вот это, честно говоря, независимо скрам, не скрам, но для скрама очень актуально. Она создаёт иллюзии того, что
29:31
есть некое управление, да? То есть смотрите, есть как бы колоночки, есть какие-то задачки. То есть вы вроде видите, что какие-то процессы идут, да,
29:38
какая движение идёт. То есть можно как-то взять отдачки, их раскидать по приоритетам, расставить. И вроде как это правильно. Ну это в смысле, это вроде
29:44
как правда, но это не так, да? То есть, а, ну, если мы говорим про
29:50
управление, то здесь нужно ставить ставку на то, что люди делают свою
29:55
работу, да, то есть и понятно, что, да, нужно ставить там приоритизацию, нужно,
30:01
то есть, то есть всё, что в скаме существует, это не отменяется. Но если команда не педалит, например, там
30:07
прикрываются тасками, растягивая задачи, то есть есть много способов, как ввести в заблуждение менеджера. Даже если он
30:14
технически сильный, всё равно можно там как бы ему сказки рассказывать, просто сказки поменьше, побольше. И когда это
30:21
вот появляется довольно много вот этих способов ввести в заблуждение, так или иначе, в конце концов производительность
30:26
проекта спадает, а это самое главное. То есть и вроде как бы вы можете управлять проектом, но если у него реально производительность низкая, либо
30:33
постоянно какие-то баги появляются или ещё что-то, то есть вы сделали задачу, сделали через жопу, а появилось две
30:38
баги. Две баги потом требуют, например, вашего участия, либо, например, блокируют тестировщика. И создаётся
30:44
такой хаос. То есть вроде как вроде как вы управляли, вроде как вы все эти тикеты туда-сюда возили, но
30:50
по-настоящему получается какие-то постоянно какие-то проблемы, да, то есть которые могут и на внешние команды влиять и так далее. То есть вот у нас
30:55
есть на работе вот такая команда идеальный пример. То есть вроде как что-то делать, вроде есть жиро тикеты,
31:01
вроде они двигаются, но то людей нету на работе, то они поздно отвечают, то они делают не так, то они делают какими-то
31:08
косяками, то появляются какие-то баги, то они им постоянно нужна какая-то лишняя экспертиза, то есть они сами не разбираются. То есть иллюзия, ну вот эти
31:14
вот все эти процессы — это, по сути, большая иллюзия. То есть нужно мерить как бы другими метриками, которые не
31:20
попадают вот в рамки вот этих вот задачек. Так, ну то, что скрамастирает
31:26
Я думаю, вы поняли. Я думаю, что многие, кто меня смотрят, они знают. Значит, ну и то, что я уже говорил, что рассадник
31:33
вот этого всего шлака — это корпоративную структуру, где очень много сотрудников, да? То есть я прямо видел
31:39
не раз там прямо ищу там ищем скрамастера на большую зарплату типа. То есть думая, что там что-то принципиально
31:44
поменя, да, достаточно сделать один одну встречу, значит, ну с более опытным э
31:50
там, ну специалистом, да, там я вообще, честно говоря, я так к этому скрити критически отношусь, но тем не менее,
31:56
да, то есть и не нанимаете с Кромастера на постоянку. Один раз приходит, один раз обучат и всё, значит.
32:03
Ну и вообще как бы среди плюсов, значит, есть такие плюсы, как
32:10
а всё-таки с помощью джира кое-что можно отследить. То есть у неё есть прямо там возможность трекать и там можно
32:16
посмотреть, если кто-то делал с эту задачу, ну прямо очень долго. То есть такие грубые нарушения можно отследить, можно посмотреть, что она,
32:22
например, была в состоянии, например, в состоянии там в прогресс, да, как разработчик разрабатывает, а, например,
32:29
там, ну, не знаю, 3 дня, а потом тестировщик занимается там, а, там ей, например, там 7 дней. И вы потом можете
32:36
посмотреть, ну, код, и вы увидите, что в коде там ничего не было. Там была какая-то стандартная задача, там не было какой-то, э, сложной, большой
32:43
необходимости что-то писать, какие-то какие-то особые решения. И вы можете понять, о’кей, что тестировщик просто,
32:48
ну, он не занимался чем, чего должен был заниматься, да? Есть понятие, например, такие штуки, как Definition of Dan, тоже
32:54
хорошая вещь. Это по сути, ну, definition of — это как бы это требования, которые определяют, что
33:00
задача выполнена. То есть тоже как бы когда вот они, ну, ну вот эта вот терминология, когда она появляется, как
33:06
бы она является плюсом, что, ну, есть некая дисциплина, что если какую-то задачу ставят, то должно быть чётко прописано, что хотят от задачи, да, то
33:13
есть когда она будет считаться законченной. Это, конечно, лень писать периодически, но тем не менее потом помогают. И потом, если что, программист
33:19
может ей защититься. То есть, если потом он задачу закончил, ему говорит: «О, мы там ещё забыли какую-то штуку». Он говорит: «Ну, в definition of не было».
33:26
Да, где вот эти acceptance critтеia прописаны? То есть, ну, это критерия как бы, ну, одобрения задачи, да, одобрения
33:33
выполнения задачи. То есть, если там не было, там написали, там написали сделать рест, чтобы он подключил туда-сюда там и, например, там, ну, какую-то
33:39
функциональность сделал. Ты там это всё сделал, сдаёшь работу и там тестировщики начинают бухтеть там, о, ты забыл то-то.
33:44
И ты ему носом тыкаешь сюда, он говорит: «Ну ладно, да, то есть претензий никак, ко мне нет претензий». А, ну и,
33:50
например, из плюсов, наверное, один из самых больших плюсов, это то, что в нормальных, а, компаниях, где всё-таки
33:57
следует основным правилам, нельзя менять посередине, а, работу программиста, то есть нельзя его прерывать. То есть если
34:04
он что-то делает, нельзя взять ему, сказать, что мы передумали, меняем задачи, он скажет, он сошлётся на
34:09
правила и как бы и он будет более-менее как бы защищён. Ладно, думаю, на этом всё, ребят. Всё, всем пока. Счасть,
34:15
здоровья.

Поделиться: