Моя команда состоит из 4 человек
Обзор:
Агентство, в котором я работаю, состоит из 7 отделов. Мое подразделение (службы данных) отвечает за сбор данных, ввод данных, новую разработку и обслуживание существующих веб-приложений (всего 5 сайтов, включая Salesforce для 70 пользователей). В настоящее время я единственный, кто разрабатывает, поддерживает и администрирует все сайты, включая Salesforce. Я также несу ответственность за всех своих сотрудников и могу собрать любую команду, которая мне нужна, но с ресурсами только для найма 3 сотрудников.
Почему я хочу использовать Scrum:
Я хочу собрать Scrum-команду, потому что наши проекты часто и случайным образом меняются из-за политики. Итак, при традиционном управлении я обнаружил, что начинаю заново и трачу много времени на переписывание требований только для того, чтобы изменить их в середине разработки.
Моя проблема:
Могу ли я успешно создать команду Scrum, используя перечисленные выше ресурсы? Причина, по которой я беспокоюсь, заключается в том, что я совмещаю роль Scrum Master, а также разработку Salesforce, разработку .NET и управление своим персоналом. Конечно, у меня будет младший разработчик и помощник администратора Salesforce, и мне потребуется некоторое время, чтобы научить их работать.
Подводя итог, возможно ли это без ущерба для концептуального контроля? Что я подразумеваю под этим; с типами ресурсов и невыделенным мастером Scrum (поскольку у меня также есть несколько других ролей), есть ли у меня высокий риск неудачи, приближающейся к использованию Scrum?
В вашей ситуации я бы настоятельно рекомендовал нанять разработчиков, которые уже работали в среде Scrum, чтобы им не требовалось от вас столько коучинга. Они не обязательно должны быть CSM или кем-то еще, но они должны понимать структуру и работать с командой, которая использовала ее раньше. Чем меньше вам приходится держать их за руки в процессе, тем лучше. Для интервью я бы просто попросил их рассказать вам о некоторых плюсах и минусах схватки или гибкой разработки, свидетелями которых они стали. Вы должны быть в состоянии сказать в течение минуты или двух, есть ли у них опыт, а также получить представление о том, насколько хорошо они будут работать с системой.
Кроме того, будьте осторожны, чтобы схватка не ограничивала вас. В небольшой команде вы можете обнаружить, что скрам для вашей команды является излишним. Например, вы можете увидеть конкретную продолжительность, указанную для определения времени ваших совещаний. В то время как команде из 12 человек вполне может потребоваться 4 часа на планирование двухнедельного спринта, вы можете обнаружить, что ваша команда из 4 человек может спланировать 2 недели за час. Всегда помните, что нужно делать то, что имеет смысл для вашей команды/проекта, и использовать ретроспективы для облегчения этого.
Размер/состав вашей команды в порядке. Я лично использовал scrum в проектах, где я был единственным членом команды. Я также работал над проектами, где я был членом команды, скрам-мастером и владельцем продукта. Это ни в коем случае не идеально, но иногда ограничения реального мира не оставляют вам другого выбора. Хотя это может сработать. Важно всегда следить за тем, чтобы команда знала, какую роль вы играете в любой момент времени. Вы должны заверить их, что, когда вы работаете в команде, ваш статус их босса не играет роли. Вам будет трудно создать самоуправляемую команду, если вы этого не сделаете, потому что они всегда будут смотреть на вас как на своего босса, чтобы отдавать им приказы, и это просто займет больше вашего и без того ограниченного времени.
Успех Скрам-команды во многом зависит от Владельца Продукта и его работы. Если она не сможет собрать хороший и полезный бэклог продукта, не имеет значения, насколько хороша скрам-команда, она потерпит неудачу. Если у вас еще нет владельца продукта, найдите его. Имейте в виду, что Владелец Продукта не является членом Scrum-команды и не может быть таковым, потому что ему необходимо обновлять и проверять отставание, что на самом деле не позволяет тратить время на разработку.
Следующей ключевой фигурой является Скрам-мастер. Ваша команда довольно мала, и есть хороший шанс, что вы сможете добиться прогресса с выделенным Scrum-мастером, но важно сэкономить время, чтобы узнать о Scrum и часто обсуждать внутри этой команды, как правильно использовать Scrum. Это должно быть исследование + презентация + беседа в виде обсуждения.
Я читал, что проект часто меняется. Как часто? Потому что, если он меняется еженедельно, у вас могут возникнуть проблемы со Scrum. В этом случае традиционная двухнедельная итерация может оказаться слишком длинной. В любом случае, Scrum — это хорошее начало, если у вас есть выделенный владелец продукта и список невыполненных работ, но я бы не упускал из виду последние события, связанные с движением непрерывного развертывания.
мир Криса
четырекв