Допустимо ли и возможно ли совместить фиксированные неизменяемые сроки в Scrum?
Я думаю, это просто сбивает меня с толку, потому что я думал, что один из основных принципов управления проектами заключается в том, чтобы помочь определить реалистичные оценки даты завершения на основе ограниченной информации. Есть ли ветвь управления проектами, в частности Agile или Scrum Project Management, которая касается противоположного, начиная с даты завершения и работая в обратном направлении, чтобы придумать творческие способы вписать все?
Я пытаюсь понять методологию и стратегию управления проектами в моей нынешней компании. Это крупное финансовое учреждение, в котором в любой момент времени реализуются сотни проектов. Существует большой офис управления программами, который собирает информацию о состоянии многих различных текущих рабочих потоков для передачи информации о состоянии вплоть до исполнительного уровня. Менеджеры проектов поддерживают планы проектов и координируют информацию о статусе проекта от ресурсов проекта до менеджеров программ.
Странная вещь, которую я не могу понять, заключается в том, что, когда проект находится в зачаточном состоянии, нет реальных технических усилий для определения оценок усилий или времени на этапах проекта. На данном этапе это кажется совершенно неважным, потому что крайние сроки каждого проекта устанавливаются ИТ-руководителями или LOB незаметно.
После того, как нам говорят, какая будет дата, нам говорят провести формальную оценку усилий (очков истории), а не времени, потому что у организации есть исполнительный мандат на Agile и Scrum. Странно то, что после того, как мы определили все размеры эпиков и футболок, руководитель проекта все еще должен выяснить, как уложить все это в заранее установленный срок. Для этого мы разделяем и проводим детальную оценку сюжетных баллов одного эпика, обычно небольшого размера, затем общее количество сюжетных баллов этого используется для сравнения, чтобы определить общее предполагаемое количество сюжетных баллов. Оттуда менеджер проекта определяет скорость и доказывает, достижимы ли все этапы проекта к установленному сроку.
Концепция минимально жизнеспособного продукта не существует. PM должен показать, сколько людей нужно для того, чтобы этот крайний срок был возможен, и если это слишком дорого, проект может быть отменен еще до его начала.
Дело в том, что за последние несколько лет почти каждый проект можно было считать провальным, потому что они практически никогда не укладывались в эти сроки. Чего я не понимаю, так это того, что, несмотря на неудачу за неудачей, ничего существенного не меняется. Не похоже, чтобы опоздание с проектом действительно имело значение в долгосрочной перспективе. Когда проект затягивается, количество совещаний по статусу увеличивается, и общая тревога, кажется, возрастает, но почти все продолжают работать на опережение, как обычно.
Другие люди, которые долгое время работают в компании, говорили мне, что на самом деле у них два свидания. Формальный крайний срок, указанный на бумаге, и фактически ожидаемая руководителями дата, когда проект будет реализован в действительности. Когда я спросил, почему бы просто не воплотить дедлайн в реальность, они почти все согласились с тем, что высшее руководство считает, что, когда проекты задерживаются на бумаге, люди «работают усерднее».
Я не вижу, чтобы это работало по ряду причин. Ветераны в компании не чувствуют давления, потому что считают, что ими пытаются манипулировать, заставляя работать усерднее. Новые люди деморализуются и перестают пытаться. Все проводят больше времени на статусных совещаниях с озабоченными менеджерами программ, чем на работе над проектом, и, наконец, характер работы больше основан на знаниях и управлении внешними зависимостями, чем на жесткой основной работе с рядами людей, яростно печатающих на клавиатуре до 2 часов ночи. Почти все работают на 40 и идут домой, несмотря на давление, потому что частое засиживание допоздна не приведет к тому, что настоящие препятствия будут устранены раньше.
Допустимо ли и возможно ли совместить фиксированные неизменяемые сроки в Scrum?
Да. Мы сделали проект, связанный с Олимпиадой, используя Scrum. Естественно, срок установлен незыблемый. В этом нет ничего плохого. Мы смогли скорректировать масштаб так, чтобы мы уложились в то, что можно было бы сделать, чтобы запустить игру вовремя к церемонии открытия. В вашем случае ваши менеджеры проектов также обладают гибкостью в подборе ресурсов. Вы можете увидеть презентацию Майка Кона о применении Agile к «проектам с фиксированной датой, фиксированной областью и фиксированным всем» .
затем нам говорят провести формальную оценку усилий (очков истории), а не времени, потому что у организации есть исполнительный мандат на использование Agile и Scrum.
Правильным подходом является оценка в стори-поинтах. Если вам нужен хороший справочник, прочтите статью Джеффа Сазерленда « Очки истории: почему они лучше, чем часы?».
мы разделяем и делаем подробную оценку сюжетных баллов для одного эпика, обычно небольшого размера, затем общее количество сюжетных баллов этого используется для сравнения, чтобы определить общее предполагаемое количество сюжетных баллов.
Это не является чем-то необычным на данном этапе проекта. По мере продвижения проекта все (команда разработчиков и владелец продукта) узнают больше о проекте. И Владелец Продукта может соответствующим образом корректировать приоритет.
PM должен показать, сколько людей нужно для того, чтобы этот крайний срок был возможен, и если это слишком дорого, проект может быть отменен еще до его начала.
Это правильный деловой подход. Если окупаемости инвестиций (ROI) нет, то зачем делать проект?
Оттуда руководитель проекта определяет скорость
Если менеджер проекта оценивает скорость эмпирически (на основе фактической скорости, достигнутой командой за 3 или более спринтов), то это нормально. В противном случае это может быть далеко.
Кроме того, вы увлеклись множеством предположений, не раскрывая важной информации, которая может помочь нам лучше понять ваш процесс:
Agile поддерживает концепцию фиксированных сроков. Вы расставляете приоритеты в своем отставании и продвигаетесь как можно дальше вниз по списку к тому времени, когда истечет крайний срок.
Чего вы не можете сделать, так это исправить и время, и масштаб.
Теоретически вы можете варьировать ресурсы и сохранять время и объем фиксированными. Однако это игнорирует сложность наращивания ресурсов. Как известно, закон Брукса гласит: «Добавление рабочей силы к позднему программному проекту делает его более поздним». Таким образом, чтобы зафиксировать время и масштаб и просто изменить ресурсы, вы должны быть в состоянии заранее предсказать любые возможные задержки.
Вы также можете возразить, что время и объем можно исправить, если вы вложите в проект огромное количество ресурсов. Но даже это может потерпеть неудачу, так как производительность потенциально может уменьшиться по мере увеличения числа людей в проекте, и коммуникация становится проблемой (проблема n+1).
Идея установления крайних сроков, чтобы заставить людей «работать усерднее», была в значительной степени опровергнута в отраслях, основанных на информации. Проблема в том, что существует множество различных способов решения любой проблемы кодирования, и самые быстрые решения часто оказываются худшими с точки зрения качества и возможности расширения в будущем.
Возможно, лучшим подходом в этой организации было бы предложить им запустить небольшой пробный проект, следуя принципам Agile, а не их текущему подходу. Согласуйте некоторые показатели, которые будут измерять успех проекта, до его начала. Иногда достаточно просто продемонстрировать успех, чтобы завоевать их расположение.
Добавляя к этому, я оченьрекомендуем отслеживать объемы и источники «срочной работы» (все, что не входило в первоначальный расчет невыполненной работы по сравнению с расчетом скорости) по мере продвижения и постоянно учитывать это при планировании или прогнозируемом объеме. Под этим я подразумеваю баллы за «неизвестные неизвестные» или новые элементы невыполненной работы, которые появляются в каждом спринте, баллы за обратную связь, баллы за повороты из-за пользовательского тестирования, баллы за стандартные «упсы, которые оказались больше, чем мы думали». По моему опыту, это, безусловно, самая большая отдельная область, которая упускается из виду и ставит команды в невыгодное положение с руководством, когда приходит время достичь их первоначальной оценки масштаба. Многие аджилисты скажут, что если вы измеряете скорость, когда происходят такие вещи, она просто «выйдет из-под контроля», но это не так.
Ты не одинок. Многие компании называют себя agile, но на самом деле таковыми являются лишь немногие. Что звучит странно, так это то, что ваша компания требует универсальных историй, которые применимы ко всем. Story Points — это релевантная метрика, полезная, когда команда имеет некоторую историю и знает свою скорость. В противном случае очки истории — это просто случайные числа. Я работал в компании, похожей на вашу, и пытался рассказать им о SCRUM. Через пару месяцев разочарований я сдался и уволился. Иногда корпоративное мышление или мышление «мы всегда так делали» неизменны.
Скливвз