Comments 33
часто в компаниях очень плохо понимают суть Scrum Master. и если хорошие PO и хорошие команды мне встречались, то вот внятных и хороших Scrum-мастеров в живую еще не видел.
можно ли сказать следующее?
— PO — ратует за результаты, за продукт, за доходы и прибыль (руководитель производственник в понятии Ицхака Адизеса)
— SM — ратует за процесс, за культуру, взаимопонимание, за комфортную атмосферу (руководитель интегратор в понятии Ицхака Адизеса)
можно ли сказать следующее?
— PO — ратует за результаты, за продукт, за доходы и прибыль (руководитель производственник в понятии Ицхака Адизеса)
— SM — ратует за процесс, за культуру, взаимопонимание, за комфортную атмосферу (руководитель интегратор в понятии Ицхака Адизеса)
если хорошие PO и хорошие команды мне встречались, то вот внятных и хороших Scrum-мастеров в живую еще не видел.
Звучит грустно, но легко в это верится.
Что касается Адизеса, то к сожалению его книги не читал (но записал в то что стоит прочесть). Но ваше описание очень похоже на роли заложенные в scrum guide.
часто в компаниях SM как трактуется scrum manager — лицо, которое по иерархии выше команды и наделено полномочиями давать прямые распоряжения.
Самое главное на чем стоит сфокусировать все свое внимание при разработке ПО, это программисты!
Всем руководителям к программистам нужно относится, как к летчикам самолета, на борту которого они находятся. Чуть Вы их напрягете, сразу же почувствуете крен или тряску.
Поэтому не понятно зачем программистам растолковывать основы scrum идеологии и тем самым попросту захламлять их рассудок. Если управленец считает, что посвятив в тонкости своей работы программистов сделает команду эффективнее, то он просто дурак. На самом деле этот поступок, скорее попытка переложить ответственность с себя на команду. А для самой команды, это лишний гул в голове + кому-то может показаться, что их отчитывают. Чтобы управленец подумал, если бы программисты, кадждые пять минут пытались посвятить его в тонкости того, как те инструменты, которыми они пользуются, путаются всяческими багами и несовершенствами воткнуть им палки в колеса? Такой подход и есть начало конфликта.
Команда состоит из профессионалов и нуждается лишь в мотивации. А для этого нужно понимать самих программистов. Не программист не способен их понять. Или способен, если он талантливый психолог + очень долго с ними работает. А одно желание со стороны руководителей неминуемо приведет к созданию напряженности.
Всем руководителям к программистам нужно относится, как к летчикам самолета, на борту которого они находятся. Чуть Вы их напрягете, сразу же почувствуете крен или тряску.
Поэтому не понятно зачем программистам растолковывать основы scrum идеологии и тем самым попросту захламлять их рассудок. Если управленец считает, что посвятив в тонкости своей работы программистов сделает команду эффективнее, то он просто дурак. На самом деле этот поступок, скорее попытка переложить ответственность с себя на команду. А для самой команды, это лишний гул в голове + кому-то может показаться, что их отчитывают. Чтобы управленец подумал, если бы программисты, кадждые пять минут пытались посвятить его в тонкости того, как те инструменты, которыми они пользуются, путаются всяческими багами и несовершенствами воткнуть им палки в колеса? Такой подход и есть начало конфликта.
Команда состоит из профессионалов и нуждается лишь в мотивации. А для этого нужно понимать самих программистов. Не программист не способен их понять. Или способен, если он талантливый психолог + очень долго с ними работает. А одно желание со стороны руководителей неминуемо приведет к созданию напряженности.
А програмисты знают куда лететь? Или главное процесс?
PO — это штурман, подсказывает ключевые точки маршрута раз в спринт.
А пилоты сами принимают все решения и ни кто им не говорит на каком самолете и как лететь.
Без Scrum — это когда к пиломат свободно ходят все пассажиры из салона и каждый говорит куда только ему хочется чтобы летел самолет.
PO — это штурман, подсказывает ключевые точки маршрута раз в спринт.
А пилоты сами принимают все решения и ни кто им не говорит на каком самолете и как лететь.
Без Scrum — это когда к пиломат свободно ходят все пассажиры из салона и каждый говорит куда только ему хочется чтобы летел самолет.
Поэтому не понятно зачем программистам растолковывать основы scrum идеологии и тем самым попросту захламлять их рассудок. Если управленец считает, что посвятив в тонкости своей работы программистов сделает команду эффективнее, то он просто дурак.
Программист работая в компании, вынужден соблюдать правила, установленные в компании. И он может либо соблюдать эти правила как карго-культ, либо соблюдать их с пониманием того, зачем они введены (И если, например, он с ними не согласен, то может поднимать вопрос об изменении правил). Если мы говорим о scrum, то задача Scrum мастера объяснять и рассказывать участникам процесса, в том числе и программистам, об устройстве фреймворка. Это он делает из уважения к участникам процесса, ведь одна из ценностей scrum — это Transparency. И раскрывая, например, суть событий scrum для программистов, SM повышает прозрачность процессов. Если, например, SM навязывает (т.е. насильственно обучает) программистам знания об основах фасилитации, то это уже странно.
кому-то может показаться, что их отчитывают. Чтобы управленец подумал, если бы программисты, кадждые пять минут пытались посвятить его в тонкости того, как те инструменты, которыми они пользуются, путаются всяческими багами и несовершенствами воткнуть им палки в колеса? Такой подход и есть начало конфликта.
Похоже на личный негативный опыт. То что вы описываете — это конечно же неправильно. Собственно этот вопрос и хотелось поднять. Что часто могут быть поступки и решения, которые вызывают негатив, а идут из-за непонимания.
Какие ещё правила? scrum, это методология для тех уровней, которые не имеют отношения к разработке.
То есть, это уровень управления. Это доказывает даже тот факт, что повысить уровень продуктивности работы команды пытаются с помощью посвящения в идеологию scrum. Для программиста это и есть культ, о котором Вы говорите не реже, чем посылаете на конференции.
Программист, это ребенок, который живет в футуристическом мире созданным им самим на основе книг, игр и кино. Накой ему Ваш scrum? Ежедневно программисту нужно только комфортное рабочее место, столько еды, сколько ему нужно чтобы не возникло повода задуматься о голоде и интересные темы не относящиеся к рутине трудовых будней, с помощью которых можно развеяться. Только так можно поддерживать хрупкое чувство комфорта, отсутствие которого просто как бур в голове мешает сконцентрироваться на задаче.
Об этом нет ни слова, зато есть постоянные встречи и упоминание о правилах. Такое ощущение, что речь идет не о it компании, а о галере, на которой даже отхлыстать кнутом могут. К галере можно ещё отнести треш-компании, которые занимаются разработкой дешевых приложений и в которых очень важен именно тем, а о рабочих думают в последнюю очередь.
Все крутые it-лэйблы в самом начале ставили интересы своих сотрудников, чуть ли не выше всего. Им давали доли, проценты, возможность самореализации. Это мотивация. А все остальное это галера, где главное выжить как можно соков до того, как кто-то остынет.
И ещё раз — scrum это методология управления, что доказывает даже Ваши статьи, в которых упор сделан только на управление. Но it это прежде всего программисты. Вот у слесарей главный прораб, а у it — программисты. Если какая-либо методология это не понимает, то у нее нет будущего.
То есть, это уровень управления. Это доказывает даже тот факт, что повысить уровень продуктивности работы команды пытаются с помощью посвящения в идеологию scrum. Для программиста это и есть культ, о котором Вы говорите не реже, чем посылаете на конференции.
Программист, это ребенок, который живет в футуристическом мире созданным им самим на основе книг, игр и кино. Накой ему Ваш scrum? Ежедневно программисту нужно только комфортное рабочее место, столько еды, сколько ему нужно чтобы не возникло повода задуматься о голоде и интересные темы не относящиеся к рутине трудовых будней, с помощью которых можно развеяться. Только так можно поддерживать хрупкое чувство комфорта, отсутствие которого просто как бур в голове мешает сконцентрироваться на задаче.
Об этом нет ни слова, зато есть постоянные встречи и упоминание о правилах. Такое ощущение, что речь идет не о it компании, а о галере, на которой даже отхлыстать кнутом могут. К галере можно ещё отнести треш-компании, которые занимаются разработкой дешевых приложений и в которых очень важен именно тем, а о рабочих думают в последнюю очередь.
Все крутые it-лэйблы в самом начале ставили интересы своих сотрудников, чуть ли не выше всего. Им давали доли, проценты, возможность самореализации. Это мотивация. А все остальное это галера, где главное выжить как можно соков до того, как кто-то остынет.
И ещё раз — scrum это методология управления, что доказывает даже Ваши статьи, в которых упор сделан только на управление. Но it это прежде всего программисты. Вот у слесарей главный прораб, а у it — программисты. Если какая-либо методология это не понимает, то у нее нет будущего.
с точки зрения компании сотрудник должен быть управляем. scrum это фреймворк для управления. в случае программистов он зарекомендовал себя эффективным.
программист, приученный к scrum, это как ребенок приученный к горшку. в современных условиях это база.
«it это прежде всего программисты». это миф времен коммунизма (колхоз это колхозники, завод это рабочие и т.п.). при капитализме все не так. можете легко проверить, подняв в очередной раз вопрос о своей зарплате.
программист, приученный к scrum, это как ребенок приученный к горшку. в современных условиях это база.
«it это прежде всего программисты». это миф времен коммунизма (колхоз это колхозники, завод это рабочие и т.п.). при капитализме все не так. можете легко проверить, подняв в очередной раз вопрос о своей зарплате.
Какие ещё правила? scrum, это методология для тех уровней, которые не имеют отношения к разработке.
В первоисточнике немного не так: Scrum is a framework for developing, delivering, and sustaining complex products.
Возможно у нас терминологическая путаница. В моем понимании «разработка» — это общее понятие, по сути от идеи до появления продукта на рынке (т.е. включает в себя анализ, ui/ux, написание кода, тестирование, интеграцию и т.д.). И вот scrum как раз про организацию процесса этой самой разработки.
Это доказывает даже тот факт, что повысить уровень продуктивности работы команды пытаются с помощью посвящения в идеологию scrum.
Это действительно дико, если решают задачу «повысить уровень продуктивности команды» при помощи «посвящения в идеологию». Я уже несколько раз писал, что первое что нужно сделать — это понять для чего нужен scrum? Какая стоит перед ним задача? Это всегда очень индивидуально — нет серебряной пули. Часто scrum внедряют не там, или не для того. Вот отличная статья когда не надо. Например, scrum можно внедрять, чтобы повысить прозрачность: когда бизнес не понимает что там происходит в it департаменте, но очень хочет понять.
культ, о котором Вы говорите не реже, чем посылаете на конференции.
Классный и справедливый подкол! Да, действительно, я постоянно советую scrum master-у учиться. Это очень коррелирует с вашей мыслью, что программисты любят технологии и любят пробовать новое. Без этого ты можешь остаться за бортом профессии. Точно также scrum master должен постоянно учиться и развиваться. Возможно в этом есть одна из бед scrum, что еще нет культуры непрерывного обучения SM.
Программист, это ребенок, который живет в футуристическом мире созданным им самим на основе книг, игр и кино. Накой ему Ваш scrum? Ежедневно программисту нужно только комфортное рабочее место, столько еды, сколько ему нужно чтобы не возникло повода задуматься о голоде и интересные темы не относящиеся к рутине трудовых будней, с помощью которых можно развеяться. Только так можно поддерживать хрупкое чувство комфорта, отсутствие которого просто как бур в голове мешает сконцентрироваться на задаче.
Мне кажется, программисты все-таки сложнее. ИМХО так себе представляют программиста некоторые HR, поэтому часто в описаниях вакансий «печеньки в офисе» представляются как великое благо (на эту тему тоже есть статьи на хабре). Мне кажется, что программист, как и любой человек хочет заниматься чем то важным, делать мир лучше, приносить реальную пользу. Когда ты пишешь код по ТЗ из Jira, то нужна хорошая фантазия, чтобы ощущать силу влияния на мир своей работой. Часто получая ТЗ программист думает: «Ну что за ...? Люди, что вы делаете? Остановитесь!». Scrum помогает такому прекрасному порыву. В scrum программист и конечный пользователь очень сильно приближаются друг к другу (между ними лишь PO). Программист может понять, что хочет пользователь. Он может придумать, как это сделать. Сделать, отдать пользователю и получить обратную связь. И это очень ценно. Ты понимаешь что, для чего и для кого ты делаешь. И ты быстро понимаешь насколько хорошо ты это делаешь. В scrum программист может максимально раскрыться, ведь над ним нет менеджера, который говорит ему «что делать».
Об этом нет ни слова, зато есть постоянные встречи и упоминание о правилах. Такое ощущение, что речь идет не о it компании, а о галере, на которой даже отхлыстать кнутом могут.
Очень жаль, что у вас такое ощущение от прочтения, я хотел противоположного. Не могли бы вы подробнее раскрыть эту мысль с цитатами. Чтобы я мог провести работу над ошибками.
Все крутые it-лэйблы в самом начале ставили интересы своих сотрудников, чуть ли не выше всего. Им давали доли, проценты, возможность самореализации. Это мотивация. А все остальное это галера, где главное выжить как можно соков до того, как кто-то остынет.
Недавно на хабре появилась статья, где разбираются реалии нашего рынка. К сожалению, опционы пока больше приняты на западе. Хочется верить в улучшение ситуации. Но scrum немножко в другой плоскости от опционов.
Возможно у нас терминологическая путаница. В моем понимании «разработка» — это общее понятие, по сути от идеи до появления продукта на рынке (т.е. включает в себя анализ, ui/ux, написание кода, тестирование, интеграцию и т.д.). И вот scrum как раз про организацию процесса этой самой разработки.
Программисты чаще воспринимают разработку с точки зрения инженерных практик, технологий и операций, выстроенных в определенную последовательность (технологический процесс). Scrum абстрагирует все это до той степени, что снаружи остается видна лишь аккуратная очередь задач, управлять которой может кто угодно.
В обратную сторону такой трюк автоматом не работает. Максимум, что дает scrum при выстраивании технологического процесса это то, что в результате процесс будет иметь достаточно «ручек» для управления в таком стиле. Основная же часть работы — обычная инженерия и менеджмент. При этом маркетинг от scrum стремиться присваивать вообще все достижения себе. Думаю это одна из причин, почему его недолюбливают.
аккуратная очередь задач, управлять которой может кто угодно.
Вообще высяснение состава и очередности задач это по-моему весьма важно и тут легко ошибиться.
"XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work."
При этом маркетинг от scrum стремиться присваивать вообще все достижения себе. Думаю это одна из причин, почему его недолюбливают.
Вы можете поделиться своим опытом? Вы рассказываете жуткие вещи.
Вроде как при scrum на sprint review команда разработки встречается со стейкхолдерами, где они смотрят инкремент и дают обратную связь. Откуда у вас маркетинг? Как и чьи достижения они забирают?
вы хотите сказать, что идея встречаться со стейкхолдерами где они смотрят инкремент и дают обратную связь это чисто заслуга Scrum?
из своего опыта, мы регулярно встречаемся и у нас не scrum.
из своего опыта, мы регулярно встречаемся и у нас не scrum.
Demetrikl подумал, что идет речь про ваш собственный маркетинг.
Вы говорите про «Маркетинг SCRUM». Мне интересно, где вы слышали, чтобы они присваивали все заслуги себе? Вы можете подтвердить это цитатой? Они вроде ничего такого не говорят. Возможно, они не упоминают разные другие практики откуда что взяли и скомпоновали в свой фреймворк, но это вроде не делает никакой другой маркетинг.
Вы говорите про «Маркетинг SCRUM». Мне интересно, где вы слышали, чтобы они присваивали все заслуги себе? Вы можете подтвердить это цитатой? Они вроде ничего такого не говорят. Возможно, они не упоминают разные другие практики откуда что взяли и скомпоновали в свой фреймворк, но это вроде не делает никакой другой маркетинг.
Demetrikl подумал, что идет речь про ваш собственный маркетинг.ApeCoder несколько раз прочитал ваше сообщение. Но так и не понял вашего вопроса ко мне. Не могли бы вы перефразировать?
Вы говорите про «Маркетинг SCRUM». Мне интересно, где вы слышали, чтобы они присваивали все заслуги себе? Вы можете подтвердить это цитатой? Они вроде ничего такого не говорят. Возможно, они не упоминают разные другие практики откуда что взяли и скомпоновали в свой фреймворк, но это вроде не делает никакой другой маркетинг.
Вы говорите про «Маркетинг SCRUM».Про маркетинг первый заговорил funca, я пытаюсь выяснить ситуацию где он сталкивался с таким коварным маркетингом, который:
При этом маркетинг от scrum стремиться присваивать вообще все достижения себе.
Тут нет никакого вопроса к вам только упоминание. Это вопрос к funca — рассказать где он видел «маркетинг скрам» и привести по возможности цитату, подтверждающую его тезис
ApeCoder Я посидел, подумал, понял.
Если funca действительно говорит о «продавцах Scrum, которые всю славу у команд забирают», то я подписываюсь под вопросами. Я не видел таких адептов scrum, которые бы говорили, что «если бы не scrum, то никуда бы ваша команда не побежала.» В agile: «Individuals and interactions over processes and tools»
Правда хочется увидеть пруфы того, что заслуги команд приписываются инструменту.
Если funca действительно говорит о «продавцах Scrum, которые всю славу у команд забирают», то я подписываюсь под вопросами. Я не видел таких адептов scrum, которые бы говорили, что «если бы не scrum, то никуда бы ваша команда не побежала.» В agile: «Individuals and interactions over processes and tools»
Правда хочется увидеть пруфы того, что заслуги команд приписываются инструменту.
вы хотите сказать, что идея встречаться со стейкхолдерами где они смотрят инкремент и дают обратную связь это чисто заслуга Scrum?
Я хочу сказать обратное. Если в конце спринта команда не проводит sprint review и не получает от стейкхолдеров обратную связь, то это не скрам. И отсюда мой вопрос к вам: Как при таких условиях маркетинг может забирать чужие достижения?
Практика регулярно встречаться со стейкхоледрами прекрасна при любом подходе. Вы молодцы, что так делаете.
Я не говорю что scrum, это ерунда. Это методология, которая реально поможет новичкам сразу встать на правильный путь, в вопросах управления разработкой. Но именно эта часть у Вас изобилует ну очень спорными утверждениями. Было бы круто увидеть ту статью, которую Вы не планировали, но которая была бы последний и исчерпывающе описывала то, что должны делать те или иные роли. Она была бы более полезна, чем эти, которые очень похожи на запугивание, с целью посещения конференций.
Что должны делать роли описывает scrum guide (официальный перевод)
Но часто непонятно «как» это делать. Мне кажется, что единого и подходящего всем «как» нет. Всегда есть разные особенности у организации и команды, плюс, что более важно, разные задачи ставят перед scrum.
Но вот ошибки на моей практике часто повторяются, поэтому я и стал писывать через эту призму.
Но часто непонятно «как» это делать. Мне кажется, что единого и подходящего всем «как» нет. Всегда есть разные особенности у организации и команды, плюс, что более важно, разные задачи ставят перед scrum.
Но вот ошибки на моей практике часто повторяются, поэтому я и стал писывать через эту призму.
Пункт про то, что SM не разделяет ценностей Agile достоин более подробного описания, в моей практике это была самая частая проблема.
Например, SM не понимает, что agile — это про то, чтобы почаще показывать то, что команда наваяла — тем, кто будет наваянным пользоваться. Или же он не понимает, что требования к продукту меняются и уточняются по ходу разработки продукта — и это нормально и ожидаемо.
Scrum это фреймворк. Поэтому конкретные процессы свободно подгоняются под заданные условия. Он хоть и появился рядом с Agile, но вполне может использоваться и сам по себе, в отрыве от этих ценностей. Например, Scrum органично вписывается как практика для цикла разработки в DSDM, хотя «снаружи» там голимый водопад и ни каких пользователей даже близко не видно.
Scrum это фреймворк
Это правда, scrum можно просто использовать как тактический инструмент в разработки. И часто scrum без agile отлично решает поставленные перед ним задачи.
Просто мой тезис в том, что когда scrum и agile идут за руку, то такая команда может давать лучшие результаты.
как вы определяете критерии и возможный предел для этих улучшений?
Предела конечно же нет, мир изменчив, и желание адаптироваться под изменения открывает команде новые горизонты для улучшений.
Опять же нет чего-то универсального, критерии определяются задачей. Важно сравнивать команду саму с собой, следить за динамикой.
Критерием и метриками можно брать, например, TTM или размер тех.долга (который может посчитать в Sonar)
Но важно чтобы эти показатели:
как вы определяете критерии для улучшений?
Опять же нет чего-то универсального, критерии определяются задачей. Важно сравнивать команду саму с собой, следить за динамикой.
Критерием и метриками можно брать, например, TTM или размер тех.долга (который может посчитать в Sonar)
Но важно чтобы эти показатели:
- Были бизнес ориентированы, т.е. они были как разработке, так и бизнесу. Критерий — как коммуникационный мост для большего взаимопонимания.
- Имели чисто информационный характер. Нельзя завязывать мотивацию на такие показатели (Потому что правда будет скрываться от бизнеса, а команда будет работать на показатель в ущерб остальному. В проигрыше все.)
- Были прозрачными для всех, т.е. все понимали о чем речь, зачем это нужно и как данные собираются и анализируются.
Да это правда проблема. Но не знаю куда подробнее. Agile невозможно насильственно привить. Понимание появляется через обучение. Можно попытаться объяснить и научить. И очень легко в работе понять, разделяет человек эти ценности или нет (поступки нагляднее слов). По-моему мнению, нужно просто дать человеку выбор (Морфиус, Нео, все дела), но предварительно объяснив, что такое agile. Agile — это же не серебряная пуля, более того он не всегда полезен.
Надо бы как-нибудь прийти на конференцию по разработке ПО с докладом, где пятнадцать минут подряд талдычить им принцип Agile: «Show your shit to your users! Show your shit to your users! Show your shit to your users!»
Термин Agile, как «гибкие методологии», появилось в противовес существующей на тот момент практике использовать «жёсткие» процессы, проходить по всем этапам, создавать все документы, модели, артефакты, не допускать их отсутствия в любом проекте, выполнять все ритуалы. Сказано, что должно быть ТЗ — значит сделай, даже если разработчиком являешься ты сам. Сказано, что работы надо планировать на квартал вперёд — значит план должен быть, хотя и вы и ваш начальник понимают, что через пару недель ситуация изменится и придется заниматься совсем другим.
Отцы-основатели сказали — давайте будем делать только то, что помогает проекту. Если не помогает — не делать. И назвали это Agile.
А теперь Scrum в том виде, как его внедряют — это такой же «жёсткий» процесс, каким раньше был Waterflow. Ритуальные действия, без осознания, нужны они или нет в этом конкретном проекте, и без возможности их поменять. Поздравляю, Scrum, ты убил гибкость в Agile.
Отцы-основатели сказали — давайте будем делать только то, что помогает проекту. Если не помогает — не делать. И назвали это Agile.
А теперь Scrum в том виде, как его внедряют — это такой же «жёсткий» процесс, каким раньше был Waterflow. Ритуальные действия, без осознания, нужны они или нет в этом конкретном проекте, и без возможности их поменять. Поздравляю, Scrum, ты убил гибкость в Agile.
Так то отцы-основатели waterfall тоже не совсем то имели ввиду, что получилось.
Вот классный, ставший классикой, ролик про это vimeo.com/18951935
Плохо когда scrum без agile — именно эту мысль хотел донести этой статьей.
Вот классный, ставший классикой, ролик про это vimeo.com/18951935
Плохо когда scrum без agile — именно эту мысль хотел донести этой статьей.
Sign up to leave a comment.
Лечение «механического» Scrum. Часть 3. Работа SM