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