Войти в систему
Войти с помощью соц. сетей:
Существует миф, что художники только и ждут, когда их поразит гениальная идея, и затем без особых усилий претворяют ее в шедевр. Все это сказки. На самом деле инновация требует преданности делу, кропотливого труда и дисциплины. Возьмем, например, американского художника и фотографа Чака Клоуза. Его фирменная техника — писать картины по фотографиям. При этом он делит холст на мельчайшие квадраты и заполняет их завитушками — своеобразными аналогами пикселей. Если смотреть вблизи, то видны эти отдельные формы, но при отдалении картина складывается в портрет. Вот как Клоуз описывает процесс работы над картиной (Oberkirch, 2008):
Мои картины создаются поэтапно, по одному квадратику за раз, что напоминает работу писателя… Среди преимуществ поэтапной работы могу назвать то, что у меня нет необходимости ежедневно изобретать колесо. Сколько я сегодня сделал, столько и сделал, нравится вам это или нет. Мне не нужно ждать вдохновения. Для меня не существует удачных и неудачных дней. Каждый день — это продолжение той работы, которую я делал накануне.
К счастью, Scrum дает возможность работать поэтапно, шаг за шагом претворяя в жизнь продукт, так что результат каждого нового спринта базируется на результатах предшествующих спринтов. Состав спринта вырабатывается и корректируется на нескольких обязательных встречах команды. Встреча для планирования спринта происходит вначале, демонстрация результатов спринта и ретроспективное совещание замыкают цикл. Совместные встречи — ценная возможность для взаимодействия и общения, обмена информацией и сотрудничества. Джерри Лэйборн, владелец продукта Ript — программы визуального планирования, — согласен с этим (Judy, 2007):
За тот год, когда мы создавали [Ript], я пропустил только одно совещание из тех, что проводились раз в две недели. Я посещал их, потому что они были действительно интересными и я многому на них учился.
Эта глава особенно важна для владельцев продукта. В ней говорится об их участии в scrum-митингах и предлагается несколько советов по эффективной работе с командой.
Совещание по планированию спринта позволяет команде запланировать свою работу на спринт и сформулировать цель спринта, тем самым закладывается основание для самоорганизации работы. Обязанность владельца продукта — убедиться в том, что бэклог продукта хорошо проработан, приоритеты в списке элементов расставлены, а самые приоритетные из них детально описаны до совещания по планированию спринта. Кроме того, на совещании по планированию спринта нужно прояснить требования и ответить на возможные вопросы команды.
Роль владельца продукта во время планирования спринта состоит в том, чтобы помочь команде осознать, что должно быть сделано. Команда же прикидывает, каков объем работы и как ее можно сделать. Вы не должны указывать команде, сколько работы нужно выполнить за спринт, или определять состав задачи от имени команды, не посоветовавшись с ней. Это прерогатива команды. И она должна брать на себя только такие обязательства, которые действительно может выполнить. Ограничение объема работы на спринт определяется скоростью работы команды и ее размерами, что в итоге создает оптимальный темп разработки: «Заказчики, разработчики и пользователи должны уметь до бесконечности выдерживать постоянный темп разработки» (Beck et al., 2001). Бесполезно пытаться добиваться слишком амбициозной цели в течение одного спринта, только чтобы полностью истощить свои силы к следующему. Scrum отдает предпочтение равномерному, устойчивому потоку задач из бэклога продукта в спринты. Надежность важнее ложных амбиций, это необходимое условие для составления реалистичных прогнозов. А излишнее давление убивает творчество.
Помните, что решение команды — это не гарантия. Новая команда может лишь через два-три спринта понять, как принимать решения, которые она сможет воплотить. Кроме того, в разработке ПО слишком много неизвестных слагаемых: неопределенность и риск идут рука об руку с инновациями. Закон Мерфи гласит: «Все, что может пойти не так, обязательно пойдет не так». Риски могут проявиться в любой момент, а проблемы не всегда будут быстро решаться. Случается, что цель спринта не достигнута, — но это должно быть исключением, а не правилом. Если это все-таки произошло, используйте ретроспективный анализ спринта, чтобы определить основную причину и выработать меры по исправлению ситуации.
Как команда понимает, что работа действительно сделана? И как владельцу продукта определить, что какой-то участок работы был успешно внедрен? Для этого необходимо заранее выработать критерии готовности, то есть описание требований, которым должно соответствовать каждое обновление. Эти критерии обычно требуют превращения элементов бэклога продукта в работающие программы, тщательно протестированные и задокументированные. Требования должны быть соответствующим образом внедрены, протестированы и задокументированы в ходе одного спринта. Исключение — концептуальные спринты, цель которых — не выдать готовый продукт, а получить необходимые для создания концепции продукта знания. У этих спринтов есть собственные критерии готовности.
Перед первым спринтом владелец продукта должен встретиться со scrum-мастером и командой и выработать критерии готовности. В некоторых проектах в критерии готовности включаются конкретные цели — например, тестирование единиц ПО. После выработки критериев они должны быть записаны и доступны в течение всего проекта.
Такой вид scrum-собрания позволяет команде управлять своей работой изо дня в день и выявлять препятствия и проблемы. Владелец продукта должен постоянно посещать их. Это отличная возможность понять, как идет работа, и выяснить, не нужна ли команде помощь (например, нужно быть готовым отвечать на вопросы, анализировать результаты работы или помогать устранять препятствия). Можно также сообщить информацию и рассказать команде, над чем вы работаете сейчас и что планируете делать дальше. Часто работа владельца продукта предоставляет важную информацию о действиях на уровне релиза и на периферии проекта.
Во время ежедневных scrum-митингов желательно не вмешиваться в самоорганизацию команды, формулировать и назначать задания, комментировать прогресс отдельных сотрудников. Если вас беспокоит ход работы, делитесь своим мнением конструктивно — например, задавая вопросы. Чтобы прояснить ситуацию с достижением цели спринта, можно сказать: «Я заметил: диаграмма сгорания задач для спринта показывает, что осталось еще много работы до завершения спринта. Вас это беспокоит?» Задавая вопросы, вы привлекаете внимание команды, но оставляете выбор действий за ней.
Нерешенные проблемы размножаются как грибы после дождя. Вот почему Scrum уделяет особое внимание борьбе с препятствиями — выявлению и устранению проблем, которые мешают работе и причиняют вред проекту. Члены команды рассказывают о препятствиях и проблемах на ежедневном scrum-митинге, и scrum-мастер отвечает за то, чтобы они были устранены как можно быстрее. Даже если работа над проблемами кажется замедлением хода проекта, она препятствует возникновению более серьезных трудностей и долгих отсрочек. «Проблемы — это сокровища, — пишет эксперт по бережливому управлению Паскаль Деннис. — Они дают возможность учиться и совершенствоваться» (Dennis, 2006; 19).
Спринт-бэклог включает в себя все действия, необходимые для достижения цели спринта. Команда создает спринт-бэклог на совещании по планированию спринта и регулярно его обновляет — как минимум раз в день. Во время этих обновлений команда может добавлять новые элементы или исключать те, которые становятся неактуальными, она также фиксирует количество очков историй, оставшееся на каждую задачу. Очень удобно работать с доской задач, размещенной в рабочем помещении и доступной каждому сотруднику. Диаграмма сгорания работ позволяет команде понять, как она идет по дистанции и насколько вероятно достижение цели спринта. После этого команда может внести соответствующие изменения в рабочий процесс.
Спринт-бэклог и диаграмма сгорания работ для спринта в основном обслуживают команду, поскольку они облегчают самоорганизацию. Однако они также приносят пользу и владельцу продукта. С их помощью можно понять, насколько вероятно выполнение поставленной задачи. Однако все это не является средством отчетности перед заинтересованными лицами. Если, например, клиенты и руководство хотят узнать о ходе работ в течение спринта, их можно пригласить на ежедневный scrum-митинг в качестве слушателей, а на обзор итогов спринта — как активных участников.
Обзор итогов спринта способствует созданию успешного продукта. Он дает scrum-команде возможность взаимодействовать с заинтересованными лицами, рассмотреть ход разработки продукта на данное время и принять решение относительно дальнейших действий. Это лучше, чем просто верить, что все идет по плану. Среди заинтересованных лиц могут быть представители маркетинга, продаж и сервиса, а также клиенты и пользователи. Например, один клиент Primavera Systems — поставщика программных решений для управления проектами, программами и портфелями — посещал обзоры итогов спринта компании, считал их чрезвычайно полезными, ценил прозрачность и возможность повлиять на разработку продукта. Отметим, что подготовка к обзору должна быть сведена к минимуму. Обзор — это рабочая процедура, а не шоу. Командам стоит воздержаться от формальных презентаций и не использовать слайды. Цель обзора — не произвести впечатление или вызвать ажиотаж, а обеспечить прозрачность, проанализировать продукт и выработать меры по его улучшению.
Задача владельца продукта — открыть совещание, сравнив обновление продукта с целью спринта, действительное с желаемым, чтобы определить степень достигнутого прогресса. Необходимо провести тщательный анализ обновления продукта и принять или отклонить каждый элемент бэклога продукта, внедрить который обязалась команда. Лучший способ — взять клавиатуру и провести несколько тестов. Не забывайте: принимать нужно только те элементы продукта, которые соответствуют критериям готовности, а если применяются пользовательские истории — то и критериям приемлемости. Не следует принимать незаконченные или содержащие ошибки элементы. За них выставляется ноль очков, и они отправляются обратно в бэклог продукта. Если частично сделанной работы становится слишком много, это ставит под сомнение прогресс и ведет к аномалиям в диаграмме сгорания работ.
Владелец продукта, давая отзыв на работу команды, должен передавать ей четкие и конструктивные послания. Необходимо проявлять уважение к усилиям команды и ее доброй воле. Если вам нравятся достигнутые результаты, похвалите команду. Если нет — так и скажите. Движение к цели спринта — это дело всей команды. Поэтому нужно обращаться ко всей команде, не выделяя никого конкретно. Проявляйте уважение к коллегам — членам scrum-команды, следите за своими намерениями и действиями и всегда думайте о том, как помочь команде двигаться вперед.
После определения степени прогресса заинтересованные лица должны выступить с отзывами на обновление продукта. Нравится ли им то, что они видят? Какие изменения нужно внести, чтобы продукт стал более успешным? Продолжает ли действовать концепция? Что с функциональностью: не слишком ли ее мало или много? Не внедрена ли какая-то функция некорректно? Может быть, стоит изменить внешний вид продукта и то, как он воспринимается? Если это нужно, то почему? На этом этапе нередко обнаруживаются новые требования или выясняется неактуальность старых. Заметим, что отзывы заинтересованных лиц позволяют владельцу продукта и команде увидеть обновление их глазами, что устраняет опасность шаблонного мышления. Чтобы получить полезные отзывы, поработайте с ожиданиями заинтересованных лиц. Объясните, что обновление продукта на раннем этапе может напоминать конечный продукт лишь отчасти, а новые идеи и требования должны поддерживать концепцию. Поэтому заинтересованным лицам, возможно, придется подождать еще в течение одного-двух спринтов, прежде чем можно будет внедрить новые идеи, в зависимости от приоритетов и успешности работы с бэклогом продукта.
Владельцу продукта необязательно ждать обзора итогов спринта, чтобы дать отзыв о результатах работы. Полезно проводить своевременные обзоры сразу после появления результатов спринта. Это дает команде возможность что-то исправить уже в ходе спринта. Своевременные обзоры особенно важны, если элементы бэклога продукта, внедряемые в ходе спринта, достаточно мелкие, чтобы команда могла закончить работу над ними за несколько дней.
Ретроспективные анализы спринта помогают scrum-команде проверить, насколько хорошо выполнена работа, выявить проблемы и их причины и понять, какие меры нужно принять, чтобы работа была эффективной. Немецкая пословица «Самопознание — первый шаг к совершенствованию» отлично резюмирует главную идею ретроспективных анализов.
Владелец продукта должен постоянно участвовать в ретроспективном анализе спринта. Присутствуя на совещаниях, нужно регулярно предлагать пути улучшения и укреплять отношения с остальными участниками scrum-команды. Приведем пример одного ретроспективного анализа спринта. Обзор итогов выявил расхождения в ожиданиях у команды и владельца продукта, в результате чего он отверг большую часть работы. Члены команды были расстроены, считая, что сделали все хорошо, а владелец продукта испытал разочарование в команде. Решено было разрядить атмосферу при помощи ретроспективного анализа — докопаться до основных причин случившегося. После конструктивного обсуждения ситуации scrum-команда сумела выработать два важнейших пути совершенствования: владелец продукта решил проводить с командой больше времени, а члены команды — помогать ему в работе с бэклогом. Если бы владелец продукта не присутствовал на ретроспективном анализе, команде пришлось бы нелегко с принятием верных решений.
Чтобы выпускать жизнеспособные обновления, члены команды должны понимать, что даже лучшие команды могут стать еще лучше, фокусироваться на факторах, сдерживающих команду, и раскрывать глубинные причины этого. Все меры по исправлению ситуации необходимо выполнить, и обычно они относятся к следующему спринту. Если требуются более серьезные усовершенствования — например, покупка и установка нового сборочного сервера, — они фиксируются в бэклоге продукта.
Хотя крупные проекты следуют тому же расписанию совещаний, что и другие проекты Scrum, сами совещания видоизменяются. В этом разделе мы расскажем, как это происходит.
Чтобы провести совещание по планированию спринта среди нескольких команд, требуется дополнительная подготовка. Это и расширение горизонта работы с бэклогом, и внедрение перспективного планирования, описанные в главах 3 и 4. Большим проектам часто идет на пользу, если команды или их представители собираются вместе в начале совещания по планированию спринта, чтобы обсудить общую цель, к которой и будут двигаться все команды. Как только команды провели индивидуальные действия по планированию спринта, нужно снова собраться и определить, какие общие планы проекта должны быть реализованы в ходе спринта.
Scrum-совещание по Scrum позволяет нескольким командам ежедневно координировать свои действия в ходе спринта. Представители команд после этого приходят на ежедневные scrum-митинги своих команд, чтобы обсудить положение дел, запланированную работу и взаимодействие между командами (Schwaber, 2007; 72). Это совещание — тактическое и не может служить компенсацией за недостаточную подготовку к спринту — например, отсутствие стратегического планирования.
Организация эффективной встречи для одной-двух команд и клиентов, руководства и других заинтересованных лиц для демонстрации результатов спринта — непростая задача. Если же команд пять, десять или больше, то обеспечить общее понимание прогресса и выработать пути продвижения вперед еще сложнее. В компании Primavera нашли отличный способ организовать свои демонстрации, в которых нередко принимало участие сразу 15 команд. Боб Шатц, бывший вице-президент Primavera по разработке, поясняет: «Наши демо больше всего напоминали выставки в школе. Каждая команда собирала стенд, на котором демонстрировала то, над чем работает. Конечные пользователи, заинтересованные лица и еще несколько человек из нашей компании объединялись в небольшие группы. Каждая такая группа начинала со своего стенда. На анализ отводилось пятнадцать минут, после чего обозреватели переходили к следующим стендам. Все это проходило в атмосфере, полной энергии, вдохновения и радости» (Schatz, 2009). Совместная встреча заинтересованных лиц в одном помещении — отличный способ дать им всем возможность для взаимодействия и обмена мнениями. Если в офисе компании это невозможно, заказывайте конференц-зал хотя бы для каждой второй демонстрации результатов спринта.
Изменения и улучшения, которые каждая scrum-команда вырабатывает на своих ретроспективах, безусловно, помогают большим проектам. Но этого недостаточно. Для улучшения результатов команды должны определить общие пути совершенствования и поделиться друг с другом найденными идеями. Это позволяет делать совместная ретроспектива спринта. Эффективный метод ее проведения — привлечение представителей команд, что способствует перекрестному обмену идеями. Но при этом творческий импульс и знания всех участников команд не используются. Альтернатива — совместная ретроспектива всеми участниками команд. Это затратное дело: может занять полдня или больше, но так полнее используется накопленный опыт команд, а все их члены могут взаимодействовать друг с другом, укрепляя межкомандные взаимоотношения. Отличный способ организации ретроспективного анализа спринта — Open Space Technology (Owen, 1997), когда участники проекта самоорганизуются вокруг проблемных областей и определяют пути улучшения. Отметим, что оба варианта хорошо сочетаются. Например, организация может регулярно проводить ретроспективы с представителями команд и после каждого третьего спринта назначать общую ретроспективу, на которой будут присутствовать все члены команд.
Владелец продукта должен поддерживать тесное сотрудничество с командой и scrum-мастером, избегая распространенных ошибок, к которым относятся «скачущий» владелец продукта, или «чайка», незаинтересованный владелец продукта, нежизнеспособный темп, стремление пустить пыль в глаза, включение в отчет диаграммы сгорания задач спринта.
Такой владелец продукта появляется на планировании спринта, исчезает и затем возникает только на демонстрации. «Чайка» не взаимодействует с командой вовремя. Даже общение с ним по телефону или электронной почте часто затруднено. Иногда scrum-мастер или один из членов команды заполняют эту нишу, исполняя обязанности владельца продукта: это помогает команде двигаться вперед, но не позволяет устранить глубинные причины проблемы. Владелец продукта играет ключевую роль в его успехе. Поэтому обязанности владельца продукта должны стоять для вас на первом месте. Нужно проводить достаточно времени на рабочем месте с командой и быть готовым отвечать на вопросы, анализировать работу или устранять препятствия.
Рабочее помещение было переполнено. Владелец продукта, scrum-мастер, команда, пользователи и несколько менеджеров среднего звена смотрели на монитор компьютера. Тестировщик, сидящий перед ним, изо всех сил старался объяснить функциональность, которую представлял. Владельцу продукта было не по себе, и он очень медленно отворачивался от монитора. Периодически он согласно кивал. Через десять минут демонстрация закончилась. Scrum-мастер посмотрел на владельца продукта и спросил: «Вам нравится то, что вы увидели?» Владелец продукта еще раз кивнул и сказал: «Хорошая работа». После этого он встал и вышел из комнаты. Другие члены scrum-команды молча смотрели друг на друга. «Пора начинать ретроспективу», — сказал scrum-мастер.
Если бы я придумал этот рассказик или хотя бы наблюдал все это лишь однажды! К сожалению, очень часто на демонстрации результатов спринта владельцы продукта ведут себя как посторонние. Но демо — это не шоу, которое вы смотрите из зала. Его цель — выяснить, что должно быть сделано для увеличения шансов на создание успешного продукта. И владелец продукта должен активно вносить свой вклад в совещание, чтобы гарантировать правильное развитие продукта.
«Перерыва между спринтами не будет. Новый спринт начнется на следующий рабочий день», — говорю я. Одна из присутствующих поднимает руку и спрашивает: «Но как команда сможет восстановиться?» «Она и не должна», — отвечаю я. Я смотрю на поникших коллег, кто-то качает головой. Я продолжаю: «Нужно убедиться, что команда способна выполнить нужный объем работы — ровно столько элементов бэклога продукта, сколько она способна действительно воплотить в продуктовом инкременте, не перерабатывая и не чувствуя истощения».
Разработка продукта похожа на марафон. Если вы хотите финишировать, нужно подобрать оптимальный темп. Многие владельцы продукта совершают ошибку, оказывая на команду давление, чтобы она работала активнее. Так достигается краткосрочный выигрыш в скорости, но сам темп нежизнеспособен. Более того, он вообще контрпродуктивен. Спринты превращаются чуть ли не в гонку на выживание — люди быстро перегорают, заболевают или уходят. Владелец продукта должен уважать силы своей команды независимо от того, как выглядит диаграмма сгорания задач. Если дело движется медленно, соберите совещание, чтобы найти подходящее решение. Но не требуйте от сотрудников, чтобы они работали больше.
Одно из моих любимых воспоминаний детства — это визит на местную ярмарку с бегами и аттракционами. Один из них особенно впечатлял: это был магический кристалл с зеркальными стенками, на которые проецировались странные изображения, порождавшие миражи. Демонстрация результатов спринта, на которой на первый план выдвигаются положительные стороны работы или, наоборот, команда показывает результаты, не соответствующие критериям готовности, — это и есть такой кристалл. Мы не воспринимаем вещи такими, какие они есть, а находимся в плену иллюзий. И это все для отвода глаз. Ради создания атмосферы прозрачности нужно, чтобы демо были реальными — независимо от присутствующих на них зрителей. (Команды могут показывать только такие результаты работы, которые, по их мнению, соответствуют критериям готовности.)
Некоторые компании используют диаграмму сгорания задач спринта как отчет по проекту или как документ для высшего руководства. И то и другое — неправильное использование этого инструмента. Его основная цель — помочь команде ежедневно отслеживать свой прогресс и вносить соответствующие изменения в работу. Это не доклад о положении дел. Использование диаграммы сгорания задач как инструмента отчетности превращает ее в механизм контроля. Если руководство постоянно просит показать ему диаграмму сгорания задач — это верный признак недостатка доверия. Владелец продукта может исправить ситуацию, приглашая заинтересованных лиц на демонстрацию результатов спринта и ежедневные scrum-митинги. Для сообщений о прогрессе используйте только диаграмму сгорания задач релиза или план релиза. (Если необходимо больше возможностей для проверки и модификации, то команде стоит сократить длину спринта.)
Владелец продукта влияет на команду и руководит ею. От его поведения зависит очень многое. Ему следует постоянно обдумывать свои намерения и действия, быть командным игроком, проявлять открытость, оказывать поддержку. В то же время нужно быть твердым и не стесняться выступать с критическими отзывами на демонстрациях результатов по обзору спринта.
Следующие вопросы помогут вам оценить свое поведение.
Войти с помощью соц. сетей: