Большое изображение, планирующее с [закрытым] Гибким
3 ответа
Планирование большого изображения с чистым Agile чрезвычайно сложно. Первая большая проблема заключается в том (как вы заметили), что чистое Agile и форвард-планирование (бюджеты, долгосрочные временные рамки и т.д.) принципиально плохо играют вместе.
Если вы знакомы с треугольник управления проектом (масштаб, стоимость, сроки), Agile в фокусе, чтобы исправить стоимость и график и позволяют области применения, чтобы быть переменным. В больших организациях масштабы и сроки часто фиксированы (нам нужен продукт X с этими функциями к следующему кварталу), а затем вы тратите большую часть своего времени, споря о стоимости (т.е. количество разработчиков) и часто в конечном итоге доставку с опозданием на загрузку, потому что шкала времени и допустимой стоимости просто не было достаточно.
Это подводит нас ко второму вопросу - изменение мышления, необходимого для запуска чисто Agile в традиционной настройки компании. Идеальным советом было бы получить вашу организацию, чтобы купить в Agile оптом и признать, что они могут построить отставание функций, но не все из них могут быть доставлены. Однако то, что будет доставлено, будет высокого качества, в срок и по известной цене. Переход на чистый Agile может привести к серьезному изменению организационного мышления, как Книга Майка Коэна описывает мастерски.
К сожалению, очень трудно изменить мышление целой организации от задней части одного проекта, так что третий путь является компромиссом - вы не делаете чистый Agile. То, что вы делаете, это что-то вроде RUP / Waterfall, где вы делаете некоторые передовые требования анализа и сделать немного дизайна и архитектуры работы. Этого достаточно, чтобы выделить области риска и понять сложность большого изображения. Затем вы запускаете итерацию "0".
Iteration 0 является доказательством разработки концепции для областей высокого риска и помогает понять ключевые оценки и производительность команды. Это может быть прототип, который выбрасывается, это может быть основой структуры вашего приложения НО важным моментом является получение обоснованного ощущения качества оценок и вероятной скорости работы команды и т.д. Это дает вам фундамент, на котором построить некоторые планы и установить вероятный бюджет.
Вы можете затем запустить работу Dev как нормальный Agile итераций, пожинает плоды ранней обратной связи с пользователем и видимость и т.д. Итерационный подход также помогает обеспечить регулярные вехи для вас отслеживать против плана, позволяет перепланировки точек и раннего предупреждения о бюджете над / в стадии выполнения. Используйте сметы/принципы на сегодняшний день, чтобы перерабатывать будущие планы по мере их выполнения
.Не делайте проектов, где значение настолько низкое, что не очевидно, что вы получите разумный возврат инвестиций.
Не пытайтесь создать фальшивую уверенность там, где ее нет. Планирование большой картины является и должно быть расплывчатым.
Быстрый процесс реализации позволяет клиенту управлять и адаптироваться. Если у вас есть опытная команда, известная и стабильная область, нет новой технологии или методологии, вы знаете ее скорость. Это также накладывает ограничения на размер проекта, который вы можете оценить. Команды регулярно меняются, технология меняется каждые несколько лет.
Если заказчику нужен детальный бюджет, ему необходимо предоставить истории пользователей до оценочного уровня. Это означает, что много работы должно быть сделано заранее. Должны быть сделаны все видимые всплески риска. Эта работа стоит только тогда, когда требования достаточно стабильны.
Уровень детализации, который описывает Эрик Дж., совершенно неприемлем. Он должен быть в программе и извлечен из нее, а не указан на бумаге заранее.
[редактирование] Иметь список историй, недостаточно понятных заказчику или разработчику, может быть интересно. Не стоит тратить на них много времени, так как их стабильность низка. Используя сортировку тележек, можно быстро получить представление о размере и приоритете. Везде, где есть большая разница в позициях, у вас есть потенциальный риск. Обращение ко всем заинтересованным сторонам с просьбой предоставить новые истории может помочь вам оценить их полноту
.При стратегическом планировании внутренние клиенты, как правило, больше заботятся о функциях, которые им нужны.
Я склонен создавать дорожную карту функций, используя инструмент, поддерживающий прослеживаемость (я предпочитаю Enterprise Architect от Sparx Systems, но многие инструменты подойдут). Я просматриваю желаемые функции и порядок их использования на уровне спонсоров проекта
Затем я работаю с соответствующими лицами (иногда бизнес-специалистами, бизнес-аналитиками или высокопоставленными IT-специалистами, например, архитекторами), чтобы разбить каждую функцию на набор требований высокого уровня. Я создаю прослеживаемость от требований высокого уровня до особенностей. На данный момент требования часто находятся на уровне "Добавить экран ABC", "Добавить экран DEF", "Создать фоновый процесс для пересчета XYZ" и т.д., без дополнительных деталей. На данный момент я работаю с соответствующими людьми, чтобы оценить усилия для каждого высокого уровня требований на основе любых доступных метрик (от интуитивных ощущений до статистики того, сколько времени, например, экраны в среднем занимают, чтобы добавить). Мой инструмент моделирования затем суммирует общее оценочное усилие для каждой функции, которое затем может быть представлено спонсорам проекта и помещено в план проекта.
Затем мы начинаем итерацию, чтобы обратиться к первой функции или набору функций. Каждое требование высокого уровня уточняется в деталях ("Экран ABC нуждается в поле "Имя", макс. длина 40, требуемая" и т.д.). В зависимости от потребностей проекта, мы можем повторно оценить усилия для более детальных требований и свернуть их до высокого уровня требований, к которым они прослеживаются. Чаще всего разработчику поручается разработка Screen ABC, он вводит свою собственную оценку в инструмент спринтового планирования, и эта оценка откатывается к исходной модели. Поскольку требования, которые он реализует (и оценивает), трассируются до требований высокого уровня, которые трассируются до уровня функционала, план постоянно обновляется по мере того, как мы попадаем в каждую итерацию.
Это требует некоторой дисциплины и усилий, чтобы настроить это, но это того стоит.
.