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

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

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

Тем не менее, мне кажется, что нет способа подойти к этому требованию «гибким» способом. Гибкие требования означают, что оценки не только взятого времени будут неверными, но и оценки потенциального сэкономленного времени. Я объяснил так же, объяснил, почему это может быть проблематично, но мне сказали, что это не подлежит обсуждению.

Вопрос о том, как продавать Agile-разработку (водопадным) клиентам, дает несколько полезных советов о том, как «продавать» Agile-решения внешним клиентам. Я не пытаюсь продать его внешним клиентам: я пытаюсь понять, как лучше согласовать требования внутреннего управления, сохраняя при этом методологию, которая, на мой взгляд, работает хорошо.

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

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

Однако один из подходов, которые мне нравятся в Agile, заключается в том, что объем проекта не является фиксированным. Первоначально он может быть измерен на уровне Feature и Epic, а затем бизнес может определить ROI на основе наиболее важных функций. Может быть, причудливый пользовательский интерфейс с наворотами имеет низкую ценность для бизнеса, но механизм рабочих процессов для обработки претензий имеет высокую рентабельность инвестиций.

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

Вот способ, которым я сделал это:

Возьмите вехи WBS и превратите каждый из них в полезную функцию

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

Футболка Размер Усилие на Особенности

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

Разбить функцию на истории

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

Маленький -> 40 баллов

Это будет основой для сравнения с другими функциями

Свяжите исторические усилия со всеми функциями

Сравните вашу маленькую функцию с другими функциями. Например,

Средняя особенность Y чувствует, что она вдвое больше по размеру и усилию, чем маленькая особенность X из 40 сюжетных очков.

Средняя особенность Y, вероятно, 80 баллов. Продолжайте до тех пор, пока у вас не будут оценены исторические баллы на высоком уровне для всех функций.

Оцените скорость вашей команды

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

Исходя из того, какой объем работы, по мнению команды, они могут выполнить за 2 недели, используйте это общее количество баллов в качестве средней потенциальной скорости вашей команды!

Найдите вашу предполагаемую дату завершения

Если ваша команда в процессе планирования спринта чувствует себя комфортно, предоставляя 25 баллов за спринт, а общее отставание выглядит как 300 баллов за золотую версию вашего проекта Cadillac, то, похоже, вашей команде в идеале понадобится 12 спринтов или 24 недели на завершить все

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

Это не проблема с «менеджментом». Это абсолютное требование, чтобы иметь возможность оценить стоимость и выгоду любого потенциального проекта перед началом. Иначе как кто-то узнает, что стоит делать (или пытаться)?

Тогда почему Agile?

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

Некоторые ключевые моменты с точки зрения оценки времени:

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

Обновить:

Просто чтобы прояснить, ваш ответ вашим начальникам выглядит следующим образом: «Мы не можем оценить сэкономленное время или общее усилие по разработке с использованием Agile, потому что оно гибкое». Я думаю, что это ошибочно. Я полагаю, что эти оценки могут быть сделаны точно так же при использовании гибкого процесса, так как неопределенность все же существует. И, конечно, Agile обеспечивает более гибкий и оперативный процесс по мере развертывания проекта.

Это, безусловно, одна из самых сложных частей внедрения Agile

«Менеджменту все еще нужны оценки времени»

Мой подход:

• Подушка 300%. Старая поговорка 300% полезна, когда вы находитесь в ситуации, когда быть действительно гибким на уровне управления не произойдет. Возможно, это не «гибкий подход», а компромисс для этой ситуации. Вы сможете выйти вперед несколько раз, но не рассчитывайте на это!

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

• Убедитесь, что вы сотрудничаете над выполнением функций и качеством с руководством, чтобы они действительно принимали эти решения

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

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

• Держите свое резюме и связанный в профиле в курсе. Если вы не можете получить поддержку менеджмента после того, как несколько раз изложите свое мнение, продолжайте. Некоторые организации не будут перечислены в ваши аргументы, поэтому перейдите к тем, которые делают. Называется это дарвинизмом занятости;)

Я думаю, что вы делаете ложные предположения о гибкой разработке. Гибкость и изменяющиеся требования буквально вписаны в Agile Manifesto .

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

Гибкие (читай: меняющиеся) требования приветствуются в Agile. Конечно, если вы спросите большинство разработчиков, они добавят предостережение о том, что изменение должно быть разумным. Просить команду создать 3D-игру, а затем изменить требования к «системе управления ядерным реактором» - это немного. Но добавление, удаление или изменение требований в рамках проекта совершенно нормально.

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

Простота - искусство максимизировать количество не выполненной работы - очень важно.

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

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

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

Это абсолютно совместимо с философией разработки Agile (или любой другой), и ваш менеджмент должен полностью в нее влиять.

Да, ловкость имеет некоторые преимущества.

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

Но вам все еще нужно дать достаточно точные предварительные оценки.

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

И я слышу это сейчас.

Я слышал это раньше. Я уверен, что сказал это раньше:

Ох, но как же? Как простой смертный, такой как я, смотрит мне в судьбу подобных вещей! Вещи, которые только сами боги могут предвидеть и направлять. Вещи, о которых смертные могут мечтать только в самых глубоких снах и забыть о них! О тиранические управленческие типы, КАК можно удовлетворить такие требования !?

Используйте свое прошлое выступление в качестве руководства и будьте честными .

• Достаточно поговорить с заинтересованным лицом и / или конечным пользователем, чтобы определить, насколько сложен продукт и / или его основные компоненты по сравнению с другими основными компонентами, над которыми вы работали. Сделайте начальную оценку относительной точки.
• Увеличьте это число на историческое количество изменений в объеме и количество ошибок, которые вы видели в прошлом.
• Примените свою историческую скорость к точечной оценке, чтобы получить приблизительный график. И применить разумный конус неопределенности .
• Пересмотрите свою оценку и понимание проекта. Будьте уверены, что вы будете готовы принять решение о решении проекта на основе вашей оценки.

Наконец, представьте ваш конус неопределенности заинтересованным сторонам, изложите свои предположения и опасения и оставьте это при этом.

Кроме того, я бы также предложил придумать эвристику объективной оценки баллов, чтобы проверить нормальные оценки вас и / или вашей команды.

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

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

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

Agile - это отличное решение для целого ряда проблем, но, несмотря на то, что предлагают некоторые евангелисты, это не единственное и не всегда правильное решение.

Ваш заявленный случай просто не является гибкой проблемой:

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

Перед вами стоит задача определения затрат и выгод от автоматизации некоторых бизнес-процессов. Это не гибкая задача, которая может быть изменена, а конкретная проблема с конкретным решением. Вы создадите список с произвольным числом бизнес-процессов, и для каждого из них будет оценочная стоимость автоматизации, предполагаемая стоимость неавтоматизации и предполагаемая выгода от автоматизации. Руководство будет сопоставлять это со своими бюджетами, ресурсами, требованиями и стратегическими целями и определять, какие (если таковые имеются) эти процессы автоматизировать. Если вы добросовестны, то вы выделите выбранные задачи, которые потенциально могут иметь более низкую рентабельность инвестиций, но которые уменьшат стоимость других этапов, таким образом улучшая общую рентабельность. Возможно, вы также определили различные способы достижения автоматизации, в том числе разработку на заказ и на аутсорсинге (с использованием гибких и / или водопадных методов), покупку готовых решений, использование сторонних поставщиков услуг и т. Д. Весь этот процесс был очень модным в 90-х годах, когда он был известен как реинжиниринг бизнес-процессов.