Я работаю менеджером отдела программного обеспечения в нашей небольшой компании (~50 человек). У меня три команды разработчиков, по 3-4 человека в каждой. Один из членов каждой команды выступает в роли лидера команды. Одна из команд в основном работает над одним проектом, и редко бывает, что им приходится помогать где-то еще. Две другие команды работают над 2-3 проектами (одинаково для обеих команд).
Мой предшественник не использовал скрам или что-то подобное, в основном он просто очень свободно распределял работу в ежедневном или еженедельном ритме. Конечно, это приводит к отсутствию каких-либо артефактов или процессов планирования/контроля проекта. Никто никогда не знал, что может произойти в следующий раз, и никто не мог предсказать, когда какое-либо задание будет выполнено. Вы можете себе представить, как работают проекты.
У меня будет задача двигаться дальше, и я решил начать внедрять скрам в команды. Конечно, я все еще очень не уверен в некоторых вещах, и мне нужен совет от людей, которые прошли такой же путь гораздо дальше.
Роли:
У нас есть индивидуальный проект с классическими менеджерами проектов и инженерами проектов. Поскольку они уже действуют как владельцы продукта, я думаю, что лучше всего было бы сохранить это. Вы согласны?
У нас также есть несколько стажеров, занимающихся исследованиями и разработками, например проекты по улучшению наших продуктов или инструментов разработки самостоятельно. Все люди могут предлагать или продвигать такие проекты. Обычно я справляюсь с ними от начала до конца. Я был бы в роли владельца продукта для них. Вы делаете то же самое?
Управление сотрудничеством и контроль различных команд. Это одна из основных вещей, за которые мне платит компания. Я думаю о реализации такой вещи, как схватки схваток между мной и лидерами команд. Я был бы здесь в роли скрам-мастера, который может или не может кусаться с ролью владельца продукта, описанной выше. Вы бы порекомендовали его мне?
Процедуры и артефакты:
я хочу начать медленно, убедившись, что все идут по нашему пути.
То, с чего я хочу начать, — это ведение журналов релизов и спринтов с записью пользовательских историй, планирование спринтов с разделением историй на задачи и ведением досок задач, а также ежедневные стендапы.
Если это сработает, я продолжу вводить оценки, диаграммы сжигания, измерение скорости разработки.
Впоследствии, возможно, измерение оптимистичных факторов индивидуальной оценки разработчиков для улучшения прогнозов завершения проекта.
Вы бы согласились на эту последовательность или сделали бы что-то еще?
Вещь, вызывающая у меня больше всего головной боли на данный момент, заключается в том, как сделать все это, одновременно работая над разными проектами внутри матричной организации.
Бэклог: Должен ли я иметь один, охватывающий все истории для всех проектов? Вероятно, это привело бы к сложному планированию спринта.
Или лучше один бэклог для каждого проекта? Но как мне тогда определить приоритеты между разными проектами? Например, история проекта 1 является наиболее важной, затем следует история 1+2+3 проекта 2, затем история 2 проекта 1 и так далее.
Столь же сложно, как и вышеизложенное, у меня есть воображение планирования спринта. Команды должны брать истории из бэклога. Но как им это сделать, если бэклогов будет несколько, а приоритеты будут зигзагами между ними?
Последние два пункта меня больше всего смущают, но мне придется решить их, прежде чем я смогу сделать хотя бы первый шаг.
Похоже, вы задаете правильные вопросы и мыслите разумно. Меня, как тренера, беспокоит несколько вещей:
Далее просто попробуйте ... это будет работать кое-как, но не идеально, и тогда вы сможете работать с командами, чтобы сделать его лучше. Вот почему ретроспектива так важна в Scrum.
Если после честного испытания и упорного труда в течение нескольких месяцев вы все еще не чувствуете, что он работает хорошо, вы можете попробовать попробовать канбан, который, кажется, работает лучше в средах, где много запросов поступает из разных направлений. .
Бютельфухс
Эрик Виллеке
Эрик Виллеке
Бютельфухс
Бютельфухс