×

Карьера в IT: роль Scrum Master

Продолжаем серию «Карьера в IT»: новая статья посвящена роли Скрам-мастера — специалиста, который отвечает за соблюдение Скрам-процесса и помогает команде эффективней поставлять продукт и приходить к общему пониманию.

Note: статья написана по рассказам украинских Скрам-мастеров и не совпадает с формальным описанием роли в Scrum Guide (руководство по Скрам от авторов методологии). Это связано с тем, что большинство наших IT-компаний практикуют не чистый Скрам, а используют только элементы фреймворка, адаптируя его под свои потребности.

По данным ДОУ, среднему украинскому Скрам-мастеру 30 лет, он имеет зарплату $1500-3000.

Задачи и обязанности

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

В Скрам-команду, кроме Скрам-мастера, входят владелец продукта и команда разработки (3-9 человек). Владелец продукта отвечает за получение максимальной ценности продукта и управляет списком требований к функциональности продукта (product backlog), отвечает за приоритеты и бюджеты. Команда разработки состоит из специалистов разных профилей — программистов, тестировщиков, архитекторов, аналитиков и др.

Скрам-мастер — это лидер команды, но не руководитель в традиционном понимании этого слова, у него нет формальной власти над командой.

«Это существенное отличие Скрам-мастера от традиционных ролей проектного менеджера или тимлида. Благодаря повышенному уровню самоуправления команда разработчиков в Скрам не нуждается в дополнительных менеджерах. Основная миссия Скрам-мастера — создать условия для зарождения самоуправления в команде, потом не дать ей погаснуть из-за микроменджмента или жесткого директивного способа управления. То есть Скрам-мастер — защитник Скрам-ценностей. Это большая часть его работы». (Алексей Кривицкий)

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

«Я делал ещё огромное множество вещей — устраивал команде и представителям заказчика тренинги и презентации, готовил и обсуждал кучу разных отчётов, планировал вместе с delivery менеджером стаффинг на следующие периоды, помогал с организацией переездов и рассаживал людей, организовывал тимбилдинги, разрешал конфликты, участвовал в найме хороших специалистов и увольнении плохих; помогал, мотивировал, объяснял, показывал, развлекал, заставлял, умолял, кричал и благодарил».

«В Скраме специально убрали роль проектного менеджера и поделили обязанности между владельцем продукта (у которого есть полнота власти и ответственность за ROI проекта) и Скрам-мастером (который отвечает за процессы и людей), а часть и вовсе отдали команде. Таким образом создается баланс, без перекоса в сторону классической модели „Начальник >>> исполнители“. Это позволяет создавать самоорганизованные команды. И только с такими зрелыми командами Скрам действительно начинает работать продуктивно». (Артем Быковец)

Чтобы отслеживать эффективность процесса, Скрам-мастер может использовать определенные метрики, например: quality, cycle time/velocity, number of issues, content of the sprint, team happiness.

Скрам-мастер работает со Скрам-командой, заказчиками, но не является начальником или подчиненным кого-либо из коллег (image by John Yorke)

Из 15 Скрам-мастеров, давших интервью для написания статьи, только четверо занимаются исключительно обязанностями Скрам-мастера, ведя одну или несколько команд. Остальные совмещают эту роль с позицией менеджера проекта, тимлида, QA или бизнес-аналитика.

«Компании утверждают, что работают по Скрам и делают Agile, но зачастую просто формально переназывают проектных менеджеров Скрам-мастерами, не меняя при этом сути. Это печально, но факт (зато зарплата выше). Как утверждает Крег Ларман (автор Large-Scale Scrum) в своих законах неуспешности изменений организаций: «Компании так или иначе оптимизируются, чтобы их статус кво не менялся... Как следствие, любая инициатива по изменению структуры или процесса будет сведена к переопределению новой терминологии, чтобы значить по сути те же старые понятия». (Алексей Кривицкий)

«Я не совмещаю роль Скрам-мастера с другими ролями. Более того, я уверен что полноценно помочь Скрам-команде стать эффективнее может только выделенный Скрам-мастер, который проводит с командой 50% времени или более». (Александр Карицкий)

Однако вопреки канону, многие украинские Скрам-мастеры считают сочетания ролей удачной практикой:

«Сочетание „ПМ + Cкрам-мастер“ я считаю удачным, ведь именно ПМ работает с планированием проекта, рисками, кризисами, приоритетами от клиентов и может внедрять новые процессы, расширять команду и всячески ее мотивировать. Работу ПМ-а можно описать как человек-план, а работу Скрам мастера — человек-процесс».

«Мне кажется, нецелесообразно тратить ресурсы девелопера на дополнительные активности. Лучше всего когда роль Скрам-мастера берет инженер по качеству или бизнес-аналитик. Не могу сказать, что совмещать легко, но как QA я в курсе всего процесса разработки».

Типичный рабочий день Скрам-мастера включает в себя:
— Скрам-митинги (ежедневный митинг продолжительностью до 15 минут, а также в зависимости от фазы спринта может быть запланирована одна из более длительных встреч — планирование спринта, обзор спринта или ретроспектива спринта).
— Решение приоритетных текущих вопросов (например, собрать, проанализировать, распространить информацию, запланировать и подготовить митинги, составить и обсудить дальнейшие планы).
— Работа с командой, встречи 1-на-1.

«С утра проводим стендапы с каждой командой, дальше встречи — с владельцем продукта для уточнения спецификаций и планов, с командой для планирования. Дальше зарываюсь в JIRA и готовлю отчеты, смотрю метрики, собираю следующие спринты для планирования, читаю новые спецификации. Если сегодня день демо и ретро — фасилитирую одно общее демо и ретроспективу для каждой команды. Дальше собираю обратную связь и структурирую информацию».

«Каждое утро смотрю на командную доску в JIRA — какие задачи были закрыты, какие попали в тестирование, к каким только приступили к разработке — обновляю графические показатели успеваемости команды по поставке обещанного инкремента в спринте и инкремента по продукту в целом. Провожу ежедневную встречу, на которой составляем план работ на ближайший день и сверяем, насколько наша стратегия по разработке фичи оптимальна. Далее — встречи с владельцем продукта, заказчиками, руководством, другими менеджерами или Скрам-мастерами. Затем решение командных вопросов и взаимодействие с другими командами по составлению графика выполнения смежных или совместных работ — приблизительно так проходит каждый день».

Активности full-time Скрам-мастера — сводка за 2 недели работы (source)

