Постигая Agile Грин Дженнифер
То, как scrum-мастер делает свою работу, сильно отличается от командно-административной модели управления.
В командно-административном проекте его руководитель – владелец и хранитель расписания и плана работы. Он беседует со стейкхолдерами, получает требования, меняет план работы, получает от команды расчеты, распределяет задачи и строит график. Именно такой подход Роджер использовал в проекте Lolleaderz.com – он получил требования от Ави, смету от команды и распределил задачи между ее членами.
Участники командно-административной команды всеми силами спасают свою шкуру и не берут на себя ответственность, если в проекте возникают проблемы, вызванные планами каких-то других работ. Любому, кто имеет исключительное право собственности на график и план работы, остальные члены группы и владелец продукта с удовольствием позволяют принимать решения самостоятельно.
Это одна из причин, почему Scrum не отводит отдельной роли для человека, который бы единолично был владельцем плана. Если за точность выполнения плана в команде отвечает только тот, кто исполняет роль его владельца, то все остальные, столкнувшись с неприятностями, могут отмахнуться от них, сообщив: «Это проблемы того парня». Практически в каждом проекте рано или поздно возникают трудности, потому что все они обусловлены проблемами планирования. Поэтому scrum-мастер не имеет собственного плана. Он помогает команде создать его и, что еще важнее, правильно использовать Scrum и его практики. Он дает возможность каждому члену команды участвовать в планировании, а практики и ценности Scrum помогают им ощутить свою сопричастность.
Представьте себе такой разговор между CEO и scrum-мастером. CEO спрашивает, что он получит в следующем году, инвестируя 2 миллиона долларов в программное обеспечение. Scrum-мастер отвечает: «Пока точно не знаю, предстоят ежемесячные обновления ПО, а в конце проекта получим программное обеспечение стоимостью не менее 2 миллионов долларов». Ни один здравомыслящий CEO не одобрит такой проект. Почему?
Причина в том, что он не основан на реальных обязательствах. Обязательства – это обещание сделать что-либо к определенному сроку. Настоящее обязательство тесно связано с дополнительной ответственностью, что подразумевает возможность информировать членов команды и искать решения, если обещание невозможно выполнить.
Большинство из нас присутствовали на собраниях, где члены команды утверждали, что не «подписывались» под сроками выполнения работ, поэтому не несут за них никакой ответственности. В этом вина некоторых неопытных руководителей. Они ошибочно полагают, что, как только задача записана в план, команда получает непреодолимое стремление ее выполнять.
Обязывают не планы, а наши обещания. План – это просто удобный способ их фиксации. Обязательства даются людьми и документируются в планах проекта. А это не просто бумажка. Это зафиксированная информация, и все держат ее в голове.
В scrum-команде владелец продукта – это человек, который взял на себя выполнение обязательства. Он должен пообещать конкретные результаты, которые будут достигнуты в конце проекта. Владелец продукта – ключевое звено в реализации бизнес-цели, ради которой затевался проект.
Чем эффективнее на встрече с командой он сможет передать эти задачи и позволить ей осознать обязательства, тем лучше будет выполняться проект. Когда проект сталкивается с неизбежными трудностями (техническими проблемами, изменениями в бизнесе, увольнением сотрудников и т. д.), владелец продукта должен найти способ сохранить взаимопонимание в команде и поддерживать в ней чувство ответственности. Ежедневно он принимает решения, основанные на бизнес-изменениях, и встречается с командой, чтобы узнать, правильно ли она понимает бэклог и трансформировавшиеся задачи проекта.
Владелец продукта не ждет безучастно окончания спринта. Он обязан ориентироваться в происходящем. Его дело – расставлять приоритеты в бэклоге, чтобы быть голосом заказчика в команде разработки, помогать выявлять наиболее важные и ценные истории и задачи. Он должен быть уверен, что каждый член команды правильно понимает выражение фактически сделано в контексте бэклога задач. В процессе планирования спринта вся команда решает, какие функции из продуктового бэклога нужно переместить в спринт бэклога. Выбор делается на основании их значимости и расчетов трудозатрат на их выполнение. На этом его работа не заканчивается, затем владелец продукта руководит этим процессом.
Ежедневно владелец продукта принимает активное участие в проекте. Как и все успешные agile-команды, scrum-команды во многом зависят от личного общения, которое помогает правильно понимать, что они создают. Планирование спринта, проведенное в начале, дает каждому члену команды достаточно информации, чтобы начать работу, но владелец продукта не успевает сообщить всей команде подробности. Поэтому во время спринта владелец продукта каждый день занят. Он подробно отвечает на многочисленные вопросы членов команды, дает конкретные рекомендации, как вести разработку, и рассказывает, каким образом пользователи будут применять созданные функции, а также решает массу других вопросов, касающихся работы продукта.
Владелец продукта имеет право принимать такие решения. (Если он не занимается этим, значит, занимает чужое место. Scrum зависит от способности владельца продукта принимать решения от имени заказчика, в том числе выполненную работу.) Но он не располагает исчерпывающими сведениями. Обычно в проекте принимает участие много пользователей и заинтересованных сторон, владеющих ценной информацией, поэтому владелец продукта тратит много времени на общение с ними, чтобы получить ответы на вопросы разработчиков. Кроме того, он использует такое общение, чтобы отслеживать происходящие изменения и поддерживать актуальность продуктового бэклога, где отражаются последние изменения, в которых нуждается компания. Таким образом, если есть изменения в относительной ценности различных элементов продуктового бэклога, то владелец может изменить их очередность, подготавливая тем самым команду к следующей сессии по планированию спринта.
В scrum-командах любят рассказывать басню про свинью и курицу, чтобы разобраться в том, как работает принятие на себя обязательств.
Свинья и курица идут по дороге.
Курица говорит свинье: «Давай откроем ресторан!»
Свинья отвечает: «Хм, можно. А как мы его назовем?»
Курица отвечает: «Почему бы не назвать его “Яичница с беконом”?»
Свинья, немного подумав, говорит: «Нет, спасибо, ведь тогда мне придется посвятить себя проекту полностью, а ты будешь вовлечена лишь частично»[29].
Рис. 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 позволит не только создавать более ценное программное обеспечение, но и продемонстрирует компании ценность новой методологии?
Ключевые моментыОсновополагающая модель 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-митингах получали обновленные статусы команды или вносили изменения в расписание? Если ежедневные митинги нужны не для этого, то для чего же?
Вся команда принимает участие в scrum-митингах
Ежедневные митинги – это один из наиболее эффективных инструментов, имеющихся в распоряжении scrum-команды. Они решают две важные задачи. Митинги помогают выяснить, справляется ли команда с работой, и адаптироваться таким образом, чтобы в результате был выпущен наиболее ценный фрагмент продукта. Это дает команде возможность принимать самостоятельные решения в нужный момент, придает ей гибкость в том, чтобы нужная работа делалась в правильное время надлежащим специалистом. Когда все члены команды используют ежедневные митинги, чтобы сфокусироваться на самой важной в данный момент работе, они занимаются только созданием следующего фрагмента программного обеспечения, и вся команда начинает соглашаться с тем, что митинги – это ценный инструмент, и использует его эффективно.
Многие новички в Agile привыкли считать, что мир вращается вокруг программирования. Эти разработчики проходят в офис, чтобы сделать то, для чего их наняли, и, выполнив задание, уходят домой. Это очень удобно, потому что дает возможность сосредоточиться в основном на решении технических проблем.
Но каждый программист знает, что это такое: потратить массу времени и усилий на разработку решения и вдруг в самом конце обнаружить проблему, которую он не мог предвидеть, потому что никогда ни с чем подобным не сталкивался.
Особенно трудно бывает, когда традиционный проект выполняется по принципу «вначале детальные требования» (big requirements up front, BRUF). Представьте себе все эти многочисленные этапы, через которые должен пройти проект, прежде чем попасть к разработчику. В типичном водопадном проекте разработка BRUF выглядит примерно так.
• Руководитель проекта должен определить объем работы, чаще всего исходя из бизнес-требований или документированных целей.
• Руководитель проекта должен «подписаться» под объемом работ.
• Бизнес-аналитик должен изучить цели и объем работ, а затем выяснить у пользователей и других стейкхолдеров, как они планируют использовать создаваемый продукт и какая проблема решается.
• Бизнес-аналитик продумывает варианты использования, функциональные требования и т. д.
• Программист принимает требования и делает оценки работ.
• Менеджер проекта принимает требования и оценки, строит график и согласовывает его со стейкхолдерами и руководством.
Эта длинная цепь событий должна произойти, прежде чем начнется разработка. Неудивительно, что такая «игра в испорченный телефон» мешает разработчикам получить правильную информацию.
Такая проблема характерна не только для водопадных команд. Даже команды, практикующие личное общение, будут сталкиваться с непониманием и недостаточной коммуникацией. Ведь общение лицом к лицу эффективно, но менее конкретно, чем письменная коммуникация. В результате устных переговоров три человека могут подумать, что достигли консенсуса, а на самом деле имеют три разных мнения о предмете обсуждения.
Известная поговорка гласит: «Солнечный свет – лучшее дезинфицирующее средство». Она может казаться сомнительной с точки зрения медицины, но это очень хороший совет для проектных команд. Лучший способ узнать, создает или нет команда ценное программное обеспечение, – это как можно чаще поставлять работающее ПО пользователям. Это называется обзором (или прозрачностью) и также относится к коммуникации.
Ежедневные митинги – это эффективный инструмент создания прозрачности, потому что он решает проблемы коммуникации. Если эти проблемы происходят, то становятся видимыми. Возьмем, к примеру, ситуацию, когда три разных человека уверены, что договорились, но все имеют разное представление о предмете договоренности. Что делать, если каждый из них начнет делать разные функции, которые нужно будет интегрировать в конце спринта? Такие мелкие неурядицы, вызывающие дополнительные проблемы, накапливаются, если их своевременно не устранять. Они возможны на протяжении всего проекта и приводят к постоянному ухудшению качества кода, который создает команда. Небольшое недоразумение становится причиной дефекта или даже двух. Если они обнаружены поздно, то придется делать заплатки либо большие изменения в коде. Именно так происходит во время длительного проекта: качество кода со временем ухудшается.
Но результаты будут другими, если этим трем людям достаточно 15 минут ежедневного общения, чтобы задать друг другу три вопроса.
• Что я сделал с момента нашей последней встречи?
• Что я планирую сделать к нашей следующей встрече?
• Какие препятствия есть на моем пути?
Когда члены команды каждый день рассказывают о своей работе, многие проблемы, вызванные недопониманием, успевают заявить о себе прежде, чем станут трудноустранимыми (и дорогостоящими!). Когда каждый член команды контролирует работу остальных, они сохраняют взаимопонимание по поводу целей проекта и того, как их достичь.
Во время ежедневных планерок каждый рассказывает, какую задачу сейчас решает, а остальные вносят предложения по улучшению работы. Если предложения удачные, то на следующий день работа будет сделана лучше. Команда также может обнаружить, что сотрудник трудится не над той задачей. Обычно это вызвано проблемами с коммуникацией. Команда меняет план работы в нужном направлении уже на следующий день. Такие изменения называются адаптацией. Ежедневный цикл обзора, контроля и адаптации позволяет командам непрерывно получать обратную связь о ходе проектов и улучшать качество ПО. Это одна из наиболее важных особенностей Scrum. Scrum-команды принимают решения, основываясь на опыте ведения проектов и на реальных, известных фактах[34].
Такая обратная связь исключает из scrum-команды «посредника», которым может быть менеджер проекта, не принимающий в нем непосредственного участия. Таким образом снижается ущерб от игры в испорченный телефон, сохраняется время при одновременном повышении качества. Этот цикл называется петлей обратной связи, и команда может его использовать, чтобы поддерживать выполнение проекта и быть уверенной: все одинаково понимают суть вопроса.
В подобной ситуации программистам не всегда удобно «наблюдать» за работой товарищей по команде. Однако даже самые заядлые интроверты, как правило, к этому привыкают и с нетерпением ждут ежедневных митингов. Потому что это самый эффективный способ управления коммуникацией и формирования единого понимания командной работы.
Речь идет о размышлениях умного, скептически настроенного командно-административного менеджера проекта, которые выглядят примерно так: «Хорошо, мы так сделали. Команды не утверждают, что наперед знают все о своих scrum-проектах. Коммуникация и общее понимание важны для команды. Но работу нужно выполнять и необходимо определить, кто этим займется. Как это происходит на практике? Какова реальная механика работы с задачами программирования, администрирования баз данных, тестирования или другими задачами, которые мы можем внести в свой список для работы?»
Существует распространенный метод, который используют scrum-тренеры и agile-коучи при обучении команд проведению ежедневных митингов. Суть его заключается в том, чтобы позволить команде потерпеть неудачу[35]. Люди, привыкшие к командно-административной системе, ждут от ежедневных встреч, что менеджер проекта или scrum-мастер возьмут управление в свои руки, выяснят у каждого статус проекта и укажут новые задачи. Команда считает такой способ работы естественным, она привыкла получать задание. Agile-коуч готов помочь команде проводить ежедневные митинги продуктивнее, поэтому он может посоветовать scrum-мастеру хранить молчание. Часто это приводит к неловкой паузе, которая длится минуту или две. Затем кто-нибудь начинает говорить о работе, которую проделал с момента последней встречи. Большая удача, если за этим рассказом последует вопрос «Какова моя следующая задача?».
Именно в этот момент scrum-мастер осознает свое отличие от менеджера проекта. Менеджер продолжит распределять между членами команды задачи, которые заранее приготовил. А scrum-мастер воспользуется ситуацией, чтобы организовать команде момент просветления, когда она наконец поймет, что надо делать дальше. Он мог бы это сделать, задавая вопрос «Что ты собираешься делать дальше?». Или он может просто молчать в зависимости от того, с какой командой имеет дело.
Дело в том, что сами члены команды – это ресурс, распределяющий задания. Каждый человек самостоятельно берет следующую задачу, как только закончит предыдущую.
Это происходит во время ежедневных scrum-митингов, когда остальная часть команды имеет возможность внести свой вклад и помогает исправить курс. Например, если разработчик берется за оптимизацию сложной базы данных, то администратор баз данных (DBA) может вмешаться и предложить отложить решение этой задачи на более поздний срок.
Командно-административное управление проектом начинается с предположения, что задачи по развитию проекта должны быть выполнены определенным членом команды. Причина, как правило, в наличии специальных знаний (например, администратор баз данных с навыками оптимизации БД). Это выглядит как аргумент в пользу предварительного планирования: создает узкое место в потоке работ, и команда, имеющая фиксированный крайний срок выполнения работы, должна учитывать это при планировании.
Как ни странно, это самый распространенный источник проблем в области управления проектами. Очень сложные задачи оценить гораздо труднее, чем простые. Задания, требующие конкретного специалиста или ресурса, несут больше риска, чем те, которые могут быть выполнены любым членом команды. Не стоит удивляться, что сложные задачи, подвластные лишь конкретному квалифицированному человеку (как в примере с оптимизацией баз данных), скорее всего, будут реализованы с ошибками. Хуже всего то, что менеджеры проектов зависят от этого узкого специалиста как на этапе оценки, так и в процессе выполнения работ.
Невозможно все просчитать заранее. Существует несколько решений, принимаемых в начале проекта (Java или C#? Windows или Linux? Mac или PC?). И есть еще ряд задач, которые необходимо сделать конкретному человеку. Но вообще scrum-команды не распределяют задачи в начале проекта или спринта.
Они не пытаются придумать «окончательную» последовательность задач. Причина в том, что в большинстве случаев задач, и особенно задач по программированию, команда не знает точно, сколько ей потребуется времени, пока она не приступит к работе, и зачастую она обнаруживает зависимости только тогда, когда они становятся явными. Это также относится к заданиям, которые кажутся небольшими в начале, но становятся объемными в конце (и наоборот). Конечно, хотя перед командой и стоит общая задача обнаружить, что она пропустила во время спринта, это не снимает с нее ответственности за разработку настолько сложного или окончательного списка задач, насколько это возможно, во время планирования спринта.
Поэтому вместо декомпозиции работ на задачи в начале спринта, упорядочивания задач, распределения их между членами команды перед началом любой работы и отслеживания плана agile-команды следуют простому правилу планирования. Они принимают все решения в последний ответственный момент[36].
Вернемся к истории проекта Lolleaderz.com. Роджер и Ави столкнулись с проблемой на четвертом спринте, потому что администратор баз данных затянул с выполнением одной из тех специализированных задач, которая, казалась, была полностью и официально распланирована с первого дня. Эта общая причина провала проекта вызвана чрезмерным планированием. Руководитель проекта предполагает, что комплектованием задач будет заниматься один человек – как правило, эксперт, обладающий специальными навыками. Обычно именно эти задачи имеют больше шансов «провалиться». Когда это происходит, никто другой не может справиться с этими заданиями, поэтому начинаются каскадные задержки, сверхурочная работа, которая неизбежно снижает качество результата (и возможно, приводит к поиску таким специалистом новой работы!).
Scrum-команды, принимающие решения в последний ответственный момент, могут справиться с этим по-разному. Вместо того чтобы предполагать, что администратор баз данных вовремя выполнит все эти задачи, они выписывают их на карточки (или какой-нибудь электронный эквивалент) и вывешивают на доску задач в колонку «выполнить». Во время ежедневной планерки их видят все и кто-нибудь, как правило, задает вопросы, если предполагает, что задача может вызвать проблемы в ходе спринта.
Команды, работающие с открытым исходным кодом, используют поговорку «При достаточном количестве глаз все ошибки лежат на поверхности» (закон Линуса). То же самое относится к плану. Ежедневные планерки – это способ команды полностью сконцентрироваться на деле. Когда проектная работа рассматривается так же внимательно, как и исходный код, появляется больше шансов найти ошибки в плане.
Команде гораздо проще обнаружить узкие места во время митингов, чем в ситуации, когда командно-административный руководитель проекта заранее все за всех продумал. И когда команда видит, что приближается к этим узким местам, у нее есть время, чтобы найти обходные пути. Благодаря бдительности всех участников часто обнаруживается, что последний ответственный момент для некоторых задач находится на более ранних этапах спринта, чем для других. В этом ценность цикла «обзор-контроль-адаптация»: он дает возможность выявить потенциальные проблемы и принимать решения всей командой.
Что бы произошло, если бы Роджер и Ави эффективнее проводили ежедневные митинги? Вместо распределения заданий они тратили бы время на совместную работу с командой, чтобы выявить проблемы графика и самостоятельной постановки задач. Работая как одна команда, они могли бы быстрее понять, что им нужен кто-то другой, кроме DBA, чтобы начать работать над хранимыми процедурами, чтобы успеть выполнить эту работу до окончания спринта. Или, по крайней мере, выяснили бы, что «взвалили на себя больше, чем могут унести», и успели бы вовремя уточнить, будет ли работающее программное обеспечение поставлено к концу спринта.
Берите пример со «свиньи»
Во время этой встречи каждый член команды несет ответственность перед коллегами и должен объяснить, почему обязательство, взятое на предыдущей встрече, не выполнено. Представьте себя членом самоорганизующейся команды, действительно чувствующим ответственность за проект. Что нужно знать, чтобы делать нужную работу каждый день? Прежде всего – понимать, над чем вы работаете. Но если ваша команда действительно самоорганизующаяся, то вы не можете полагаться на некоего командно-административного менеджера проекта, все решающего за вас. Нужен другой механизм, чтобы получить текущее задание. Первое, что дают ежедневные scrum-митинги, – это ваша следующая задача. Если наступает очередь ответить на вопрос, что вы будете делать начиная с сегодняшнего дня и до следующей планерки, то в случае, когда вы уже выполнили все необходимые работы, ваша обязанность – взглянуть на задачи, которые все еще находятся в столбце «выполнить», и выбрать наиболее значимую для вас и для проекта. Если вы сделали неправильный выбор, то тот, кто действительно предан позиции «свиней», скажет вам об этом.
Ведите дискуссии о задачах вживую
Ежедневные митинги нужны для выявления проблем, а не для их решения. Если не удалось решить проблему в течение пары минут во время дискуссии, запланируйте следующую встречу с теми, кто должен участвовать в решении. Многие повторные встречи будут посвящены тому, кто станет выполнять эти задачи. Именно так работают самоорганизующиеся команды: большинство задач может быть назначено самостоятельно, но некоторые из них требуют обсуждения. Только в процессе ежедневных митингов можно сказать, какие задачи требуют обсуждения, а какие нет.
Чередуйте право направлять работу команды
В проекте нет единственного «хранителя плана» или одного наиболее значимого человека. Очевидно, что некоторые разработчики опытнее других. Но хорошие идеи могут прийти в голову даже самому неопытному сотруднику, и не стоит отметать их только на этом основании. Свежий человек иногда находит серьезную проблему в задачах, с которыми предстоит иметь дело команде. Чтобы люди внимательнее слушали друг друга и не пропускали мимо ушей ценные предложения, можно привлекать члена другой команды, чтобы он начал ежедневную планерку.
Не воспринимайте это как ритуал
Хотя мы и проводим эти встречи каждый день (и оттого некоторые scrum-команды считают их «церемониалом»), каждый должен присутствовать и активно участвовать. Довольно легко считать ответы на три вопроса (что я сделал с момента последнего scrum-митинга? что я буду делать дальше? какие есть препятствия на моем пути?) ритуалом, который просто нужно соблюдать, не задумываясь о причинах. Со временем ритуалы обычно исчезают, потому что приобретают формальный характер. Но три упомянутых выше вопроса – это основа ежедневных митингов. Они нужны, чтобы выявить проблемы на ранних этапах проекта. Например, эффективный способ определить узкие места, вызванные слишком большим количеством задач, возложенных на одного человека, – это выслушать его ответ на вопрос о том, что мешает его успеху. Потому что он способен обнаружить это узкое место раньше, чем другие.
Каждый принимает участие
Каждый – это значит и тестировщики, и бизнес-аналитики, и остальные члены команды, и владелец продукта. Все они действительно имеют обязательства. Владелец продукта выполняет особенно важную работу, потому что держит всех в курсе задач бэклога, наиболее существенных для пользователей и компании. Чем лучше команда понимает значимость поставляемого продукта, тем точнее она может удовлетворить запросы пользователей. Владелец продукта вместе с остальной командой также должен ответить на три вопроса, потому что он может забыть о важности своей задачи, а ответы напомнят об этом. (Оказывается, что посвящать все свое рабочее время переговорам с пользователями, разбираться в их бизнесе и руководить бэклогом – это занятие, достойное уважения разработчиков, если они видят это воочию!)
Не относитесь к этому как к статус-митингу
Типичный статус-митинг – это отличный пример «ритуала», который мы должны совершать каждую неделю. Все мы знакомы с ритуалами и совершаем их, не задавая лишних вопросов. Предполагалось, что совещание служит двум целям: информировать команду и администрацию. Но для большинства команд это действительно всего лишь односторонняя связь, связка двух человек – члена команды и руководителя проекта. Вы можете избежать этого убедившись, что каждый присутствующий на ежедневных scrum-планерках действительно слушает выступающих. (Это означает, что не нужно проверять электронную почту, мобильный телефон и контролировать выполнение работы!) Как только члены команды начинают понимать, что ежедневные scrum-митинги реально помогают выявлять проблемы на раннем этапе и сохранять время разработчика, они признают: в этих встречах нет бюрократической волокиты, они похожи на ориентированный на разработчика инструмент, который можно использовать, чтобы сделать код лучше.
Проверьте каждую задачу
Когда вы ищете препятствия, анализируйте не только текущую работу. Просчитывайте ситуацию на несколько ходов вперед, исследуя каждый элемент в колонке «сделать», чтобы выяснить, повлекут ли они последствия. Если есть потенциальная проблема, то лучше обсудить это с командой. Иначе впоследствии можно «обжечься». Поэтому проверка задач требует доверия между всеми участниками команды. Если кто-то – намеренно или случайно – недостаточно точно описывает то, над чем работает и что планирует сделать, то остальные члены команды могут не заметить вовремя потенциальное препятствие, которое может привести к серьезным проблемам.
Измените план, если это необходимо
Адаптация как часть цикла «обзор-контроль-адаптация» – это эффективный способ самоорганизации. Допустим, команда выявляет препятствие во время ежедневного scrum-митинга и на следующей встрече понимает, что допустила серьезный просчет и не в состоянии выполнить поставку обещанной главной функции. Есть ли смысл продолжать придерживаться прежнего плана, который явно не будет работать? Конечно, нет. Бэклог и доска задач должны отражать реальный проект. Если проблема обнаружена, то вся команда должна работать вместе, чтобы исправить ситуацию. В этом случае очень кстати придется владелец продукта – «свинья». Именно он способен немедленно внести изменения в ожидания остальных людей. Помните: если люди негативно отреагируют на изменения, о которых узнали сегодня, то изменения, обнаруженные позже, они воспримут гораздо хуже.
Ключевые моментыВо время ежедневных scrum-митингов каждый член команды отвечает на три вопроса: что я сделал с момента последнего митинга? Что я буду делать, начиная с сегодняшнего дня и до следующего митинга? Какие есть препятствия на моем пути?
Команда использует эти вопросы, чтобы каждый день совместно проверять план проекта и адаптироваться к изменениям, а также для получения постоянной обратной связи на протяжении всего проекта.
Успешные scrum-команды принимают решения в последний ответственный момент, поэтому они не делают лишнюю работу и легко адаптируются к изменениям.
Ежедневные scrum-митинги принадлежат всей команде, а не только scrum-мастеру или владельцу продукта, и все в равной степени в них участвуют.
Описание: команда, разрабатывающая приложение для мобильного телефона в небольшой компанииРоджер – руководитель команды, пытающийся использовать Agile
Ави – владелец продукта
Эрик – scrum-мастер в другой команде
Акт III. Спринтерский забег в тупик
После затянувшегося обеда Эрик, Роджер и Ави разговорились о том, как использовать ежедневные scrum-митинги, и у Роджера появилась идея. На следующем митинге он попросил девушку – младшего разработчика начать встречу с ответов на три вопроса. Когда она спросила Роджера о следующей задаче, он промолчал. Молчание длилось приблизительно полминуты и вызвало всеобщее замешательство. Роджер уже засомневался, была ли эта идея действительно удачной, но тут один из старших разработчиков заговорил. После краткого совместного обсуждения младшая разработчица уже знала, что делать дальше. Она сняла с доски задач карточку, которая находилась в колонке «сделать», написала на ней свое имя и прикрепила ее в колонку «в процессе выполнения».
Последующие scrum-митинги прошли еще удачнее. Казалось, что для этого потребовалась всего одна дискуссия, и у команды вдруг начало получаться – все заговорили о задачах друг друга, и понадобилось лишь запланировать еще два обсуждения, чтобы определить, кто чем должен заниматься. Роджер был приятно удивлен, что ему придется принимать участие только в одном из них. Теперь ему предстояло заняться разработчиком, который регулярно выполнял задачи на 95 %. Оказалось, что этому разработчику требовалась серьезная помощь, но он не решался попросить о ней, чтобы не занимать время коллег (кроме того, вероятно, стеснялся признаться, что у него проблемы).
После нескольких планерок Эрику удалось порадовать Роджера: члены команды начали привыкать работать вместе. В течение следующей недели стало очевидно, что идея самоорганизации реализовалась – и они сделали это вместе как команда. Ежедневно все члены команды определяли объем работы на следующий день, помогали друг другу придерживаться выбранной стратегии и решать проблемы. Они использовали scrum-митинги для корректировки курса как команда, которая берет за основу планирования ежедневный обзор выполняемой работы.
Казалось, все шло отлично. Так было вплоть до конца спринта. Команда представила новую версию работающего программного обеспечения, точно так же как это было после предыдущих шести спринтов.
Это была катастрофа.
Ави вернулся с очередного совещания стейкхолдеров крайне разочарованный. Он ожидал, что менеджеры по обслуживанию клиентов будут в восторге от возможностей новой версии редактора Lolleaderz.com, который позволял пользователям создавать записи о собственных достижениях и делиться ими в социальных сетях. Кроме того, команда обновила функционал рекламного баннера, чтобы любой аккаунт-менеджер имел индивидуальную страницу для каждого аккаунта, показывающую самую последнюю информацию о просмотрах и расходах на рекламу.
Вместо этого большинство менеджеров выразили крайнее недоумение. Их не проинформировали, что будет столько изменений. Неожиданно каждый из них получил десятки голосовых сообщений от клиентов, в которых те интересовались новыми функциями. Раньше они пользовались графиками Роджера, где было много предварительной информации, помогающей им продавать новый функционал. Но мир вокруг менялся слишком быстро, и они почувствовали, что не успевают за ним.
У Ави новости были еще хуже. Некоторые стейкхолдеры попросили вернуть старые графики и поинтересовались, не может ли команда перенести выпуск части опций на следующий квартал. Все выглядело так, будто компания решила полностью прекратить использовать Scrum и вернуться к водопадному процессу.
Но так ли это на самом деле? Эрик слышал те же новости, что и Роджер, но выказывал необычайный оптимизм. Как вы думаете почему?
Спринты, планирование и ретроспективы
Для некоторых проектов планирование спринта – это легко. Например, когда нужно в итоге создать то, о чем люди просят на протяжении нескольких месяцев. Если есть функция, которую требуют пользователи, и вы сделаете ее высокоприоритетной, то это легкая победа. В этом случае планирование спринта – это просто следование здравому смыслу.
Но порой возникают сложности. Часто во время планирования нужно думать о том, чего хотят пользователи, что ценят, и при этом выясняется, что никогда раньше вам не приходилось об этом задумываться. Когда люди говорят, что Scrum сложен, то они имеют в виду именно это.
К счастью, успешные scrum-команды имеют для решения этой проблемы не самое секретное оружие – владельца продукта. Когда этот человек действительно тратит время на попытки понять, чего хотят стейкхолдеры и что представляет для них ценность, он может помочь команде определить цели каждого спринта и те проблемы, которые компания должна решать в первую очередь. Визуализируя эти ценности для команды и участвуя в составлении нового плана для каждого спринта, он превращает поэтапный процесс в непрерывный. И когда в конце каждого спринта команда проводит ретроспективу, владелец продукта помогает ей извлечь уроки, чтобы ожидания команды соответствовали тому, чего она на самом деле может достичь.
Какова ценность каждого нового релиза, получаемого в конце спринта?
Если вы планируете ограниченные по времени спринты, то придерживайтесь такой стратегии: когда время спринта подходит к концу, останавливайте всю работу по разработке, поскольку если команда будет поставлять работающее программное обеспечение в конце каждого спринта, то подобная стратегия принесет существенную пользу. Вы получите стандартные контрольные точки, помогающие поддерживать высокое качество ПО. Это позволяет владельцу продукта, пользователям и заинтересованным сторонам увидеть функционально полные версии, в которых встроенные опции хорошо сочетаются друг с другом. Таким образом значительно снижаются риски, потому что команде не придется дожидаться окончания проекта, чтобы интегрировать функции, созданные разными людьми, и обнаружить, что они не работают вместе.
Проведем мысленный эксперимент, который поможет понять проблемы интеграции. Представим себе, что два члена команды трудятся над разными функциями программы, сохраняющими текущий рабочий файл пользователей, но делают это по-разному. Знаете ли вы, сколько вариантов «конфликтных ситуаций» может возникать между этими функциями? Вот лишь некоторые из них: одна функция использует значок «сохранить», а другая – «файл» в меню, две характеристики имеют несовместимые способы доступа к общим ресурсам, или сохраняют файлы в несовместимых форматах, или могут перезаписать общие данные, которые управляют приложением. Возможны и другие проблемы интеграции. Можете ли вы вспомнить иные потенциальные проблемы, возникающие в процессе интеграции? Если вы давно разрабатываете ПО, то вам не нужно ничего придумывать, так как наверняка приходилось не раз сталкиваться с подобными вещами.
Объединяя все разработки вместе в конце каждого спринта, не дожидаясь для этого окончания проекта, команда может распознать и предотвратить многие подобные проблемы. Существуют и другие преимущества такого подхода: улучшение коммуникации, более активное участие стейкхолдеров и легко измеримый статус проекта. Разбивка проекта на этапы называется инкрементальной разработкой. Scrum-спринты – еще один способ разделить ваш проект на инкременты. Вот почему Scrum – это инкрементальный подход.
Но Scrum – это нечто большее. Scrum-спринты – не просто поставка работающего программного обеспечения в ограниченные сроки. Это также понимание ценности, которую данный программный продукт обеспечивает, точно определяя, какая именно ценность будет поставлена, и осознание необходимости смены курса, если есть способ, позволяющий поставить большую ценность. Когда методологии или процессы, такие как Scrum, работают таким образом, это называется итеративная разработка. То есть Scrum – это одновременно и инкрементальный, и итеративный подход.
Майк Кон в своей замечательной книге «Пользовательские истории. Гибкая разработка программного обеспечения»[37] хорошо объясняет главные отличия между понятиями «итеративный» и «инкрементальный»:
Итеративный процесс позволяет достигать прогресса за счет последовательных уточнений. Команда разработчиков берет первый отрезок системы, зная, что он неполный или слабый в некоторых (а возможно, во многих) областях. Затем она многократно совершенствует эти области до тех пор, пока продукт не станет удовлетворительным. С каждой итерацией программное обеспечение улучшается путем добавления дополнительных деталей.
В инкрементальном процессе программное обеспечение создается и поставляется частями. Каждая часть, или инкремент, представляет собой полный ряд функций. Инкременты могут быть маленькими или большими, возможно, это будет только логин системы на экране или очень гибкий набор управления данными экрана. Каждый инкремент полностью закодирован и протестирован, и считается, что работу, проделанную в этой итерации, уже не нужно будет пересматривать.
У нас уже есть план мероприятий для принятия первой части системы, пусть и известно, что она неполная или слабая в некоторых областях, и мы в несколько приемов усовершенствуем эти области, используя цикл «обзор-контроль-адаптация». Scrum-команда, применяющая инкрементальную разработку, так же как она применяет цикл «обзор-контроль-адаптация» во время ежедневных scrum-митингов, использует эту технологию для проекта в целом. В этом цель планирования спринтов, управления бэклогом спринта и проведения ретроспектив.
Вот почему владелец продукта так важен для scrum-команды и ему отводится отдельная роль. Задачи владельца продукта:
• выявить главные потребности компании и транслировать их команде разработчиков;
• понять, какие именно функции программного обеспечения команда потенциально может поставить;
• выяснить, какие функции наиболее ценны для компании, а какие второстепенны;
• работать с командой, чтобы понять, какие функции создавать легче, а какие сложнее;
• использовать понятия ценности, сложности, неопределенности, комплексности и прочие, чтобы помочь команде выбрать нужные функции для создания продукта в каждом спринте;
• делиться этими знаниями с остальными работниками компании, чтобы они могли сделать все необходимое для подготовки следующей версии программного обеспечения.
Владелец продукта выполняет очень специфические функции в проекте. Он владеет продуктовым бэклогом и выявляет наиболее приоритетные задачи, которые команда будет разрабатывать в следующем спринте. Вместе с командой участвует в планировании спринта и решает, какие из пунктов войдут в бэклог спринта, и принимает те задачи, которые были выполнены командой по поручению компании. Это означает, что владелец продукта должен иметь широкие полномочия. Если их нет (или он боится это делать), значит, человек занимает чужое место. Он также должен четко понимать, что ценно для компании. Разговаривая с людьми, владелец продукта выясняет их мнение о том или ином продукте, но окончательное решение обо всех приоритетах продуктового бэклога принимает только он.
Вот почему так важно, чтобы команда и владелец продукта с самого начала спринта договорились о том, из чего состоит каждый из этих пунктов. Когда они планируют бэклог спринта, все должны прийти к единому мнению о том, что означает слово «выполнено» для каждого пункта – это не просто «дело сделано», а «Выполнено» с большой буквы. Бэклог задач считается «выполненным», когда его принимает владелец продукта и весь результат можно поставлять клиентам. Если нет однозначного определения понятия «выполнено» по каждому пункту, то неизбежны путаница и жаркие споры в конце спринта. Но когда все имеют четкое представление о том, что это означает для каждого пункта, то команда отчетливо видит, как продвигается спринт.
Спринты ограничены по времени – обычно 30-дневным сроком (хотя некоторые scrum-команды выбирают короткие спринты – длиной в две-три недели). Когда спринт заканчивается, все «выполненные» пункты принимаются владельцем продукта. Любые пункты в статусе «не выполнено» возвращаются в продуктовый бэклог – даже если команда сделала многое (или почти все), работая над ними. Это не значит, что команда должна все начать сначала, удалить исходный код или что-нибудь отменить. Просто работа над этим пунктом не закончена до тех пор, пока он действительно не будет «выполнен» и принят владельцем продукта.
Это важно, поскольку гарантирует, что пользователи никогда не будут заблуждаться относительно того, поставлена ли ценность командой или нет. Лучше осторожничать при принятии обязательств. Обзор спринта – это специальное мероприятие, когда вся команда выступает перед пользователями и заинтересованными сторонами, чтобы продемонстрировать результаты своей работы за последние 30 дней. Если обещания не выполнены, то каждый член команды должен напрямую объяснить пользователю, что он делал и почему не справился. Это очень мощный инструмент, помогающий каждому почувствовать коллективную ответственность. Кроме того, именно в этой ситуации пользователи и стейкхолдеры могут задавать вопросы. Такое взаимодействие помогает всем объединиться и гораздо лучше понять, что действительно ценно, – и они могут начать создавать чувство настоящего доверия. Чем чаще люди встречаются и говорят о программном обеспечении (как в этом случае), тем больше доверия и свободы будет в команде и ей легче будет создавать ПО. Хотя пользователи и стейкхолдеры присутствуют на встрече и обсуждают ситуацию с командой, только владелец продукта имеет право принимать работу от имени компании.
Изредка владелец продукта и команда обнаруживают, что либо спринт был плохо спланирован, либо произошли серьезные изменения, которые не могут ждать окончания спринта. В этом случае владелец продукта имеет право остановить спринт, прекратить все работы и переместить все пункты из бэклога спринта в бэклог продукта. Подобное явление должно быть чрезвычайно редким, так как оно может разрушить с трудом заработанное доверие между командой, пользователями и стейкхолдерами.
Подумайте, что вас мотивирует, когда вы работаете. Как часто мысли, подобные перечисленным ниже, приходят вам в голову?
• «Опыт работы с этой технологией украсит мое резюме» (если вы разработчик).
• «Если я проявлю себя в этом проекте, то могу получить в команде более высокую должность» (если вы руководитель проекта).
• «Выполнение такой сложной задачи точно в срок прославит меня» (если вы менеджер проекта).
• «Если мне удастся удовлетворить такого крупного клиента, то я получу огромный бонус» (если вы менеджер по работе с клиентами, владелец продукта, стейкхолдер и т. д.).
Мы все так думаем. И это нормально.
У любого человека есть свои собственные интересы, и в этом нет ничего плохого. Но персональная мотивация не объединяет команду. Когда люди работают вместе над единой задачей, они могут достичь гораздо большего, чем каждый по отдельности. Так что, пока каждый из нас беспокоится только о том, что может дать ему работа, которую он выполняет, мы добиваемся намного меньшего, чем если бы все работали как одна команда.
Приведем пример, как личные интересы могут нанести ущерб проекту. Предположим, в команде есть человек, который может переложить неинтересные или раздражающие его задачи на другого, обычно ниже его по статусу. Большинство из нас сталкивались с такой ситуацией. Например, старшие разработчики настолько заняты созданием нового ПО, что сняли с себя обязанность исправлять ошибки. Ведь заниматься разработкой новых функций гораздо интереснее, тем более если есть возможность ознакомиться с новыми технологиями. К тому же обычно существует команда младших разработчиков (зачастую в другом городе, где меньше платят), готовая заняться исправлением ошибок. Вообще это довольно распространенная практика: набирается «команда» опытных разработчиков для создания новых функций и группа поддержки, куда входят менее опытные специалисты, которые исправляют ошибки и ставят «заплатки» в уже выпущенное программное обеспечение.
Это очень удобно для старшего разработчика, желающего «выстрелить и забыть». Ведь он уверен: допущенные им погрешности будут устранять другие люди, которых он и знать не желает. В краткосрочном плане это очень неплохой способ работы для одного человека, но с точки зрения команды и в долгосрочной перспективе это неэффективно. Без всякого сомнения, ошибки должен исправлять тот, кто их сделал. Он уже знает детали кода, потому что писал его и хорошо в нем разбирается. Чтобы исправлением занялся кто-то другой, нужно затратить усилия на коммуникацию. Правда, иногда достаточно отправить письмо по электронной почте, но порой необходимы дополнительные документы (например, отчет об ошибке и обновленная спецификация). Человеку, который займется исправлением, потребуется время, чтобы разобраться в коде. Программист, создавший его, исправит погрешность за несколько минут, а другим понадобятся часы или дни (особенно если это новички или недостаточно опытные разработчики).
В scrum-командах редко встречается ситуация, когда грязную работу спихивают на другого, потому что все сотрудники привержены общему делу. Командная культура предполагает, что более опытный разработчик сам делает грязную работу за несколько минут, а не передает ее младшему коллеге, который потратит часы. Это и есть один из источников гиперпроизводительности и «удивительных результатов» применения Scrum, которые, похоже, недоступны многим командам.
Любая (даже не гибкая) команда может стать высокопроизводительной, если введет правила, запрещающие своим старшим членам передавать «скучные» задачи младшим по должности. Но по-настоящему успешной scrum-команде не нужно создавать специальных правил для подобных ситуаций. Причина в том, что все ее участники наделены подлинным чувством ответственности за каждый аспект проекта. Поэтому старшим членам команды никогда не придет в голову желание «свалить» технические задачи на младших коллег. Они поступят разумно, выполнив ту работу, которая необходима прямо сейчас (вспомните CEO, который пошел за кофе для сотрудников)[38]. Исправление ошибок и другие задачи обслуживания просто добавляются в бэклог спринта, рассматриваются во время ежедневных scrum-митингов и выполняются надлежащими людьми в определенное время. (И последний ответственный момент для исправления ошибок, возможно, как раз именно сейчас, потому что разработчик еще ничего не забыл.)
В успешной scrum-команде все чувствуют свою сопричастность не только к коду, который создают, но и к бэклогу, и каждый старается делать все возможное, чтобы поставить работающее программное обеспечение. Бэклог спринта – это ответственность каждого, даже самый молодой разработчик ощущает, что именно он сделал для пользователей. Вот что подразумевает Кен Швабер под коллективной ответственностью в цитате, приведенной в начале этой главы: каждый член команды разделяет ответственность за бэклог и чувствует персональную ответственность за поставку наиболее ценного работающего программного обеспечения, необходимого пользователям, – включая все функции, а не только те, над которыми работает лично он.
Читать бесплатно другие книги:
