Scrum: слишком много или недостаточно?

Ответ 1

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

У вас всегда будет проблема с шоу-стопорами, но вы можете помочь в этом, сократив длину вашего спринта. Клиент может не подождать несколько месяцев, но они могут подождать две недели для некоторых вещей. Тогда более короткая длина спринта может помочь вам отложить некоторые запросы к следующему спринту, что сделает их менее разрушительными. Вы также должны быть заранее с клиентом, что сбои на самом деле заставляют ваш темп страдать. Они могут добровольно подождать, если они узнают, что их выбранные функции откладываются некоторыми запросами.

Еще одно замечание, которое я сделаю, состоит в том, что, как и почти во всем, лучше начинать, следуя шаблону, насколько это возможно, пока вы учитесь. После того как вы хорошо понимаете основные принципы, вы можете увидеть, где некоторые принципы могут быть согнуты, сломаны или заменены гораздо более четко, чтобы улучшить процесс. Пока вы не получите его, то, что вы измените, может повредить или помочь - вы действительно не знаете, так как у вас нет опыта, который говорит вам, как должно работать. Если ваш мастер Scrum действительно не испытан, вы можете захотеть приблизиться к определенным практикам, пока не получите еще несколько спринтов под вашим поясом.

Ответ 2

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

Основные идеи Scrum:

Имейте жесткий цикл обратной связи от требований к разработке и обратно к заинтересованным сторонам.

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

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

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

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

Это то, где большинство проектов терпят неудачу и где Scrum может действительно преуспеть, если все покупают этот процесс. Так много проектов развития созданы там, где релиз должен иметь X-функции, выпущенные по дате Y, и никакой гибкости в изменении этого. Это приводит к полупрофилированным функциям и программному обеспечению с ошибкой, поскольку разработчики втискивают все необходимые функции в свой контрольный список.

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

Ответ 3

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

Я бы предложил попробовать охватить учебник Scrum так же, как позволяет ваша бизнес-среда, посмотреть, как это работает, а затем настроить его.

Почему ваш мастер Scrum не хочет перемещать задачи из резервной копии спринта? Не он ли 100% охватывает принципы Scrum? (Я видел бы это как беспокойство у мастера Scrum)

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

Ответ 4

Каждая компания отличается, каждый проект отличается и каждый клиент отличается.

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

В конце концов, какой-то общий ответ на сайте QA не заменяет серьезного анализа вашего собственного проекта, компании, команды и клиентов - нет волшебной формулы, и вы должны принять собственное решение.

Ответ 5

Ответ: Вам нужно принять оба Scrum и XP вместе, чтобы получить все преимущества схватки.

Причины:

Причины основаны на годах работы в XP и схватке, а также на том, что я узнал из Джеффа Сазерленда (для ACCU в Лондоне, май 2009 г.)

• Scrum - это технология управления - не обязательно метод создания программного обеспечения. Некоторые люди используют схватку в других доменах, например. подготовка музейных выставок и ведение религиозных учреждений... поэтому у него есть механизмы, необходимые для того, чтобы междисциплинарная команда обеспечивала работу адаптивно небольшими шагами.
• Scrum первоначально включал все экстремальные методы программирования. Джефф Сазерленд на самом деле сказал, что никогда не видел, чтобы проект схватки достиг высших порядков производительности, измеренных для схватки без использования экстремальных методов программирования.
• Scrum и XP оба происходят из одного и того же фона. Объектно-ориентированное программирование, в частности с Smalltalk. Программисты ушли и разработали XP, в то время как люди управления создали схватку. Вам нужны оба аспекта - методы развития и методы управления.
• Практики XP были умышленно удалены из Scrum, чтобы упростить их принятие.. Реализация XP-технологий сложна, и ее сложно быстро принять. Джефф на самом деле сказал, что Кен Швабер удалил практику XP, чтобы помочь людям начать работу с схватками. Теперь опасность состоит в том, что эта минимальная схватка стала тем, что люди видят и ожидают.
• Множество нетехнических менеджеров проектов теперь учат схватке, но у них нет набора навыков для обучения XP
• Не все разработчики находят, что методы XP легко адаптируются - они могут быть сильно проданы, и требуется несколько месяцев, а не 2 дня, необходимые для установления основного схватки.

Ответ 6

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

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

Экстремальное программирование решает технические проблемы, связанные с, при разработке программного обеспечения, и он очень хорошо вписывается в схватку. Причина, по которой люди, занимающиеся борьбой, не заставляли всех выполнять техническую практику XP, заключается в том, что требуется около шести месяцев для внедрения этих технических решений, а не для 2-х дней, необходимых для реализации самой основной схватки.

Независимо от того, является ли схватка "злом", есть определенные недостатки. Мы обсуждали непростые отношения между XP и Scrum в XP Days, London, 2009: http://xpday-london.editme.com/WhereHasXpGone

Ответ 7

Scrum - это не проблема, которую вы показываете. Большинство методологий разработки работают, даже водопад, насколько нам нравится, bash он работает. Scrum действительно заставляет вас сконцентрироваться на важных вещах, но это не остановит людей от принятия плохих решений, таких как не выполнение этого процесса.

Система довольно проста в своем ядре.

См. проблему. Определите, что сделано. Создайте серию задач, которые помогут вам сделать это. Оцените эти задачи. Выберите достаточно, чтобы вы могли что-то сделать за короткий промежуток времени. Заполните задачи. Промыть и повторить.

ОК, правда, эти шаги упрощены, и я не бросил мастер схватки и клиента. Но дело в том, что структура - это просто базовая стратегия управления временем. Если люди в вашей системе хаотичны и нехорошо справляются с этим, то схватка действительно им не поможет.

Ответ 8

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

Для вашего Scrum Master он может отслеживать, что удалено из текущего Sprint. Также Sprints планируются на основе предыдущего достижения Sprints, а не того, что было запланировано ранее. Я не понимаю.