Data ...

[stanika]

И тут у меня когнитивный диссонанс...

Я уже больше полугода работаю с командой, которая занимается обработкой данных (привет Хетти). Сначала я совсем ничего не понимала, потом разобралась, что и зачем мы делаем и на этом я застряла. На сессиях с командой я не могу сказать "эй, вы закопались, давайте вернемся к основному обсуждению". Я могу только спросить "Вы все еще обсуждаете то, что нужно, или уже закопались?". Впрочем и мой вопрос тоже неплохо работает. Но все-таки вроде хотелось что-то понять. Итак, я озвучила это желание (разобраться в содержании работы) пару месяцев назад на ретроспективе. Добрые коллеги мне на днях об этом напомнили, и хотя как раз сейчас я беру вторую команду, я решила, что надо поддержать коллег и выказать интерес к тому, что они делают.

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

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

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

Comments

[waggi-tan.livejournal.com]

Ты подожди, это затягивает ;)

[stanika.livejournal.com]

Гм... спасибо за вдохновение =)

[a-jelly.livejournal.com]

А разве есть смысл рулить тем, что не понимаешь детально?

[stanika.livejournal.com]

А я рулю процессом. Процесс - скрам - я понимаю детально. А контентом (содержанием) рулят сами программисты - они его очень даже детально понимают. А приоритетами рулит владелец продукта - и в этом он разбирается

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

[a-jelly.livejournal.com]

Как я понимаю, scrum - это не процесс. Scrum - это методология, набор принципов по которым предлагается выстраивать собственно процесс разработки ПО. Вот когда люди там пишут код или тестируют - это процесс разработки. Но, пытаться применить даже известную тебе досконально методологию к {мало|не}известному процессу - это, IMHO, утопия. Ну, т.е. это может работать постольку-поскольку, на уровне плацебо, но не более того.

И, в принципе, это верно для любой методологии будь то водопад, scrum или что-то еще, мне кажется.

[stanika.livejournal.com]

Не очень понимаю, о чем мы сейчас разговариваем, прости. Я работаю скрам мастером уже больше года и все мои команды очень довольны тем, что я для них делаю. Программисты прямо говорят мне - "я никогда не ожидал, что человек, который ничего не понимает в программировании, может так помогать команде работать лучше". Это не плацебо, это просто абсолютно другой подход.

Скрам - это НЕ методология, однозначно. Что такое скрам можно долго и отдельно разговаривать. Это нужно?

[a-jelly.livejournal.com]

Если scrum - это не методология, то что это?

Темы для разговора например такие (они же вопросы для обсуждения)
1. Как вы думаете, какой мастер по большому счету лучше - который сечёт фишку в программировании или нет?
2. Сколько лет надо проработать с программистами [в индустрии] чтобы досконально представлять себе что им помогает и что мешает?
3. Сколько scrum-мастеров должен в жизни повидать программист, чтобы составить представление о scrum?
4. Что важнее - личные качества "scrum-мастера" или методология, которой он придерживается при работе с командой?

Ваши ответы уже продвинут дискуссию вперед...
Как-то так.

[stanika.livejournal.com]

Скрам (сущ.) – фреймворк, предоставляющий спектр возможностей для продуктивной и 
творческой разработки продуктов с максимально возможной ценностью и решения нетривиальных задач в процессе работы (официальный перевод scrum guide)

Скрам - это правила игры. Как правила игры в шахматы - выучить правила довольно легко, научить играть - очень трудно.

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

2. Невозможно "досконально" представлять себе, что помогает и что мешает. Разработка программного обеспечения лежит в запутанном домене (по модели Киневин Дейва Сноудена), здесь очень велика непредсказуемость и не существует "лучших практик".

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

4. Если скрам мастер не придерживается "правил игры" - то он больше не скрам мастер. Если у скрам мастера нет возможности придерживаться правил игры - значит в компании реализуют water-scrum-fall и скрам мастеру пора заниматься коучингом на уровне компании.
Если в компании наличествует крепкая аджайл-культура, а команды делают хороший скрам, то плохой скрам мастер можно это попытаться испортить, но скорее всего его скоро уволят (был опыт такой у друга). В целом личные качества для скрам мастера играют немного больше роли, чем для программиста.

Достаточно ли этого для продолжения беседы? =)

А какой у вас опыт со скрамом?

[a-jelly.livejournal.com]

Ок, когда вы пишете "Скрам - это правила игры", то переформулируете другими словами "Scrum - [...] набор принципов".
По первому вопросу - позиция ясна.

По второму - т.е. получается вы согласны, что нет особой ясности, помогает ли scrum программистам?

По третьему - мы работаем в реальном мире, т.е. если контора определяет свою методологию как scrum - это оно и есть. Иначе всегда можно применить уловку "No true Scotsman". А насчет количества - почему шутка? Просто статистика. Положим - поработал с одним мастером - плохо, с другим - еще хуже, с третим - вообще атас. Сколько нужно ждать хорошего?

