Комментарии 3
Я вот из тех, кто всегда с удовольствием читает о новых идеях в управлении проектами.
И, видимо, точно так же попадаю в 90% тех, кого 90% статей на эту тему удивляют.
Даже приблизительно не могу представить себе, как методика, выросшая из Бековского манифеста может требовать фиксированности команд.
Ну, в любом случае, чтобы прояснить:
я правильно понимаю, что новая аббревиатура подразумевает проектную программу, в которой мы просто соглашаемся в обязательном порядке иметь такие проекты, как «Архитектурные решения (ядро?)», «Поставка контента» и «Функциональные модули» (видимо каждый предлагается оформить в отдельный проект с выделенной под него командой?)
И, видимо, точно так же попадаю в 90% тех, кого 90% статей на эту тему удивляют.
Scrum же начал «требовать» от руководителей PMO добиться кросс-функциональности на уровне фиксированных команд, состав которых не меняются на протяжении 6-12 месяцев.
Даже приблизительно не могу представить себе, как методика, выросшая из Бековского манифеста может требовать фиксированности команд.
Ну, в любом случае, чтобы прояснить:
я правильно понимаю, что новая аббревиатура подразумевает проектную программу, в которой мы просто соглашаемся в обязательном порядке иметь такие проекты, как «Архитектурные решения (ядро?)», «Поставка контента» и «Функциональные модули» (видимо каждый предлагается оформить в отдельный проект с выделенной под него командой?)
Добрый день africaunite,
Благодарим за Ваш комментарий и с интересом отвечаем на вопрос.
Scrum способствовал тому, что команды разработчиков сместили свой фокус с технических решений в сторону бизнес результатов, дающие именно такие решения. Такое изменение фокуса подразумевает способность команды «обеспечить» бизнес результаты, вследствии чего появилось понятие кросс-функциональности. Попытка сделать 100% команд кросс-функциональными, с нашей точки зрения, была не совсем удачной и не представляла оптимальное решение. В условиях больших компаний, такое изменение выглядело слишком радикальным.
И так фантазируем…
Представьте себе, что Вы разрабатываете CRM решение и у Вас есть пять команд разработчиков. Если они все кросс-функциональные, то Вы очень свободны в выборе той команды, которая будет реализовывать тот или иной функционал. Но это идиллия. Изначально, у вас 5 команд, каждая из которых отвечает за свой модуль. Проблема и возникающие при этом вопросы в следующем: как эти команды эффективно объединить одной целью для выпуска нового релиза в срок, как быстро определить ограничения и зависимости между командами и как оптимально интегрировать решения всех команд в продукт.
С нашей точки зрения, SAFe даёт весьма конструктивные ответы на эти вопросы. Поэтому ответ на Ваш вопрос звучит следующим образом: «нет требования к обязательному наличию тех или иных команд, есть предложение как организовать существующие команды наиболее оптимальным образом для достижения единого результата – выпуска качественного продукта в срок».
Надеюсь, мы ответили на Ваш вопрос и с интересом готовы продолжить общение по другим не менее актуальным и спорным вопросам.
Благодарим за Ваш комментарий и с интересом отвечаем на вопрос.
Scrum способствовал тому, что команды разработчиков сместили свой фокус с технических решений в сторону бизнес результатов, дающие именно такие решения. Такое изменение фокуса подразумевает способность команды «обеспечить» бизнес результаты, вследствии чего появилось понятие кросс-функциональности. Попытка сделать 100% команд кросс-функциональными, с нашей точки зрения, была не совсем удачной и не представляла оптимальное решение. В условиях больших компаний, такое изменение выглядело слишком радикальным.
И так фантазируем…
Представьте себе, что Вы разрабатываете CRM решение и у Вас есть пять команд разработчиков. Если они все кросс-функциональные, то Вы очень свободны в выборе той команды, которая будет реализовывать тот или иной функционал. Но это идиллия. Изначально, у вас 5 команд, каждая из которых отвечает за свой модуль. Проблема и возникающие при этом вопросы в следующем: как эти команды эффективно объединить одной целью для выпуска нового релиза в срок, как быстро определить ограничения и зависимости между командами и как оптимально интегрировать решения всех команд в продукт.
С нашей точки зрения, SAFe даёт весьма конструктивные ответы на эти вопросы. Поэтому ответ на Ваш вопрос звучит следующим образом: «нет требования к обязательному наличию тех или иных команд, есть предложение как организовать существующие команды наиболее оптимальным образом для достижения единого результата – выпуска качественного продукта в срок».
Надеюсь, мы ответили на Ваш вопрос и с интересом готовы продолжить общение по другим не менее актуальным и спорным вопросам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Станет ли SAFe отраслевым стандартом в Enterprise Agile?