Текст книги "Scrum без ошибок"
Автор книги: Илан Голдштейн
Жанр: Управление и подбор персонала, Бизнес-Книги
Возрастные ограничения: +16
сообщить о неприемлемом содержимом
Текущая страница: 3 (всего у книги 15 страниц) [доступный отрывок для чтения: 5 страниц]
Глава 2. Отношение и способности
Если посмотреть на типичный список вакансий, можно увидеть, что большинство работодателей делают акцент на описании функциональных задач и обязанностей. Однако для успеха Scrum необходимо использовать совершенно другой подход и больше углубляться во внутренние фундаментальные установки и компетенции, необходимые участнику scrum-команды. Следующие три лайфхака помогут погрузиться глубже в роли участников scrum-команды и осознать, что им необходимо, чтобы отлично справляться со своими обязанностями.
Лайфхак 4 «Искусный scrum-мастер» опишет семь ключевых навыков, которыми должен обладать великий scrum-мастер.
Лайфхак 5 «Рок-звезды или студийные музыканты?» посвящен разбору фундаментальных компетенций, которые необходимы участникам scrum-команды.
Наконец, лайфхак 6 «Выстраиваем команду» предложит инструкцию, как собрать эффективно работающую scrum-команду.
Лайфхак 4. Искусный scrum-мастер
Я не верю, что звание scrum-мастера может быть присвоено кому-то только потому, что он или она знает правила и практики Scrum вдоль и поперек. Этого звания достойны только те, кто понимает подлинную суть этой роли и руководствуется ею в жизни. Scrum-мастер должен осознавать, что означает быть лидером-слугой. Роберт Гринлиф, основатель современного движения «Лидер-слуга», так описывает эту, казалось бы, противоречивую роль:
Все начинается с искреннего чувства, что ты хочешь служить, в первую очередь служить. И это осознание заставляет стремиться к лидерству. Такой человек резко отличается от того, кто хочет в первую очередь быть лидером из-за жажды власти или материальных благ[22]22
Greenleaf R.K. The Servant as Leader. Westfield: Greenleaf Center for Servant Leadership, 2008.
[Закрыть].
Итак, что значит быть лидером-слугой в контексте Scrum? Давайте посмотрим на некоторые фундаментальные компетенции и навыки, которыми должен обладать настоящий scrum-мастер.
ЛИДЕРСТВО БЕЗ ПОЛНОМОЧИЙ
Умение руководить без получения управленческих полномочий – главный вызов для нового scrum-мастера. Присоединиться к группе – сложно. Руководить группой – еще сложнее. Вести за собой, не обладая явными управленческими полномочиями, – сложнее всего (см. рис. 2.1).
Рис. 2.1. Лидерство без полномочий требует настоящего лидера-слуги
Руководить, используя безграничную власть и чрезвычайные полномочия, на первый взгляд кажется простым делом. Однако любой свергнутый диктатор согласится с тем, что такой подход не работает в долгосрочной перспективе. На протяжении какого-то периода диктатор может выжимать результаты из подчиненных, не испытывающих никакого уважения к руководителю. Но лишь вопрос времени, как скоро так называемое лидерство рухнет и воцарится хаос – вне зависимости от того, сколько сил было потрачено ради сохранения власти. Подлинному лидеру не требуются ни власть, ни сверхполномочия, ни, разумеется, сила. Люди хотят следовать за таким человеком и вдохновляются более деликатным стилем лидерства.
Я верю, что способность быть лидером, не имея власти, врожденная. Вероятно, ее можно развить, но это очень сложно. Для тех, у кого ее нет, но кому очень хочется ее развить, приведу небольшой список того, с чего стоит начать:
• отбросить свое эго;
• искренне заботиться как о команде, так и о продукте;
• действовать честно и вести себя одинаково по отношению ко всем участникам команды;
• излучать уверенность и скромность одновременно;
• быть максимально доступным в любое время (перерыв на душ может быть исключением).
ВНЕДРЯЙТЕ ИЗМЕНЕНИЯ БЕЗ СТРАХА
Как говорил Вудро Вильсон, 28-й президент США: «Хотите нажить себе врагов – попробуйте что-то изменить». Изменения пугают большинство людей, потому что вынуждают выйти из зоны комфорта в новый, неизвестный мир – мир, в котором сложившийся статус и профессионализм подвергнутся проверке на прочность.
Проблема для молодого и полного энтузиазма scrum-мастера заключается в том, что использование Scrum полностью изменит мир команды, в которую он пришел.
Если не внедрять изменения обстоятельно и благоразумно, то любые из них, даже конструктивные, могут быть восприняты участниками команды негативно.
Присоединяясь к новой scrum-команде, вы не должны поспешно все менять. Будьте терпеливы; наблюдайте за средой, текущими процессами, людьми, командой, технологиями и тем, что происходит в организации в целом. Будьте «мухой на каждой стене» и поговорите с максимальным количеством людей. Даже если у вас приказ сверху немедленно реорганизовать работу команды и «скраммифицировать» все вокруг, сначала оцените ее готовность к этому. У вас не будет второго шанса произвести первое впечатление: если вы начнете переход на Scrum раньше времени, внедрить изменения станет гораздо тяжелее.
Сразу найдите союзников и укрепляйте отношения с ними. Люди из вашего окружения, готовые стать ранними последователями, – те, кто рад позитивным изменениям, – окажут неоценимую помощь при внедрении новых практик.
Когда будете готовы, не медлите. Сначала реализуйте одну или две инициативы (например, начните проводить ежедневный scrum и вести единый бэклог продукта). Добейтесь нескольких небольших, но убедительных побед, расскажите о полученных выгодах и отталкивайтесь уже от этого. После того как завоюете доверие, окружающие будут гораздо лучше воспринимать ваши стремительно разворачивающиеся в команде инициативы.
БУДЬТЕ ДИПЛОМАТОМ, НЕ БУДУЧИ ДЕМАГОГОМ
Scrum-мастер – это ступица, соединяющая спицы в колесе – представителей разных отделов, которых нужно объединить для создания эффективно работающей scrum-команды.
Чаще всего вы будете сталкиваться с глубоко укоренившейся привычкой каждого отдела (например, IT-отдела и отдела маркетинга) жить в своей отдельно стоящей от всех остальных подразделений башне (см. рис. 2.2). И что еще хуже, не просто в башне, а в целой крепости с отлично выстроенной системой обороны, призванной держать чужаков из других подразделений как можно дальше. Нужны навыки искусного дипломата, чтобы одолеть эту привычку делить всех на своих и чужих. Нужно уметь донести выгоды от работы команды и научить уважению ко всем ролям, которые необходимы для выполнения работы и создания ценности для пользователя. Scrum-мастер не должен принимать чью-либо сторону или втягиваться в интриги внутри компании. Заботы scrum-мастера – эффективность и поддержание здоровой рабочей атмосферы в команде. Но ни первое, ни второе несовместимо с демагогией.
Рис. 2.2. Настоящий scrum-мастер построит мост через пропасть между отделами
Как пишет Кеннет Рубин: «Scrum-мастер должен быть открыт и честен в общении. При работе с участниками команды нет места для тайн и скрытой информации; то, что вы видите и слышите от scrum-мастера, должно быть тем, что вы получаете»[23]23
Rubin K.S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Ann Arbor: Addison-Wesley Professional, 2012.
[Закрыть].
ВЕДИТЕ СЕБЯ САМООТВЕРЖЕННО, НО НЕ ОБЕСЦЕНИВАЙТЕ СВОЮ РОЛЬ
Я помню, как смотрел «Тур де Франс» (ежегодную изнурительную велогонку во Франции) и был поражен быстрым коротким финишем одного из велосипедистов на особенно сложном и изматывающем участке. После того как все участники гонки набрали скорость, возник настоящий хаос из велосипедистов, толпой летящих к линии финиша. Всего за несколько миль до финиша два гонщика из одной команды оторвались от пелотона. Один ехал в более комфортной позиции, пристроившись за задним колесом второго – ведущего, который проторял дорогу. Проделав всю тяжелую работу, ведущий велосипедист притормозил и встал обратно в пелотон. Он потратил почти всю энергию, но вытащил товарища по команде подальше от основной группы велогонщиков и открыл ему путь к победе. Эта самоотверженная роль в велогонках выполняется ведущим. Обязанность ведущего – использовать всю свою выносливость и тактическое мышление для защиты товарища по команде ради его победы, не претендуя на личную славу.
Scrum-мастер должен выступать как этот ведущий велосипедист; признание успехов команды должно быть для него выше признания его собственных заслуг. Но такое самоотверженное поведение не означает, что роль ведущего должна быть недооценена. Да, ведущий не будет стоять высоко на пьедестале, но роль, которую он играет, должна признаваться жизненно необходимой для успеха команды.
ЗАЩИЩАЙТЕ, НО БЕЗ ФАНАТИЗМА
При описании роли scrum-мастера обычно используют метафору овчарки, которая ведет стадо через опасную местность и защищает от волков. Мне нравится это сравнение, но я предостерегаю от того, чтобы воспринимать его буквально. Хорошему scrum-мастеру не следует излишне опекать свою команду – так же как маме не нужно становиться «матерью-наседкой», которая постоянно квохчет вокруг своих детей (конечно же, с самыми лучшими намерениями) и не оставляет ребенку ни единого шанса на самостоятельность.
Scrum-мастер должен знать, когда ему нужно бросать все и спасать команду, а когда лучше позволить команде решать проблемы самостоятельно, чтобы дать ее участникам возможность расти как в личностном плане, так и профессионально.
ПОДДЕРЖИВАЙТЕ ТЕХНИЧЕСКИЕ ЗНАНИЯ, НЕ БУДУЧИ ЭКСПЕРТОМ
Технические специалисты могут стать великими scrum-мастерами, но я часто сталкиваюсь с двумя большими проблемами, когда scrum-мастером является либо технический специалист, либо эксперт в какой-то узкой области:
• Когда участник команды столкнулся со сложностями при решении задачи, непреодолимое желание помочь ему или ей возникает слишком рано, не дав возможности разобраться самостоятельно.
• Желание поучаствовать в обсуждении технических или функциональных деталей на планировании спринта будет слишком велико. А принимая активное участие в подобном обсуждении, scrum-мастер отвлекается от своих основных обязанностей – обязанностей фасилитатора.
СПОКОЙНО ОТНОСИТЕСЬ К ТОМУ, ЧТО РАБОТА НИКОГДА НЕ БУДЕТ ЗАКОНЧЕНА
Scrum-мастер может дожить до того счастливого дня, когда, посмотрев на команду, он поддастся искушению и скажет: «Мы сделали это! Я больше ничего не могу улучшить!» Однако независимо от того, как обстоят дела, помните: нет предела совершенству и улучшения возможны всегда. Более того, со временем команда будет изменяться – за счет выгорания кого-то из участников, продвижения по службе, а в некоторых (печальных) обстоятельствах – увольнения. После таких изменений снова предстоит много работы и дальнейших улучшений.
ЛИДЕРСТВО СЛЕДУЮЩЕГО ПОКОЛЕНИЯ
Настоящие scrum-мастера – часть нового поколения «просвещенных профессионалов». Роль scrum-мастера глубже и сложнее, она не сводится к перечню обязанностей из должностной инструкции. Чтобы осознать ее суть, придется смотреть в самый корень.
Вот почему я настаиваю, что при поиске новых scrum-мастеров нужно видеть картину целиком: scrum-мастером может оказаться человек с любым бэкграундом – главное, чтобы он успешно демонстрировал способности, описанные в предыдущих лайфхаках. Не каждый может стать scrum-мастером, но каждый может им оказаться.
Лайфхак 5. Рок-звезды или студийные музыканты?
Пока никто не смотрит, я бы хотел тайком вставить одну дополнительную строку в Agile-манифест:
Отношение важнее профессионализма
Несмотря на то что профессионализм – это ценно, еще больше мы ценим отношение к работе и коллегам. Не поймите меня неправильно, профессиональные компетенции, безусловно, важны, но, если бы мне пришлось выбирать между опытным разработчиком с суперответственным отношением к работе и гениальным, но вечно угрюмым и неприветливым разработчиком, я выбрал бы первого.
РОК-ЗВЕЗДЫ
Среди IT-специалистов популярен тренд набирать в команду ярких «рок-звезд». У меня всегда была проблема с этой метафорой, ведь она запутывает всех. Давайте на минуту задумаемся, какими качествами обладают настоящие рок-звезды. Уверен, вы согласитесь, они представляются нам харизматичными, творческими личностями с яркой индивидуальностью. Это ведь хорошие черты, верно? Но давайте взглянем на другую сторону медали – взрывной характер, постоянное желание привлечь к себе внимание, высокомерие и подход «есть мое мнение и неправильное». Разве это похоже на хорошего командного игрока? Думаю, нет.
СТУДИЙНЫЕ МУЗЫКАНТЫ
Теперь давайте посмотрим на студийных музыкантов. Они легко обходятся без света софитов, вместо стремления к славе поддерживают вокалиста группы в создании отличного альбома. Ветеран музыкальной индустрии Бобби Овсински пишет в справочнике студийного музыканта:
Все считают, что студийные музыканты – это творческие универсальные музыканты с невероятно широким набором разных навыков… На самом деле секрет в том, что если вы тесно работаете с другими музыкантами, звукорежиссерами, продюсерами, исполнителями, музыкальными лейблами и агентами (и кто знает, с кем еще) и с вами работать легко, значит, шансы, что вас позовут снова, весьма велики.
Работа в студии имеет свои особенности, и она отличается от игры вживую. Существует протокол студийного музыканта, и вы должны будете его соблюдать. Достаточно сказать, что, если вам нравится быть в центре внимания, студийная работа не для вас[24]24
Owsinski B. The Studio Musician’s Handbook (Music Pro Guides). New York: Hal Leonard, 2009.
[Закрыть].
Мой вывод: я бы предпочел команду студийных музыкантов команде рок-звезд.
ЦЕННОСТИ SCRUM
Как набрать команду студийных музыкантов, чтобы быть уверенным, что ваш Scrum не рухнет под грузом огромного эго участников команды и постоянных конфликтов? Стоит начать с основных ценностей Scrum. Ценности Scrum должны разделяться всеми участниками команды и лежать в основе их профессиональных качеств. Эти ценности показаны на рисунке 2.3.
Рис. 2.3. Основные ценности Scrum[25]25
В соответствии с переводом «Руководства по Скраму» (The Scrum Guide) (2017), размещенном по адресу https://www.scrumguides.org/docs/scrumguide/v2017/2017-scrum-guide-russian.pdf.
[Закрыть] должны быть приняты всеми участниками команды
В дополнение к ценностям Scrum я всегда ищу в участниках scrum-команды следующие качества: энергия, эмпатия, любознательность и дружелюбие. Давайте расскажу, что я имею в виду, более подробно.
Энергия
Я работал с несколькими умными, профессиональными разработчиками. Это были дружелюбные и добродушные люди. Похоже на портрет идеального кандидата в scrum-команду, верно? Однако те же самые разработчики обладали особыми способностями, сродни тем, что были у высасывающих души дементоров из «Гарри Поттера» (подробнее о дементорах можно прочесть в энциклопедии Гарри Поттера). Как настоящие энергетические вампиры, они могли иссушить всю положительную энергию в комнате. Особенно это проявлялось во время ежедневных scrum (стендапов), основная цель которых – дать команде энергетический заряд на весь день. Если кто-то из участников команды пополняет свой запас энергии, высасывая ее из остальной команды, посмотрите, что беспокоит этого участника и чем вы можете ему помочь.
Эмпатия
Работа в тесном коллективе требует терпения и понимания. Каждый участник команды полагается на всех остальных при достижении командных целей. Однако реальность такова, что у всех у нас случаются непродуктивные дни. Проколотая шина, опоздавшая няня, тяжелые личные обстоятельства или просто плохое самочувствие – огромное количество вещей может помешать нам достичь прогресса. Когда такие ситуации возникают (а они неизбежны), другие участники команды должны помочь и взять на себя любую дополнительную нагрузку – как, например, солдат вытаскивает раненого товарища с поля боя.
Любознательность
Команды разработки кросс-функциональны. Из лайфхака 6 вы узнаете, что в идеале они состоят из людей, обладающих «Т-образными» компетенциями. Иными словами, участники команды должны уметь грамотно действовать за пределами своих компетенций, чтобы преодолеть бутылочное горлышко узкопрофильности. Это требует желания и готовности расширять свои навыки и умения, используя любую возможность узнать больше о задачах и функционале, в которых они не являются экспертами.
Дружелюбие
Помню, как работал с асоциальным, но умным и профессиональным разработчиком. После его особенно критического выпада против нового владельца продукта я решил поговорить с ним. Наш разговор прошел примерно так:
Я: Независимо от того, что ты думал о его идеях, есть способы и средства донести свое мнение без атомной бомбардировки словами.
Он: Мне платят не за то, чтобы я заводил здесь друзей, а за работу.
Я: И да и нет, приятель. Ты прав, ты здесь, чтобы выполнять свою работу, но тебе платят еще и за то, чтобы ты работал в команде в атмосфере сотрудничества. Чем более дружелюбным ты будешь, тем более эффективным станешь.
Он: (Тишина.)
Подбирая человека в команду, я ищу не просто вежливого человека – я стараюсь идентифицировать того, кто действительно дружелюбен. Гораздо легче спешить на помощь другу, чем незнакомцу (или, что еще хуже, кому-то, кого вы не любите). И само собой разумеется, работать с друзьями намного веселее (это идет только на пользу). Как пишет Юрген Аппело, автор книги «Management 3.0»: «Это не значит, что вы должны со всеми стать близкими друзьями. Это невозможно. Но узнать немного больше о жизни коллег, об их семьях, доме и увлечениях (а им знать больше о вас) было бы отличным началом»[26]26
На русском языке: Юрген А. Agile-менеджмент. Лидерство и управление командами. М.: Альпина Паблишер, 2019.
[Закрыть].
Уважение
Уважение является одной из основных ценностей Scrum. В отличие от других ценностей Scrum, именно эту ценность порой воспринимают неоднозначно, поэтому я считаю важным более подробно объяснить, что я подразумеваю под уважением.
Давайте посмотрим правде в глаза: люди (даже очень умные) иногда не слишком удачно формулируют свои мысли. Возможно, они неправильно истолковали какую-то важную исходную информацию, а может быть, просто переволновались и выдали то, что было на уме, не отфильтровав сначала. К сожалению, я работал в нескольких компаниях, где мозговой штурм больше походил на схватку дзюдоистов, которые только и ждут ошибки друг друга, чтобы бросить «противника» через комнату, парализовав его при помощи гиперкритики.
Враждебность – последнее, что вы хотите получить, когда ваша команда креативит. Надо создать чувство безопасности, когда каждый знает: товарищи по команде будут уважительны, даже если они не в восторге от ваших идей или мнений. Как пишет Дейл Карнеги, проявляйте уважение к мнению другого человека. Никогда не говорите, что он не прав. Когда люди слышат «вы не правы» слишком много раз, их идеи (включая хорошие), скорее всего, вскоре иссякнут (см. рис. 2.4). Есть возможности не соглашаться без демонстрации неуважения.
Рис. 2.4. Усилия, которые вы готовы приложить, уменьшаются тем больше, чем чаще вам говорят: «Вы не правы!»
ВРЕМЯ ДЕЛАТЬ МУЗЫКУ
Я считаю, что успех Scrum основан на командах – людях с одинаковым позитивным настроем, готовых к коллаборации. Группа ярких, но эгоистичных людей никогда не будет работать так же хорошо, как группа сплоченных товарищей по команде, готовых к сотрудничеству.
Помните, что Scrum – это про команды, а не индивидуальности. Это не означает, что люди здесь не признаются уникальными личностями. Это значит, что их личные цели должны уступить место целям команды. Бобби Овсински пишет:
Каждый здесь затем, чтобы сыграть свою роль настолько хорошо, насколько это возможно. Когда лампочка звукозаписи не горит, люди здесь настолько же разнообразны и разобщены, как и везде, но, когда приходит время создавать музыку, каждый на 100 % сфокусирован только на музыке.
Однозначно дайте мне студийных музыкантов вместо рок-звезд, большое спасибо![27]27
Owsinski B. The Studio Musician’s Handbook (Music Pro Guides). New York: Hal Leonard, 2009.
[Закрыть]
Лайфхак 6. Выстраиваем команду
Спортивные тренеры в течение многих месяцев обдумывают, кого включить в команду. У вас не всегда будет богатый выбор кандидатов, однако так же, как при формировании спортивной команды, вам потребуется уделить много внимания подбору людей в scrum-команду. Это особенно актуально, если вы запускаете пилотный проект, где будущее Scrum для вашей организации находится в руках этой команды.
Вы должны учитывать множество факторов, подбирая scrum-команду. Это отношение к работе, совместимость друг с другом, набор профессиональных компетенций и личных качеств, размер команды, доля узкопрофильных специалистов в команде, совместно используемые ресурсы и оборудование рабочего пространства – и это только часть. Самое важное – набрать такую команду, которой будет легко проститься с предыдущей иерархической моделью управления и таким привычным взглядом на мир, как разделение на своих и чужих.
КАЖДЫЙ БУДЕТ РАЗРАБОТЧИКОМ!
В успешной самоорганизующейся scrum-команде нет места разногласиям, клановости и разделению на функциональные (например, программисты и тестировщики) и иерархические (техлиды и все остальные) подкоманды.
Scrum решает эту проблему очень просто: все участники команды разработки рассматриваются на равных и имеют одно общее название – «разработчик». Являетесь ли вы программистом, тестировщиком, UX-дизайнером или техническим писателем, в Scrum вы разработчик. С философской точки зрения мне очень нравится этот подход – он устанавливает единые правила игры и отражает тот факт, что в разработке программного обеспечения должны быть задействованы все (это больше не уникальная вотчина программиста, ранее монополизировавшего звание разработчика).
На практике внедрение этого подхода может быть сопряжено с трудностями, поэтому мне нравится объяснять его немного по-другому. Я привожу команде аналогию с медицинским специалистом: независимо от специальности все они врачи. Точно так же, как доктор может специализироваться на неврологии или педиатрии, разработчик может заниматься программированием или тестированием. Для простоты и ясности я, как правило, использую более конкретные обозначения (программист, тестировщик и т. д.) при обращении к ним. Однако, безусловно, выступаю за более широкое понимание профессии разработчика.
РАЗМЕР SCRUM-КОМАНДЫ
Я сделал этот раздел коротким, потому что в сообществе тех, кто использует Scrum, нет никаких разногласий по этому пункту. Как утверждает Майк Кон в своей последней книге «Scrum. Гибкая разработка ПО»: «Общепринятый совет: идеальный размер scrum-команды – от пяти до девяти человек»[28]28
Cohn M. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009. На русском языке издана: Кон М. Scrum. Гибкая разработка ПО. Описание процесса успешной гибкой разработки программного обеспечения с использованием Scrum. М.: Вильямс, 2016.
[Закрыть]. Добавлю, что отдаю предпочтение нижнему порогу – от пяти до семи.
СООТНОШЕНИЕ ГРУПП РАЗРАБОТЧИКОВ
Когда дело доходит до состава команды разработки, не существует единого правила для всех, потому что каждый проект и команда разные. Однако, если вы не знаете, с чего начать, предлагаю соотношение, следуя которому я работал успешно (хотя я настоятельно рекомендую вам проверить его эффективность на практике и адаптировать под свою команду).
3 программиста / 1 тестировщик / 0,5 узкопрофильного специалиста
На заметку:
• в одной scrum-команде может работать несколько узкопрофильных специалистов. Я имею в виду тех, кто сосредоточен исключительно на узких областях, – администраторы баз данных, UX-дизайнеры и отраслевые эксперты;
• 0,5 совсем не означает, что я люблю работать с карликами, просто эти разработчики будут делить свое время между двумя проектами. Мы обсудим эту достаточно спорную идею позднее;
• предложенное соотношение подразумевает высокий уровень автоматизации тестирования, который позволит тестировщику сфокусироваться на задачах, более подробно описанных в лайфхаке 18.
В этом описании идеального соотношения участников scrum-команды я говорю об узкопрофильных специалистах. Вы можете включать таких специалистов в ваши scrum-команды, но при этом важно помнить, что Scrum нацелен на завершение начатой работы как можно раньше. Чтобы использовать такой тип потока задач, необходимо придерживаться концепции «роения». То есть вместо того, чтобы несколько разработчиков одновременно трудились над разными элементами бэклога продукта, предпочтительнее ограничить количество задач и нацелить максимум разработчиков на завершение меньшего количества элементов бэклога. Ограниченная пропускная способность узкопрофильных специалистов создает бутылочное горлышко, и тогда у команды возникает проблема. Чтобы брать лучшее от обоих подходов – работу с универсальными специалистами-разработчиками и работу с узкопрофильными специалистами, – я призываю поощрять разработчиков развивать T-образные навыки (см. рис. 2.5). Как объясняет Кеннет Рубин[29]29
Rubin K.S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Ann Arbor: Addison-Wesley Professional, 2012.
[Закрыть], разработчик с Т-образными навыками обладает:
1) глубокими знаниями в своей предметной области (например, для UX-дизайна) – вертикальная палочка буквы Т;
2) широкими, но необязательно глубокими навыками в других областях (таких, как тестирование и составление технической документации) – горизонтальная палочка буквы Т.
Рис. 2.5. Поощряйте разработчиков развиваться в своей области и осваивать дополнительные компетенции в смежных областях
Участники команды с развитыми Т-образными навыками гораздо лучше создают «роение».
Майк Кон рекомендует подход, который я использую, чтобы подталкивать команды в правильном направлении:
На следующем планировании спринта договоритесь, что один из участников команды на протяжении всего спринта не будет работать по своей специальности. Он может помогать советами тем, кто выполняет эту работу, но не должен делать ее сам[30]30
Кон М. Scrum. Гибкая разработка ПО. Описание процесса успешной гибкой разработки программного обеспечения с использованием Scrum. М.: Вильямс, 2016.
[Закрыть].
Через быстро обучающихся участников команды знания будут быстро распространяться, и, хотя может показаться, что первая пара спринтов идет медленно, вы начнете видеть отдачу от этих вложений очень скоро.
ЧАСТИЧНАЯ ЗАНЯТОСТЬ
В предыдущем разделе я упомянул о выделении узкопрофильными специалистами 50 % своего времени для работы в команде. Это «частичное назначение» не слишком популярно в сообществе Scrum, и по уважительной причине. Джеймс Шор и Шейн Уорден, авторы The Art Of Agile Development, сформулировали это так:
Работники, присоединяющиеся к команде только на часть своего рабочего времени, не связаны со своими командами, их часто нет рядом, чтобы участвовать в обсуждениях и отвечать на вопросы, и они должны переключаться между задачами, что вызывает значительные, но неочевидные на первый взгляд проблемы.
Я полностью согласен с тем, что в идеале все участники команды должны посвящать 100 % времени своей команде. При этом я часто нахожу ненужным (с точки зрения требований) и нереалистичным (с точки зрения бюджета) держать узкопрофильных специалистов, таких как администраторы баз данных, посвящающих полный рабочий день одной команде разработчиков. Это не значит, что я не согласен с Шором и Уорденом, и это не значит, что не бывает случаев, когда вам в штате нужны узкопрофильные специалисты. Это значит, что нам часто приходится использовать доступные возможности по максимуму, но во многих ситуациях мы не можем позволить себе роскошь включить узкопрофильных специалистов в команду на полный день.
В качестве утешительного приза для пуристов, читающих эту книгу, отмечу: я не против распределения разработчиков по двум проектам, я категорически против их распыления на три проекта или более – подобный уровень переключения контекста контрпродуктивен.
Еще один вариант, который вы могли бы рассмотреть, особенно если узкопрофильному специалисту приходится работать над более чем двумя проектами одновременно: воспринимайте их как партнеров и тренеров для остальной команды. Вместо того чтобы включать их в состав scrum-команды, вы распределяете их между несколькими командами, и они помогают в конкретных задачах, одновременно обучая других разработчиков.
МОЖЕТ ЛИ SCRUM-МАСТЕР РАБОТАТЬ С НЕСКОЛЬКИМИ КОМАНДАМИ?
Этот вопрос постоянно обсуждают на форумах, посвященных Scrum. Прежде чем изложить свою точку зрения, поделюсь некоторыми статистическими данными, представленными на глобальной scrum-конференции (первой международной конференции по Scrum) scrum-тренером Полом Годдардом:
• 75 % scrum-мастеров менее половины своего времени действуют как scrum-мастер в своей нынешней команде;
• 45 % scrum-мастеров поддерживают две или более зрелые scrum-команды;
• 88 % scrum-мастеров берут на себя дополнительные обязанности за пределами их ответственности как scrum-мастера.
Многие в scrum-сообществе будут доказывать, что роль scrum-мастера достаточно значима, чтобы обеспечить тождество «одна команда = один scrum-мастер». Я поддерживаю этот тезис, а в лайфхаке 26 привожу множество убедительных аргументов, почему scrum-мастер должен все свое время посвящать команде. И все-таки вопрос остается открытым. Я однажды работал scrum-мастером в трех командах одновременно. Это, возможно, не идеально, но позволяет действовать эффективно, если предположить, что эти команды находятся на пути к зрелости, то есть к высокой самоорганизации. Рассмотрим подобное жонглирование командами чуть позже.
Молодые scrum-команды требуют одного scrum-мастера на полный рабочий день – это очевидно. Только возникшим командам необходим высокий уровень обучения, наставничества, сопровождения и больше всего инспекции и адаптации. Брать на себя больше одной молодой scrum-команды нереалистично.
Взрослеющие команды, которые успешно используют Scrum, не имеют системных проблем (таких как интриги и тому подобное) и идут по пути непрерывных улучшений, могут потенциально работать со scrum-мастером, ведущим две разные scrum-команды.
Наконец, «элитные», зрелые scrum-команды, которые умеют самоорганизоваться и совершенствование которых связано с точечной настройкой, могут, пожалуй, обойтись и scrum-мастером, работающим в трех похожих scrum-командах (см. рис. 2.6).
Рис. 2.6. Сколько команд может вести один scrum-мастер в зависимости от уровня развития команд
ОТНОШЕНИЕ ВАЖНЕЕ ПРОФЕССИОНАЛИЗМА
Отношение настолько важно, что я посвятил ему целый лайфхак, поэтому рекомендую вам не изобретать велосипед, а внимательно прочитать лайфхак 5.
НЕ БОЙТЕСЬ СБОРНОЙ СОЛЯНКИ (НО БУДЬТЕ ОСТОРОЖНЫ)
Имея возможность активно путешествовать и жить на нескольких континентах, я могу понять и оценить преимущества неоднородности. Это особенно очевидно в командах разработки. Поскольку считается, что разработка программного обеспечения является отраслью с международно принятыми стандартами, многие из нас работают в условиях, напоминающих Генеральную Ассамблею ООН.
Команды, состоящие из представителей разных культур, возрастов, опыта и знаний, обычно гораздо интереснее и в конечном итоге формируют питательную среду для создания прорывных решений.
Но будьте осторожны! В нескольких командах, с которыми я работал, мне пришлось деликатно разбивать подгруппы, которые сформировались на базе общего географического и культурного бэкграунда. Складывание подобных подгрупп приводило к ситуациям, в которых в открытой рабочей зоне говорили на разных языках (и я не про языки программирования).
По своей сути люди тяготеют к тем, у кого с ними много общего. Но я выступаю активно против подгрупп внутри scrum-команды. Это вызывает чувство отчуждения, не говоря уже о потенциальной потере знаний из-за того, что другие не понимают их язык.
Кроме того, я обнаружил, что участникам таких разнородных scrum-команд следует быть осторожными и выбирать выражения, чтобы шутки не показались грубыми, а дружеское подтрунивание оскорбительным.
ПРАВИЛА СОВМЕСТНОЙ РАБОТЫ
Лисса Адкинс, автор «Коучинга agile-команд», рекомендует формировать то, что она называет «правилами совместной работы», для разрешения ситуаций, подобных описанным выше.
Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?