По четвертому - в реальном опять же мире, команды далеко не идеальны (ибо тупо хороших программистов на всех не хватает), не идеальны и владельцы компаний, да и мастеров наверное тоже не пруд-пруди. Я видел ситуации, когда годами не увольнялись плохие менеджеры, программисты, HR и кто угодно еще. Это уж как повезет.

Но суть вопроса была в другом - если к примеру, завтра, тот же самый scrum-мастер перекуётся на новую методологию и начнет работать с теми же командами - заметят ли они разницу?

P.S. Опыта со scrum у меня нету, ибо основные его принципы во Франции по большому счету не реализуемы :)

[stanika.livejournal.com]

Если контора "говорит", что использует скрам, а на самом деле использует "утреннюю летучку" и "планирование", то нет - это не скрам. Скрам - очень сложная штука, она не работает без культурных изменений в команде, а позже и в компании. Это правда. Я согласна с тем, что вокруг дофига "зомби-скрама", и к сожалению, это сильно роняет "авторитет" этого подхода.

Еще раз про методологию. Методология - это описание действий в зависимости от предыдущих действий. Если вы сделали это - ваш следующий шаг такой-то. Если пошло так- сделайте эдак, если пошло иначе- поступите таким образом.

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

Я не думаю, что во Франции совершенно невозможно работать по скраму, хотя я знаю, что применять скрам в Голландии гораздо проще, чем в России.

Если скрам мастер завтра начнет проповедовать другие правила - да, команда должна заметить, что они играют по другим правилам. Если команда не заметила - значит это был зомби-скрам. Потому что команда полностью знает правила скрама и поддерживает их. Потому что команда знает, зачем им это нужно. Иногда, когда я пытаюсь что-то изменить, команда мне говорит "а-та-та", нельзя сливать! Потому что моя команда знает, с чего вдруг вообще мы делаем скрам, чем он нам помогает. А другая моя команда делает канбан и четко знает, почему это не скрам.

Скрам программистам несомненно помогает. Но помогаю ли программистам конкретно я? Только если я каждый день с ними общаюсь и спрашиваю, чем помочь. Если я прихожу к новой команде с опытом моей прошлой команды и начинаю "помогать" - это неправильно. Просто нет рецептов. Есть "возникающие практики". Сделали и посмотрели - помогает или нет? Будем повторять или что-то другое попробуем?

