11 октября 2018 2181
Недавно у меня был очень интересный разговор со Стивом Портером из Scrum.org. Мы обсуждали Скрам-команду, в которой разработчики не “вытягивают” свою работу сами. Вместо этого наиболее опытный разработчик во время Ежедневного Скрама выбирает, какие элементы Бэклога Продукта команда будет делать сегодня и сам определяет, кто будет работать над каждым элементом бэклога. Этого разработчика очень уважают все члены Команды Разработки. Вопрос в том, должен ли Скрам-мастер как-то вмешиваться в эту ситуацию?

socrates1-2x.jpg

Недавно у меня был очень интересный разговор со Стивом Портером из Scrum.org. Мы обсуждали Скрам-команду, в которой разработчики не “вытягивают” свою работу сами. Вместо этого наиболее опытный разработчик во время Ежедневного Скрама выбирает, какие элементы Бэклога Продукта команда будет делать сегодня и сам определяет, кто будет работать над каждым элементом бэклога. Этого разработчика очень уважают все члены Команды Разработки. Вопрос в том, должен ли Скрам-мастер как-то вмешиваться в эту ситуацию?

С одной стороны, в Руководстве по Скраму не сказано, что члены Команды Разработки должны сами выбирать элементы Бэклога для работы. Также там сказано, что никто (даже Скрам-мастер) не может указывать Команде Разработки, как превратить Бэклог Продукта в готовые к релизу Инкременты. Иными словами, на первый взгляд Команда Разработки следует Руководству по Скраму, и необходимости во вмешательстве Скрам-мастера нет. Однако есть ряд причин, по которым ситуация может требовать вмешательства Скрам-мастера. Вот две из них: то, как понятие «Команда Разработки» определено в Руководстве по Скраму, и ценности Скрама.

Во-первых, такая ситуация может противоречить определению того, что есть Команда Разработки с точки зрения Скрама. В руководстве по Скраму не упоминается «группа разработки». Там есть «Команда Разработки». Я считаю, что слово «команда» используется намеренно, и одна из основных причин, по которой Скрам настолько эффективен, заключается в том, что он основан на команде, а не на группе. По определению команда – это группа людей, которые разделяют общее предназначение команды и набор общих целей; члены команды преданны друг другу и достижению цели. В контексте Скрама мы можем рассматривать создание готового к выпуску Инкремента продукта в качестве предназначения, а Бэклог Спринта – в качестве набора Целей команды. 

Однако быть преданным тому, что ты не взял на себя добровольно, крайне сложно. Более того, когда один человек ставит задачи другому, назначает ему определенный фронт работ, то делает тем самым второго человека менее мотивированным на выполнение этой работы. Принятие на себя ответственности зависит от конкретного человека, но если человек не принимает самостоятельное решение, он не берёт на себя ответственность за это решение. Лучшее, что вы можете получить в такой ситуации, - это обязательства, но не ответственность. Таким образом, назначая элементы Бэклога членам Команды Разработки, ведущий разработчик разрушает способность команды быть собственно командой. Эта ситуация может также нарушать принцип равенства членов Команды Разработки: «Скрам не признает подкоманд в Команде Разработки, независимо от областей, над которыми необходимо работать (например, тестирование, архитектура, эксплуатация или бизнес-аналитика)». Здесь же может оказаться, что «все разработчики равны, но некоторые разработчики более равны, чем другие».

shutterstock_521540137-min.jpg

Во-вторых, такое положение дел противоречит ценностям Скрама. Цитируя Руководство по Скраму: "когда Скрам-команда опирается на ценности Скрама (преданность, смелость, сфокусированность, открытость и уважение) и разделяет их, “три кита” фреймворка — прозрачность, инспекция и адаптация — реализуют и создают атмосферу всеобщего доверия». Я уже показал выше, как описанная ситуация может разрушить способность команды быть преданными целям Скрам-команды. Также эта ситуация может быть признаком отсутствия уважения. Руководство по Скраму определяет уважение следующим образом: «участники Скрам-команды уважают профессионализм и самостоятельность друг друга». Ситуация, когда кто-то определяет за остальных, какую работу каждому нужно делать в тот или иной день, далека от того, чтобы демонстрировать уважение к членам команды как к самостоятельным профессионалам. Это скорее может свидетельствовать об отсутствии доверия и низкой оценке профессионализма остальных. Такая ситуация может быть очень токсична для командного духа и производительности.

