Статьи

Контракт Scrum (часть 1)

Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .

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

В следующем разделе мы увидим схватку в действии. Мы рассмотрим, как команды веб-разработчиков и разработчиков мобильных устройств работают с различными функциями Scrum. И мы начнем с команды, с которой мы уже познакомились.

Ум начинающего

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

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

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

Скрам-контракт вращается вокруг нескольких ключевых понятий:

  • Уважение Ролей
  • Охватывая прозрачность
  • Поддержание границ
  • Итерируя с надеждой
  • Совместное использование определений

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

Уважение Scrum Роли

Как мы видели в главе 3, scrum определяет ряд ролей, которые люди могут взять на себя. Эти роли служат цели в контексте схваток, и каждый должен понимать их независимо от того, как они соотносятся с положением или званием человека в организации. Scrum не о замене организационной иерархии. Фактически, схватка пытается быть настолько независимой от организационной иерархии, насколько это возможно.

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

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

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

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

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

Обеспечение прозрачности

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

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

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

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

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