Превращает ли Scrum активных разработчиков в пассивных разработчиков?

103

Я веб-разработчик, работающий в команде из трех разработчиков и одного дизайнера. Сейчас около пяти месяцев мы внедрили методологию разработки программного обеспечения Agile Scrum. Но у меня странное чувство, которым я просто хотел поделиться на этом сайте.

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

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

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

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

  1. Я склонен искать меньше, чтобы найти лучшее решение, подход или технику
  2. Я не просыпаюсь утром в ожидании приятной работы. Скорее, я чувствую себя вынужденным работать, чтобы жить
  3. У меня больше голода работать над своими хобби-проектами после работы
  4. Я больше не буду подталкивать команду, чтобы перейти на более высокий технологический уровень
  5. Теперь я провожу больше времени на ужине или чаепитии и меньше энтузиазма, чтобы вернуться к работе
  6. Теперь я хочу больше, чтобы работа закончилась раньше, чтобы я мог вернуться домой

Большая проблема в том, что я вижу и диагностирую такое поведение и у моих коллег. Это результат схватки? Действительно ли scrum заставляет команду разработчиков чувствовать, что они не участвуют в формировании всего программного обеспечения, таким образом делая пассив для проекта? Как я могу преодолеть это чувство?

Saeed Neamati
источник
4
Вы уверены, что раньше вы просто не ввели себя в негодность?
Donal Fellows
27
Хороший пост в блоге.
Роберт С.
20
то, что вы описываете, не SCRUM
4
@Чад. То, что я обсуждал здесь, не является жалобой на мою рабочую ситуацию. Мне просто интересно, если это настроение является результатом схватки? И другие разработчики тоже испытывают то же самое или нет?
Саид Нимати
5
@Saeed - Извините за грубость, но ваше настроение является результатом вашего решения о том, как справиться с вашей рабочей средой. На это могут повлиять и другие мнения и взгляды, но вы также можете принять этот метод. Это освобождает вас от необходимости нести ответственность за проектные решения и позволяет вам просто работать над решением конкретных проблем. Это не истощает всю вашу энергию и позволяет вам работать над большим количеством ваших домашних проектов. У вас есть больше времени, чтобы развить вас. Это не плохие вещи. Это не ваша работа работодателей, чтобы сделать вас счастливыми. Вы можете найти другую работу или вы можете принять это.
SoylentGray

Ответы:

51

Однако теперь я чувствую, что мне всегда говорят что-то делать, вместо того, чтобы что-то делать.

Это серьезный показатель того, что что-то сошло с рельсов. Гибкий проект не должен чувствовать себя так. Риторика «люди над процессом» должна включать «мы не заставляем наших людей делать то, что отстой». Вот несколько идей:

Вы делаете "Scrum но"? То есть частично схватка, частично какая-то другая вещь. (т.е.: «Мы занимаемся скрамом, но все наши истории должны исходить от нашего PMO, а не от владельца продукта».) В наши дни множество сумасшедших дерьмов называется Scrum.

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

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

Шон Макмиллан
источник
10
+1 Scrum (как и все Agile методологии) будет тяжелее в разговоре, чем направление. ОП должен описывать, чего должен достичь конечный результат, а затем привлекать дизайнеров и разработчиков к способам их достижения.
StevenV
5
«люди над процессом»: Забавно, тогда зачем навязывать процесс SCRUM вместо того, чтобы позволять людям использовать свои собственные? И почему все эти меры (парное программирование, частые обзоры прогресса), которые во имя прозрачности, позволяют намного более тщательно контролировать работу разработчиков?
Джорджио
3
@ Джорджио: Потому что структурированная разработка позволяет командам работать вместе, не наступая друг другу на ноги. Мы просто еще не разобрались, как это сделать идеально.
Фоши
2
@ Giogio, это проблема с Agile в целом. Хотя цель состоит в том, чтобы люди руководствовались процессом, в действительности Agile становится религиозным последователем, что снова ставит процесс над людьми. Лично я считаю, что Lean лучше справляется с этой задачей, чем Agile, хотя он не пытается навязать строго горизонтальную структуру команды - он позволяет разработчикам лучше выбирать задачи. Предполагая, что ваша команда не изменится, доска канбан в дополнение к тому, что вы делаете сейчас, может сделать менеджмент счастливым, а также счастливым, предоставляя вам свободу выбора историй / задач.
JQwierdy
62

Ваша проблема не в Scrum (и, как Джаррод Роберсон упомянул в комментариях, это не Scrum, что вы описываете) - это микроуправление Владельца продукта и отсутствие уверенности в себе (и вашей команде) .

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

Вы ошибаетесь Просто из краткого обзора страницы Википедии для Scrum можно увидеть, что: «Команда, межфункциональная группа, которая занимается фактическим анализом, проектированием, внедрением, тестированием и т. Д.» Видеть? Владелец продукта говорит вам, что делать, но команда должна решить, как это сделать.

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

КСТАТИ микроуровне делает свою очередь активных разработчиков в пассивные разработчик.

