Существует ли хорошая модель для выбора гибкого подхода?

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

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

Существует ли хорошая модель или инструмент, помогающий определить подходящую гибкую методологию для конкретной ситуации?

Что, по вашему мнению, является ключевым критерием выбора конкретной гибкой методологии в отсутствие хорошей модели? И если вы действительно хотите выйти за рамки, какой вес (в процентах от общего числа) вы бы присвоили своим критериям?

В книге Роберта Высоцки предлагаются некоторые общие подходы, основанные на том, ясна ли цель проекта, полны ли требования, сжат ли график и ожидаются ли изменения содержания. Но могут быть и другие ресурсы, на которые стоит обратить внимание.

Хорошее чтение , чтобы подготовиться к тем, кто пытается исказить и разрушить Agile, чтобы он соответствовал «контексту» организации.
@NathanCooper Спасибо. Одна из моих любимых цитат из этого сообщения в блоге: «Единственный способ добиться успеха — кроме, пожалуй, действительно удачного случая — это создать команду, которая хорошо работает вместе и добивается результата. XP и Scrum — лучшие известные нам способы. чтобы хорошо работать вместе».
Я бы настоятельно рекомендовал уделять больше внимания готовности/способности команды принять гибкое мышление и цели по сравнению с процессом. Вы также должны привлечь их к оценке отправных точек процесса. Замедлит ли это старт? Определенно. Однако изолированный выбор процесса для команды и последующее его обучение могут затормозить многие пилотные проекты; получить "всех в лодке", так сказать.
Срок действия ссылки на книгу истек, вы можете найти заархивированную версию по адресу web.archive.org/web/20091214011345/http://www.wysockiepm.com .

Ответы (5)

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

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

  • Члены команды должны быть наделены полномочиями и нести ответственность за результат (в большинстве случаев нет необходимости получать одобрение от вышестоящих органов — например, PO должен иметь возможность изменять масштаб без участия спонсора)
  • От всей организации требуется самоотверженность, чтобы даже одна команда могла быть гибкой (например, мы не смогли начать наш первый спринт, потому что отдел безопасности не разрешал членам команды получать ключи от комнаты разработчиков в течение 2 недель)
  • Это не марафон, это спринт - вам нужно будет постоянно вкладывать энергию, не будет более медленных периодов (нет времени на другие ваши обязанности - если вы на 100% в проекте, никакая другая работа не подойдет) в свой график)
  • Примите перемены — ожидайте, что соглашения, заключенные вчера, будут пересмотрены и, возможно, отменены завтра, не суетитесь по этому поводу.
  • Будьте гибкими в отношении результата — то, что вы имеете в виду, возможно, не то, что вы получите после нескольких изменений.
  • И, самое главное: доверяйте другим членам команды — вы не должны играть в корпоративную политику или силовые игры, вы плывете в одной лодке.

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

Я не согласен с концепцией спринта, переход к аджилити скорее будет марафонским, чем спринтерским. Ключевым моментом является устойчивый темп, а не выполнение задач в быстром темпе 100% времени... есть вероятность, что во время первых попыток темп и производительность на самом деле замедлятся. И последнее, но не менее важное: отсутствие другой работы, соответствующей графику, может быть довольно опасным.
Согласен, я бы хотел, чтобы команда написала все во время своего первого проекта Scrum/Agile. Есть причина, по которой руководство по Scrum рекомендует держать команды вместе; они не только получают знания о наборах навыков друг друга, но и становятся более эффективными как команда Scrum .
«это не спринт, это марафон, мы не должны пытаться выиграть его на первых 100 метрах», — такова была реальная цитата нашего клиента во время проекта внедрения agile, от которого нам пришлось почтительно отказаться (контекст был таков, что они предпочитаю не толкать его во время первого спринта, так как позже будет много времени, чтобы набрать обороты).

Если, как вы говорите, ваша организация чрезвычайно бюрократична и ориентирована на водопад, я бы не стал «тратить» слишком много времени на размышления о том, что делать, а вместо этого начал бы что-то делать:

  1. Найдите проблему для решения
  2. Подскажите как решить
  3. Примените свое решение
  4. Осмотр и адаптация

Или, как предлагает Дэйв Томас :

Вот как можно сделать что-то в гибкой манере:

Что делать :

Узнайте, где вы находитесь

Сделайте маленький шаг к своей цели

Скорректируйте свое понимание на основе того, что вы узнали

Повторение

Как это сделать :

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

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

Ох и удачи ;)

Не совсем ответ, так сказать, но я бы посоветовал вам посмотреть очень интересное выступление Юваля Йерета: «Хорошие и плохие способы запуска Agile по пути Канбана» . Он рассказывает, как стимулировать внедрение Agile с помощью Канбана, рассматривая каждое небольшое изменение как вариант, и дает несколько полезных советов по управлению изменениями по методу Канбан.

Кроме того, вы также можете прочитать интервью Юваля Йерета Бена Линдерса на ту же тему.

(источник: infoq.com)

Во-первых, Agile Software Development — это изменение вашего процесса в соответствии с вашими потребностями. Скрам не гибок, Канбан ( JIT ) не гибок. Это ваша команда меняет процессы или придумывает свои собственные процессы, которые подходят для вашей ситуации — вот что значит быть гибким.

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

  1. Непрерывная поставка — выбор №1 сегодня. Вы можете выпускать в PRD, даже если функции не готовы (есть методы, позволяющие скрыть эти изменения). Но вам нужен кто-то, кто имеет опыт в этом, чтобы заставить его работать. И это может привести к худшему качеству, чем следующий выбор, если у вас слабая команда разработчиков.
  2. Точно в срок , Теория ограничений — с ними вы освобождаете каждую задачу (или группируете их небольшими партиями). Если вы не сильны в КД - это лучший вариант для начала. Это немного медленнее, чем CD, и быстрее, чем Scrum, и дает очень хорошее качество.
  3. Scrum — он основан на итерациях и имеет много дополнительных действий. Таким образом, это приводит к более низкому качеству и более медленной (намного более медленной) разработке. Но это все равно намного лучше, чем Водопад.

Они не всегда исключают друг друга. Опять же - ваша ситуация, скорее всего, потребует чего-то изменить. И процессы не обязательно должны быть статичными — вы можете менять их туда-сюда в зависимости от текущего настроения в команде.

Я бы посоветовал вам не усложнять и выполнить следующие шаги :)

  1. собрать команду
  2. создать бэклог продукта
  3. оцените свой отставание
  4. удар спринта или итерации

затем проверьте, адаптируйте и повторите!

Удачи :)

Существует ли хорошая модель для выбора гибкого подхода?
СпросиСетьПолитика конфиденциальности1y, 0v