Comments 55
Единственное, что вызвало вопросы, так это звездочки: что там, за ними, за непривычная комбинация?..
«50 лайков и 20 жду проду»? «Я не такая, я на рупь дороже»? «Поуговаривайте меня»? «Вы за мной ещё бегать будете, быдло сраное»?
нет не интересно, интересно было лет 7 назад когда волна поднялась, а сейчас так, сентиментальный фельетон в стиле СССРовского "фитиля"=)
но написано красиво, да
Честно говоря не очень понятно почему Иван подумал, что надо попробовать.
Если вам интересно, чем закончилась эта история – расскажу.
понятно как это все закончилось, но интересно как это будет описано :)
Неопытный цыган попался. Матёрый бы так все обставил, что и руководитель группы и руководитель проектов оба почувствовали бы себя сначала уверенными в своей правоте, а потом все меньше и меньше уверенными, а в итоге он бы им объяснил, что они кругом неправы и им осталось бы только покаяться и во всем согласиться.
Ну оно и понятно - что за скрам мастер такой, который канбан доску называет скрам доской? Малограмный неуч, а не скрам мастер.
Тогда Виктор не прав в том, что данную методологию можно применить к чему угодно.
Есть очень много бизнес процессов в которых формализм и соблюдение нормативки важнее продукта. И зачастую это не глупость и не костность, а осознанная необходимость.
Есть очень много бизнес процессов в которых формализм и соблюдение нормативки важнее продуктану так это получается, что люди знают «как». А гибкие методологии — когда не знают. Ну вон отличный пример — полет первого человека в космос, никто не знал как, по частям решали проблему. Ракету потестили, потом на животных… ну вот как-то и достигли результата, в итоге.
работающий продукт важнее исчерпывающей документации;
Попробуйте сказать это аудиторам.
Так и представляется сценка где-нибудь в арбитражном суде:
Судья (С): Почему не выполнили условий контракта?
Ну если хотите работать по контракту по скраму — очевидно это надо прописывать в контракте. Не «будет сделано к февралю», а как-то иначе под скрам формулировать.
Тогда не только бухгалтеры и юристы, а весь реально работающий люд: строители, водители, логисты, грузчики, отдел кадров… иначе подите объясните, что «люди и взаимодействие важнее» получения зарплаты, а «сотрудничество с заказчиком важнее» простаивающей линии с убытком N мил руб / час.
А деньги когда — утром или вечером?
Если вам интересно, чем закончилась эта история – расскажу.
Да все понятно, чем это закончится. Шустрый парниша будет с полгода выносить всем окружающим мозги своей аджайл религией, команда будет уныло исполнять весь предписанный набор ритуалов, с периодически подгорающей задницей от срыва дедлайнов и необходимости выходить работать в выходные и после работы. Понемногу все будут выгорать и сваливать. В итоге и "парниша" помашет всем ручкой и уйдет в закат, рассказывать очередному работодателю о крутизне "правильного аджайла". Проект громко провалится, но с клиентом кое-как удастся договориться, наберут свежее мясо новых разработчиков, и с трудом его закончат.
Ну или другой, лайтовый, вариант, вся эта фигня просто выродится в утренние "нытинги", отнимающие время, но ни на что не влияющие, но зато дающие руководству возможность гордо всем заявлять что "у нас внедрен аджайл". Вася (или кто там, Витя) будет напряженно делать вид что от его "работы" есть хоть какая-то польза, коллеги будут напряженно делать вид будто в это верят.
Если вам интересно, чем закончилась эта история – расскажу.
Как и другие тут, не понимаю, зачем тут такая наживка (не ютуб чай, резать видео да лайки-комментарии-подписки-колокольчики
Господи! Кто такой срам-мастер и зачем он вообще нужен??? Очередные балаболы и аниматоры)))
Доцент, конечно, тупой, в смысле, выдуманный вами Виктор, но кое что вы углядели правильно — скрам — это не про то, как взять команду, обвешанную тимлидами, продактами и проджектами и перевести её на скрам. Так и будет — лиды-продакты-проджекты будут лишними и лишёнными управления, при этом останутся ответственными за провалы. Тут телега впереди лошади.
Эджайл — перестройка ВСЕГО процесса, включая часть процессов заказчика. Тогда, возможно, будет работать, и то, скорее всего, не всегда. Причём если вся эта заваруха идёт не от команды, а навязывается руководством сверху, то таки может заработать, но производительность, скорее всего, упадёт и изрядно. Возможно, через какое-то время вернётся и даже обгонит (и, даже, в 4 раза), но лично я до такой степени совершенства команды ни разу не дорабатывал :), увольнялся раньше, хотя и не по причине скрама (как раз этот полноценный вариант был довольно прикольным и вполне для меня терпимым — всякие другие, когда и "скрам" и ПМы — это вообще зашквар и просто перенос обязанностей с ПМов и лидов на команду).
В общем, если хотите оставить и хитро прищурившегося продакт/проджекта и нанять какого-то скраммастера получится полная хрень.
Ну и с целеполаганием проблемы — а давайте наймём модного чувака и он расскажет нам зачем мы его наняли — феерично!
- А вы… - Виктор на секунду задумался. – Ах да, руководитель проекта. В терминах скрама вы – product owner. Владелец продукта, по-русски говоря.
но ведь project manager <> product manager <> product owner
это ж три разные сущности. даже в скраме ;)
Судя по комментариям - продолжать, скорее, не стоит. Судя по отзывам в соц.сетях - стоит. Последней каплей стал парень в курилке, который подошёл и сказал, что нужно продолжение.
продолжение нужно однозначно!
Так-то все правильно, но вот скрам как раз можно применять «частично», что собственно Иван и делал «по-колхозному». А почему нет? Взяли полезное, выбросили бесполезное. Такое сплошь и рядом. И пофигу, что «Это уже не скрам». А для чего же он нужен?! Чтобы бизнесу стало легче. А если в команде сплошь аутисты? Или никак команде не перестроить свое мышление уже полгода? Тогда уж лучше и не трогать, а работать по-старому. Иначе бизнесу станет тяжелее.
Скрам — штука хорошая, но если брать его и применять бездумно, то ничего хорошего не получится.
Скрам приживается хорошо в той культуре, где есть доверие команде
Тут это вопрос остро встал, был получен ответ, и стало ясно, что тут делать нечего. Если люди не понимают, что такое командная ответственность, пока будут говорить что у любой проблемы есть фамилия и имя, скрам даже близко не подойдет
Остается лишь сказать им - работайте, не поднимая головы. Работайте сверхурочно, по выходным, с дикими напрягами, с выгораниями. И все это только из-за того, что не согласны доверять команде.
На практике, команда всегда сильнее индивидуальных мастеров.
Сейчас век командой работы. Не важно какие у тебя звезды собрались, если они не "стакаются", не в симбиозе - ничего не получится. Самая средняя команда с нормальным внутренним укладом уделает по производительности и эффективности
Да, все верно говорите. Вся проблема в том, что не стоит натягивать сову на глобус.
Это из скрам гайда - "команда состоит из профессионалов". В этом случае, когда в команде одни студенты, не стоит даже заикаться про скрам - ничего не выйдет.
Простите, но это Ваши выводы. я таких выводов не делал
Если пройтись по пунктам:
а) Да, тяжело сделать полноценный скрам в команде дворников. И не надо этого делать
б) Наличие тимлидов уже противоречит чистому скраму. В скраме есть команда, и в команде есть только разработчики, никаких иерархий. в скриншоте выше сказано, что такое команда в определении скрама. Ещё один скрин. Это все из скрам гайда, там всего 13-17 страниц.
Если кроме тимлидов никто не способен к самоорганизации - лучше признаться, что у Вас не скрам и полностью от него отказаться. Это будет честный поступок. Не можете - не делайте, все просто. Не нужно винить систему, не следуя его инструкциям. Вот если я возьму нет тот фреймворк/БД/ЯП/... я потом буду ругаться на него, то скорее всего проблема изначально в выборе инструмента
Образно, если взял SQLite для хранения 1млрд данных, то скорее всего я косякнул. И это нормально, просто нужно понимать, что выбираете и зачем.
в) тут ничего не понял. Опять какие-то кнуты, контроль, которых нет в чистом скраме
ЗЫ: я PSM I, https://www.scrum.org/certificates/405142, почта ilnuribat<собачка>gmail.com
Практически всегда горстка профессионалов разбавляет толпу обычных работяг.
Тут важно дать всем одинаковые права/обязанности. Да, будут спецы очень крутые, будут спецы так себе. При этом скрам ориентирован на те сферы, где очень много хаоса, например стартапы. Там нет понимания что делать через месяц, есть примерные планы, но все это может полностью поменяться, перестроиться, и пойти в другом направлении. И именно в таком ключе, когда нужно принимать решение относительно некоторого будущего(не в целом планов, а чего-то маленького), становится не сильно важно, какой ты крутой спец в технологиях. Тут и самый простой мидл может оказаться точнее матерых сеньоров. И именно в таких случаях надо слушать всю команду, о чем думают все.
Я сам работал в чистом скрам команде, почти год. начинал с джуна, и уже через месяц участвовал в принятии решений, понимал что в целом я с сеньорами на одном уровне. Да, задачи я решал в порядок медленнее/хуже, но решение принимали мы все вместе - как делать то или иное.
В другом месте работы, за меня решали абсолютно все, чуть ли не как столбец назвать в бд, как назвать переменные, какие файлы создать. Настолько сильная детализация задачи убивает любой вкус решения, становится неприятно даже делать задачу. Само собой как-то охота тянуть, потому что вы уже все за меня порешали, я стал тупым исполнителем. Не давали право выбора, право решать хоть самой мелкой задачи самостоятельно.
Вторая часть - про руководителей. Видел пример скрам команды в высшем звене. Не был внутри, не могу даже предположить как там может это сработать. Все таки, я больше программист, не могу думать за руководство.
Скрам в первую очередь все же ориентирован на команды исполнителей, самодостаточную, самостоятельную, ни от кого других не зависящей. Получается, если собрать руководителей, то они ничего самостоятельно не смогут решать, могут только делегировать, поэтому скорее всего полноценной скрам команды не получится, ИМХО.
Скрам в первую очередь все же ориентирован на команды исполнителей, самодостаточную, самостоятельную, ни от кого других не зависящей.
Программисты, можно сказать, руководители компиляторов. Почему нельзя сделать скрам команду из руководителей и, по аналогии, софтом будут рядовые исполнители.
Условно, если не хочешь или не можешь быть самоорганизованным — будь ресурсом.
PSM I
У меня вопрос, как к человеку в теме: есть ли во аджайле какой-то подход к элиминации корпоративных паразитов. Допустим есть бирюзовая самоуправляемая компания и в ней одна из команд решила (явно или неявно): "Давайте, будем работать по часу в неделю". Далее она делает оценки исходя из этого и выполняет их. Какие есть подходы по воздействию на нее? Желательно со ссылками на авторитеты.
Ссылок на авторитетов не смогу дать, не видел таких материалов.
В скрам гайде не нашел момента, если команда целиком саботирует процесс.
На практике у меня была одна команда, которая решила саботировать - они даже играл CS во время работы все вместе. Через несколько месяцев всю команду уволили, хотя там были пару очень крутых спецов.
В целом, надо работать с командой целиком. Если вся команда саботирует, значит воздействовать на всю команду целиком. Если кто-то конкретный саботирует, то скрам мастер должен это выявить и показать команде, что внутри есть паразит. Если коллег это устраивает, то тут ничего не поделать. Если совсем никак не реагируют на проблемы, я бы (мое личное мнение) уволил всю команду.
На практике у меня была одна команда, которая решила саботировать — они даже играл CS во время работы все вместе. Через несколько месяцев всю команду уволили, хотя там были пару очень крутых спецов.
Интересно. Были ли какие-то попытки исправить ситуацию. Может уволить каких-нибудь членов команды, чтобы привести остальных в чувство?
Работайте сверхурочно, по выходным, с дикими напрягами, с выгораниями. И все это только из-за того, что не согласны доверять команде.
Как-то везде где начинали внедрять "скрам" все описанное вами вместе с ним и появлялось. Сверхурочная работа, дикие напряги, рабочие выходные, выгорания..
Да, бывает такое. Это значит что компания ещё не готова к серьезным изменениям.
Я обычно просто спрашиваю - что будете делать, если узнаете что ваш разработчик не имеет задач. Если отвечают, что срочно дают новые задачи, значит в этой компании всегда есть и будут сверхурочные
По сути, авралы возникают не потому что программисты балбесы, а потому что так устроено в этой компании, что дают задачи всегда выше возможностей
Скрам же говорит следующее: нужно организовать такой темп работы, чтобы она продолжалось бесконечно. И любые авралы сводят на нет самый просто темп.
Это если вы бежите марафон, а вам говорят: "следующий километр нужно бежать как спринт". Ок, вы ускорились, пробежали как спринт, но марафон вы теперь вряд ли нормально завершите, если вообще сможете завершить. По сути, это и есть выгорания, напряги и так далее
И скрам лишь выявил проблемы, показал что это не нормально. Нужно начать работать с культурой компании, объяснять руководству, что есть понятие темпа, что программисты люди трудолюбивые, их не надо кнутом гнать, они и так готовы днем и ночью работать, если хотя бы не мешать им заниматься любимой работой.
В скраме, если разработчик не имеет задач в спринте, он не берет новую задачу из следующего спринта, он берется за устранение технического долга. Поэтому в скраме очень важно чтобы продукт был рабочим, чтобы не было багов. Не так важно сколько новых фич вы выпускаете, если у вас половина сайта в багах. Лучше доведите до ума то что есть, и только потом делайте новые. И чтобы каждая новая фича не убивала существующие. Отсюда вытекает, что команда должна в быстро проверять, не сломали ли они что-то из существующего. Для этого они пишут автотесты.
Итого: автотесты в скраме пишут разработчики для себя, чтобы видеть, не сломали ли они что-то из существующего.
не в скраме чаще всего(не всегда) автотесты пишут потому что: тим лид сказал / по шапке дадут / так принято / это модно. Но не как помощь для самого программиста
В скраме больше осознанности что ли
Эхх.. поработать бы так в реальности. Я как-бы работал по скраму на нескольких проектах, но все это было именно "как-бы". Было два основных варианта: либо каргокульт, с формальным выполнением всех ритуалов, но по факту это все можно было назвать чем угодно но не аджайлом, либо какая-то абсурдная потогонка, в которой на первом месте стоял не продукт и пользователь, а своевременный запил фич к демо, на которой как раз и делали все эти попытки бежать марафон со спринтерской скоростью, после чего удивлялись отчего это команда так быстро выгорела и вообще ничерта не хочет делать.
Сейчас вот работаю вообще не понятно как, и водопадом это не назвать, и на Аджайл не особо похоже. Просто получаешь ТЗ, говоришь за какое примерно время его запилишь, и делаешь. Если сроки факапятся, то обычно никаких репрессий за этим не следует, просто сроки сдвигаются. В принципе так комфортно работается, но это явно не везде так получится работать, не везде менеджмент спокойно относится к неопределенности в сроках выполнения задач, хотя по факту она есть всегда.
Респект автору, интересно написано! Я конечно догадываюсь что это закончилось тем чем скрам всегда и заканчивается) но продолжения жду с нетерпением!
Жёлтый Скрам. Собеседование