Comments 11
Чтобы SCRUM работал, нужна Команда, а не N разработчиков, сидящих в одной комнате и решающих пересекающиеся задачи. У Команды должен быть Лидер, который ведет за собой и заражает драйвом всю Команду. Такая Команда сможет брать на себя обязанности и ответственность.
Если этого нет, то SCRUM не заведется, потому что «ну а смысл из-за 10 копеек жопу рвать?».
А если это есть, то SCRUM может помочь оптимизировать некоторые процессы. Сам по себе SCRUM не сделает из сборища коллег полноценную Команду. Для этого нужно нечто большее, чем просто рекомендованный набор методик.
Если этого нет, то SCRUM не заведется, потому что «ну а смысл из-за 10 копеек жопу рвать?».
А если это есть, то SCRUM может помочь оптимизировать некоторые процессы. Сам по себе SCRUM не сделает из сборища коллег полноценную Команду. Для этого нужно нечто большее, чем просто рекомендованный набор методик.
Ну как раз Лидера в scrum-команде, имхо, быть не должно.
А мне кажется, что доска, хоть и задает вектор движения команды — делает это весьма скучно и однообразно. Чего нельзя сказать о лидере. Вектор все видят на доске, а лидерство уже как ритм на галерах (вычитая, конечно же, рабскую составляющую). Короче — пульс команды Скраммастер не всегда может/должен/хочет ощущать, но среди самих исполнителей наверняка есть инициативные, или просто, с хорошим настроением :)
Запланированная история не выполняется в срок. Второй разработчик либо простаивает, либо вынужден делать задачу с меньшим приоритетом.
Задачи вообще не должны идти таким образом, что бы в течении 1 спринта 1 команда ждала другую. Это ошибка product owner'a.
3. Фиксирование договоренностей внутри команды
Смотрим выше — тоже самое. Команды не должны работать над одним и тем же в параллельных спринтах.
И этих ошибок вы при таком подходе не избежите.
5. Правильная оценка задачи или не бойтесь их переоценивать во время спринта.
Что делать:
нужно выделять такие задачи,
перечеркиваем старую оценку и ставим новую.
если задача связана с другими и тянет за собой хвост, необходимо по возможности перераспределить связанные задачи (назначить на другого разработчика)
повторно оценить ценность задачи — возможно ее на данном этапе ее следует отложить
Что значит выделять?
Как понять, что её не успеть сделать? Если задачу не удается решить в срок, то команда старается, если не успевает, тогда переходит в следующий сприт. Product owner берет на заметку. При повторе подобной ситуации, нужно снижать фокус-фактор или перетасовывать команды.
Задачи вообще не должны идти таким образом, что бы в течении 1 спринта 1 команда ждала другую. Это ошибка product owner'a.
Спасибо, возьмем на заметку!
На каждом Stand-up митинге разработчики внутри команды должны «сверять часы». Каждый должен озвучивать ожидаемые сроки передачи ему данных «эстафетной палочки».
ИМХО, экономически целесообразнее вначале прописывать интерфейсы взаимодействия и заглушки, а затем все заинтересованные пилят «со своей стороны» и осбо не беспокоятся, в какой конкретно день какого спринта оно сойдется. Тратится время на черновую проработку интерфейсов заранее и на создание стабов, зато потом экономится время на «я не могу ничего делать, потому что у меня все готово, а со стороны Васи еще день делать».
Хгм, на работе мы избавились от достаточно многих недопониманий как внутри команды, так и между командами, когда в пределах проекта был принят definition of done. Возможно, такой документ упростил бы вам жизнь в ситуациях 3 и 4, ведь недоделки по какой-то из задач могут к вам «приплыть» и в следующих спринтах
Команда 1 реализовала отдачу данных для Команды 2 и приступила к другим своим задачам. Через 3 дня Команда 2 обратилась к Команде 1 — данные не заливаются/данные не валидные и т.п.
Формат выдачи данных не был описан правильно (косяк Product Owner-a), либо команда реализовала неправильные тесты (накосячила команда).
Не зря в условиях внедрения scrum написано, что команда должна быть профессиональная и стабильная. Т.е. технические проблемы, инфраструктура и т.д. должны быть решены как никогда хорошо.
Ну либо такую задачу, в которой компоненты взаимодействуют так тесно, хорошо бы решать в одной команде. Тогда она сама может описать формат обмена и тестироваться все будет с самой начальной стадии.
По некоторым описанным проблемам (1-4 и 6 пункты) складывается ощущение плохой коммуникации между смежными командами.
Разрешите оффтопный вопрос к знатокам Scrum'a в этом топике:
Есть ли смысл внедрять Scrum в случае, когда программистов меньше чем проектов. Т.е каждый программист независимо от других ведет минимум один отдельный проект?
Есть ли смысл внедрять Scrum в случае, когда программистов меньше чем проектов. Т.е каждый программист независимо от других ведет минимум один отдельный проект?
Sign up to leave a comment.
Заметки по внедрению Scrum — что обязательно приведет к провалу итерации, если ничего не предпринимать