«Самое главное в течение дня — быстрая и эффективная реакция на возникающие проблемы. Зачастую приходится откладывать в сторону рассуждения о том, что тут собрались взрослые люди, и что они смогут решить простые проблемы сами. Надо активно вмешиваться везде, где есть подозрение, что кто-то что-то не так понял и делает что-то не то. Например, разработчик предположил, что владелец продукта имел в виду одно и поленился уточнить. Сразу надо вмешаться и простимулировать разработчика уточнить требование сейчас, а не ждать 3 дня, делая никому не нужную вещь. Или если у разработчика исчез доступ к внутренней библиотеке, и он не знает как быть — надо помочь решить такой вопрос как можно скорее, даже если это требует просто хождения по офису с вопросом кто знает, как это чиниться. Или видишь назревающий конфликт между двумя сотрудниками — сразу приступить к его решению, не дожидаясь, пока они начнут делать друг другу гадости и тормозить работу. Я здесь утрирую, чтобы показать, что задачи в течение рабочего дня могут быть совершенно разные и непредсказуемые».

Преимущества и недостатки

Роль Скрам-мастера больше всего подходит специалистам, которым нравится работать с людьми и процессами:

«Я по натуре очень организатор и очень „обеспечиватель“, именно этим и занимается Скрам-мастер — коуч, наставник, учитель. Так как прямого влияния на команду у него нет (вспомните servant leadership), но команду можно вырастить и замотивировать, Скрам-мастеру нужно быть хорошим переговорщиком. Это невероятно зажигает».

«Люблю улучшать то, что нужно и можно улучшить. Люблю организовывать людей и вместе с ними достигать поставленных целей. Кроме того, люблю логичные, обоснованные, структурированные, но не избыточные подходы. Скрам как раз такой — есть довольно небольшой набор более чем логичных правил и процедур. Если их соблюдать и руководствоваться хоть долей здравого смысла в остальном, можно с высокой долей вероятности получать хорошие результаты».

«Нравится экспериментировать и постоянно улучшать качество создаваемой фичи через поиск и реализацию вариантов улучшения процесса разработки и поставки инкремента пользователю».

«Мне нравится разработка в стиле agile — быстрая, прозрачная, эффективная. И мне нравится организовывать команды работать таким образом. Здесь чувствуется жизнь и видишь небольшие изменения в продукте и процессе каждый день».

«Часто чувствую себя универсальным солдатом, который должен сделать все возможное и невозможное, чтобы помочь команде достичь целей спринта, целей релиза».

Задача Скрам-мастера — постоянно улучшать процесс, выявляя и устраняя проблемы, мешающие прогрессу работы

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

«Мне в этой роли не хватает непосредственного people-менеджмента. Я работаю с процессами и не работаю с развитием людей по отдельности, не ставлю personal objectives и не провожу для них appraisal. Этим занимается Team Leader на проекте. По этому нужно хорошее взаимодействие с ним для того, чтобы влиять и принимать участие в personal development для каждого члена команды».

«Скрам-мастер помогает команде решить проблемы и получить „медали“, при этом зачастую остается в тени и в силу менталитета отечественных разработчиков не получает даже элементарной благодарности. Если ваше эго велико, то это не ваш путь ;)»

«Скрам стал модным трендом. Многие компании внедряют его, не задав важный вопрос — „А зачем он нам нужен и что это решит?“. Непонимание базовой потребности создает дальнейшую боль для Скрам-мастера, внедряющего скрам в процесс разработки».

Как стать и куда двигаться дальше

Must have теория изложена в Scrum Guide, также можно почитать книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда, одного из основателей Скрама. Также рынок предлагает множество курсов и мастер-классов. Можно получить официальную сертификацию — это поможет систематизировать знания и получить бонус-строчку в резюме.

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

«Навыки Скрам-мастера — понимание гибкой методологии разработки, развитый навык стратегического планирования, неформальное лидерство, прекрасное понимание жизненного цикла разработки продукта, отличные коммуникативные навыки, гибкость в принятии решений, навыки разработки — опционально, навыки тестирования — опционально. Попасть не сложно — главное не просто понимать, а полностью принять и синтезировать принципы гибкой методологии, мира Agile, научиться жить и мыслить ими как своими собственными идеями».

«Скрам-мастер — это специалист гуманистической инженерии, если можно так сказать. Поэтому, кроме понимания процессов разработки и поставки, очень важно начать разбираться в групповой динамике команд, источниках самомотивации людей, конфликтологии — собственно, становиться коучем для всей команды и ее участников. Это означает начинать подниматься на уровень выше — от дедлайнов, майлстоунов, проектных планов и репортов к таким долгосрочным вещам, как построение стабильных высокоэффективных команд и культуры постоянных экспериментов и улучшений». (Алексей Кривицкий)

Позиция скрам-мастера объединяет в себе 8 ролей, каждая из которых имеет свои инструменты воздействия на команду (image by Barry Overeem)

Из специальных знаний — понимать Agile Reporting (backlog tracking, burndown metrics, cycle time, velocity, team capacity), владеть и понимать specification by example, continuous integration, delivery и deployment, user story mapping, разбираться в различных практиках, принятых в индустрии (TDD, BDD, user stories, iterative development, pull approach), чтобы потом это внедрять в командах.

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

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

«Важно понимать истинные бизнес-цели проекта, инженерные практики, архитектуру; уметь слушать людей; чётко понимать границы ответственности между разными участниками процесса; знать, как можно достичь одного и того же разными методами, учитывая ситуацию на проекте; быть лидером; уметь эффективно общаться с заказчиками/командами/менеджментом; грамотно управлять своим вниманием, энергией и временем; понимать и работать с мотивацией команд; постоянно совершенствоваться в Agile методологиях, чтобы вовремя выбирать оптимальный подход».

Возможные карьерные пути Скрам-мастера:
— расти как специалист по гибким методологиям — стать Скрам-тренером (обучать других Скрам-мастеров, проводить треннинги);
— освоить другие Agile-фреймоврки и стать Agile-коучем — внедрять методологию на уровне программы или всей организации, тем самым трансформируя компанию на основе Agile-мышления;
— попробовать себя в роли владельца продукта;
— освоить специальность менеджера проектов, delivery менеджера или бизнес-аналитика.

Карьерный рост Скрам-мастера в рамках Agile (image by Paul Heidema)

«Согласно отчету LinkedIn, из списка 20-ти самых перспективных специальностей, Скрам-мастер — на 10-м месте хит-парада. Это означает, что в ближайшие годы мы увидим рост интереса к этой роли и наплыв желающих ее познать и осилить. А значит, уровень запутанности и недопонимания этой особенной роли только увеличится». (Алексей Кривицкий)


Благодарю за помощь в написании статьи Артема Быковца, Алексея Кривицкого, Сергея Волотовского, Александра Карицкого, Анну Лаврову и 14 других украинских Скрам-мастеров, которые рассказали DOU о своей профессии. Приведенные в статье цитаты взяты из их рассказов.

См. также cтатьи о других специальностях в IT.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному2
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Все хорошо в скраме если бы только его не пихали везде где он не нужен. ИМХО 90% проектов не готовы к демократии такого рода потому что люди которые на них работают больше похожи на детей чем на взрослых, а остальные 10% умеют пользоваться инструментами XP и не тащат за собой тяжеловесные фреймворки типа скрама.
Отдельную нишу занимает скрам в СНГ.
Это как подростковый секс: все о нем говорят но ни у кого его никогда не было.

Сама беcполезная позиция, наличие такого человека в команд, значит что нормальному программисту туда идти работать не следует.

Краще мати дочку простітутку ніж сина скрам мастера!

Еще немного и появятся смузи тестировшики ))

158 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

Чтобы понять для чего нужен Scrum Master и какой основной результат его работы, достаточно почитать Scrum Guide или, если нужно чуть шире, — «Scrum A Pocket Guide» Gunther Verheyen. А если в двух словах, то в организации (не только на конкретном проекте) должна произойти трансформация от традиционной «командно-контрольной» системы к самоорганизующейся Agile, где Scrum Master выступает servant-leader’ом. То есть предусматривается довольно высокий уровень сознательности и профессиональности Development Team, а также понимание Agile подхода менеджментом компании — без этого весь процесс не более чем профанация.

Также хочу упомянуть 2 любопытных момента:
1. Роли Project Manager в скраме, как известно, не существует и тут возникает коллизия с реальностью наших аутсорсинговых/продуктовых IT компаний. Ведь хочется делать скрам и PM’а оставить, и Delivery менеджер нужен. Вот и получается, что приходится совмещать несовместимые парадигмы — Project Manager vs Scrum Master / Product Owner.
Хотя определенный смысл все можно найти в случае LeSS и SAFe, когда PM может координировать работу скрам команд.

2. Из тех же источников, которые я наводил выше, можно узнать, что фреймворки гибкой разработки возникли, как ответ на неспособность традиционной вотерфольной методологии («командно-контрольной» системы) разработки обеспечить быструю реакцию на современную ситуацию с изменением требований и быструю адаптацию продукта к требованиям рынка. Также наведена провальная статистика успешности IT проектов при традиционной разработке. Поэтому:
— Забудьте про конечный результат Agile трансформации — это нескончаемый процесс усовершенствования взаимодествия и процессов в команде и организации, включая использование принципов Kaizen и Lean.
— Измерить успешность внедрения Scrum и принципов Agile в компании можно в перспективе 1-3 лет с момента начала внедрения. Проверьте KPI проектов, количеством успешно завершенных проектов по сравнению с кол-вом успешных до начала внедерения и т.п.

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

Не понятно какой основной результат работы скрам мастера. Какая его цель?
В каком случае становится понятно что скрам мастер не справляется?

У нас на работе есть скрам мастера — все что он делает — это говорит что дейли началось или ретро. Предыдущий скрам мастер был в разы лучше — он еще печеньки иногда приносил

дуже схоже, що в мене ваш скрам-мастер!!!

И ты будешь присылать их тиму каждый день по его пальцу пока они не вернут все печеньки? ;)

Исходя из задач и зон ответственности описаных в топике

Скрам-мастер это человек с врожденной мудростью, энциклопедическими знаниями в проектном менеджменте, управлении персоналом, спец в налаживании бизнес процессов на уровне обладателя корочек MBA, и еще в чем-то что я затрудняюсь идентифицировать (в силу ограниченности моих знаний).

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

Это как плохому менеджеру — всегда персонал не тот. «Вот мне бы программистов как в Гугле, то я бы!»
Вот и попутчик ему — скрам-мастер :)

Все очень просто (по крайней мере в моей реальности). Один ненужный посредник — это теоретический минус из моей зарплаты и бонуса.

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

Если вы внимательно прочитали — там написано «в моих реалиях».
Мои реалии это фронт офис большого инвестмент банка.

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

Пользу приносят только трейдеры.

Все остальные это так себе.

Тогда Вы, наверное, делитесь с трейдерами зарплатой?

Не изображайте из себя идиота, а то люди поверят. Зарплатой как раз делятся трейдеры.

Из опыта в банке сидят 1 синьор с титулом СТО и 100500 стажеров-эникейщиков ;) основной продукт — поддержка клиента для интернет банкинга и CLI-ОДБ RSbank ну и шредер же :)

Вы пропустили или не поняли что значит

фронт офис большого инвестмент банка

Инвест банкинг это в первую очередь аналитика(риск менеджмент например), а это в современном мире тянет за собой много очень технических вещей, те же big data тулы типа Hadoop/Spark/Storm. Стажеры на этом поприще много не навоюют.

Кто мне скажет, почему у девелоперов так бомбит от нетехнических должностей? Они каким-то образом ущемляются, часть их потенциально более высокой зарплаты идёт на зарплату скрам-мастера? Зачем нам прораб, сами обои в ванной поклеим?

Кто мне скажет, почему у девелоперов так бомбит от нетехнических должностей?
это Project Manager задает такой вопрос? вы девелоперов не видели что-ли, не общались? ;)
Зачем нам прораб
прораб это пиэм. вообще-то большинство моих коллег, девелоперов, вполне понимают необходимость прораба.

а вот пассы руками приходящего скрам-мастера — не понимают.

Вот у нас на проекте скарам масте это девочка симпатичная, она сидит с нами на митингах и разбавляет наш мужской коллектив.
Ну еще она собирает наши пожелания и жалобы возникшине за прощедший спринт и куда то их уносит , такое впетчаление что до ближайшего мусорго ведра)

Это собственно вся польза которую она приносит) и уносит)

Ну вот как бы да

The Scrum Master is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences.
Основное занятие на практике обычно вот это, а ритуалы, то уже такое
Это собственно вся польза которую она приносит) и уносит)
короче по Вашей логике, можно было бы вместо неё назначить скрам-мастером дворовую кошку, которая бы на митингах разбавляла ваш человеческий коллектив.

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

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

И абсолютно очевидно, что для девелопера и прожект менеджер, и тестировщик
ну это лечится просто — отправить такого девелопера временно во фриланс. чтобы он побыл и сейлсом и пиэмом и тестировщиком :)

тепличные дети да этого не понимают.

