Только команда занимается Scrum, но остальная часть компании (включая продажи, менеджмент, HR) все еще думает по-старому. Примеры:
Постоянное взаимодействие с клиентом и вовлечение клиента очень важно.
HR должен понимать, что эффективность команды важнее, чем производительность отдельных людей. КПИ должен измениться на это.
Определение функции - это непрерывный процесс. Определение проекта будет развиваться в процессе разработки по отзывам клиентов. Из-за этого срока проекта требуемый бюджет или набор функций результата могут измениться (после утверждения заинтересованным лицом).
Изменение является частью процесса.
Оценка - это непрерывный процесс, который вы не можете сказать в начале проекта, что все функции (многие из которых неизвестны в начале) будут выполнены в течение 5 месяцев.
Команда уполномочена принимать решения. Команда принимает на себя обязательства по количеству функций, предоставленных во время следующего спринта. Этого нельзя требовать или командовать.
Спринт - безопасная зона для команды. Как только команда фиксирует некоторые определенные пользовательские истории, обязательство не может быть изменено вне группы.
Часть старой организационной структуры не имеет смысла при переходе на Scrum. Scrum определяет три роли: Scrum master, владелец продукта, команда. Существуют и другие роли, но этих трех обычно достаточно для доставки приложения. Распространенным не имеет смысла наличие мастера Scrum, руководителя группы, владельца продукта и одного или нескольких менеджеров проектов. Менеджер проекта и руководитель группы являются избыточными ролями в Scrum.
The most basic approach is including analysis and documentation in acceptance criteria for user stories.
Это моя первоначальная реакция тоже. Если история имеет критерии приемлемости, это лучшая документация, которую вы можете иметь. Но если команда решит создать дополнительные документы (например, README в стволе или вики с полезной информацией), то я не вижу проблемы. Я думаю, что люди боятся, что SCRUM = ничего никогда не записывается.Самая большая проблема, которую я заметил за более чем 10 лет работы с xp и scrum, - это когда команды, которые еще не совсем «гибки», решают «быть гибкими в отношении гибкости» и начинают настраивать их, отбрасывая определенные части и т. Д. Без четкое понимание того, что делает каждая часть и почему она есть.
Я видел, что команды с scrum более успешны, когда они сначала что-то делают по книге, чем команды, которые меняют то, что они еще не «получают».
Именно тогда вы получите такие вещи, как «первый спринт, мы выполним все требования. Второй спринт, весь дизайн, и т. Д. И т. Д., Последний спринт, все тестирование». Также известен как водопад. Или даже такие простые вещи, как «давай сядем в любом случае, что за дела с этим дурным делом?».
Что-то связанное с Шухари ( http://c2.com/cgi/wiki?ShuHaRi ).
источник
Самая большая проблема всегда - бай-ин. Если какая-либо команда или ключевые лица не участвовали (управление проектом, контроль качества, разработка и т. Д.), То провал почти гарантирован.
Другая связанная с этим проблема заключается в том, чтобы заставить всех участников осознавать, что такое схватка, а что нет.
Я видел среды, в которых управление проектами фактически восприняло это как билет, чтобы прийти непосредственно к разработчикам с изменениями и ожидать, что это будет сделано завтра, так как мы используем отличный новый процесс. Любой, кто был в этой ситуации или в других неудачных попытках внедрения Scrum и имел горький вкус во рту. Эти люди иногда также пытаются отменить проект.
Еще одна проблема, с которой я столкнулся - это встречи на свежем воздухе. Вы всегда получите парня, который хочет сесть во время встречи на стенде ... "У меня плохая спина" или что-то в этом роде. Кажется, всегда один и тот же парень, который не имеет ни малейшего представления о том, какова цель стоящего в тупике, и не будет молчать о политике или о том, что он делал в эти выходные. Стендовые встречи, как я обнаружил, являются ключом к эффективному общению. Важно не позволить никому отравить эти встречи.
источник
management has actually taken this as a ticket to come directly to developers
Это хороший пример ситуации, когда процесс SCRUM не понят, верно? Это команда не может принять новые истории в середине спринта.Пытаясь выполнить весь анализ кода, который мы разрабатывали, в одном и том же спринте, мы фактически его кодировали.
источник
Некоторое время назад мы перешли к схватке, и, честно говоря, управляющая компания рассматривала каждую схватку как двухнедельный процесс с водопадом. Была такая приверженность правилам схватки, которая стала процессом сама по себе!
Это проблема, которую я нахожу, все гибкие методологии должны быть гибкими, чтобы эффективно работать так, как вам удобно. Не так, как это запрещено процессами. Например, у нас были двухнедельные ссоры, и команда сказала, что они чувствовали, что двух недель недостаточно для хорошей работы (не из-за простоя, вызванного окончанием демонстрации схватки и первоначальным пересмотром требований), поэтому они хотели перейти к 3 неделя. Шок ужас! Менеджмент отказался, потому что они решили, что 2 недели на схватку были идеальными, и теперь это было задокументировано в процедурах контроля качества.
Скрам является наименее гибким из гибких методов, и, возможно, поэтому он так популярен - его легче продать старой гвардии. Вы должны удалить вещи, которые вам не нравятся, но я не думаю, что это произойдет. Мой совет: используйте более гибкий, менее основанный на правилах и добавьте правила, которые вам нужны. Я предпочитаю Кристалл из-за этого.
В конце концов, просто запомните полужесткий проворный манифест .
источник
Самая большая проблема заключается в том, что ваш клиент также должен принять процесс SCRUM и стать гибким. Большинство клиентов хотят услышать это в начале проекта:
Звучит разумно, но абсолютно не совместимо с гибкой. Вы должны объяснить своему клиенту, почему agile хорош для него, а не для водопада.
источник
how much will it cost?
и они ожидают подробного ответа прямо сейчас. Мой ответ на эту проблему всегда звучит так: «Если вы точно знаете, чего хотите, в конце концов, вам не нужна гибкость. Просто запишите ее». Но мы все знаем, что этого не произойдет. ;-)У меня было две большие проблемы на моем первом посещении SCRUM:
1) У нас не было владельца продукта. Наш начальник должен был сыграть эту роль, потому что никто, кто должен был быть владельцем продукта, не согласился бы на это. Такого рода вещи мешают, потому что он не всегда знает ответы.
2) Мы плохо учли внешние компоненты. Наши первые несколько спринтов включали в себя запуск полностью автоматизированного тестирования, и мы неоднократно сталкивались с проблемами при автоматизации используемых нами тренажеров. Каким-то образом нам никогда не удавалось лучше понять, что это должно было случиться.
источник
Основная проблема, с которой я сталкиваюсь в своем проекте, состоит в том, что сбор требований происходит после того, как мы оценили следующий спринт. Мы оцениваем на основе критериев приемлемости. Во время сбора требований мы обнаруживаем, что точно настроенный переменный ток намного больше, поэтому начальная задача, рассчитанная на 8 часов, теперь действительно составляет 24 часа! Итак, могу ли я изменить свое отставание в спринте и пересмотреть оценки и сократить свои истории? Нет, сэр! Agile требует, чтобы вы не могли изменить отставание спринта! Вот что говорит мой TL. Так что я не должен также кодировать в соответствии с первоначальными критериями принятия, для которых я оценил время в 8 часов! Бог! Нет! Вы не можете сделать это! Это не было бы Agile, не так ли!
источник