Большое изображение, планирующее с [закрытым] Гибким

Закрытый. Этот вопрос основан на мнении. Это в настоящее время не принимает ответы.Подробнее.

Хотите улучшить этот вопрос? Обновите вопрос, таким образом, ему можно ответить с фактами и цитатами путем редактирования этого сообщения.

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

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

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

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

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

Спасибо,

~ Justin

задан RationalGeek 29 December 2009 в 18:56

0 ответов

Другие вопросы по тегам:

project-management agile project-planning

Большое изображение, планирующее с [закрытым] Гибким

0 ответов

Похожие вопросы: