Книга: Постигая Agile

Каждый член scrum-команды – владелец проекта

Каждый член scrum-команды – владелец проекта

У каждого scrum-проекта есть владелец продукта, scrum-мастер и команда. Но не всякий проект можно назвать эффективным. Два владельца продукта, которые придерживаются разных методологий (Scrum и Waterfall), будут действовать по-разному. Scrum-мастер не делает того же, что командно-административный менеджер проекта или технический руководитель команды. Вот когда scrum-мастер, владелец продукта и команда начинают работать вместе, а не врозь, – это начинает походить на scrum-проект.

То, как scrum-мастер делает свою работу, сильно отличается от командно-административной модели управления.

В командно-административном проекте его руководитель – владелец и хранитель расписания и плана работы. Он беседует со стейкхолдерами, получает требования, меняет план работы, получает от команды расчеты, распределяет задачи и строит график. Именно такой подход Роджер использовал в проекте Lolleaderz.com – он получил требования от Ави, смету от команды и распределил задачи между ее членами.

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

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

Представьте себе такой разговор между CEO и scrum-мастером. CEO спрашивает, что он получит в следующем году, инвестируя 2 миллиона долларов в программное обеспечение. Scrum-мастер отвечает: «Пока точно не знаю, предстоят ежемесячные обновления ПО, а в конце проекта получим программное обеспечение стоимостью не менее 2 миллионов долларов». Ни один здравомыслящий CEO не одобрит такой проект. Почему?

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

Большинство из нас присутствовали на собраниях, где члены команды утверждали, что не «подписывались» под сроками выполнения работ, поэтому не несут за них никакой ответственности. В этом вина некоторых неопытных руководителей. Они ошибочно полагают, что, как только задача записана в план, команда получает непреодолимое стремление ее выполнять.

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

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

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

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

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

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

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

Рис. 4.2. В истории про свинью и курицу роль первой значительно превышает вклад второй в готовый завтрак

Так и в scrum-проекте: кто-то вовлечен частично, как курица, а кто-то полностью, как свинья. Чем это отличается от неэффективного водопадного подхода? Все сводится к тому, как действуют члены команды, руководитель проекта и владелец продукта[30].

В scrum-командах часто говорят о ролях «свиней» и «куриц». Это упрощение введено для того, чтобы легче было определить человеку ту роль, которую он играет в проекте. Вспомните проекты, в которых вы участвовали: всегда ли вы действительно связывали собственные успехи или неудачи с успехом проекта?

Дело в том, что большинство людей считают себя «курами». Они готовы внести свой вклад в проект, но не хотят рисковать, ведь проверки, повышения, достижение будущих карьерных целей, сохранение рабочего места – все зависит от успеха проекта. Также легко забыть, что люди работают за деньги. Почему люди выполняют свою работу? Что на самом деле их мотивирует? Это не обязательно успех в текущем проекте.

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

Бывало так, что вы как разработчик выбирали технологию для проекта лишь потому, что хотели изучить ее? Или в качестве руководителя проекта предпочитали agile-методологии, потому что они делают вас более востребованным? Скорее всего, да. Мы все хотя бы раз прошли через это. Каждый целеустремленный человек поступал подобным образом, и это важно признать. Но есть одно обстоятельство, предусмотренное правилами Scrum: выполнение задач спринта важнее всех прочих профессиональных целей[31], которые у вас есть. Иными словами, пока ты в scrum-команде – оставайся «свиньей».

Когда все члены команды – «свиньи», значит, каждый взял на себя обязательства и будет делать все, что необходимо для их выполнения.

Вот пример, помогающий понять, что значит брать на себя обязательства. Допустим, вы CEO компании и у вас есть обязательства перед проектом. И выясняется, что члены проектной команды устали и нуждаются в кофе. Если все заняты и не могут прерваться прямо сейчас, то несмотря на занимаемую должность вы пойдете за кофе для команды, потому что действительно имеете обязательства и убеждены: именно на это нужно потратить свое время.

В то же время в каждом проекте программного обеспечения должны быть и «куры». Например, каждый пользователь – это потенциальная «курица». Сколько раз вы были разочарованы возможностями браузера, текстовым редактором или почтовым клиентом? Вы когда-нибудь оставляли свои отзывы на сайте или отправляли их по электронной почте команде поддержки? Это один из способов превратить себя в «курицу». Раз команда прислушивается к вашему мнению и решает проблему, значит, вы помогли повысить ценность продукта. И чем активнее «курица», тем более высокую ценность она может привнести.

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

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

Когда член команды бесстрастно выполняет задачи, возложенные на него руководителем проекта, не беспокоясь о возникновении каких-либо проблем, он ведет себя как «курица». Он не чувствует своей ответственности за этот проект, впрочем, как и ответственности других членов команды. Но если этот член команды искренне заинтересован в создании правильного плана и наиболее ценного программного обеспечения для клиента и своей компании, то он ведет себя как «свинья».