Основываясь на этом я пришёл к выводу, что эта команда не следует Руководству по Скраму и Скрам-мастеру следует вмешаться, повысив осведомлённость команды о том, что происходит и как это влияет на команду. Будучи довольно уверенным в своём заключении, я поделился этим со Стивом, и он ответил: «Будь осторожен, рассуждая о том, как команда разработчиков должна работать. Если ты видишь поведение, которое ты не понимаешь или которое, по твоему мнению, можно улучшить, подойди к ситуации с любопытством. Помни, что те, кто выполняет работу, лучше понимают, что правильно и неправильно». 

Я подумал: «Ага!.. Я всегда говорил о “сознании начинающего” и важности контекста. И сам допустил ошибку, избегать которую я учил других!». Я давно работаю в крупных компаниях, и мне платят за то, что у меня есть ответы. В какой-то момент я понял, что успешен потому, что задавал вопросы и помогал своей команде найти наилучший ответ, а не выкладывал им свои решения. Именно поэтому я начал изучать Agile, Скрам, самоорганизацию, командообразование и тому подобное. Именно поэтому я не перестаю учиться. И это то, чему я учу других. "Помните о неведении" - таков был мой совет моим ученикам. И оказалось, что я не смог последовать собственному совету. Очень отрезвляющий момент!

shutterstock_482235484-min.jpg

При работе с людьми очень редко всё именно так, как оно выглядит на первый взгляд. Каждая ситуация, каждая проблема очень специфичны и зависят от контекста, поэтому у вас могут быть разные решения для двух (казалось бы) похожих вопросов – они находятся в различном контексте. Поэтому поверхностного взгляда недостаточно, даже если все выглядит очевидным, потому что есть большая вероятность, что это не так. Очень приятно быть "умным парнем" и иметь ответ на любой вопрос. Быть экспертом. Как пишет Майк Мэддок в статье для блога Forbes: «как экспертам, нам платят больше, доверяют больше, а иногда даже больше чествуют. Наши родители гордятся нами, наши партнёры гордятся нами, и иногда даже наши дети думают, что мы крутые». И это приводит к очень прямолинейному мышлению. Когда мы знаем слишком много и забываем урок Сократа о том, что мы ничего не знаем. И это приводит к плохим решениям, иногда с плохими последствиями, иногда с катастрофическими последствиями.

Я не хочу быть таким человеком.

Я хочу избежать ловушки эксперта. Я предпочитаю сомнение, любопытство и открытость новому, за счёт чего я могу совместно с командой находить лучшее решение. Я буду спрашивать себя: “Что тут есть ещё? Чего мне здесь не хватает? Что может привести меня к противоположному выводу?». Поэтому я написал мантру на карточке, которая у меня сейчас в кошельке и перечитываю её несколько раз в день:

ПОМНИ

          О

             НЕВЕДЕНИИ.


Последние статьи в блоге

Платформа сертификации IBS получила аккредитацию АПКИТ

Ассоциация предприятий компьютерных и информационных технологий (АПКИТ) приняла новый регламент сертификации ИТ-специалистов.

Новости
10 марта 2025

Специальные акции на учебные программы

У нас отличная новость для всех, кто стремится развивать свои навыки в мире ИТ.

06 марта 2025

Как остановить спам-атаку

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

06 марта 2025

Учебный центр IBS подписал партнерское соглашение с ООО «РусБИТех-Астра», разработчиком российской операционной системы Astra Linux.