незаслуженно получающее баснословные деньги
это кто, тестировщики то? пиэмы кстати тоже, особенно в западных компаниях далеко не всегда на синьорских зп :)
если он или она не в состоянии общаться с ним на одном языке
аха, понятно. то есть пиэм — не умеет общаться с людьми, не умеет вести проекты, неуважаем(а может вообще презираем, потому что и хардскилов не имеет хотя бы) командой — и вот придет скрам-гуру и все наладится :)
это кто, тестировщики то? пиэмы кстати тоже, особенно в западных компаниях далеко не всегда на синьорских зп :)
ну так тем более, по сравнению с девелоперами. чего волком смотреть-то?
аха, понятно. то есть пиэм — не умеет общаться с людьми, не умеет вести проекты, неуважаем(а может вообще презираем, потому что и хардскилов не имеет хотя бы) командой — и вот придет скрам-гуру и все наладится :)
да я не защищаю скрам-мастеров. у меня самого скрам-мастер ассоциируется с героем Харви Кейтеля из Криминального Чтива, которого наняли «решить проблему», избавиться от трупа до приезда жены. просто следующим топиком будет условный продакт менеджер или бизнес-аналитики и формошлёпы набегут опять стадом.

не обязательно из рубрики «Карьера в IT»
возможно кто-то напишет статью «нужно ли знание ООП продакт менеджеру» или что-то вроде этого

Гугл дослідження проводив (Project Oxygen):
The interviews produced more than 400 pages of notes, which were coded using standard behavioral science methodologies. The final result was eight behaviors — things great managers do that make them great. They are, in order of importance:

1. Be a good coach.

2. Empower; don’t micromanage.

3. Be interested in direct reports, success and well-being.

4. Don’t be a sissy: Be productive and results-oriented.

5. Be a good communicator and listen to your team.

6. Help your employees with career development.

7. Have a clear vision and strategy for the team.

8. Have key technical skills so you can advise the team.

нетехнических должностей
Ви впевнені що висновок правильний?
Може бомбити і від технічних посад, при умові що їх займає невідповідна людина. І навпка, я не зустрічав девелоперів яких би бомбило, наприклад, від бухгалтерів, прибиральників, сейлзів, суппорту.

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

Я тут немножко придерусь в слову, но все же.

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

Ну такое я бы сюда не относил, потому это везде. Не писать же в вакансии столяра на заводе «стрессоустойчивость».

О, так столярам тоже нужны скрам-мастеры: чтобы планировать требования начальников и защищать работников от стресса :)

Я вот только сейчас увидел, насколько все это похоже. Возникает логичный вопрос: есть ли на столярных фабриках (хз правильно ли выразился, но думаю суть ясна) скрам-мастеры, career advisor-ы, happiness manager-ы и т.д.? И если нет, то выходит в IT это все просто от избытка баксов?)

Если исходить из философии Scrum, то он применим в любой сфере деятельности. Не вижу ничего смешного, это просто манера ведения рабочего процесса.

«Дао Тойота» — книга на тему

Одна просьба ко всем этим евангелистам, перед тем как писать статью оживите ее практическими примерами как какой-то конкретный инструмент решил проблему в реальной команде, типа не было скрама — было плохо: пришел скрам — все стало хорошо и приведите список KPI по которым вы это определили почему было плохо и почему стало хорошо. Такой материал который вы написали существует уже несколько лет даже в русскоязычном сегменте интернета. Сколько можно продавать чужие мысли и пиариться на этом ?

Интересно, почему скрам в комментариях поддерживают только скрам мастера и коучи, а все остальные — плюються.

Скрам сам по себе не плох, не хуже RUP. Но это очень легковесный простой способ формировать список задач на итерацию и отслеживать ее. Скрам мастер, это просто роль в команде, которую может выполнять любой, сам по себе процесс не должен отнимать много времент. Но тут аоявля.тся коучи, факинсциляторы и прочие hr-ы, которые начинают превращать легковесный фреймворк в религию, тратить время разработчиков на херню, морочить голову и произносить кучу бессмысленных слов, чтобы выглядеть поважнее (см. ниже попытку объясеить что такое коучинг).

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

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

На полке рядом со всяким сбродом особое место занимают Аджаил Коучи и компании типа «Скрам Мастер».

спасибо, коллега) можем пойти на кофе внизу, отвечу на все вопросы по теме: «зачем компаниям могут быть нужны Agile Coach» :)

Я в леви не работаю года два уже, так что не получиться, но тебе не кажется странным что тебе приходиться объяснять зачем нужен Agile Coach ? Мое личное мнение что Agile Coach не решает никакой проблемы, если у тебя есть обратные сведения то я прошу поделиться тем как и чем твой коачинг помог реальным командам, я даже готов как то в леви приехать и послушать =)

мне это не кажется странным, но не кажется нормальным. И в моем понимании — это последствие «внедрение» Скрама и «гибких методологий» ранее без объяснения (а порой даже и без понимания) ЗАЧЕМ это делается... какую задачу мы хотим им решить?! что для этого нужно? КАК мы будем это делать? КТО за что будет отвечать?
Люди делали культ-карго из Скрам. Просто загоняя команды как стадо и допрашивая их «Что же было плохо в прошлом спринте?!» не обьяснив ЗАЧЕМ и не показав, что это может быть полезно в первую очередь команде, а не тому, кто эти вопросы задает... А делали это потому, что — «Так принято!» или «так написано в книге»

Вот и получили такую культуру, которая как иммунитет защищается от одного упоминания про Scrum. Какое же тут ожидать отношение к такой отдельно взятой роли как Agile Coach...

Вот так всегда ты человеку вопрос а он тебе про то как «Корабли бороздят вселенную» =)

Сорри) я ответил выше на вопрос. Просто еще работаю параллельно и не все сразу успеваю)

Это по поводу Competera:

jobs.dou.ua/...mpanies/competera/photos
Признание труда — 71%
Грамотный проектный менеджмент — 75%

Статистика как минимум по критерию team happiness как то говорит об обратном, финансовые результаты компании проверить не могу (

открытость, смелость и честность — это ведь Scrum Values? :)
или ты веришь тем компаниям у которых 99% оценки и 200+ голосов? ;)

Я же взрослый мальчик, я ищу подтверждение твоим словам, может скажи мне где их найти тогда ?

www.linkedin.com/in/abykovets например тут в разделе рекомендаций

ну и не всегда стоит «решать проблему»
иногда ее можно предотвратить.. а иногда — помочь синхронизироваться по best practice, а также по граблям по которым топтались другие. Взгляд со стороны и тд

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

Ну и где здесь ответ о том как ты удачно трансформировал компанию и теперь она зарабатывает в 35 раз больше потому что у них бешено взлетела велосити ? Какие у тебя KPI ? Расскажи мне какую компанию ты привел к успеху при помощи Agile coaching ?

Знаешь, ты как лицо заинтересованное конечно расскажешь)
А вот если взять выборку из 10 разработиков , из абсолютно разных компаний и интересно какой процент респондентов, скажет что скрам мастера нужны и важны на проекте.

