Мы небольшой стартап, который быстро растет.
У нас есть 4 отдела: (Backend dev [2 человека], Frontend dev [2 человека], QA [2 человека] и один системный администратор)
До использования методологии Scrum у нас не было четкого представления о нашем прогрессе, над чем работают другие и т. д. Сейчас мы прошли эту проблему, но теперь мы столкнулись с большой проблемой; кажется, что команда не соответствует текущей методологии.
Чтобы дать вам четкое представление о нашем случае, вот как мы работаем над проектом:
У нас есть бэклог-совещание с владельцем продукта. Команда определяет невыполненную работу на другом собрании (на основе приоритета, установленного владельцем продукта). Каждый отдел разделяет невыполненную работу на части и перечисляет все задачи, которые необходимо выполнить к следующему спринту. Например, backend-группа начнет работу над API, front-end будет заниматься дизайнерами и готовить готовые шаблоны, QA-команда будет читать и понимать истории, а системным администраторам нужно определить следующий приоритет в соответствии с текущим проектом.
Каждый отдел создает свой собственный спринт. (странно, я знаю :s) и в итоге у нас 5 спринтов. (Пятый — для работодателей. Ну, они хотят быть частью методологии, лол.)
Прежде чем мы начали использовать Scrum, мы соблюдали двухнедельный цикл, а после внедрения Scrum руководитель проекта предлагает проводить спринты за две недели. Однако мы только что обнаружили, что спринт может занять больше :s.
В соответствии с нашим случаем у меня в голове возникает список вопросов.
Вписываются ли QA, Backend, Frontend и системное администрирование в методологию Scrum? Что мы можем сделать, если QA и системное администрирование имеют ежедневные задачи? Можем ли мы использовать только один спринт вместо 5?
В традиционном Scrum все эти роли считаются частью одной и той же команды Scrum. Элементы бэклога релиза перемещаются в бэклог спринта, когда они фиксируются всей командой (независимо от того, какие функции есть у отдельных членов команды), а затем распределяются по задачам (опять же, всей командой).
Причина, по которой скрам обычно не разделяет функциональные области команды, заключается в следующем: 1) то, что вы QA, не означает, что вам нечего внести в обсуждения разработчиков, и 2) вы все работаете над одним и тем же. продукта и должен иметь некоторое представление о продукте в целом, чтобы вы могли уловить любые конфликты между функциональными областями. Например, ваши разработчики внешнего интерфейса должны знать, чем занимаются ваши разработчики внутреннего интерфейса, и наоборот.
Где функциональные области действительно вступают в игру, так это когда члены команды вытягивают предметы из вашей полосы «Не начато» на вашей карточной стене. Если я QA-парень, я собираюсь сначала взять задачи, над которыми нужно поработать, которые относятся к QA. Если я фронтенд-разработчик, я буду брать для работы задачи, связанные с пользовательским интерфейсом. Отдельный член команды должен работать над элементами, относящимися к его функциональной области.
Следующим всегда возникает вопрос: что делать, если не осталось задач для моей функциональной области? Ответ - попробуйте что-нибудь другое. Если над этим никто не работает, вам не помешает попробовать. Это не только даст вам представление о том, как работают другие функциональные области, но также и о том, как ваш продукт работает в областях, которые вы, возможно, не видите регулярно. Вы всегда можете передать задачу кому-то из этой функциональной области позже (когда они будут доступны), и вы узнаете что-то из этого опыта.
Это традиционная схватка, как был сформулирован вопрос. Если вы ищете совет, относящийся к вашему сценарию, это совсем другое обсуждение, и вы узнаете, почему вы делаете то, что делаете.
Переход на Scrum сложен, так как это не так просто, как иметь команду, трудная часть состоит в том, чтобы заставить членов команды работать вместе как единое целое (команду) и избавиться от старых привычек работать в изоляции. Гораздо проще сказать, чем сделать на самом деле.
Это основная причина, по которой у нас есть короткие спринты и ретроспективы, что позволяет команде проверить, как они работают вместе, и найти пути улучшения. Скрам-мастер должен следить за этими поведенческими проблемами и поднимать их в ретроспективе, спрашивая команду, как они собираются изменить свою работу.
Это лишь некоторые из общих проблем, с которыми я сталкиваюсь в новых командах; они могут или не могут относиться к вам.
Команда думает как о названиях должностей, а не о совместной ответственности за выполнение.
Нет четкого определения готовности, определяющего качество.
Команды не самоорганизуются, и скрам-мастера или менеджеры все еще пытаются контролировать команду.
Команды не учатся проверять и адаптироваться, а просто обводят одни и те же проблемы
Тестировщики считают, что только они несут ответственность за контроль качества
Скрам-мастера не ищут слабые места и возможности для улучшения, а затем представляют их команде; спросить команду, как они это исправят
Членам команды не объяснили Scrum
Инструментарий часто бывает плохим во многих компаниях, что мешает командам внедрять передовой опыт.
Первоначально Scrum выявит множество проблем, но многие из них будут проигнорированы.
Мастера-новички Scrum не видят разницы между хорошими и плохими изменениями, поскольку они не усвоили тяжелых уроков.
Внедрение Scrum в компанию требует сильного коучинга со стороны квалифицированных и опытных профессионалов. Организационные изменения — это совсем другое дело, и их нельзя проводить без надлежащего опыта.
Основная концепция scrum — объединить всех (баз данных, пользовательского интерфейса, разработчиков, контроля качества). Это творит чудеса, поскольку теперь разработчик будет знать, с какими проблемами сталкивается QA во время тестирования, и будет более внимательно относиться к проблемам, которые они обычно игнорируют до передачи QA. Точно так же QA будет знать, как разработчик работает изо дня в день, и поможет. Это происходит из принципа совместной ответственности схватки. Вся команда несет ответственность за доставку. Я не могу сказать, что доставка не удалась, так как Dev завершил работу с опозданием или QA не завершился вовремя.
Все начинают думать об улучшениях, которые они могут внести в систему, и это способствует успеху команды. Объединение всех ваших команд вместе разрушит существующую разрозненность. Здесь есть хорошее предисловие о командном мышлении Линды Райзинг .
Используемая вами методология называется ScrumBut.
http://www.scrum.org/ScrumBut
Для меня нормально вносить любые изменения в Scrum, чтобы получить более комфортную среду для команды. Но после того, как вы сделали эти модификации, просто больше не называйте это Scrum.
Мы привыкли следовать процессу Scrum в нашем проекте. Опыт был ужасен. Затем в течение года мы сделали много модификаций. У нас еще есть ретроспективы, планерки (внеплановые), двухнедельные спринты, небольшой бэклог, демо в конце спринта. Мы не измеряем скорость, и у нас есть дополнительные спринты для регрессионного тестирования и исправления ошибок. Мы присоединились к Демо и ретроспективе вместе.
У меня как у тестировщика нет возможности провести глубокое тестирование фичи, которая была завершена за 2 часа до финальной демоверсии, поэтому я говорю об этом на встрече Демо+Ретроспектива. Обычно я беру эти тестовые дни со следующего спринта.
Это не Scrum, но это работает для нас.
Расширяя то, что @NightMan и @Nikhil Gupta написали в своих ответах: это может быть очень нелогичным для вас и вашей команды, но объедините их всех как одну команду и работайте над одним спринтом.
Да, поначалу будет тяжело, но вы почувствуете общую цель и, самое главное, начнете улучшать свою организацию.
Некоторые из примеров областей, которые будут изменены/улучшены:
Проблема: мы не можем сделать это в течение того же Спринта, так как мы закончили программировать за 10 минут до окончания Спринта . Решение. Внедрите автоматизацию тестирования. Разработчики и тестировщики с самого начала написания кода для определенного элемента невыполненной работы также автоматизируют тестирование , поскольку вряд ли у вас будет достаточно времени для тестирования во время спринта. В долгосрочной перспективе вы получите огромное преимущество в производительности.
Проблема: мы не можем включить нашего администратора баз данных в состав команды Scrum, он/она является «общим ресурсом». Решение: Включите их хотя бы частично в команду и позвольте им объединяться с другими членами команды, со временем они начнут приобретать часть своего набора навыков и не будут слишком полагаться на одного конкретного человека.
Суть такова: соберите их как одну команду, попробуйте, и вы удивитесь, сколько пользы вы от этого получите.
Раньше я руководил очень похожими командами и обнаружил, что невероятно важно, чтобы все роли работали в одной команде.
Во-первых, я думаю, вам обязательно нужно управлять одной командой. Причина в следующем: члены вашей команды работают для достижения общей цели. Все в структуре вашей команды должно работать на это. У одной скрам-команды есть общие цели спринта, общие сроки, и им нужно работать вместе, чтобы добиться этого. Если вы добавляете искусственное разделение, вы просите людей играть в игру с обвинением. Я не могу сосчитать, сколько раз я слышал такие вещи, как «Ну, это сделано, это просто не было протестировано» или «Мы не могли выполнять нашу работу, потому что Боб был болен и не настроил сервер». Конечно, вы более эффективны, когда позволяете людям сосредоточиться на своей области знаний, но когда вся команда одинаково заинтересована в достижении целей, вы обнаружите, что это не так.
Во-вторых, я думаю, вы потеряете много преимуществ схватки. Чтобы немного разобраться в вашем случае, вы упомянули, что команда BE работает над API. Если это делается в отрыве от команды FE и бизнес-группы, то как они выбирают то, что пишут? Может быть очень сложно показать, что в конце каждого спринта они предоставляют готовый к выпуску набор функций, которые приносят пользу конечному потребителю. Это ситуация, которую я видел слишком много раз. Когда меня спросили, какую ценность создает работа, я услышал: «Ну, сейчас никакой, но в июне, когда все остальное будет сделано, это будет очень важно». Это здорово, пока мы добираемся до июня. Я участвовал в нескольких проектах, которые были прекращены досрочно, и компания была очень разочарована тем, что они потратили впустую все затраченное на проект время и ничего не получили от этого.
Надеюсь, это поможет.
Звучит интересно. Вы всегда будете сталкиваться с некоторыми препятствиями при переходе на SCRUM.. Чтобы решить проблему, с которой вы столкнулись..
Шеннон Дэвис
Лусеос
Рави Парех
Рави Парех