Если команде трижды достались плохие скрам мастеры - это жесть =(((
Если плохие менеджеры не увольняются - надо увольняться самому и идти работать в нормальную компанию =)

[a-jelly.livejournal.com]

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

Зададимся вопросом - может ли судья испортить игру? Да, может, если не будет вовремя свистеть и наоборот, будет свистеть не вовремя. Может ли он улучшить игру команды? Определенно нет. Это может сделать тренер, капитан, сами игроки. Но не судья.

Как писал один автор: "Главным достоинством scrum'а в сравнении с другими методиками является малый оверхед. Команды, которые используют скрам, всего в 1.5-2 раза менее эффективны, чем команды, которые не используют ничего. Это выдающийся результат, потому что другие методологии замедляют команду ещё больше"

И в этом смысле, кстати, мне лично scrum нравится - своим минимализмом.

Хотя, мои знакомые знакомые со сравнимым опытом в IT прочувствовавшие scrum на своей шкуре скорее колеблются между безразличием и острым неприятием.

Тем не менее, говоря что есть правильный scrum, а есть имитация, вы, IMHO, заметаете проблему под ковер и уходите от возможной объективной оценки. Ведь всегда остается возможность сказать - scrum не виноват! Это был плохой, негодный scrum! Но кто и как оценит - где же истинный шотландец?

Мысль о том, что программисты должны знать, что такое scrum и его правила конечно печалит. У них и так есть чем занять голову...

Касаемо применимости во Франции, возьмем даже просто ежедневное совещание (Daily Scrum meeting):

• начинается точно вовремя - нереально!
• все могут наблюдать, но только «свиньи» говорят - нереально! говорить будут все
• длится не более 15 минут - через 15 минут последний участник только-только подойдет с полудопитым кофе

:)

[stanika.livejournal.com]

Про солнце и комнату может и витиевато - но это одна из лучших метафор про скрам.

Есть несколько проблем в использовании скрама. Во-первых, скрам есть смысл использовать как часть аджайл подхода. А использовать аджайл стоит только в запутанном домене. Если домен сложный - не надо использовать аджайл, это только мешает! А люди считают, что он silver bullet, и используют его где ни попадя ((

Кроме того, даже в аджайл организации совершенно необязательно использовать скрам. Есть канбан, если вам нужен какой-нибудь набор правил. А можно и просто руководствоваться 4мя аджайл принципами без всяких наборов правил.

Программисты не должны знать, что такое скрам и его правила. Это просто common sense. Сначала мы планируем, а потом спрашиваем клиента, понравилось ли ему то, что мы сделали. Потом мы обсуждаем в команде, как нам работалось вместе, и можно ли это улучшить. Все.

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

А насчет "свиней" - это какие-то детали. На наших летучках только представители команды, и только они говорят.

[a-jelly.livejournal.com]

Вот интересно, я в жизни ни разу не видел команды программистов которая бы хотела собираться на совещание, тем паче - с утра и ежедневно. Хотя допускаю, что такие существуют...

[pucholik.livejournal.com]

ааа! У тебя есть первичные даннные, с ними же столько всего классного можно сделать! Я бы тут же стала искать зависимости между количеством проживающих и потреблением на одного человека. А еще между протреблением газа и электричества одним домохозяйством. А еще ..., но вообще-то это все праздное любопытство, обычно же данные анализируют под какую-то конкретную задачу, т.е. у заказчика обычно уже есть какой-то вопрос и остается только понять, какие закономерности нужно искать

[stanika.livejournal.com]

Спасибо за идеи! Задачи заказчика меня лично не волнуют, это мои программисты решают задачи, а я просто пытаюсь понять контекст, в котором они работают =)

[mikhailkireev.livejournal.com]

Еще корреляция потребления электричества и газа в зависимости от времени суток и времени года, пиковое время потребления электричесва по дням недели (например, гипотеза, что в выходные оно будет другим чем в будни) и прочее, и прочее. Но это может быть сложно сделать на начальном уровне владения SQL. Для начала можно глянуть, например, как изменялось потребление из года в год.

А еще можно глянуть данные у себя дома (у тебя же стоит ваш термостат вроде?) и сравнить со средними показателями и попытаться вывести теорию почему отличие и т.д. и т.п.
Если найдешь что, что тебе интересно выяснить и залезешь в данные чтобы докопаться и докопаешься, то программисты тебя очень-очень сильно зауважают!

Оффтопик: у тебя случайно нет знакомых, которые скоро из Питера в Голландию едут?

[hettie-lz.livejournal.com]

у меня, естественно, душа болит, когда ... мда....

У Эмблера есть про то, как применять Agile в database development. Если не знать, в чем разница - это прямая дорога к получению неэффективного продукта на выходе.

[stanika.livejournal.com]

Почему-то я не ответила на этот коммент, хотя сохранила его в почте.

А за что душа болит?

Про Эмблера - спасибо, сейчас поищу!

Разница в чем?

Запуталась =)

[hettie-lz.livejournal.com]

SQL - это не язык программирования, он требует другого способа мышления. И когда его пытаются изучать и применять, как язык программирования, можно получить желаемый результат, но не вполне оптимальным способом:), так что БД будет плакать :))

Вы читали мои статьи про ORIM? (на конференциях 2014 и 2016 годов, и всякие более мелкие).

[stanika.livejournal.com]

Я не имею ни малейшего представления, что такое ORIM =) Я думаю, что наши разработчики представляют себе, что такое sql (эээ, я очень на это надеюсь!). А мне пока все равно - язык, не язык, я все равно пока буквально пару команд выучила и первую таблицу сделала. Никаких баз данных я все равно создавать не буду, куда уж мне, мне бы все играть =)

[hettie-lz.livejournal.com]

Дело ж не в создавать :)). Вам ведь надо организовывать работу других, и надо представлять, в чем она заключается. Потому что я язык обманчиво - простой: состоит из всего одного оператора :)

[stanika.livejournal.com]

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

Я ничего не организую и мне совершенно не нужно представлять, чем занимается команда. Я вчера, то есть в субботу, об этом говорила с подругой и мы пришли к такой метафоре - вот идут люди в поход. Я не знаю, куда они идут. Я не знаю, хотят ли они идти пешком или идти на лыжах. Мне не важно, что они взяли с собой. Что я могу сделать -
- спросить, нужно ли им, чтобы я подмела дорожку перед ними, и если нужно - подмести;
- спросить, а вот та штучка, которая упала сзади - это так надо, чтобы упала или стоит поднять?
- спросить, а вы уверены, что у вас с рюкзаке все, что вам нужно?

А главное, что я делаю - помогаю им сотрудничать. Анализировать свои действия. Учиться смотреть друг на друга и ценить это. Помогать или наоборот не трогать товарища, когда не надо. Делиться содержимым рюкзаков. Учиться смотреть вперед - хороша ли дорога, которую они выбрали. Учиться смотреть назад - как прошли предыдущий кусок, что можно улучшить, что надо продолжать делать.

Поэтому для меня sql - абсолютно и только для того, чтобы команда радовалась =) почему-то им приятно, когда они меня чему-то учат, так я не против

[hettie-lz.livejournal.com]

Ладно, пока отложим :))