Лукас Стейскал
источник
38
Аминь в этой последней строке
Вивани
6
«Владелец продукта говорит вам, что делать, но команда должна решить, как это сделать». Это именно то, что может быть проблемой для мотивации разработчиков: отсутствие инноваций. Большую часть времени клиент будет хотеть более быстрых лошадей, а не автомобилей. Но я абсолютно согласен с микроуправлением.
MaR
1
+1 @ Лукас, из-за разницы между тем, что и как . Спасибо, приятель.
Саид Нимати
5
«Владелец продукта говорит вам, что делать» - я не совсем согласен с этим. Они должны сказать вам, что им нужно . Небольшая, но важная разница. Другими словами: они описывают проблему / проблему, вы предлагаете решение.
DanMan
2
@MaR Вот почему разработчики не общаются с клиентами. Клиенты разговаривают с владельцем продукта и просят более быстрых лошадей, ПО - это то, что видит все проблемы клиентов, объединяет и расставляет их приоритеты, и в процессе выясняет, что машины лучше, чем более быстрые лошади
Изката
29

То, что вы описываете, НЕ СКРАМ

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

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

SCRUM - это сотрудничество, то есть то, для чего нужны встречи по планированию Sprint, чтобы способствовать сотрудничеству между всеми заинтересованными сторонами; владелец продукта, разработчики и тестирование.

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

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

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

Мне грустно слышать истории о том, что такие хорошие вещи извращаются, как это.

оборота user7519
источник
3
Человеческая натура всегда найдет способ вырвать поражение из челюстей победы.
Уоррен П
2
Есть то, чем должен быть SCRUM , и есть то, чем он заканчивается , по крайней мере, в большинстве компаний. SCRUM сам по себе не является злом, но это инструмент, который очень легко используется злом руководством.
AresAvatar
11

Я предполагаю, что до Scrum все просто делали то, что хотели: yippee ki-yay mf'er . Ваши пользователи являются вашими благотворителями, и они ведут историю и оплачивают счета. Владелец продукта гарантирует, что история закончена. Так или иначе, ваша группа пришла к выводу, что владелец продукта должен рассказывать вам, как программировать.

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

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

JeffO
источник
10

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

Agile - это не следование предписанному пути, а то, что оно делает вас более продуктивным и мотивированным. Люди, а не процессы, говорят манифест (перефразированный), и это теряется в используемой вами системе.

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

gbjbaanb
источник
6
меня? да - раньше мы хорошо работали, потом руководство решило, что будущее за Agile, и ввело разборки, которые нас сильно ограничили. То, что мы делали без усилий, увязло в процессе и бюрократии. Однажды я взял 3 карты с доски для игры! Вспыхнули огни, и сирены заговорили об этом нарушении «пути схватки», и я однажды отнес карточку обратно на стол . Менты управления проектами пришли за мной. И я обычно садился в ежедневных беспорядках, которые тоже не подходили. Все мелочи ИМХО, но были превращены в горы.
gbjbaanb
2
Не думаете ли вы, что в вашем случае это плохая нисходящая реализация Scrum, которая привела к потере производительности? Вы говорите, что "увязли в процессе и бюрократии", что странно, потому что Scrum - самая простая наименее бюрократическая методология в мире ... На самом деле вся структура Scrum помещается на одном листе или 2. Кстати, то, что вы называете "доской для Scrum" не является частью структуры. В случае с Саидом, хотя я и считаю, что проблема заключается в разрыве между типом организации, в которой он работал (с большой свободой и силой решения для разработчиков), и типом организации, к которой относится Scrum.
guillaume31
3
@ ian31: да, этот проект был особенно плохим, но Scrum обращается к таким менеджерам. Вы никогда не увидите, чтобы они выбрали Kanban или Crystal. Скрам слишком легко превращается в «схватку но», когда эти ребята овладевают ею. Жаль.
gbjbaanb
1
Я думаю, это весело, что любая компания превратит Scrum в религиозную церемонию. Привет! Стой во время этой церемонии, где мы притворяемся проворными! Привет! Улыбнитесь, пока мы притворяемся, что слушаем вас, а затем весело продолжаем делать то, что мы хотели сделать в любом случае!
Уоррен П
2
Я полностью не согласен с направлением этого ответа. Я думаю, что какой-то «мини-водопад» может быть очень полезным, особенно для неопытных, но умных разработчиков, которые могут делать 5 разных вещей одновременно и не заканчивать ни одну из них. Фактически, человек, который обучал меня в Scrum, сказал, что вы все еще можете делать «мини-водопады» в Scrum, если хотите, но в идеале они должны быть в течение нескольких дней или даже часов . Я думал, что часы слишком коротки. Вы не всегда можете разработать-> внедрить-> протестировать историю за несколько часов. И разделение историй так, чтобы вы могли не всегда оптимально.
Робин Грин
8

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

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

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

