![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stanikaИ тут у меня когнитивный диссонанс...
Я уже больше полугода работаю с командой, которая занимается обработкой данных (привет Хетти). Сначала я совсем ничего не понимала, потом разобралась, что и зачем мы делаем и на этом я застряла. На сессиях с командой я не могу сказать "эй, вы закопались, давайте вернемся к основному обсуждению". Я могу только спросить "Вы все еще обсуждаете то, что нужно, или уже закопались?". Впрочем и мой вопрос тоже неплохо работает. Но все-таки вроде хотелось что-то понять. Итак, я озвучила это желание (разобраться в содержании работы) пару месяцев назад на ретроспективе. Добрые коллеги мне на днях об этом напомнили, и хотя как раз сейчас я беру вторую команду, я решила, что надо поддержать коллег и выказать интерес к тому, что они делают.
И вот Телмо открыл для меня одну базу данных. Сказав, что если даже я там все сломаю, это не страшно. Она ... ну типа пробная, для хакатона была сделана. Помог мне начать действовать и выдал ссылку на то, как писать запросы на SQL.
Ну и говорит - этого тебе хватит на пару часов поиграться, а завтра еще чем-нибудь займемся.
И вот тут-то я поняла, что я совсем не человек данных. Ну хорошо, я вижу, что люди используют столько-то электричества и столько-то газа. И что? Ну я могу посчитать сколько все они используют в среднем. Или какое максимальное значение. Ну я могу это сделать ради того, чтобы выучить эти команды в языке, но мне-то что с того? Это ведь прямо совсем-совсем другой менталитет. Гм... Ну пойду, напишу пару запросов что ли ...
Я уже больше полугода работаю с командой, которая занимается обработкой данных (привет Хетти). Сначала я совсем ничего не понимала, потом разобралась, что и зачем мы делаем и на этом я застряла. На сессиях с командой я не могу сказать "эй, вы закопались, давайте вернемся к основному обсуждению". Я могу только спросить "Вы все еще обсуждаете то, что нужно, или уже закопались?". Впрочем и мой вопрос тоже неплохо работает. Но все-таки вроде хотелось что-то понять. Итак, я озвучила это желание (разобраться в содержании работы) пару месяцев назад на ретроспективе. Добрые коллеги мне на днях об этом напомнили, и хотя как раз сейчас я беру вторую команду, я решила, что надо поддержать коллег и выказать интерес к тому, что они делают.
И вот Телмо открыл для меня одну базу данных. Сказав, что если даже я там все сломаю, это не страшно. Она ... ну типа пробная, для хакатона была сделана. Помог мне начать действовать и выдал ссылку на то, как писать запросы на SQL.
Ну и говорит - этого тебе хватит на пару часов поиграться, а завтра еще чем-нибудь займемся.
И вот тут-то я поняла, что я совсем не человек данных. Ну хорошо, я вижу, что люди используют столько-то электричества и столько-то газа. И что? Ну я могу посчитать сколько все они используют в среднем. Или какое максимальное значение. Ну я могу это сделать ради того, чтобы выучить эти команды в языке, но мне-то что с того? Это ведь прямо совсем-совсем другой менталитет. Гм... Ну пойду, напишу пару запросов что ли ...
no subject
Date: 2017-06-20 08:54 am (UTC)Темы для разговора например такие (они же вопросы для обсуждения)
1. Как вы думаете, какой мастер по большому счету лучше - который сечёт фишку в программировании или нет?
2. Сколько лет надо проработать с программистами [в индустрии] чтобы досконально представлять себе что им помогает и что мешает?
3. Сколько scrum-мастеров должен в жизни повидать программист, чтобы составить представление о scrum?
4. Что важнее - личные качества "scrum-мастера" или методология, которой он придерживается при работе с командой?
Ваши ответы уже продвинут дискуссию вперед...
Как-то так.
no subject
Date: 2017-06-20 09:27 am (UTC)творческой разработки продуктов с максимально возможной ценностью и решения нетривиальных задач в процессе работы (официальный перевод scrum guide)
Скрам - это правила игры. Как правила игры в шахматы - выучить правила довольно легко, научить играть - очень трудно.
1. По большому счету лучше скрам мастер, который не разбирается в программировании. Такой скрам мастер дает возможность команде расти, принимать самостоятельные решения, учиться на своих ошибках и брать на себя ответственность.
2. Невозможно "досконально" представлять себе, что помогает и что мешает. Разработка программного обеспечения лежит в запутанном домене (по модели Киневин Дейва Сноудена), здесь очень велика непредсказуемость и не существует "лучших практик".
3. Чтобы составить представление о скраме, программисту неплохо бы работать в здоровой среде, где есть возможность делать настоящий скрам, а не фейк. Сколько скрам мастеров для этого нужно - больше похоже на шутку, чем на серьезный вопрос.
4. Если скрам мастер не придерживается "правил игры" - то он больше не скрам мастер. Если у скрам мастера нет возможности придерживаться правил игры - значит в компании реализуют water-scrum-fall и скрам мастеру пора заниматься коучингом на уровне компании.
Если в компании наличествует крепкая аджайл-культура, а команды делают хороший скрам, то плохой скрам мастер можно это попытаться испортить, но скорее всего его скоро уволят (был опыт такой у друга). В целом личные качества для скрам мастера играют немного больше роли, чем для программиста.
Достаточно ли этого для продолжения беседы? =)
А какой у вас опыт со скрамом?
no subject
Date: 2017-06-20 10:08 am (UTC)По первому вопросу - позиция ясна.
По второму - т.е. получается вы согласны, что нет особой ясности, помогает ли scrum программистам?
По третьему - мы работаем в реальном мире, т.е. если контора определяет свою методологию как scrum - это оно и есть. Иначе всегда можно применить уловку "No true Scotsman". А насчет количества - почему шутка? Просто статистика. Положим - поработал с одним мастером - плохо, с другим - еще хуже, с третим - вообще атас. Сколько нужно ждать хорошего?
По четвертому - в реальном опять же мире, команды далеко не идеальны (ибо тупо хороших программистов на всех не хватает), не идеальны и владельцы компаний, да и мастеров наверное тоже не пруд-пруди. Я видел ситуации, когда годами не увольнялись плохие менеджеры, программисты, HR и кто угодно еще. Это уж как повезет.
Но суть вопроса была в другом - если к примеру, завтра, тот же самый scrum-мастер перекуётся на новую методологию и начнет работать с теми же командами - заметят ли они разницу?
P.S. Опыта со scrum у меня нету, ибо основные его принципы во Франции по большому счету не реализуемы :)
no subject
Date: 2017-06-20 10:18 am (UTC)Еще раз про методологию. Методология - это описание действий в зависимости от предыдущих действий. Если вы сделали это - ваш следующий шаг такой-то. Если пошло так- сделайте эдак, если пошло иначе- поступите таким образом.
Скрам - это набор минимальных правил, которые помогают людям решить, а как же им стоит действовать в разных ситуациях. Скрам не дает ответов и не решает проблемы. Скрам - как солнце в комнате. Вы убрались, пока были облака, и вам кажется, что в комнате чисто. Но вышло солнце и вдруг вы увидели, сколько же вокруг пыли. Солнце - не будет за вас убираться. Скрам только покажет вам, какие проблемы есть у вас в организации. А вам придется эти проблемы решать. Скрам конечно предлагает пару инструментов, но если вы будете метлой забивать гвозди, то процесс затянется. А сделать из веника пылесос смогут только сами команды, никак иначе. Пылесосы в мире скрама не продаются, их можно только создавать =)
Я не думаю, что во Франции совершенно невозможно работать по скраму, хотя я знаю, что применять скрам в Голландии гораздо проще, чем в России.
Если скрам мастер завтра начнет проповедовать другие правила - да, команда должна заметить, что они играют по другим правилам. Если команда не заметила - значит это был зомби-скрам. Потому что команда полностью знает правила скрама и поддерживает их. Потому что команда знает, зачем им это нужно. Иногда, когда я пытаюсь что-то изменить, команда мне говорит "а-та-та", нельзя сливать! Потому что моя команда знает, с чего вдруг вообще мы делаем скрам, чем он нам помогает. А другая моя команда делает канбан и четко знает, почему это не скрам.
Скрам программистам несомненно помогает. Но помогаю ли программистам конкретно я? Только если я каждый день с ними общаюсь и спрашиваю, чем помочь. Если я прихожу к новой команде с опытом моей прошлой команды и начинаю "помогать" - это неправильно. Просто нет рецептов. Есть "возникающие практики". Сделали и посмотрели - помогает или нет? Будем повторять или что-то другое попробуем?
Если команде трижды достались плохие скрам мастеры - это жесть =(((
Если плохие менеджеры не увольняются - надо увольняться самому и идти работать в нормальную компанию =)
no subject
Date: 2017-06-20 11:52 am (UTC)Зададимся вопросом - может ли судья испортить игру? Да, может, если не будет вовремя свистеть и наоборот, будет свистеть не вовремя. Может ли он улучшить игру команды? Определенно нет. Это может сделать тренер, капитан, сами игроки. Но не судья.
Как писал один автор: "Главным достоинством scrum'а в сравнении с другими методиками является малый оверхед. Команды, которые используют скрам, всего в 1.5-2 раза менее эффективны, чем команды, которые не используют ничего. Это выдающийся результат, потому что другие методологии замедляют команду ещё больше"
И в этом смысле, кстати, мне лично scrum нравится - своим минимализмом.
Хотя, мои знакомые знакомые со сравнимым опытом в IT прочувствовавшие scrum на своей шкуре скорее колеблются между безразличием и острым неприятием.
Тем не менее, говоря что есть правильный scrum, а есть имитация, вы, IMHO, заметаете проблему под ковер и уходите от возможной объективной оценки. Ведь всегда остается возможность сказать - scrum не виноват! Это был плохой, негодный scrum! Но кто и как оценит - где же истинный шотландец?
Мысль о том, что программисты должны знать, что такое scrum и его правила конечно печалит. У них и так есть чем занять голову...
Касаемо применимости во Франции, возьмем даже просто ежедневное совещание (Daily Scrum meeting):
:)
no subject
Date: 2017-06-20 01:46 pm (UTC)Есть несколько проблем в использовании скрама. Во-первых, скрам есть смысл использовать как часть аджайл подхода. А использовать аджайл стоит только в запутанном домене. Если домен сложный - не надо использовать аджайл, это только мешает! А люди считают, что он silver bullet, и используют его где ни попадя ((
Кроме того, даже в аджайл организации совершенно необязательно использовать скрам. Есть канбан, если вам нужен какой-нибудь набор правил. А можно и просто руководствоваться 4мя аджайл принципами без всяких наборов правил.
Программисты не должны знать, что такое скрам и его правила. Это просто common sense. Сначала мы планируем, а потом спрашиваем клиента, понравилось ли ему то, что мы сделали. Потом мы обсуждаем в команде, как нам работалось вместе, и можно ли это улучшить. Все.
По поводу утренней летучки. Если команде не нужна эта сессия для синхронизации, значит это либо очень зрелая команда, либо что-то идет не так. Конечно скрам мастер поддерживает добрый почин программистов, но если я решу, что мы больше не будем делать эти утренние сессии, то команда все равно будет их проводить. Потому что это помогает лучше работать.
А насчет "свиней" - это какие-то детали. На наших летучках только представители команды, и только они говорят.
no subject
Date: 2017-06-20 03:10 pm (UTC)