а вот если взять выборку из 10 жителей любой пост СНГ страны и спросить нужны\важны ли министры и депутаты в стране? а вот если взять выборку из 10 рядовых солдат срочников в армии и спросить нужны ли прапорщики и замполиты в армии? а вот если взять 10 офицеров разных армий и спросить нужен ли министр обороны? а вот если взять 10 учителей в школах и спросить нужен ли глава районо? а вот если взять 10 глав районо и спросить нужен ли министр образования? а вот если взять 10 сольных музыкантов и спросить нужны ли дирижеры? ... а вот если ...

я могу продолжать...

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

нет, я так не считаю. Но я вижу, что МНОГИЕ разработчики воспринимают Скрам Мастера как еще одного РМа (читай менеджера). А еще к моему сожалению, многие скраммастера себя такими видят и считают (даже из цитат в статье выше)...
И вот у разработчиков к менеджменту такое вот отношение, что «мы тут работаем и деньги приносим компании, а вы на эти деньги питаетесь»
Выше я лишь привел аналогии такой культуры (менталитета) вне нашего «замечательного.ит»

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

да. так часто бывает. Про то, что много компаний лишь декларируют, что они Agile и внедряют Scrum, а по факту ищут серебрянные пули, ведутся на buzz-words и не готовы ничего в себе поменять — в статье как-раз тоже упоминается. И порой — это очень ограничивает реальную эфективность работы ScrumMaster’a
но ведь и квалифицированных разработчиков часто ограничивают легаси архитектурой и старыми технологиями проекта, некомпетентными архитекторами или бюрократией... повод ли это считать, что толковый синьер — бесполезен и проедает бюджет и нанимать команду формошлепов?

вполне может быть и да) ведь смысла нет, в супер высокоскоротном жестком диске , если его производительность будет резаться в 5 раз так как передающая шина будет рабоать в 5 раз медленне.

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

дада! пропускная способность системы не может превысить пропускную способность самого узкого места :) и как правило — Dev Team — далеко не всегда является этим «самым узким местом»

потому максимально эфективен Agile Coach будет там — где он сможет коучить не только команды, но и Product Marketing, Sales, CEO и прочие отделы компании.

спасибо за конструктивный диалог.

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

Вот кстати да. Роль главного qa часто не дооценивается. А он то как раз, видит продукт непредвзято, дотошно, и с метриками в руках. А если он еще почитывает Деминга или подобных, то в состоянии предложить немало полезного.

Скрам-мастер — по идее роль, а не должность. И типа чем лучше сработана команда, тем меньше он нужен.

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

системные изменения требуют большего времени, чтобы получить видимый результат чем изменения на уровне скрам команды (<9 человек)
Вот если результат работы ScrumMaster не видно долгое время — это уже вопрос. По Agile Coach для организации — время требуется больше. Это как System Architect vs Senior Developer.

Валидно но на уровне команды agile coach тоже должен работать правильно ? И команда тоже должна почувствовать как ты помог ей вырасти ?

правильно. с такими командами тоже могу познакомить ;)

Не из компетера случаем ?)

нет. из Betlab например

jobs.dou.ua/...betlab/photos/#photo11978
Там тоже стоит 78 по проектному менеджменту.

и что? а я каким к этому образом? ScrumMaster <> PM!!!
ну и я говорить могу лишь за те команды с которыми я там работал и в которых смог построить норм self-organisation и производительность и норм мотивацию. Я там уже 1,5 года не работаю и за это время компания выросла с 60 человек до 100. Эти оценки — это пальцем в небо имхо. Мои команды — могут дать фидбек за который мне не будет стыдно

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

справедливо. я лишь отвечаю тебе на представленные тобой аргументы. Выборка которую ты берешь за основу — не репрезентативна для оценки моей работы там. Я лишь отвечал тебе на вопросы: «какие компании можешь привести в пример?» и «команды из каких компаний кроме Competera еще могут сказать, что ты был эффективен и полезен как ScrumMaster» + «я верю фактам, а не словам» — на который я дал ссылку на linkedin.

среднему украинскому Скрам-мастеру 30 лет, он имеет зарплату $1500-3000.

скрам мастер тоже хочет свой кусок пирога сыра

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

це чудово. але тут як в казці про ворону: дали тобі кусок сиру, так тримай його в зубах і не каркай :)

Знаю лично нескольких человек с тайтлом «аджайл коуч», хорошие люди, ничего плохого про них не скажу. «Строили скрам» в компаниях, где работал.
Но был всегда один нюанс. От них никто не мог получить четкий понятный ответ на прикладной вопрос. Они то ответ давали, мы спрашивали еще, но все их ответы как-то вели к осознанию того, что ты так до конца и не понял «что и как делать правильно».
То есть постоянно какое-то «таинство» и недосказанность оставались по завершению тренингов/внедрения скрама.
Думаю это и есть причиной такой реакции

«от тебе портрет полковника: голубой
с золотом фон, на нем — пять огромных галунов, в одном углу картины — конь,
в другом — кресты. Портрет промышленника — это фабричная труба и сжатый
кулак на столе. Понимаешь теперь, Пьер Душ, что ты подарил миру? Возьмешься
ли ты написать за месяц двадцать „идео-аналитических“ портретов? Художник
грустно улыбнулся.
— За один час,-ответил он.-Печально лишь то, Глэз, что, будь на моем
месте кто-нибудь другой, затея, возможно, удалась бы, а так...
— Что ж, попробуем!
.- Не мастер я болтать!
— Вот что, старина, всякий раз, как тебя попросят что-либо объяснить,
ты, не торопясь, молча зажги свою трубку, выпусти облако дыма в лицо
любопытному и произнеси эти вот простые слова: „А видели вы когда-нибудь,
как течет река?“»

www.lib.ru/MORUA/r_pros1001.txt

Потому что мало где нормальный скрам практикуется. И люди банально не понимают, в чем смысл. Хотя скрам всего лишь формализует простые процессы, которые иначе происходят неявно. Суть скрама не тупо следовать риуталам, а следовать ритуалам, что б добиться определенных выгод. Люди, просто не знают, каких выгод ожидать, потому не действуют так, что б их получить. Это как собирать мебель по инструкции не зная какой должен быть конечный результат.

Ещё один повод пообвинять :) То им аджайл и скрам во всем виноваты, то ещё кто.. А теперь ещё и лично скрам-мастера : кроме того, что все зло от СМ, так они ещё и нафиг не нужны .. Ужас, как страшно жить :)