К сожалению, многие компании ожидают от членов команды действий, характерных для «кур», а не для «свиней». Программисты нередко обнаруживают, что их попытки принять участие в планировании заканчиваются ничем, потому что планирование и принятие решений – это привилегия менеджеров. («Уж не возомнил ли ты себя менеджером? Отправляйся на свое рабочее место, жалкий программист!») Если такое видение характерно для команды, то ей трудно эффективно применять Scrum.

Scrum-мастеру непросто поощрять команду «кур» в их стремлении стать владельцами или «хранителями» плана. Командно-административному менеджеру, стремящемуся стать scrum-мастером, трудно ломать стереотипы. Это не помогает успешным менеджерам проектов, привыкшим единолично разрабатывать план. А высшему руководству гораздо удобнее, когда за все отвечает один человек. (Некоторые любят рассуждать о нем как о «единственном, кому должны свернуть шею».) Он чувствует свою значимость, потому что создал порядок из хаоса.

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

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

Рис. 4.3. Когда командно-административный менеджер проекта выступает в качестве «хранителя» плана, он вынуждает команду быть «курицами»

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

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

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

Для многих менеджеров проекта это совершенно новый способ планирования. Традиционные руководители проектов воспринимают план как способ мотивировать команду и фиксировать сроки выполнения работ. Они убеждены, что план заставляет команду работать, а без него сотрудники будут бездельничать. Менеджер проекта, требующий от команды чересчур оптимистичных оценок объема работ и «утверждающий» их в начале спринта, будет чувствовать себя комфортно, используя этот план для дальнейшего третирования команды. Вот почему такое отношение к «плану работ, рабочему плану» может привести к разладу между руководителем проекта и командой.

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

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

Рис. 4.4. Самоорганизующиеся команды относятся к оценке работ и планам как к неким фактам, которые могут быть выявлены, а не как к обязательствам, полученным под давлением

В успешных scrum-командах сотрудники не ограничиваются простым выполнением задач. Каждый из них – настоящий энтузиаст своего дела и старается поставлять пользователям и стейкхолдерам наиболее ценное программное обеспечение. Когда все члены команды разделяют это чувство и обязуются поставлять работающее ПО в конце каждого спринта, мы говорим о коллективной ответственности. Не каждый в отдельности берет на себя ответственность за задачи на микроуровне, а команда в целом обязуется поставлять ценные функции в бэклог. Это дает команде свободу и возможность регулировать работу по мере обнаружения в проекте новых фактов. Например, если в середине проекта Роджер и разработчики видят, что должны внести изменения в уже сделанную работу, то Ави доверит им делать это до тех пор, пока весь бэклог спринта не будет выполнен. И когда выяснится, что они ошибались (бывает и такое!) и не успевают выполнить все задачи бэклога спринта, они могут рассказать Ави, какие задачи бэклога вызывают у них беспокойство, не вдаваясь в ненужные подробности.

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

В scrum-командах нет места для «куриц». Владельцы продукта – часть команды, а значит, они тоже должны быть «свиньями». Им это не всегда удается, особенно если они чувствуют, что им пришлось работать в scrum-команде. Безусловно, большинство стейкхолдеров хотят быть «курицами», потому что работать с некоторой отстраненностью комфортнее. (Но иногда они хотят быть «свиньями», потому что это дает больше власти и возможности влиять на команду. Решение должен принять владелец продукта.)

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

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

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

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

Каждая методология имеет заложенные в ней ценности. В главе 3 мы узнали, что конкретные agile-принципы часто связаны (или глубоко интегрированы) с определенными практиками, которые являются эффективным способом использования каждого принципа в проекте. Вам уже известно, что члены команды в компании, где решения принимают исключительно менеджеры, не могут полностью посвятить себя проекту. То же самое касается ценности или метода: если они конфликтуют с ценностями компании, то не могут быть приняты.

Но если культура компании соответствует agile-ценностям и принципам, то такая команда будет гораздо успешнее, чем командно-административная. (Это один из источников «удивительных результатов», о которых говорят agile-команды.)

Вы удивитесь, увидев, насколько agile-ценности и принципы соответствуют культуре вашей компании.

Первый шаг на пути внедрения Agile – разговор о ценностях, влияющих на культуру в вашей компании. Если обнаружилось, что внедрение гибких методов вызывает проблемы, поищите несоответствия между agile-ценностями и корпоративной культурой. Это поможет сгладить переход (или, по крайней мере, почувствовать себя лучше, понять, почему все пошло не так).

Самоорганизующиеся команды работают иначе, чем командно-административные, потому что имеют разные ценности. В уже упоминавшейся книге Agile Project Management with Scrum Кен Швабер описывает пять scrum-ценностей: мужество, приверженность, уважение, сосредоточенность и открытость. Понимание того, что значит самоорганизация, начинается с изучения практической значимости принципов, которые могут быть учтены в ваших проектах.