Jonno
источник
На 100% согласен. Теперь вы более согласны с владельцем продукта, но это означает, что у вас меньше свободы делать то, что вы считаете правильным. Я тоже это испытал, и это отстой и сделало мою работу намного менее приятной. Но это означало, что я намного лучше соответствовал целям бизнеса и менеджера по продукту. Бизнес оплачивает счета - включая мою зарплату - так что да, они могут сказать, что они хотят на уровне детализации. Я не думаю, что они на самом деле говорят вам, как кодировать. Если бы они знали, как они могли бы сделать это сами.
Майкл Даррант
Бизнес не платит разработчикам за то, что они хотят. Они платят разработчикам за повышение производительности, которое обеспечивает хорошая программная среда. Если вы позволите бизнесу сказать вам, что делать «на уровне детализации», действительно ли вы думаете, что они получат хорошую программную среду, которую ищут?
Андомар
@ Andomar - это баланс. У каждой стороны есть свои идеалы, предположения и недостатки. Игнорирование любого из них приводит к опасности.
Джонно
5

Получаете ли вы пользовательские истории в форме "Как - роль ... я хочу - цель / желание - чтобы это --benefit--"? Похоже, что ваш владелец продукта хочет сделать работу по дизайну, и он / она не может быть лучшим человеком, чтобы сделать это. Использование шаблона пользовательской истории может помочь гарантировать, что Владелец продукта придерживается интересов бизнеса, а разработка программного обеспечения осуществляется разработчиками программного обеспечения.

Майкл Манси
источник
4
Как разработчик, я больше никогда не хочу видеть такого рода пользовательскую историю, так что мне, возможно, никогда не придется внутренне стонать от ее бессмысленности.
Уоррен П
@WarrenP Да, шаблон может быть проблемой, независимо от того, идет ли он в форме кодового шаблона или требований к шаблону. Я думаю, что ключевой момент заключается в том, что все эти 3 элемента должны быть либо сформулированы, либо поняты, но, что более важно, всем должно быть ясно, что на самом деле требуется, и шаблонные требования на самом деле могут этому помешать. Особенно, если разработчики начинают думать, что достаточно добавить несколько коротких слов в этот шаблон.
Робин Грин
4

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

Из проворного манифеста:

Нашим главным приоритетом является удовлетворение потребностей клиентов путем своевременной и непрерывной поставки ценного программного обеспечения.

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

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

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

guillaume31
источник
3

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

Мисько
источник
3

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

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

И у нас иногда есть микроуправление, но это другая проблема.

Тим
источник
3

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

Q: Методология предписывает х, но х не работает хорошо. Что нам делать?

A: Уточните вашу реализацию x. Может быть, прекратить делать это вообще. Методология не главный из вас!

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

Ян Олсен
источник
2

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

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

temptar
источник
Нет @temptar, наши отношения действительно хорошие. Без обид, без ненависти, вообще ничего. Все хорошо, все, кроме того, что мы чувствуем к работе.
Саид Нимати
2

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

JB King
источник
2

У меня был такой же опыт со Scrum, и мне нравится называть это «тиранией истории».

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

Единственный выход, который я нашел до сих пор, состоял в том, чтобы либо отказаться от Scrum - часто это невозможно и / или нецелесообразно, потому что в конце концов у него есть свои преимущества, - или представить что-то вроде 20% времени Google, чтобы дать разработчикам творческий выход помимо «вы». Вы можете сами выбирать, как реализовать страницу входа в систему », потому что на самом деле вы не ограничены существующим кодом и архитектурой системы, если ваша реализация не предусматривает свободу выбора между циклом« a for »и« while » свобода.

Александр Баттисти
источник
1

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

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

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

Да, и по моему опыту это не имеет никакого отношения к Scrum / agile. Произошло разборки, итеративный, водопад, что угодно. Кажется, вопрос доверия не зависит от процесса

комара
источник
1

В нашей команде владелец продукта говорит нам, что делать, и мы решаем, как мы это делаем. Очень важно иметь это разделение, иначе вы окажетесь в описанной вами ситуации.

thegreendroid
источник
1

По моему опыту, Scrum должен внимательно следить за тобой, что ты делаешь. Это просто сидеть на вашем плече и смотреть, что вы делаете. Хотя у этого есть свое преимущество, я ненавижу методологию схватки. Ожидается количество, а не качество. Качество ставится под угрозу с методологией Scrum.

Анто
источник
«Качество подвергается риску с помощью методологии Scrum.»: Возможно, несколько экстремально говорить, что качество подвергается риску, но, да, управляемость проекта получает более высокий приоритет, чем качество.
Джорджио
Удивительно, как мало людей знают о схватках или проворстве, и тем не менее, как они публикуются, как авторитеты Создается впечатление, что человек работал в течение нескольких недель в неблагополучной группе, где они сказали, что они «занимаются скрамом» и пришли к выводу, что именно так и должно быть. В данном случае это абсолютно анонимный парень, у которого только один пост или комментарий за 4 года, и нет никаких доказательств экспертизы по этому вопросу. Вот почему мы не можем воспринимать многие из этих комментариев очень серьезно.
Кертис Рид