Можно ли иметь людей с несколькими ролями в команде Scrum?

Я оцениваю некоторые методики в стиле Agile для возможного введения в мою команду. Допустимо ли в Scrum один и тот же человек выполнять несколько ролей? У нас небольшая команда из четырех разработчиков и веб-дизайнер; у нас на самом деле нет лидера (я выполняю эту роль), тестировщиков качества или бизнес-аналитиков, и все наши задачи по разработке исходят от ИТ-директора. Автоматизированное тестирование рассматривается как пустая трата времени, и все фокусируется на скорости, а не на качестве.

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

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

Во-вторых, если это может сработать, не является ли для кого-то неразумным, скажем так, выступать в роли ScrumMaster и разработчика? Или для разработчика также быть владельцем продукта (хотя есть вероятность, что это будет ИТ-директор, который не является разработчиком)? Я понимаю, что Scrum Master и владелец продукта должны быть разными людьми, но в то же время я не думаю, что у нас есть кто-то, кто обладает качествами владельца продукта (скорее всего, это превратится в «Мне нужны все эти истории, я все равно, как, но сделай это "тип сделки и / или любое замораживание будет заморожено по прихоти).

Мне кажется, что мне, возможно, придется выбирать фрагменты Scrum / XP / Lean, чтобы компенсировать то, как все происходит в настоящее время, поскольку весьма маловероятно, что менталитет можно изменить; например, парное программирование никогда не сработает (рассматривается как пустая трата времени, вы наполовину выполняете задачи, если вам нужно два человека для всего), TDD будет трудно продать, но будут приветствоваться короткие циклы.

Scrum, Kanban или любая другая методология Agile - это, прежде всего, методология, ориентированная на проекты разработки программного обеспечения . Другими словами, это практика управления проектами по самой своей природе.

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

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

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

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

Это не должно работать так

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

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

Это не задание команды разработчиков программного обеспечения.

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

Как я уже отмечал здесь , если либо Scrum Master или владелец продукта имеет осуществимые задачи, они также являются членами команды.

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

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

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

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