Каждый человек ответствен за цели проекта

Такой уровень ответственности возможен, если для достижения поставленных целей команда имеет право принимать решения и каждый ее участник может высказать свое мнение о планировании и выполнении проекта. Команда проекта «Электронная книга», упомянутая в главе 3, изначально имела требование разработать шаблон для создания интернет-магазина. Для создания успешного продукта следовало проигнорировать это требование в заказе. Тогда они могли бы поставить более ценное программное обеспечение. Это можно было осуществить, если бы команда, scrum-мастер и владелец продукта сами принимали решения, избегая бюрократических процедур.

Члены команды уважают друг друга

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

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

Все сосредоточены на работе

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

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

Это вас не убедило? Тогда попробуйте провести мысленный эксперимент. Скажем, у вас две задачи, которые нужно выполнить в течение недели. Сделаем вид, будто благодаря удивительным причудам физических законов многофакторность не добавляет дополнительных издержек. Вы плавно переключаетесь между задачами, не тратя ни секунды на проволочки, и в этом случае работа займет ровно две недели. Даже в этих идеальных (но нереальных) условиях не стоит работать в многозадачном режиме. В обычной ситуации вы выполните одно задание за первую неделю, а другое – за вторую. Однако, работая над несколькими задачами одновременно, вы должны будете потратить хотя бы немного времени на выполнение второго задания в течение первой недели. В результате оно так и не будет выполнено на следующей неделе. Именно по этой причине многозадачность не приветствуется, даже если она вам вполне под силу (чего нельзя сказать о нас).

Многозадачность – не единственный фактор, отвлекающий команду. Придется часто посещать бесполезные собрания, участвовать в деятельности, не имеющей прямого отношения к проекту, а также оказывать помощь в работе над другими проектами. В хорошей scrum-команде участникам позволительно игнорировать эти отвлекающие факторы без риска для карьерного роста[32]. (Поддержка текущего проекта может быть внесена в бэклог спринта, но только если из него предварительно что-нибудь удалили, чтобы его продолжительность не увеличилась.)

Команды ценят открытость

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

Создание культуры открытости в scrum-команде – это звучит позитивно. Так оно и есть! Но зачастую это очень непросто, потому что scrum-ценности сталкиваются с уже существующей корпоративной культурой.

Во многих компаниях открытость не приветствуется, заменяется жесткой иерархией, зависящей от скрытности. Менеджеры, насаждающие такую корпоративную культуру, используют несколько способов. В отсутствие прозрачности гораздо легче сообщить команде о невыполнимой задаче («Меня не интересует, как вы это сделаете, мне нужен результат!»), заставляя людей работать сверхурочно. Это позволит менеджеру выйти сухим из воды, когда команда провалит проект («Я тут ни при чем, это они виноваты!»).

Вот почему открытость и самоорганизация при внедрении Scrum часто оказывается «третьим рельсом»[33]. Это центральное понятие, необходимое для правильного внедрения Scrum, но оно также требует от компании нового отношения к команде. Во всем, что касается подробностей разработки ПО, скрытный менеджер, спасающий свою шкуру, недопустим. Многие начинающие scrum-команды столкнулись с неудачей при попытке внедрить Scrum, потому что скрытные менеджеры стремились «залезть в душу» к каждому сотруднику.

Открытость угрожает «мультяшным» менеджерам, похожим на героя комикса с остатками волос на голове, торчащими вверх, и скрытным менеджерам. Но даже хорошим командам нелегко ее принимать. Взгляните на открытость с позиции разработчика, который рассматривается в качестве эксперта по некоторой части кода, или менеджера проекта – «хранителя» плана, или владельца продукта – единственного представителя команды, контактирующего с пользователями и решающего, какие функции войдут в ПО. Каждый из этих людей имеет полное право рассматривать это как свой вклад в проект. Бывает очень трудно открывать эти вещи команде и поощрять других ее членов делиться знаниями, имеющимися только у них, и вносить изменения без предварительного получения разрешения.

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

Члены команды имеют мужество отстаивать проект

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

Scrum-команды отваживаются жить в соответствии с ценностями и принципами, приносящими проекту пользу. Не так-то легко отражать постоянное противодействие компании, чьи ценности не соответствуют принципам Scrum и Agile. Это требует бдительности со стороны всей команды, особенно scrum-мастера. Но важно, чтобы каждый верил: ценность поставляемого ими программного обеспечения поможет преодолеть это противодействие. Чтобы провести для руководства обзор проделанной работы, также приходится запастись мужеством. Еще оно пригодится, когда вы говорите себе: «Помощь команде в создании ценного программного обеспечения важнее, чем выпячивание моего личного вклада».

Так как же сформировать у команды мужество? Как помочь ей поверить в себя и в то, что Scrum позволит не только создавать более ценное программное обеспечение, но и продемонстрирует компании ценность новой методологии?

Оглавление книги