Вот тут должен быть долгий коммент с обоснованиями (когда-нибудь допишу статью).
...
Сколько Agile на рынке? 20 лет. И что-то я не наблюдаю экспоненциального роста производительности и качества в области разработки ПО.
...
Скрам-пам-тарарам: просто непонимание, что декомпозици задач должна сменяться композиций, если вы хотите сделать продукт, а не набор юзер стори.
Agile manifesto — гениальное руководство по постоянному накоплению технического долга.
...
Начните отсюда reqcenter.pro/waterfall-myths,
потом сюда ru.wikipedia.org/.../Rational_Unified_Process
и закрепите ISO 9001:2008
и можно пытаться начинать писать нормальное ПО, соответствующее внешним факторам качества it.wikireading.ru/52098
...
Agile — продажа Common Sense, ну тоесть воздуха.

Сколько Agile на рынке? 20 лет
16
И что-то я не наблюдаю экспоненциального роста производительности и качества в области разработки ПО.
Не всё то Agile, что ним обзывают.
И оно больше про TTM, чем абстрактную производительность.
просто непонимание, что декомпозици задач
Казалось бы: при чём здесь «декомпозиция задач»? Но если очень хочется про декомпозицию, то Elephant Carpaccio вам в помощь.
Agile manifesto — гениальное руководство по постоянному накоплению технического долга.
Неужели RUP спасает от технического долга?
и закрепите ISO 9001
Ммм? Больше документов писать? Или кому-то надо построить огород из QMS, чтобы какой-нить сервис, скажем, для букинга запилить?

Уже отписался ниже, но повторюсь. А разбивка поста на цитаты и выборочное комментирование обычно мало к чему приводят.
...
Всего один тезис.
Есть тип деятельности: разработка ПО (как и преподавание, выращивание картошки, написание стихов и пр). Существует несколько моделей, претендующих на некоторую математическую строгость описания искомого объекта. Так вот между «условным Waterfall», RUP и Agile, метрика расстояния до искомого объекта у Agile не самая лучшая.
...
Да есть проекты, в которых связи между декомпозированными частями не сильные, так сказать естественно распараллеливаемые задачи. И для таких проектов, выстраивание в спринты — достаточно лаконично и не скрывает подводных камней, bus-factor и технический долг не существенны и пр. Но чаще всего это fixed-price и все вытекающие отсюда нюансы: уровень входа в такие проекты, цена и пр.
...
Для всех остальных проектов — увы все грустно. И это не я так просто думаю, я это знаю, видя как действительно сложные проекты летят в тар-та-ра-ры. И здесь «правильный Agile» «не правильный Agile», «правильный Scrum Master» «не правильный Scrum Master» не решают ровным счётом ничего.
...
Проблема в консерватории.

А разбивка поста на цитаты и выборочное комментирование обычно мало к чему приводят.
Так удобнее и понятнее.
Так вот между «условным Waterfall», RUP и Agile, метрика расстояния до искомого объекта у Agile не самая лучшая.
Более 70% проектов, которые ведутся с использованием классических методологий, не вписываются в бюджет и сроки, около 40% не соответствуют требованиям.

И почему ряд такой «„условным Waterfall“, RUP и Agile»? Если используется слово «Agile», то с другой стороны должно быть либо «предиктивные», либо «классические».
Потому что Agile — это общее название нескольких десятков методов и фреймворков, которые объединяют общие принципы. Некоторые минималистические, типа Kanban, Scrum, некоторые огромные (SAFe) и покрывают области от стратегического планирования бизнес инициатив до того, как мы пишем код.

я это знаю, видя как действительно сложные проекты летят в тар-та-ра-ры.
Я видел, как проекты фейлятся, ещё до того, как в этой стране услышали слово «Agile» (я и сам его тогда не знал).
Видел проекты, у которых бюджеты растут в разы, и где-то ближе к последней трети они обрастают чейндж реквестами.

Если условный человек паркуется, как чудак, то он это будет делать, независимо от того — у него Жигули или Ленд Крузер.

Фреймворк или методология — это всего лишь инструмент. Можно уметь или не уметь его правильно использовать. И вопрос успеха — это вопрос опыта вовлечённых сторон и понимания ними того, как можно правильно выйти из разных ситуаций и добиться успеха.

Мне, как человеку поработавшему, с RUP, MSF (в т.ч. в организациях с ISO 9001, CMMi level 5), Scrum, Kanban, DAD, SAFe, условно всё равно, какой подход будет использоваться на очередном проекте, потому что я работаю с проектом стратегически и тактически, и опыт позволяет не набивать шишки (ну, либо начать вовремя кричать «Alarm!!!!!111» ЛПРам), независимо от методологии.

«Waterfall существует только в умах тех, кто его осуждает» Conrad Weisert
...
А где статистика по проектам использузющим Agile? Что-то мне подсказывает, что цифры там будут аналогичные.
И не надо писать много-эмоциональных-букоф.
...
Я просто вернусь к тому, моменту, который был Вами проигнорирован ввиду того, что ответа у Вас нет и быть не может. А вопрос ключевой.
...
Есть процесс — разработка ПО. Есть несколько моделей его описывающих. Какая из моделей наиболее точно отражает поведение искомого объекта, при всех прочих равных условиях?
...
Если чёткого ответа нет — то все это гомеопатия.

«Waterfall существует только в умах тех, кто его осуждает» Conrad Weisert
Влад, можно без общих фраз?
Я, наверное, первый человек в том же GL, который отучивал людей говорить слово «waterfall», ибо то, что под ним подразумевает не специалист, не является тем, что он есть по своей сути.
А где статистика по проектам использузющим Agile? Что-то мне подсказывает, что цифры там будут аналогичные.
Ну, если в Гугле забанили...
cdn.infoq.com/...ution Agile Waterfall.jpg
VersionOne регулярно делает исследования на эту тему.

Ну, и так, из личного опыта: меня уже более 10 лет приглашают вытягивать разного рода проекты из состояния «всё плохо, спасите-помогите!!!».
И вот был такой проект, который в компании с валидной сертификацией ISO 9001, CMMi level 5, вёлся с ориентиром на RUP. Было проекту 2 года. Он должен был завершиться за 4 месяца до того как меня попросили ним заняться. Был он fixed bid. Компания несла на нём финансовые и репутационные потери. В общем, нужно было его быстро и успешно завершить.
Это была моя первая проба пера со Scrum — мы запустили там Scrum, назвав его, правда, «customer driven development», ибо к тому моменту заказчик уже всех называл разными нехорошими словами, крыл матом и никому не верил.
Через 2 месяца проект успешно завершился. И заказчик открыл ещё один с использованием того же «customer driven development», который, повторюсь — чистейший Scrum. Так ему понравился результат.

