Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
Для большей части этой книги мы говорили о практичности схватки. Хотя базовое определение scrum очень универсально — оно поддерживает широкий спектр приложений, — мы подробно и подробно объяснили механизм scrum, который может применяться в веб-и мобильных командах. (Однако многие из этих принципов и практик применимы и к другим видам разработок.)
Теперь, когда у нас есть общий словарный запас и понятия, в этой главе мы собираемся обсудить, как начать команду с Scrum. Мы более подробно расскажем о аргументах в пользу scrum при разработке веб-приложений и мобильных приложений. Мы обсудим, что такое схватка лучше всего, как она соотносится с альтернативами, и дадим ответы на некоторые вопросы, которые возникают при обосновании схватки и применении ее в компании.
Принимая меры к Scrum
Мы узнали кое-что о scrum и о том, как scrum может помочь вашему веб-проекту и проекту мобильной разработки. Следующий вопрос — как поднять вашу команду с нуля на схватку. Это будет по-разному для каждой команды, и вам нужно будет оценить собственную ситуацию, чтобы определить, насколько организация готова принять гибкий подход.
Купить в
Если ваша организация в настоящее время использует что-то вроде процесса «водопада», люди на каждом этапе цикла могут чувствовать себя комфортно, выполняя свои роли, и не будут стремиться попробовать что-то новое. Возможно, вам придется показать им, насколько более эффективной и продуктивной может быть организация с помощью процесса, основанного на разборках.
Руководители могут быть обеспокоены тем, что у них будет меньше контроля над командой, которая самоорганизуется, и у них будет меньше участия в процессе, который генерирует свои собственные идеи. Укажите им, что гибкий процесс дает им возможность смещать и корректировать приоритеты в каждом спринте, более эффективно адаптироваться к рынку и в то же время предоставлять ценную обратную связь, которую они могут использовать для управления процессом принятия решений.
Менеджеры по инженерному обеспечению могут быть смущены тем, какова их роль в команде, которая управляет собой, но это беспокойство вытекает из семантического заблуждения о концепции команды, которая является самоуправляемой. Менеджеры по-прежнему необходимы, чтобы помочь команде распределять ресурсы, решать личные проблемы, а также выявлять и удерживать таланты. Менеджеры также привносят свой собственный опыт и знания в весь процесс разработки. Инженерные менеджеры могут посвятить часть своего времени практической работе в качестве одного из инженеров в команде, но их главная обязанность — обеспечить место команды в организации, убедиться, что у них есть необходимые инструменты и ресурсы, и защищая их от отвлекающих факторов, чтобы они могли продолжить процесс схватки.
Дизайнеры могут задаться вопросом, как они вписываются в процесс схватки, когда их работа не обязательно следует тому же циклу, что и остальная часть команды. Покажите им, что Scrum предоставляет дизайнерам больше возможностей оказывать большее влияние до принятия решений, потому что дизайнеры могут быть вовлечены в каждый этап разработки и участвовать на всех этапах планирования вплоть до выпуска.
Инженеры могут быть обеспокоены сменой своих ролей, особенно если они привыкли делать что-то очень хорошо. Agile возлагает на каждого инженера большую ответственность за то, чтобы играть более широкую роль в команде, но также открывает новые возможности для обучения и роста. Стабильность, обеспечиваемая инженерам благодаря приверженности спринту, и уверенность в том, что согласованные ими требования не изменятся, пока не закончится спринт, могут быть сильными сторонами продажи в организации, где проблемы были связаны с перебоями и хаосом.
Принятие гибкой не односторонний разговор. Чемпионы схватки должны слушать и учиться на проблемах людей, которых попросят изменить свой подход в этом процессе. Для всех полезно помнить, что схватка — это всегда эксперимент, который будет длиться на протяжении всего следующего спринта, с возможностью в этот момент пересмотреть и изменить то, что, по-видимому, не работает. Иногда экспериментальный характер схватки является одним из наиболее убедительных аргументов в пользу его попытки.
Повышение квалификации
Хотя схватка не так уж сложна и может быть довольно подробно описана в книге, неоценимо иметь команду, обученную кем-то извне, кто понимает гибкость.
Объективный сторонний тренер может войти в организацию и увидеть проблемы так, как это может сделать человек внутри организации. Хороший тренер также сможет обучать людей через некоторые из более тонких или сложных аспектов процесса, обеспечивая полное понимание не только того, что они делают, но и почему они это делают.
Скрам-тренинг может занять один или два дня для всей команды, и его лучше всего проводить за пределами площадки, в нейтральном месте, где люди не будут отвлекаться на текущую повседневную работу. Не пытайтесь обойти вашу организацию, предоставляя им меньше обучения, чем нужно. Слишком легко начать применять ярлыки scrum к процессу, который не является гибким.
Предупреждение: не используйте Scrum как просто новый способ описания существующих процессов
Ошибочно думать о схватках как о новом способе говорить о существующем процессе. Scrum — это не просто набор красивых словарных слов. Есть команды, которые начинают использовать scrum-инструменты без надлежащего обучения и в конечном итоге следуют тому же неработающему процессу, который не работал для них в прошлом, применяя такие ярлыки, как «спринт» или «история», или ежедневно выполняя часовые задания. «Стоячие» встречи. Не позволяйте своей команде быть одним из них.
Активное и целенаправленное участие каждого важно для того, чтобы скрам-тренинг укоренился. Любой, кто не обучен должным образом, может не понимать, как следует применять схватку, и это может привести к разочарованию и путанице, которых легко избежать, если немного подготовиться.
В список людей, приглашаемых на тренинг, должны входить некоторые представители высшего руководства, а также все люди в организации, которые собираются участвовать в ритуалах на ежедневной основе. Вам не нужно обучать всех в компании, но любой, чья роль связана с непосредственным взаимодействием с командой разработчиков, является вероятным кандидатом.
Кадровые
Возможно, нет необходимости нанимать кого-либо нового, чтобы внедрить ссору в вашей организации. Большинство ролей в гибкой команде могут выполнять люди, которые уже существуют в организационной иерархии.
Менеджер по продукту может быть вероятным кандидатом на роль владельца продукта в команде разработчиков. Инженеры — будь то младшие, старшие или менеджеры — все должны считаться равными в команде разработчиков ради разборок, несмотря на различия в их званиях в организации. Часто инженеры QA также включаются в Scrum, что дает ряд преимуществ в плане резервирования, перекрестного обучения и организационного охвата.
Менеджеры проектов, возможно, являются лучшими людьми, уже работающими в организации, чтобы вступить в роль мастера схватки, пройдя некоторый тренинг о различиях между навыками, связанными с управлением проектами, и управлением скрамом. В крайнем случае, любой член команды разработчиков может быть обучен, чтобы действовать как мастер схватки. Тем не менее, хороший мастер схватки может быть лучшим новым наемом, который можно получить при внедрении схватки.
Кто-то, кто понимает, как работает схватка, и знаком с проблемами, которые могут возникнуть, может сгладить неровности более легко, чем человек, который только начинает работать с процессом. Для мастера схватки менее важно знать тип работы, которую вы выполняете, чем иметь кого-то, кто умеет тренировать людей через процесс схватки.
Отслеживание эффективности
Скрам — это создание устойчивого процесса, который добавляет реальную ценность, и регулярный анализ этого процесса, чтобы убедиться, что он дает желаемые результаты. Так почему бы не использовать гибкие методы, чтобы убедиться, что scrum работает на вашу компанию?
Одним из наиболее полезных методов при внедрении scrum в новой организации является установление базового уровня производительности до scrum и его использование для измерения эффективности scrum. То, где вы устанавливаете этот базовый уровень, и то, как вы его измеряете, очень субъективно. Каждая организация имеет свои стандарты и показатели производительности.
Например, команда веб-разработчиков может судить о себе по количеству сопоставимых функций, которые она может добавить на веб-сайт. Агентство мобильной разработки может отслеживать, насколько быстро они могут перейти от концепции к реализации с типичным клиентом. Возможность исправления или устранения ошибок также может иметь значение. Поспрашивайте и узнайте, как компания в настоящее время оценивает свою эффективность. (Вы можете быть удивлены тем, как мало формального внимания уделяется этому вопросу.)
Прежде чем внедрять scrum, соберите репрезентативную выборку данных об эффективности работы организации без scrum. Таким образом, у вас будет точка сравнения, которую вы сможете использовать при оценке эффективности скрама и сообщении об этом заинтересованным сторонам. Постоянно обновляйте данные, когда команда применяет схватку и развивает свои гибкие способности.
Если вы не видите улучшений, вы можете использовать процесс scrum, чтобы поднять проблему во время ретроспективы, и выяснить, что работает, а что нет, и как вы можете улучшить.