Как (Agile) управлять довольно сложной ИТ PoC?

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

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

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

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

У вас также есть ретроспективная встреча. Вы используете это, чтобы улучшить свою работу. Важно ли это при создании PoC? Или вас интересует только PoC? Я не обязательно говорю, что вы должны идти в ковбойском стиле и стрелять от бедра, но вы действительно хотите много вкладывать в процесс? Будет ли этот PoC одноразовым после того, как вы подтвердите/аннулируете идею, или вы создадите настоящее приложение поверх него? Например, нужно ли вам определение «Готово»? Вы хотите, чтобы этот PoC считался успешным только в том случае, если каждая строка кода была проверена, или если у вас есть хороший охват модульных тестов? Да? Нет? Если PoC будет успешным, и позже вы сможете реализовать реальное приложение, вы можете сосредоточиться на своем процессе. С PoC типа «вынести вещь за дверь как можно быстрее» вы, вероятно, выиграете.

В Scrum также есть собрание по планированию спринта. Вы оцениваете, какую работу вы можете выполнить в следующем спринте. Вы ставите цель спринта. Вы создаете выпускаемый инкремент каждый спринт. Вы пытаетесь сохранить масштаб неизменным во время спринта. Имеет ли это смысл для работы, которую вы делаете? PoC — это минимально жизнеспособное решение. Меньше, и это не поможет вам подтвердить/опровергнуть ваши предположения. Еще немного, и это уже не просто PoC. Будут ли инкременты доступны для выпуска? Если вы обнаружите что-то, что полностью изменит ваш объем работы в спринте, что вы будете делать со спринтом? Отменить? Придерживаться цели спринта? Если вы планируете свой спринт и на следующий день понимаете, что вам нужно сделать что-то другое, вы просто тратите время на планирование, а вы могли бы поработать над реализацией PoC.

Вам нужно сделать доработку отставания? Формируется ли ваша PoC по мере того, как вы ее создаете, или вы уже определили минимум элементов, которые должны быть частью PoC? Некоторые новые вещи появятся, некоторые изменятся, некоторые больше не будут нужны, но произойдет ли это из-за того, что вы обнаружите во время внедрения, или это будет потому, что у вас есть «деловые причины» для добавления, изменения или удаления элементы из бэклога?

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

Я бы лично управлял этим с помощью Канбана.

Разместите все на доске, чтобы иметь представление о том, что вы делаете. Выполнение Канбана сделает всех более вовлеченными. Взаимодействие происходит чаще, а не в ритме спринта.

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

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

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

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

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

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

1. Исследуйте домен. Ознакомьтесь с терминологией, чтобы иметь возможность общаться с заинтересованными сторонами.
2. Найдите самые рискованные части требований и нарисуйте макеты/диаграммы.
3. Затем определите, какие макеты/диаграммы вы можете реализовать и каковы между ними зависимости.
4. Тогда просто сделайте это!

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