Планирование большого изображения с помощью Agile

Question

Я довольно внимательно прочитал и просмотрел SO и ничего не нашел по этой теме, поэтому, надеюсь, я не создаю обмана. Если это было задано до того, как я буду признателен за ссылку.

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

Большая разница в моем сознании и в уме руководства в нашей организации заключается в том, как долгосрочное планирование будет работать в гибком процессе. Прежде чем мы сможем даже начать работу над проектом, мы должны иметь бюджет, одобренный внутренними клиентами, которые платят за программное обеспечение, которое мы производим. Как мы узнаем, каков должен быть этот бюджет, если мы не будем делать некоторые довольно подробные требования и оценки впереди? Конечно, наши требования и оценки, а не совершенные (а иногда и действительно отключенные), но они лучше, чем ничего.

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

Как это планирование на стратегическом уровне происходит в магазине Agile? Вы просто бросаете оценки против начальных туманных историй пользователей, с которых вы начинаете? Разве вы не проводите долгосрочное планирование такого рода? У вас все еще есть фаза высокого уровня требований/дизайна, а затем переход в Agile-процесс, когда проект не работает?

Спасибо,

~ Джастин

Answer 1

Планирование большой картины с использованием чистого Agile чрезвычайно сложно. Первой большой проблемой является (как вы заметили), что чистое гибкое и форвардное планирование (бюджеты, долгосрочные временные рамки и т. Д.) Принципиально не хорошо сочетаются.

Если вы знакомы с project management triangle (сфера охвата, стоимость, временные рамки), фокус Agile заключается в том, чтобы исправить затраты и расписание и позволить области быть переменной. В больших организациях масштабы и временные рамки часто фиксируются (нам нужен продукт X с этими функциями к следующему кварталу), и вы затем тратите большую часть своего времени на аргументацию стоимости (то есть количество разработчиков) и часто заканчиваете тем, что до позднего времени загружались, поскольку временные рамки и Недостаточно разрешенной стоимости.

Это приводит нас к второму вопросу - изменению мышления, требуемому для запуска чистой Agile в традиционной настройке компании. Идеальный совет - заставить вашу организацию покупать Agile оптом и признать, что они могут создать отставание в функциях, но не все из них могут быть доставлены. Однако то, что поставляется, будет высокого качества, вовремя и известной стоимости. Переход на чистый Agile может привести к серьезному сдвигу организационного мышления, так как Mike Cohen's book очерчивает мастерски.

К сожалению, очень сложно изменить мышление всей организации с обратной стороны одного проекта, поэтому третий способ - это компромисс - вы не делаете чистой Agile. То, что вы делаете, - это что-то вроде RUP/Waterfall, где вы выполняете анализ передних требований и выполняете немного работы по дизайну и архитектуре. Этого достаточно, чтобы выделить области риска и понять сложность большого изображения. Затем вы запускаете итерацию «0».

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

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

Answer 2

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

Я имею тенденцию создавать дорожную карту с использованием инструмента, который поддерживает отслеживание (я предпочитаю Enterprise Architect от Sparx Systems, но многие инструменты будут делать). Я просматриваю желаемые функции и порядок, в которых они необходимы на уровне спонсора проекта.

Затем я работаю с соответствующими лицами (иногда бизнес-специалистами, бизнес-аналитиками или старшими ИТ-специалистами, такими как архитекторы), чтобы разбивать каждую функцию на набор требований высокого уровня. Я создаю прослеживаемость от требований высокого уровня к функциям. На данный момент требования часто находятся на уровне «Добавить экран ABC», «Добавить экран DEF», «Создать фоновый процесс для пересчета XYZ» и т. Д., Без дальнейших подробностей. На данный момент я работаю с соответствующими людьми, чтобы оценить усилия для каждого требования высокого уровня, исходя из любых доступных показателей (начиная от чувств кишки до статистических данных о том, как долго, например, экраны берут в среднем, чтобы добавить). Затем мой инструмент моделирования суммирует общие оценочные усилия для каждой функции, которые затем могут быть представлены спонсорам проекта и размещены в плане проекта.

Затем мы начинаем итерацию, чтобы обратиться к первой функции или набору функций. Каждое требование высокого уровня уточняется в подробных требованиях («Экран ABC требует поля« Имя », максимальная длина 40,« требуется »и т. Д.). В зависимости от потребностей проекта мы можем переоценить усилия для более подробных требований и свернуть их до требуемого высокого уровня, к которому они обращаются.Чаще всего разработчик будет назначен для разработки Screen ABC, введя его собственную оценку в инструмент планирования спринта, и эта оценка вернется к исходной модели. Поскольку требования, которые он реализует (и оценивает), отслеживают требования высокого уровня, которые отслеживаются на уровне функции, план постоянно обновляется по мере того, как мы получаем каждую итерацию.

Для этого требуется определенная дисциплина и усилие, но это того стоит.

Answer 3

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

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

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

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

Уровень детализации, который описывает Эрик Дж., Совершенно не нужен. Это должно быть в программном обеспечении и извлечено из него, а не указано на бумаге заранее.

[редактировать] Наличие списка историй, которые недостаточно понятны заказчику или разработчику, может быть интересным. Вы не должны тратить на них много времени, так как их стабильность низкая. Используя сортировку корзины, вы можете получить краткое представление о размере и приоритете. Везде, где есть большие различия в поведении, у вас есть потенциальный риск. Просить всех заинтересованных сторон предоставить новые истории может помочь вам оценить полноту.

Answer 4

Как сделать большую картинку Проворный? Подумайте об этом так: Основная цель бизнес-аналитика в проекте Waterfall - представить минимальную, но качественную картину основных требований к поведению, и основная задача бизнес-аналитика в Agile-проекте - это придумать с минимальной, но качественной картиной основных требований к поведению.

Answer 5

«SAFe» исправить это финансирование «поезд ловкого релиза» вместо Proyects:

http://www.scaledagileframework.com/budgets/