Agile Управление проектами
Если кто-то использует Scrum для части проекта, связанной с разработкой программного обеспечения, использует ли PMBOK или какую-либо другую методологию управления проектом для "других" задач проекта, например, для бизнеса, маркетинга, обучения. Что такое управление проектами для задач, не связанных с разработкой программного обеспечения, т.е. традиционное управление проектами?
6 ответов
Мы расширили схватку на другие отделы компании, моделирование, текстуры и анимацию художника. Нам пришлось немного адаптировать метод, но он работает хорошо. У нас были проблемы, которые были решены с использованием гибкой методологии. Некоторые небольшие отделы (аудио, спецэффекты) уже работали нормально, поэтому мы не пытались исправить то, что не сломалось. Agile добавил бы ненужные накладные расходы для них.
Не обязательно, чтобы все отделы компании использовали одну и ту же методологию, лучше всего адаптироваться к потребностям каждого. Но Scrum может быть решением для людей, не являющихся программистами, но может потребоваться немного адаптации. Ежедневная работа, спринты, отставание - это может быть полезно для многих видов работ.
Проект определяется в PMBOK как фиксированный объем, продолжительность и бюджет. Неудача проекта определяется как выход за пределы одной из трех сторон этого "железного треугольника". Скрам - это набор принципов и несколько конкретных практик для работы со всеми видами знаний, основанный на гибких ценностях, и он специально разработан для усилий по разработке, которые могут не быть проектами или могут иметь гибкий охват, продолжительность или бюджет.
Вы правы в том, что Scrum имеет дело только с несколькими аспектами процесса разработки программного обеспечения, такими как планирование. Он определяет только несколько ролей, собраний и артефактов, чтобы сделать его максимально гибким. Scrum может и должен адресовать части потока создания ценности вне самой разработки программного обеспечения. Однако, как вы упомянули, он не имеет отношения к многим вещам, таким как практика разработки программного обеспечения и анализ бизнес-кейса.
Часто стандартное решение Scrum состоит в том, чтобы "позволить команде принять решение" по вопросам, которые не определены непосредственно Scrum. Часто руководящие принципы для решения таких вопросов исходят из других культур и систем ценностей или принципов в Agile-мире, таких как XP, или бережливая разработка программного обеспечения. Другие культуры, предоставляющие полезные вещи для команд Scrum, включают Реальные Опционы, Метод Добавочного Финансирования, Эво.
Некоторые вещи из PMBOK могут быть полезны для "менеджера проекта" или ПО в команде Scrum, однако нужно быть осторожным, поскольку вещи из PMBOK подразумевают довольно иную систему ценностей, чем та, на которой базируется Scrum. Обычно лучше всего искать решения в гибкой культуре. Однако некоторые вещи из PMBOK все еще применяются в проворном контексте.
Если вы ищете списки рассылки, связанные с "гибким управлением проектами", вы найдете много процветающих сообществ, обсуждающих такие темы.
Гибкая разработка и PMBOK не должны смешиваться. Если вы это сделаете, вы, вероятно, в конечном итоге с Scrummerfall. Я видел, как это происходит с традиционными менеджерами проектов, которые переходят на гибкие. Они просто не понимают этого и, похоже, возвращаются к старым образцам.
Однако, по моему мнению, SCRUM не покрывает все необходимое для управления проектами. Это своего рода недостаток общей стратегии, которой можно управлять. Одной из возможностей является объединение SCRUM с EVO-проектом / управлением стоимостью или другими методами управления стоимостью. Однако для этого потребуется другой тип юридического договора с клиентом. Проекты тогда больше походят на непрерывный процесс, который ограничен во времени, ограничен бюджетом или заканчивается, когда клиент чувствует, что он получает меньше, чем его инвестиции (используя бизнес-кейсы и целевые показатели). Дополнительным преимуществом является то, что клиент будет видеть вас скорее в качестве долгосрочного партнера, чем краткосрочного поставщика.
Если ваши усилия по разработке программного обеспечения являются лишь одним из аспектов более крупного проекта - например, развертывание нового финансового продукта - тогда, конечно, вам придется использовать какую-то методологию управления проектами для организации всей вовлеченной работы. Однако встраивание усилий по разработке программного обеспечения на основе Scrum в проект, управляемый в соответствии с принципами PMBOK, может быть сложной задачей, поскольку PMBOK предписывает линейный поэтапный подход к выполнению проекта, тогда как Scrum, как и другие методологии Agile, способствует постепенному улучшению с помощью итерации. Это не значит, что они не могут сосуществовать. Как и все остальное, все сводится к реализации. Просто помните, чтобы быть прагматичным и адаптировать методологии к вашим потребностям, а не наоборот.
Хотя изучение этих техник - это здорово, могу ли я предположить, что ваше основное внимание на самом деле сосредоточено на запуске проекта и выполнении работы?
РЕДАКТИРОВАТЬ: между прочим, это серьезный вопрос, а не броский клев.
Scrum - это НЕ метод разработки программного обеспечения, а метод управления проектом.
Кроме того, Scrum часто вводится вместе с Lego или другими артефактами (ищите "Scrum 59 минут"). Поэтому его можно использовать для решения всех задач проекта, независимо от их природы.