Я просто вернусь к тому, моменту, который был Вами проигнорирован ввиду того, что ответа у Вас нет и быть не может. А вопрос ключевой.
Для этого и нужно цитирование — чтоб давать контекст комментарию.
Я вот сейчас вообще не понял о чём речь.
Если чёткого ответа нет — то все это гомеопатия.
Так и я — о том же — у тебя какие-то общие фразы и отсылы к общему бессознательному из мира ощущений и эмпатии.
Было проекту 2 года. Он должен был завершиться за 4 месяца до того как меня попросили ним заняться
Очень плохая музыка. Это очень плохой пример. Это называется тушение пожара, а роль на проекте была — пожарный, который боролся с пожарниками )

...
То что ты описал имеет очень опосредованное отношения к разработке ПО. Это называется Кризис менеджмент. Все что ты делал, так это вел проект по Critical path обладая экспертными знания в предметной области. Используя аналогичные подходы, можно вытягивать разные проекты от строительства до выборов.
...
А вот сейчас начнётся специфика: вы вернули технической долг в полном объёме, может наладили CI\CD, покрыли все тестами (юнит\регрессия\интеграция\нагрузка и пр.). Сделали прозрачный DevOps? Могу поспорить что нет. А заказчик был настолько хэппи, что не понял какой чемодан без ручки ему вручили.
...
То что ребята, начав работать по RUP забили на архитектуру и не смогли выстроить ортогональный базис будущей системы, ну так это не вопрос к RUP/Waterfall.
...
А вот когда заказчик захочет внести маленькое-маленькое изменени\улучшение в систему, это ему будет стоить очень много денег, потому как к сожалению Agile/SCRUM не знает что такое extensibility и reusability (а также остальные 13 внешних факторах качества ПО)
...

Так и я — о том же — у тебя какие-то общие фразы и отсылы к общему бессознательному из мира ощущений и эмпатии.
Ок, не даёшь работать в мета пространствах )

Есть объект внешнего мира — круг. Есть две его модели: квадрат и восьмиугольник. Можно ввести метрику, которая будет показывать насколько точно модель (квадрат и восьмиугольник) описывает реальный объект (круг).
...
Есть объект — разработка ПО и несколько моделей:
«Waterfall», RUP, SCRUM, XP, Kanban, ScrumBUT, сидим ничего не далаем, копируем код со стековерфлоу и т.д. и т.п
Какая из них наиболее точно описывает эффективный процесс разработки ПО?

Так Agile Manifesto и родилось как ответ на кризис и массовую безработицу разработчиков, и 1 проект как раз я перевел на Скрам тоже для crisis management: важно, чтобы уровень неопределённости и пр. предпосылки наличествовали. При идельной Project Charter и по РМР можно вести ;)

Начните отсюда reqcenter.pro/waterfall-myths,
потом сюда ru.wikipedia.org/.../Rational_Unified_Process
и закрепите ISO 9001:2008
и можно пытаться начинать писать нормальное ПО, соответствующее внешним факторам качества
И че — будет экспоненциальный рост производительности и качества?
и можно пытаться начинать писать нормальное ПО, соответствующее внешним факторам качества it.wikireading.ru/52098
Не читал, но осуждаю

Все хорошо в скраме если бы только его не пихали везде где он не нужен. ИМХО 90% проектов не готовы к демократии такого рода потому что люди которые на них работают больше похожи на детей чем на взрослых, а остальные 10% умеют пользоваться инструментами XP и не тащат за собой тяжеловесные фреймворки типа скрама.
Отдельную нишу занимает скрам в СНГ.
Это как подростковый секс: все о нем говорят но ни у кого его никогда не было.

Скрам это как социализм, на словах демократия, а на деле диктатура с микроменджментом.

к скраму и правда накопилось в индустрии много претензий. но давайте разбираться:

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

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

есть такая метафора, что скрам — дает зеркало. это так, если его правильно внедрить. без всего мусора, с которым он ассоциируется.

а то, что потом в этом зеркале видны кривые рожи (не примите лично!) — ну да, некомфортно, но ведь они там и раньше были. просто зеркало было замыленным.

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

так, что скрам безопасен, если внедрен опытными людьми (отсюда и вся эта статья о скрам-мастерстве)

безопасен...НО! кроме случаев, когда вместо скрама подается что-то очень кривое с таким же названием. к сожалению, 80% команд и компаний украины если не больше делают скрам очень криво. и это ведет очень часто к наращиванию тех долга, эксплуатации команды, недовольству команд и проч.

вот это и нужно чинить. а не скрам.

по поводу вреда кривого скрама есть есть крутая статья апологета xp по этому поводу: ronjeffries.com/...rticles/016-09ff/defense

А давай лучше так: искать нужно не там где светло, а там где потеряли.

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

...
Agile, как методология не фокусируюется и не усиливает сильные стороны разработки ПО, как продукта, продающегося на рынке (аналогично, влияние слабых сторон нужно уменьшать). Скажем так, модель разработки ПО, предлагаемая Agile, очень и очень поверхностно описывает искомый объект.

Я там писал выше

Люди, просто не знают, каких выгод ожидать, потому не действуют так, что б их получить. Это как собирать мебель по инструкции не зная какой должен быть конечный результат.
Все правильно Алексей сказал.

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

А еще и нагло уворованные. Аналогия про зеркало практически дословно утянута у буддийских наставников. Чистым зеркалом объявлялся просветленный ум а не скрам ☺

Вобщeм eвангeлисты скрама выглядят как опытные жулики.

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

Вообще-то из апологетических текстов видно ничего, они не доказывают ни эффективность скрама, ни отсутствие эффективности. Как инструмент он некоторым подходит, а некоторым нет. С Алексеем я на 146% согласен в этом:

компании, заявляющие о внедрении скрам, на самом деле не хотят меняться вовсе

То есть часто менеджеры считают, что если они введут стендапы, то волшебным образом всё наладится. Или еще лучше, когда менеджмент такой: «о, то есть я теперь у команды буду появляться только на стендапах послушать их отчет, а еще можно гибко впихивать новые таски в любой момент времени? а чё, так можно было? заверните два!» А об остальных составляющих можно скромно забыть.

Короче, как всегда, у нас есть инструмент, кто как его использует — зависит от личного буратинства.

у нас есть инструмент
в том то и дело что никакого инструмента «у вас» нет.

есть набор тезисов, весьма обобщенных, на уровне афоризмов и некоторых полезных quick & dirty analyze практик.

а если превращение их в действенный инструмент требует мутной апологетики, таинственного знания от гуру, то это уже указывает на мистические свойства инструмента. что допустимо для инструментов типа буддийской медитации, но никак не для достижения конкретных, осязаемых, «материальных» целей.

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

Есть вполне конкретные формализованные ритуалы. Которые и являются инструментами. Мы тут о конкретно скраме, а не Agile в общем.

Мы тут о конкретно скраме,
из этой темы, как и из подобных вывод то — а нет никакого «конкретного» скрама.
Есть вполне конкретные формализованные ритуалы
есть, об этом и сказал. но отдельные ритуалы, практики — это еще не инструмент как методология.

а когда начинаются расспросы о ней — то в ответ будет муть.

я впервые с скрамо-мутью столкнулся лет 5 тому. посетив какой-то круглый стол. где со сцены рассказывали несколько скрам-мастеров и пиэмов.

очень четко была разница — кто сыпет какими-то общими и непонятными словами ни ап чем, а кто по делу, потому что занят — делом.

еще раз — скрам-мастеров зовет «на помощь» бестолковый менеджмент. толковому достаточно посетить пару семинаров скрамокоучинга, чтобы взять отдельные полезные практики.

в этом то возможно и ответ, что внедрение скрама ни к чему обычно не приводит — менеджеры то те же. они довели ситуацию до 3.14ца, пришел скрамо-мастер, чего-то там поменял, какие-то ритуалы ввел — а бестолковость конкретных менеджеров — осталась :)

А чем ритуалы не инструмент? Мало 4 ритуалов? Есть описания подходов, помогащие разбить проект на подзадачи так, что б удобно было в по спринтам раскидать.
Я не знаю чем инструмент от методологии отличается. Меня скрам как инструмент вполне устраивает.

Насчет того, что менеджры бестолковые. Я на самом деле не сильно понимаю как скрам-мастеру без наличия полномочий что-либо сделать. Толк будет, только если скрам-мастер будет учить людей. А что б учить людей нужно тратить время. А время — деньги. Плюс скрам достаточно требовательный к планированию. Если криво разбить проект на задачи, то тяжко будет. И если скрам-мастер не может влиять на процес планирования, то ритуалы удут работать намного хуже.

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

Способы разбивки проекта на подзалачи — это классическая часть проектного менеджмента. Если пиэм не умеет подобрать способ — то он бестолков. А если он и не знает способов — то вопрос как он оказался на этой должности.

Проектный менеджмент — вот это общее название для методологий и практических рецептов для, неожиданно — реализации проектов.

Насчет остального — уже писал. Аргументы саентологов, скрам-мастеров и прочих недогурков мне неинтересно рассматривать.

Есть еще такой вариант:
«Скрам это как социализм — когда он проваливается, то его адепты начинают говорить, что это просто был неправильный скрам».

безопасен
у вас ошибка в слове «бесполезен»
на моем опыте половина из них вызвана просто непониманием самих принципов (это лечится тренингами, отчасти)
Когда знаешь как, умеешь, но уже не можешь сам — ты тренер.
Когда знаешь как, не умеешь и не можешь сам — ты профессор.
Когда не знаешь как, не умеешь и не можешь сам, но можешь наказать, если эти суки сделают не так — ты президент.
©
Данное гениальное изречение — валится на тест кейсе «скрум — тренера». Хотя .... скорее всего, некоторые дают себе названия, которые не имеют ничего общего с реальностью.

Согласно Scrum Guide:
Фасилитация — организация процесса групповой работы, направленная на облегчение
достижения целей, поставленных группой.
Коучинг — партнерство,стимулирующее работу мысли и креативность клиента, в котором он с помощью коуча максимально раскрывает свой личный и профессиональный потенциал.

Фасилитация — организация процесса групповой работы, направленная на облегчение
достижения целей, поставленных группой.
Коучинг — партнерство,стимулирующее работу мысли и креативность клиента, в котором он с помощью коуча максимально раскрывает свой личный и профессиональный потенциал.

Как происходит организация процесса групповой работы, и есть ли формальное описание качеств «коуча» с помощью которых он раскрывает креативность и потенциал? Что есть «креативность» в контексте этого предложения?
Какие метрики используются для измерения результата работы «коуча» и "фасилианта"(?) ?

Еще немного и появятся смузи тестировшики ))

Это те, которые закидываются смузи и тестят? Или тестят качество смузи?

Качественно смузят ваш продукт.

сделать должность 2 в 1)

Или баристу.

Но он же будет со знанием английского.

откуда такая нелюбовь? может вам просто попадались только такие «специалисты» на вашем пути?

Краще мати дочку простітутку ніж сина скрам мастера!

Интересно узнать ваш ход мыслей, на случай дочери скрам мастера :)

Лучше дочь скрам мастер, чем сын программист в джойКазино.

Зачтем в цитатки для ванильного паблика

Павло, обережно зі словами. Вони мають властивість ставати реальністю ;) 😂

Мне в этой роли не хватает непосредственного people-менеджмента.

При желании, people management хорошо включается в роль Scrum Master’а.

Сама беcполезная позиция, наличие такого человека в команд, значит что нормальному программисту туда идти работать не следует.

Осторожно, тролль! Не ведитесь на провокации этого молодого человека :-)

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

Вспоминается демотиватор с лицом Януковича и подписью — а что разае так можно было?

Просто обьязанности как абстрактный конь в вакууме. Фиг померяешь. А если что не так, то всегда можно сказать фасили титмровал и коучил, помогал и обучал, попутно налаживал процессы вне команды. ;)

Кстати а в чем разница между обучал и коучил?

Обучение может подразумевать предоставление прямых и конкретных решений. Коучинг — это наведение (стимулирование) человека, которого коучат, на правильное решение.
Результаты, в долгосрочной перспективе, получаются очень разные.

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

Во втором случае человек повышает свои компетенции, расширяет кругозор, повышает свою ценность и результат закрепляется на много лучше.

Олексий

к сожалению, адекватной альтернативы слова

коучинг
на русском нет. найдете — пишите.
кто сказал, что обучение это разжевать и в рот положить?
Обучение зачастую строится на учебном материале, т.е. своего рода шаблоне, примере и т.п.
а коучинг — это галимая калька с английского
Не нравится — придумайте своё название. Главное ж не как назвать, а результат.

больше денег можно просить всегда, когда клиент доволен.

разница не очевидная, но есть.

на самом деле есть, как минимум, 4 стиля работы с группой (или человеком):
— фасилитация (применимо только для группы)
— коучинг
— менторинг (наставничество)
— обучение

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

agile коучинг — это по сути смешение всех приведенных 4 стилей работы, отсюда часто возникает путаница.

Что я за бред только что прочитал? Вам просто слова английские нравятся?

чем больше умных незнакомых слов — тем больше лохов ведётся

считаю в этом списке пропущены: фистинг и флагелляция!

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

Надо активно вмешиваться везде, где есть подозрение, что кто-то что-то не так понял и делает что-то не то.
По тонкому льду шагаете)) Могут и неправильно понять.

Підписатись на коментарі