Текст книги "Scrum без ошибок"
Автор книги: Илан Голдштейн
Жанр: Управление и подбор персонала, Бизнес-Книги
Возрастные ограничения: +16
сообщить о неприемлемом содержимом
Текущая страница: 2 (всего у книги 15 страниц) [доступный отрывок для чтения: 5 страниц]
Лайфхак 2. Хрупкий Agile
Пожалуй, один из самых неприятных комментариев, которые я слышу от молодых scrum-команд: «Мы используем Scrum: работаем в спринтах, проводим ежедневные стендапы, у нас даже есть бэклог продукта». Может быть, вместо этого сказать честно: «Мы не ведем никакой документации, выпускаем релизы как бог на душу положит, планируем все на лету и не задумываемся об ошибках, потому что просто исправим их в следующей итерации»?
Эти люди делают Scrum ужасную антирекламу, а их проекты неизбежно терпят неудачу. Что еще хуже, после всего этого очень сложно вернуть доверие стейкхолдеров, разочарованных искаженной реализацией Scrum.
ЭТО ФРЕЙМВОРК, А НЕ МЕТОД
Часто можно услышать, что Scrum – это метод. Это неправильно. Scrum – это фреймворк практик, связанных небольшим набором четко определенных правил. Между методом и фреймворком есть существенная разница. Метод подразумевает универсальный формульный подход, в то время как фреймворк предлагает более гибкую платформу, на основе которой могут быть получены разные подходы в зависимости от той или иной рабочей среды.
Чтобы правильно внедрить Scrum, важно следовать четким правилам и работать в рамках практик фреймворка. Только так вы окажетесь на верном пути. Кен Швабер в своем блоге пишет: «Scrum – это как шахматы. Вы либо играете по правилам, либо не играете совсем»[15]15
Schwaber K. Scrum Fails? // Ken Schwaber’s Blog: Telling It Like It Is. 2011, April 7. Доступно по ссылке: http://kenschwaber.wordpress.com/2011/04/07/scrum-fails/.
[Закрыть]. Расширяя эту аналогию, можно сказать, что частичная реализация Scrum похожа на игру с 20 шахматными фигурами вместо стандартных 32. Есть небольшой шанс, что игра так или иначе пойдет, но это будет не стандартная и выверенная игра в шахматы, это будет другая игра с непредсказуемыми последствиями (см. рис. 1.3).
Рис. 1.3. Так же как нельзя менять правила игры в шахматы, не следует менять и правила Scrum
Scrum не содержит лишних правил или практик. Чтобы он работал как задумано, его нужно реализовывать целостно. Частичное применение Scrum равнозначно отказу от него.
КВАЛИФИКАЦИЯ ПРОТИВ КАЧЕСТВА
Сертификация scrum-мастеров, безусловно, полезна, но и здесь присутствует человеческий фактор, снижающий ее значимость. Много лет назад, когда я проходил первый курс обучения на scrum-мастера, в нашей группе был участник, менеджер проекта из банка, который, казалось, видел себя сержантом на курсах молодого бойца. Я тогда подумал:
даже если он несколько лет потратит на обучение, все равно ему не стать scrum-мастером, ведь качества гораздо важнее подтвержденной сертификации (см. лайфхак 4).
ЗЛОУПОТРЕБЛЕНИЕ AGILE-МАНИФЕСТОМ
Те, кто склонен искажать Scrum, обычно цитируют Agile-манифест, чтобы оправдать отсутствие документации и дефицит планирования.
Манифест agile-разработки программного обеспечения
Занимаясь непосредственно разработкой программного обеспечения и помогая в этом другим, мы постоянно открываем для себя более совершенные методы. Благодаря проделанной работе мы осознали следующие ценности:
• люди и их взаимодействие важнее процессов и инструментов;
• работающее программное обеспечение важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования плану.
То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.
Те, кто злоупотребляет Agile-манифестом, либо (а) не прочитали последнюю строку, либо (б) забыли последнюю строку, либо (с) проигнорировали последнюю строку.
И помните: хотя элементы слева ценятся больше, элементы справа также важны и почти всегда пригодятся вам в процессе разработки продукта.
АНТИПАТТЕРНЫ SCRUM
Рассмотрим несколько симптомов того, что Scrum искажен, деформирован и используется неверно. Не путайте их с проблемами «прорезывания зубов», с которыми сталкиваются начинающие (но настоящие) scrum-команды. Например, ежедневный Scrum, который не всегда начинается вовремя, – это неидеально, но при правильной мотивации эту проблему можно решить, и регулярное смещение графика не всегда сигнализирует о том, что команда не принимает эту практику.
Спринты тестирования
Обеспечение качества – неотъемлемая часть процесса разработки. Требование не может считаться выполненным, если оно не удовлетворяет критериям готовности (см. лайфхак 11). Однако иногда это правило нарушается. Обычно это происходит на этапе «функциональных» спринтов, фокусирующихся исключительно на разработке нового кода (чтобы создать впечатление прогресса), дополняемых связкой «догоняющих» спринтов для выявления и исправления багов.
Типичное оправдание такого поведения – команда хочет в первую очередь показать общие функциональные возможности ПО пользователям (чтобы проверить свою работу). В такой ситуации я обычно говорю команде: «Если вы работаете в спринтах, это еще не значит, что вы ушли от водопадной модели». Помните: до тех пор пока функциональность продукта не будет полностью протестирована и готова к релизу, она не является завершенной (должна считаться невыполненной, то есть бесполезной, и очень рискованной).
Другое проявление этого антипаттерна – программисты и тестировщики работают в разных спринтах. Например, тестировщики отстают на один спринт от программистов[16]16
В текущем спринте они тестируют результат работы программистов из предыдущего спринта. Прим. ред.
[Закрыть]. Такое становится возможным, если практика автоматизированного тестирования все еще недостаточно зрелая и зависимость от ручного регрессионного тестирования велика. Этот ступенчатый сценарий спринта неизбежно приводит к таким же «догоняющим» спринтам, которые обсуждались выше.
Бесконечные нулевые спринты
Нулевой спринт на самом деле не спринт, а искусственный термин, используемый для описания предварительной работы, которую команде необходимо выполнить, прежде чем она будет готова начать первый настоящий спринт (со всеми необходимыми атрибутами).
Эта предварительная работа, как правило, не подразумевает временных рамок и не обладает всеми типичными структурными элементами, которые есть в реальном спринте (бэклог спринта и четко сформулированные требования).
Хотя мне не нравится вводящий в заблуждение термин, концепция предварительного этапа мне понятна и я не имею ничего против. Главная проблема с нулевым спринтом возникает, когда в него входит бесполезная работа, задерживающая начало реальных спринтов. Давайте взглянем на то, что должно и чего не должно быть в нулевом спринте (см. рис. 1.4).
Рис. 1.4. Минимальный список задач для нулевого спринта
Элементы в списке «Не включать» на рис. 1.4 могут показаться туманными, в отличие от конкретных функциональных требований, но это не значит, что их нельзя оценить, спланировать и разбить на задачи и, следовательно, включить в спринт. Ввиду неопределенного характера этой подготовительной работы необходимо окружить ее надлежащими техниками спринта, чтобы обеспечить большую прозрачность и более жесткий контроль.
Изменяющаяся продолжительность спринта
Постоянная продолжительность спринта важна по ряду причин, описанных в лайфхаке 8.
Одно из самых распространенных оправданий, которые я слышал при несоблюдении этого правила: команда хотела взять несколько дополнительных дней и закончить почти готовые требования, чтобы обзор спринта был впечатляющим.
Полагаю, есть только две причины для изменения длины спринта:
1. Когда новая команда экспериментирует на начальном этапе работы.
2. Когда все работы завершаются ранее последнего дня финального спринта (см. рис. 1.5).
Рис. 1.5. После определения продолжительности спринта поддерживайте ее неизменной
Изолированная оценка
Подобная ситуация характерна для всех процессов вне Scrum, с которыми я сталкивался. Она возникает, когда ведущий разработчик пытается единолично оценить продолжительность всех работ. Вы можете спросить: а в чем проблема? Разве опытный сотрудник с наивысшей квалификацией не способен дать точную оценку? Тем не менее это действительно одна из проблем. Хотя ведущий разработчик может быть самым опытным, в большинстве случаев сам он не станет выполнять работу. По своим способностям он, несомненно, отличается от участников команды, которым и предстоит выполнить стоящие перед ними задачи. Следовательно, и его оценка будет отличаться от реального положения дел. Работу выполняет не один человек, а вся команда, поэтому она (как коллектив) и должна давать оценку (см. лайфхак 14). Когда это делает один человек, никакой системы сдержек и противовесов для него не существует. А если у него был выходной, он не услышал некоторые важные данные и сделал неправильные выводы? Когда в оценке задействованы все участники команды, такие промахи гораздо менее вероятны благодаря нескольким слоям и фильтрам при обработке информации.
Доверие к спецификации
Услышав такие комментарии, как «если этого нет в спецификации, это не будет сделано» или «я реализовал именно то, что было в спецификации», можете быть уверены: ваша одежда насквозь промокла от водопада, под которым стоит ваша команда. Это также показывает, что участники команды утратили способность общаться между собой и стали бюрократами. Любая так называемая спецификация должна служить лишь напоминанием или шаблоном. Фактические же требования выполняются коллективно в процессе совместной слаженной работы команды.
Ошибка при выборе scrum-мастера
Если ваш scrum-мастер не поддерживает атрибуты, описанные в лайфхаке 4, и/или не выполняет функции, указанные в лайфхаке 26, то вас, скорее всего, ведет самозванец. Если он единолично принимает продуктовые и технические решения, раздает задачи в режиме микроменеджмента, регулярно заставляет команду работать сверхурочно или ведет себя как тиран, проблемы неизбежны.
СЛУШАЙТЕ РОДИТЕЛЕЙ
Прислушайтесь к совету, который родители наверняка давали вам не раз и не два: если вы собираетесь что-то сделать, делайте это правильно. Мы уже говорили о том, что в Scrum, как и в шахматах, правила менять нельзя. Либо реализуйте Scrum в границах фреймворка, либо не называйте то, что делаете, Scrum.
Лайфхак 3. Творческий комфорт
Scrum-мастер: Доброе утро, ребята!
Разработчик 1: (Ворчит.)
Разработчик 2: (Едва различимый кивок.)
Разработчик 3: (Наушники на голове, никакой реакции.)
Знакомо?
Давным-давно этот типичный ритуал был для меня одним из самых неприятных моментов начала работы. Обычное утреннее приветствие всегда вызывало у меня раздражение, и это в самом начале рабочего дня. Почему? Да просто потому, что взаимодействия, подобные описанному, могут заставить вас чувствовать, что вы входите в склеп, а не в улей продуктивности.
Некоторые из вас могут решить, что немного грустно говорить «Доброе утро!», особенно холодным, серым утром в понедельник. «Мы ведь инженеры, черт возьми, а не продавцы мыльных пузырей!» Тогда представьте: вы пришли в гости к приятелю, едва слышно что-то буркнули вместо приветствия, плюхнулись на диван и сидите молча. Как чувствовал бы себя ваш друг в такой ситуации? Думаю, он был бы раздражен.
Улыбка и искреннее «Как дела?» помогают почувствовать, что вы среди друзей, способствуют более продуктивному и живому настрою. Такие мелочи, как дружеское приветствие утром, могут серьезно влиять на то, как команда будет работать, а ее участники – взаимодействовать друг с другом.
Советы этого лайфхака подойдут любой команде. Но вероятно, scrum-команды – наиболее сплоченные группы, с которыми вам доведется работать, поэтому очень важно в самом начале дня убедиться, что все ваши коллеги полны энергии и воодушевлены предстоящей работой.
Зачастую мы проводим на работе большую часть жизни и с коллегами общаемся чаще, чем с родителями, супругами и детьми. Тем из вас, кто, прочитав это, тяжело вздохнул, нужно продолжать читать дальше, потому что приход на работу не должен быть похож на вход в забой.
Хорошая новость: существует несколько простых (и недорогих) способов поддерживать удовлетворенность команды.
ЛИЧНАЯ БЛАГОДАРНОСТЬ
После всего сказанного выше о главенствующей роли scrum-команды вы могли подумать, что признания индивидуальных заслуг здесь просто нет. Это не так. Scrum, безусловно, больше ориентирован на командный результат, чем на индивидуальные рекорды и достижения, но это не означает, что люди становятся винтиками в системе. Команды состоят из отдельных личностей, которым необходимы признание и высокая оценка их тяжелой работы.
Я был scrum-мастером в молодой scrum-команде, которая так хорошо проявила себя на очень важном проекте, что мы получили общекорпоративную премию как лучшая команда года. Это признание было невероятно важно для команды в целом, но, когда я подходил к каждому и искренне благодарил за хорошо выполненную работу, признавая его вклад, это было вдвойне приятно всем.
Вот что говорит Тони Шварц, президент и СЕО Energy Project, автор блога в Harvard Business Review, о том, почему индивидуальная оценка имеет большое значение:
Искренняя признательность их заслуг окрыляет и вдохновляет людей. На самом базовом уровне это дает ощущение безопасности и позволяет лучше делать свою работу. Это заряжает энергией. Когда нашу работу оценивают неадекватно – а такое часто случается, – нас охватывает мучительное беспокойство, это истощает силы и отвлекает от создания ценности[17]17
Schwartz T. Why Appreciation Matters So Much // Harvard Business Review. 2012, January 23. Доступно по ссылке: http://blogs.hbr.org/schwartz/2012/01/why-appreciation-matters-so-mu.html.
[Закрыть].
Разумеется, я рекомендую не отказываться от благодарности всей команде, а вслед за Дейлом Карнеги, автором бестселлера «Как завоевывать друзей и оказывать влияние на людей», «оставлять дружеский след маленьких искр благодарности в ваших ежедневных путешествиях». Так вы поможете людям творить чудеса.
РАБОЧАЯ СРЕДА
Помню, как несколько лет назад мое электронное письмо с описанием необычной обстановки офисов Google в Цюрихе стало вирусным («Работа в Google» 2005). Многие мои друзья (никак не связанные с программным обеспечением) искренне удивлялись расходам на офисную мебель и оборудование, которые, по их словам, больше подходили детской игровой площадке, чем офису солидной компании. «Люди действительно там работают или просто дурачатся весь день?» – возмущался мой друг адвокат.
Наша отрасль как свет в конце тоннеля корпоративного мира мрачных офисов, больше похожих на фабрики индустриальной эпохи. В отличие от моего друга юриста многие технологические компании понимают, что выполнять сложную работу, наслаждаясь рабочей средой, действительно возможно!
Я не говорю, что вам нужно накупить цветастых кресел-мешков, лавовых ламп и поставить горки. Однако стремление превратить рабочую среду в нечто похожее на уютный дом не должно рассматриваться как каприз или причуда. Это осмысленная цель!
Scrum в значительной степени ориентирован на интерактивную среду, которая способствует такой scrum-ценности, как открытость, поэтому рассматривайте приведенный ниже перечень как фундамент благоприятной scrum-среды:
• большая белая доска и свободные стены, где можно разместить доски задач и связанные с ними артефакты;
• много света (хотя мне доводилось работать с парой странноватых разработчиков, у которых была вампирская тяга к темноте);
• открытое пространство для каждой команды с небольшими перегородками, отделяющими зону одной команды от другой;
• достаточно широкие проходы между стульями для комфортного проведения промежуточного контроля (см. лайфхак 12);
• небольшой круглый стол для обсуждений в рабочей зоне команды;
• легкодоступные вместительные переговорные с проекторами и белыми досками для таких scrum-встреч, как планирование спринтов, обзоры спринтов и ретроспективы;
• зоны «Не беспокоить», где участники команды могли бы уединиться и спокойно поразмышлять; там должно быть достаточно места, чтобы ходить, а также должен стоять стол;
• изолированные зоны для личных телефонных разговоров;
• буферная зона, защищающая от самых шумных подразделений компании – отдела продаж и отдела по работе с клиентами, где сотрудники говорят по телефону большую часть времени.
ОТЛИЧНОЕ ОБОРУДОВАНИЕ
Предложение разработчикам внедрить новейшие и лучшие технологии не должно рассматриваться как жест великодушия. Как вы думаете, считают ли плотники острую стамеску роскошью? Нет, это для них необходимый рабочий инструмент.
Самое интересное: разработчики, которым предлагают новейшее и максимально производительное оборудование, видят в этом огромное преимущество для себя. Как отмечает обозреватель программного обеспечения Джоэл Спольски[18]18
Spolsky J. Smart and Gets Things Done. Joel Spolsky’s Concise Guide to Finding the Best Technical Talent. Berkeley: Apress, 2007.
[Закрыть], программистов легко подкупить, предоставив им самое крутое и самое современное «железо». Это гораздо более дешевый способ заставить их работать на вас, чем конкурентоспособная зарплата!
Я уверен, Джоэл не призывает платить меньше и не агитирует за экономию на окладах и бонусах. Дело в другом: просто предоставляя хорошие инструменты вместо старого подержанного оборудования (ради экономии пары долларов), вы не только делаете разработчиков счастливыми, но и улучшаете общую производительность!
ИДЕНТИЧНОСТЬ
Люди по своей природе общинные, племенные создания, нам нравится чувствовать себя частью особой группы. Scrum – идеальный инструмент для подобного социального контекста, ведь он поощряет размещать команду отдельно от других сотрудников. Как только этот первый шаг будет сделан, наступает время строить действительно прочные связи. Я призываю (но не заставляю) scrum-команды придумать себе название, выбрать свой цвет, как это делают спортивные команды, и украсить свою территорию соответствующими плакатами, логотипами и баннерами. Как отмечают Том Демарко и Тимоти Листер в своей эпохальной книге Peopleware: «Участники хорошей команды испытывают ощущение элитарности. Они чувствуют, что составляют нечто уникальное, что они выше всякой заурядности»[19]19
DeMarco T., Lister Т. Peopleware: Productive Projects and Teams. Dorset House, 1999. Издано на русском: Демарко Т., Листер Т. Человеческий фактор. Успешные проекты и команды. М.: Символ-Плюс, 2005.
[Закрыть].
В одной компании, которую я познакомил со Scrum, образовались команды «Вулкан», «Громовые коты» и даже «Потрясающая команда», которые вели дружескую борьбу, постоянно подтрунивая друг над другом, например, за то, что сломали сборку или проводили слишком долгие ежедневные стендапы. Я искренне верю, что эта невинная конкуренция повысила не только производительность, но и чувство гордости за качество проделанной работы.
Хотя индивидуальность команды – жизненно важный аспект, необходимо, чтобы она идентифицировала себя с продуктом, который разрабатывает, и чувствовала себя вовлеченной в него. По словам Майка Кона, один из лучших способов добавить энергии – разжечь страсть. Чем больше увлеченных людей, тем выше вероятность их ежедневного максимального погружения в проекты. В данном случае ключевую роль играет владелец продукта. Он должен иметь четкое представление о том, что хочет получить в итоге, убедительно изложить свои ожидания и передать свое видение команде, чтобы та работала над проектом с энтузиазмом.
Я нашел хороший способ пробуждать такую страсть и чувство сопричастности. Следует приглашать разработчиков на первые встречи, посвященные пользовательским историям. Это поможет scrum-команде не только почувствовать себя вовлеченной в концепцию продукта, но и с самого начала понимать, какого результата от нее будут ждать и почему.
СИЯЮЩИЕ, СЧАСТЛИВЫЕ ЛЮДИ
Превращая рабочую среду в домашнюю или, еще лучше, в парк захватывающих аттракционов, включая местных джокеров и клоунов (в моих командах их было много), мы возвращаемся в наш самый беззаботный период жизни – детство, когда мы были максимально креативны и безмерно счастливы.
Думать, что такие широкие жесты, как выплата бонусов, или раздача красиво звучащих должностей, напечатанных на визитках с восхитительными водяными знаками, или такие инициативы, как знаменитые 20 % времени Google[20]20
В соответствии с правилом «20 % времени» каждый сотрудник Google имел право 20 % рабочего времени посвящать сторонним проектам, не связанным с его основным функционалом. Прим. ред.
[Закрыть], позволят сотрудникам оставаться постоянно мотивированными, – это иллюзия. Я не считаю, что люди должны постоянно испытывать чувство «мастерства, целеустремленности и автономии». В книге «Драйв. Что на самом деле нас мотивирует» Дэниел Пинк отмечает, что теплое приветствие утром, искренняя похвала за хорошо проделанную работу и ощущение, что вы часть уникальной команды, – часто этого достаточно, чтобы поддерживать улыбки на лицах ваших коллег[21]21
Пинк Д. Драйв. Что на самом деле нас мотивирует. М.: Альпина Паблишер, 2013.
[Закрыть].
Заключение
В трех лайфхаках этой главы мы сосредоточились на выборе тактических приемов, инструментов и советов, которые помогут вам и вашей компании освоить Scrum. Давайте вспомним, что мы обсуждали.
Лайфхак 1. Scrum на поле
• краткая презентация Scrum;
• концепция фиксированной гибкости, используемая для минимизации переключений контекста и одновременно предлагающая гибкость по отношению к скоупу работ;
• ключевые преимущества для scrum-команды и спонсоров проекта.
Лайфхак 2. Хрупкий Agile
• как отличить фреймворк от метода;
• почему важнее фокусироваться на личных, а не на профессиональных качествах;
• на какие антипаттерны Scrum стоит обратить особое внимание.
Лайфхак 3. Творческий комфорт
• как развить и укрепить командный дух, фокусируясь на благодарностях всей команде и каждому ее участнику;
• как улучшить рабочую среду, чтобы обеспечить продуктивное пространство взаимодействия;
• как помочь вашей команде прочувствовать свою идентичность и проникнуться общей целью.
Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?