Теперь мы можем проводить авторизованное обучение по работе с Astra Linux для специалистов в области информационной безопасности.

17 февраля 2025

Двойная выгода: покупай один курс — получай второй за 50% стоимости!

Воспользуйтесь возможностью изучить более глубокие аспекты одной области — например, при покупке курса по Java, архитектуре ПО, управлению проектами, системному и бизнес-анализу, тестированию ПО и Big Data вы можете получить второй курс этой же тематики за полцены! Не упустите шанс развить свои навыки и поднять свою карьеру на новый уровень. 

29 января 2025

Сертификация преподавателя Java-разработки для крупного провайдера ИТ-обучения

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

Новости
21 января 2025

Системный аналитик 100 lvl — дорожная карта развития

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

23 декабря 2024

Платформа сертификации IBS признана лучшим digital-решением для корпоративного обучения

Центр сертификации IBS стал обладателем Гран-при премии «Смарт пирамида» — одной из самых престижных российских премий за достижения в области обучения и развития человеческого капитала.

20 декабря 2024

Учебный центр IBS получил сертификат ГОСТ Р ИСО 9001-2015

В октябре 2024 года Учебный центр IBS получил сертификат соответствия ГОСТ Р ИСО 9001-2015. Это важное достижение подтверждает, что мы придерживаемся высоких стандартов качества и результативно управляем образовательными процессами организации.

19 декабря 2024

9 курсов со скидкой до 50%

Друзья, в январе стартует 9 курсов, обучение на которых можно купить со скидкой до 50%*! 

15 декабря 2024

8 заблуждений про тестирование

Тестирование программного обеспечения окружено множеством заблуждений. Эти стереотипы нередко приводят к недопониманию его реальной роли и важности для успешного создания продуктов. Рассмотрим восемь самых распространенных мифов о тестировании и объясним, почему они не соответствуют действительности.

15 декабря 2024

Путь к Fullstack-тестировщику: что нужно знать о ручном и автоматизированном тестировании?

Тестирование программного обеспечения — одна из самых востребованных областей в IT. И часто новички и даже опытные специалисты, желающие строить свою карьеру в этом направлении, часто сталкиваются с вопросом: какое тестирование выбрать — ручное, автоматизированное или Fullstack? У каждого из этих направлений свои особенности, преимущества и требования к знаниям. В этой статье рассмотрим каждое из направлений, их плюсы и минусы, области применения и навыки, необходимые для успеха.

15 декабря 2024

Совет по развитию сертификации ИТ-специалистов при АПКИТ аккредитовал «Платформу сертификации IBS»

Директор департамента обучения и развития IBS Владимир Гернер участвовал в заседании Совета по сертификации ИТ-специалистов при АПКИТ.

Новости Жизнь компании
08 октября 2024

Java-сертификация: IBS в сравнении с Oracle

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

Новости
04 октября 2024

Исследование IBS: число новых ИТ-решений в реестре ПО выросло в 2023 году более чем на треть

Анализируем ситуацию на рынке российского ПО.

Жизнь компании
01 октября 2024

6 суперспособностей Fullstack-тестировщиков, которые напоминают навыки животных

Читайте о скиллах, которые делают тестировщиков востребованными на рынке труда.

27 сентября 2024

5 мифов о системных аналитиках

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

20 сентября 2024

Методология 12 факторов: как успешно разрабатывать облачные приложения

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

12 сентября 2024

Баги, которые стали фичами

Многие вещи, которые мы используем ежедневно, были случайно открыты. В честь дня тестировщика рассказываем про 5 багов, которые стали фичами.

09 сентября 2024

Шаблоны облачного проектирования

Читайте про наиболее популярные шаблоны облачного проектирования: шаблон Bulkhead и шаблон Sidecar.

06 сентября 2024

Не нашли, что искали? — Просто напишите, и мы поможем

Корпоративное обучение Оценка персонала Сертификация О нас Стань тренером Блог
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.