Текст книги "Постигая Agile"

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

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

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

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

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

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

Это одна из основных причин успешной работы 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]32
  Эти советы кажутся нереальными? Задевают за живое? Если команда не имеет права игнорировать отвлекающие факторы, то, возможно, они не должны ее отвлекать. Потому что отвлекающий фактор, который нельзя проигнорировать, превращается в требование. Если вы работаете в команде, где игнорирование «отвлекающего фактора» – серьезная проблема для проекта, то мышление вашей команды может стать препятствием для внедрения Scrum и с этим придется что-то делать.


[Закрыть]. (Поддержка текущего проекта может быть внесена в бэклог спринта, но только если из него предварительно что-нибудь удалили, чтобы его продолжительность не увеличилась.)

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

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

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

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

Вот почему открытость и самоорганизация при внедрении Scrum часто оказывается «третьим рельсом»[33]33
  Американский жаргонизм, означающий «вопрос, который не следует затрагивать или поднимать» (по аналогии с контактным рельсом в метро). Прим. ред.


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

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

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

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

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

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

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

Ключевые моменты

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

Чтобы «осознать» Scrum, члены команды должны выйти за рамки простого внедрения практик и четко осознать, что означают самоорганизация и коллективная ответственность.

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

Чтобы стать успешными scrum-командами, необходимо глубоко усвоить scrum-ценности: приверженность, уважение, сосредоточенность, открытость и мужество.

Описание: команда, разрабатывающая приложение для мобильного телефона в небольшой компании

Роджер – руководитель команды, пытающийся использовать Agile

Ави – владелец продукта

Эрик – scrum-мастер в другой команде

Акт II. Обновления статуса – это только для социальных сетей!

Вернемся к команде Lolleaderz.com. Роджеру и Ави требовалась помощь. Они знали, что в Hover Puppy существует еще одна команда, имеющая большой опыт работы со Scrum. Роджер попытался поговорить с представителями этой команды, чтобы разобраться в непонятных вещах, но запутался еще больше. Казалось, у них все точно так же, как и в его команде: спринты, ежедневные scrum-совещания, ретроспективы, бэклог, владелец продукта и scrum-мастер. На первый взгляд, обе команды делали одно и то же, но в одной получались отличные результаты, а другая медленно чахла. Роджер и Ави встретились с Эриком – scrum-мастером другой команды. Он достиг больших успехов в Scrum и был рад помочь товарищам найти причину их неудач.

Первым делом Эрик спросил: «Есть ли у вас коуч?» Роджер не сразу его понял. «Это наставник, – объяснил Эрик. – Человек, помогающий правильно внедрять Scrum. Лучшего способа не существует. Если бы не он, моя команда ничего бы не добилась». И здесь Роджер впервые смог оценить Ави как продавца, потому что к концу дискуссии тот убедил Эрика стать коучем в команде Lolleaderz.com.

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

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

На следующий день Эрик наблюдал за другим scrum-митингом, который проходил по тому же сценарию. Он заметил, что один из членов команды сообщил о выполнении задания на 95 %, и вспомнил, что этот сотрудник ранее уже называл ту же цифру. Эрик сказал об этом Роджеру. «Да, похоже, он опаздывает. Не волнуйся, я контролирую ситуацию и уже обновил задание. Он постоянно затягивает сроки, поэтому я заранее учел непредвиденные обстоятельства. Если он чересчур забуксует, то я уверен, что об этом узнают Ави и генеральный директор».

В тот же день Эрик встретился с Роджером и Ави. Он начал с главного. «Роджер, ты используешь scrum-митинги для управления своим планом проекта. Что происходит, если член команды запаздывает? Ты обновляешь свой график, и получается, что работа сделана, не так ли? За исключением того, что само по себе обновление диаграммы Ганта не уменьшает сдвиг окончания проекта на более поздний срок».

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

Вы можете объяснить, почему у Эрика возникли проблемы с Роджером и Ави, которые на ежедневных scrum-митингах получали обновленные статусы команды или вносили изменения в расписание? Если ежедневные митинги нужны не для этого, то для чего же?