Помоги проекту - поделись книгой:
2) проект по созданию новой системы, использующей новые технологии.
Таблица 9.5. Достичь воздействия
Эти проекты должны быть продолжительностью от трех до шести месяцев каждый. Один из проектов, желательно новая разработка, должен состоять из 20–30 человек, организованных в три или четыре Scrum-команды. Другой проект должен состоять из одной Scrum-команды. В связи с тем что почти любой процесс работает с легким проектом, оба проекта должны включать трудные технологии и требования, в противном случае оценки будут иметь ограниченную ценность.
Дайте командам выполнить проекты. Они создадут готовое к использованию программное обеспечение для организации. Они также будут выявлять препятствия, которые могут быть добавлены в бэклог трансформации. Люди лучше поймут, какие вещи будут происходить. Те, кто проявил себя и сделал успехи возможными, должны быть выделены и вознаграждены.
Действие 5, которое показано в табл. 9.6, – тело проекта. Три области: разработка, изменения и управление – взаимодействуют, чтобы постепенно создавать всё лучшие продукты, и организация последовательно структурируется для закрепления этих преимуществ. Команда трансформации и остальной коллектив реально погружаются в работу по трансформации в течение этой деятельности.
Таблица 9.6. Измерение, оценка и укрепление достижений
Сердце Scrum – инспекция и адаптация. Адаптация – возникновение новых способов разработки программного обеспечения и управления им. Команда трансформации продолжает инспектировать, что происходит, что отражают показатели и о каких препятствиях сообщается. Команда ставит высокий приоритет этим потребностям в бэклоге трансформации. Спринты, основанные на этом бэклоге, создают инкременты организационных изменений и улучшений, которые ведут к реализации видения.
Некоторые сотрудники в организации полностью поймут и примут Scrum и лежащее в его основе мировоззрение. Настало время выдвинуть этих сотрудников на ключевые влиятельные и управляющие позиции. Они будут сохранять начальный импульс преобразований. В противном случае результат может быть получен на короткое время, а затем нивелируется, поскольку лидеры неизбежно покинут организацию. К концу четвертого года новое руководство должно быть разработано таким образом, чтобы обеспечение непрерывности преобразований больше не становилось проблемой.
Используйте надежность из ранних проектов, чтобы изменить все системы, структуры и политики, которые не совпадают с видением трансформации.
Закрепление преобразования означает встраивание изменений в организацию так, чтобы она приобретала новую культуру. Действие 6 обращается к этому, как показано в табл. 9.7. Любые процедуры, процессы, привычки, способы выполнения работ или привычки, которые были частью старой культуры организации, необходимо искоренить и заменить новыми способами ведения дел, которые поддерживают видение трансформации.
Таблица 9.7. Внедрение, расширение и сохранение
Закрепление продолжается на протяжении всего процесса трансформации. Это не цель, а практический способ, который становится частью непрерывного улучшения организации и стремления к совершенству. Все, что до этого не работало, заменяется тем, что работает лучше. Это ведет к появлению создающей знания и обучающейся организации.
По мере того как внедряются новые методы ведения дел, связи между видением, новыми моделями поведения и организационными успехами усиливаются с помощью признания заслуг, продвижения по службе и премирования. Это цементирует понимание каждым важности происходящего.
Организация станет чувствовать себя иначе, возможности будут использоваться с преимуществом по скорости, и проблемы начнут обнаруживаться и быстро решаться. Системы и программные продукты, используемые организацией, будут иметь гораздо более высокое значение. Разработка станет более продуктивной и творческой. Сотрудники будут эффективно взаимодействовать и разделять друг с другом воодушевление и радость от общей работы.
Проект трансформации вызывает серьезные потрясения внутри организации. Он должен управляться сверху и использовать отличную и последовательную систему связей. Видение преобразований должно быть четким. Всей организации необходимо принимать участие и понимать выгоды. Цель – постоянное обучение, которое последовательно обновляет и улучшает организацию. Наградой будет превосходство.
10. Скрамить Scrum
Скрамить Scrum означает использовать его для внедрения Scrum, для выполнения организационной трансформации. Чтобы внедрить Scrum, следует произвести два главных изменения. Во-первых, необходимо разработчиков программного обеспечения сформировать в команды и обучить создавать программы, используя Scrum. Во-вторых, любые препятствия на пути к созданию и доставке программного обеспечения должны быть устранены. Эти препятствия обнаруживаются, когда разработчики используют Scrum. Первое изменение будет улучшать выдачу программного продукта, второе – исправлять затруднения продуктивности и возвращать инвестиции. Оба трудны и требуют тяжелой работы. Несмотря на энергию и приверженность руководства, время, требуемое для этих изменений, не может быть уменьшено, потому что эти изменения – ключевая часть проекта трансформации.
Интернациональная компания SeaChange – мировой лидер в продуктах по передаче мультиэкранных видеоматериалов. Ее технологии представлены такими партнерами, как NBC, Comcast, Telus, PBS, SKY, Vodacom, Verizon, Cox, Time Warner Cable и другие, распространяющими высококачественные видеоматериалы. Корпорация Digital Equipment запустила SeaChange в 1993 году.
Стив Дэйви, глава отдела разработки SeaChange, расположенного в Бостоне, должен был разработать новые функциональные возможности и новые релизы продуктов – это было необходимо, чтобы поддерживать продукты SeaChange на продвинутом технологическом уровне и постоянно добавлять новые функциональные возможности и особенности для повышения конкурентоспособности. Этого было достаточно, чтобы оставаться в бизнесе. Вызов заключался в том, чтобы вводить новшества и создавать новые возможности, которых не имелось у конкурентов. Стратегия Стива состояла в том, чтобы нейтрализовать преимущества конкурентов и сокрушить их с помощью преимуществ SeaChange.
Стив столкнулся со множеством вызовов. Большинство требований были смутными и все очень срочными. Постоянное добавление новых критически важных требований становилось результатом задержек в выпуске релизов и разработки ненужных возможностей. Тем не менее Стив полагал, что изменение требований, даже путем задержки выпуска, – конкурентное преимущество, если это возможно выполнить.
SeaChange договорилась о продаже компании Verizon следующего выпуска продукта с добавлением некоторых дополнительных функций. Договор обязывал запустить релиз в течение трех месяцев. Стив счел это невозможным, но, как и раньше в подобных случаях, ему сказали, что это нужно сделать. Он со своей командой упорно работал, даже ночью и в выходные. В течение трех месяцев им удалось поставить Verizon около 90 % релиза. Продукт был полон дефектов и проблем производительности. В течение следующих шести месяцев Стив часто посещал Verizon в Баскинг Ридж, постоянно выслушивал жалобы на низкое качество продукта и обещал, что исправит проблемы.
Неудивительно, что Verizon не выпускал на рынок новое программное обеспечение SeaChange в течение шести месяцев после поставки. Если бы Стив мог объединить три месяца разработки с дополнительными шестью месяцами после, его частые визиты в Нью-Джерси не потребовались бы.
Стив знал, что он должен понять, как избежать повторения этого опыта. В то же время SeaChange быстро распространялась по всему миру, приобретая новые компании и интегрируя их продукты. Стиву нужен был способ управлять продуктами, который бы работал и мог присоединять дополнения.
Люди, применявшие Scrum, в большинстве случаев делали это, потому что в этом нуждались. Если бы их метод работал, им не нужно было бы меняться. Изменения – это всегда трудно, травматично и рискованно. Только отчаявшиеся или дальновидные люди берутся за это. Проблемы должны ощущаться сильнее, чем трудности или риски. Более того, многие руководители квалифицированы в текущем управлении, но не в управлении изменениями. К счастью, одним из умений Стива Дэйви было управление изменениями. В 2005 году он опробовал Scrum на одном продукте: новом, основанном на использовании интернета, нацеленном на рынок социальных средств коммуникаций. Scrum показал себя очень хорошо, и продукт был быстро разработан. К сожалению, ниша этого продукта оказалась неактуальной до 2009 года, поэтому его отложили. Тем не менее SeaChange получила уверенность в пользе Scrum.
Более того, Стив использовал Scrum для управления переходом к Scrum! Он собрал маленькую группу ключевых менеджеров и руководителей. Группа создала список того, что требуется для изменений, описала специальные действия, необходимые для создания изменений, и проблемы, с которыми они сталкивались. Команда работала по этому списку, создавая реальные изменения каждые 30 дней. Они ежедневно встречались для оценки прогресса и обзора непредвиденных проблем и часто сообщали всем, что происходит и почему, поскольку изменения затрагивали каждого и люди хотели знать, как это отразится именно на них.
Руководству поручили содействовать, но не направлять. Функция руководства изменилась: больше нет необходимости заставлять сотрудников делать то, что указано в плане, – надо было просто помогать им уложиться в план. «Ресурсами» стали творческие люди. Подобные изменения в корпоративном мировоззрении оказались особенно сложны для менеджеров среднего звена, поэтому они сопротивлялись переменам. Один из менеджеров покинул компанию, потому что не смог работать по-новому.
Еще одна сложная задача появилась в рамках торговых и маркетинговых операций. Scrum призывает к упорядоченной последовательности новых и улучшенных возможностей продукта. План меняется часто, но всегда явно. Разработчики трудятся только над ним. Чтобы сделать этот процесс эффективным, сотрудники отдела продаж и маркетинга, участвующие в составлении плана, должны знать, что их требования и пожелания пользователей будут учтены на одном уровне со всеми другими требованиями. Они должны были согласиться с решениями на основе видения и направления развития продуктов компании, а не на основе их личных желаний и потребностей. Это было существенное изменение. Персонал отдела продаж и маркетинга должен взаимодействовать, вырабатывать идеи и принимать решения, которых станет придерживаться.
Как часть изменений персонал SeaChange и руководство часто встречались на ретроспективных собраниях. Они давали оценку тому, что происходило, и тому, насколько это эффективно. Они совместно разрабатывали и реализовывали способы стать более эффективными. Ранее за качество были ответственны специальные сотрудники. Инженеры разрабатывали перед выпуском продукта как можно больше функциональных возможностей, а те, кто контролировал качество, смотрели, работают эти возможности или нет. Но при использовании Scrum за качество отвечает каждый. Оно не проверяется только перед самым завершением работы и выпуском продукта. Каждый инкремент должен быть высокого качества, и каждый следующий инкремент строится на качестве предыдущих.
SeaChange теперь использует Scrum по всему миру. Все приобретаемые компании должны его адаптировать. Приобретения могут сохранять все свои успешные практики, как это было сделано в Carbonite. Они используют Scrum, чтобы окружить эти практики для создания предсказуемости, регулярности, управления информацией и интегрировать работу каждого. Используя Scrum, SeaChange смогла идти в ногу со временем и оторваться от конкурентов. Кроме того, компания теперь способна быстро интегрировать новые компании и использовать их продукты.
В главе 3 мы обсуждали, как Iron Mountain боролась с разработчиками и как Пол Луппино успешно решил эти проблемы. Scrum распространился по всей организации разработки программного обеспечения Iron Mountain.
Пол получил повышение и теперь работает на президента компании Iron Mountain Гарольда Эббигхаузена. Он применил принципы Scrum к управлению бизнесом, и теперь шесть линий бизнеса должны отчитываться о законченных инкрементах работы каждые 30 дней вместо их одно-, трех- и шестимесячных планов. Руководящая работа, такая как создание экономических связей, изменение процессов, работа с потребителями по улучшению взаимосвязей и решению организационных вопросов, представлена в бэклоге, называемом бэклог трансформации продукта, который более подробно мы опишем в этой главе далее. Определенные пункты должны быть закончены в течение каждого спринта. Когда что-то не заканчивается, вся команда управления работает, чтобы понять причину. Насколько задача трудновыполнима? Возможно, какая-то ее часть слишком велика, не нужно ли ее разбить на более мелкие фрагменты? Требуется ли менеджеру помощь? После этого работа для следующего спринта формулируется иначе. Iron Mountain также применил принципы Scrum для общего управления. Так как обе сферы, разработка программного обеспечения и общая организация, очень сложны, Scrum был эффективен в применении в обеих сферах.
Две Scrum-команды задействованы во время трансформации организации:
1) команда трансформации, которая использует Scrum, чтобы трансформировать организацию и достигнуть видения;
2) команда развертывания, которая использует Scrum для выполнения актуальной работы по трансформации, вызывающей изменения.
Руководитель, ведущий проект трансформации организации, становится владельцем продукта в команде трансформации. Он может решить организационные, ведомственные и личные противоречия на благо всей организации. Заинтересован в этом каждый сотрудник организации. Scrum-мастер, имеющий большой опыт в области упрощения процедур и организационного развития, также приглашается в команду. Он удерживает целостность проекта трансформации, следит за продвижением изменений и за сохранением использования Scrum-процессов.
Команда трансформации может добиться успеха, только если ее члены работают вместе и слаженно. Если индивидуальные успехи высшего руководства признаются более важными, чем командный успех, трансформация потерпит неудачу. Изменение не может произойти без взаимодействия и командной работы. Прекрасный пример такого типа командной работы – The Five Dysfunctions of Teams Патрика Ленсиони[18].
Команда трансформации создает команды развертывания, чтобы повлиять на организационные изменения. Эти команды выбирают пункты работы по трансформации из бэклога продукта и трансформируют организацию, шаг за шагом, через инкременты изменений. Команда трансформации создает эти команды развертывания по мере надобности. Они могут быть как постоянными, так и временными. Члены команды могут быть членами руководства, Scrum-мастерами или думающими лидерами со всей организации. Члены команды не должны работать на условиях полной занятости. Они могут быть экспертами и лидерами в областях, где должны случиться изменения. Их доступность и квалификация будут определять скорость трансформации.
Команды развертывания отличаются от команды трансформации, которые управляют и направляют к изменению (рис. 10.1).
Рис. 10.1. Команда трансформации и развертывания
Они также отличаются от Scrum-команд разработки, которые создают программное обеспечение, инкремент за инкрементом. Команды развертывания создают изменения.
Трансформация организации – сложный процесс. Команда трансформации управляет усилиями через Scrum. Наиболее важные и возможные изменения выбираются из бэклога продукта трансформации командой трансформации и назначаются командам развертывания. Трансформация происходит инкремент за инкрементом.
Перед каждым спринтом команда трансформации дает оценку предстоящей работы в бэклоге трансформации. Команды развертывания организуются, основываясь на типе задач в бэклоге. Участники для каждой команды определяются и привлекаются для предстоящего спринта.
Мероприятия планирования. Мероприятия планирования спринта должны длиться не более одного дня. Команды развертывания встречаются с владельцем продукта трансформации, который обсуждает предстоящие изменения и помогает командам развертывания разработать тактику и планы для создания изменений. Затем команды развертывания дают прогноз по пунктам бэклога продукта для спринта.
Спринт. Команды развертывания проводят спринт, чтобы создать инкремент изменений. Они ежедневно встречаются для оценки прогресса и пересмотра предстоящей работы, если необходимо. Каждая команда включает Scrum-мастера, который сообщает владельцу продукта в команде трансформации о препятствиях и помехах, с которыми они столкнулись.
Обзор спринта. Обзор проводится в конце каждого спринта. Демонстрируются ощутимые изменения. Результатам изменений и работе по изменению дается оценка. Иногда командам развертывания нечего продемонстрировать. Это может означать, что для команд развертывания были выбраны неправильные люди, что члены команд трансформации тратили недостаточно времени для решения проблемы или что проблема была гораздо сложнее для решения, чем казалось в текущих условиях. Средством решения проблемы должна быть реструктуризация бэклога продукта трансформации или очередная попытка.
Продолжая движение спринт за спринтом, организация трансформируется и трансформирует себя. Команда трансформации должна быть в постоянном поиске новой работы. Самоуспокоение и расслабление часто происходят до того, как изменения закрепляются. Тогда изменения непостоянны, ограничены сроком полномочий людей, которые привели к этим изменениям.
Scrum – процесс для управления сложной работой. Нет более сложной работы, чем изменение организации с одного способа ведения бизнеса на другой. Мы рассказали, как для этого использовать Scrum. Scrum остается неизменным, только тип работы, записанный в бэклоге, меняется, так же как и результат этой работы.
Приложение 1. Глоссарий
PRN – по обстоятельствам (от лат.
Scrum – итеративный, инкрементальный процесс, использующий эмпирический метод для контроля и управления. Scrum – один из нескольких гибких процессов.
Scrum-команда состоит из владельца продукта, команды разработки и Scrum-мастера. Scrum-команды – самоорганизующиеся и кросс-функциональные.
Scrum-мастер – методический лидер Scrum-команды, который отвечает за то, чтобы Scrum-процесс был понятен и принимался. Scrum-мастера добиваются этого путем соблюдения Scrum-командами теории Scrum, практических приемов и правил.
Scrum-митинг – 15-минутное, ограниченное по времени совещание команды разработки для синхронизации действий и создания плана работы на следующие 24 часа. Это делается путем проверки работы, выполненной с момента последнего Scrum-митинга, и прогнозирования работы до следующего.
Scrum-митинг проводится каждый день в одном месте и в одно время для уменьшения путаницы. Во время совещания каждая команда разработки рассказывает о следующем:
• что было завершено со времени последнего совещания;
• что будет сделано до следующего совещания;
• какие есть препятствия на пути.
Базовая линия – линия, базовая для измерения. В диаграмме выгорания задач она отражает точку во времени, когда не останется работ по выполнению требований перед выпуском продукта.
Бэклог продукта – упорядоченный список всего, что может потребоваться в продукте; является единственным источником требований для всех изменений, которые должны быть сделаны при его разработке. За бэклог продукта, включая его содержание, пригодность и порядок, отвечает его владелец.
Бэклог спринта – набор пунктов бэклога продукта, выбранных для спринта, а также план по созданию инкремента и реализации цели спринта. Бэклог спринта – прогноз команды разработки, которая определяет, какие функциональные возможности будут в следующем инкременте и какое количество работы необходимо для создания этого функционала.
Бэклог спринта определяет работу, которую сделает команда разработки, чтобы превратить пункты бэклога продукта в «законченный» инкремент. Бэклог спринта делает видимой всю работу, которую команда разработки определяет как необходимую для достижения цели спринта.
Видение – частично оформленная идея того, что функционирует определенным способом, может быть использовано для решения задач, меняет подход к работе или рабочее место его пользователей определенным образом, создает новую полезность или меняет распространение в мире или в рыночной нише. Идея, которая раньше не существовала в этой форме.
Владелец продукта отвечает за максимальное значение ценности продукта и производительности команды разработки. Способы его работы могут быть различными в разных организациях, Scrum-командах и зависят от конкретных людей.
Диаграмма сгорания задач отслеживает количество работы по выполнению требований, оставшейся до выпуска продукта, где время измеряется в спринтах.
Инкремент – сумма всех пунктов бэклога продукта, законченных во время текущего спринта и всех предыдущих спринтов. В конце спринта новый инкремент должен быть «законченным», что означает, что он должен быть готовым к использованию и соответствовать определению «законченности», принятому в Scrum-команде. Это должно быть пригодное к использованию состояние, вне зависимости от того, решит ли владелец продукта выпустить его.
Итеративно-инкрементальный процесс – способ разработки системы или продукта через последовательность итераций, каждая из которых генерирует законченный инкремент функциональных возможностей, строящийся на всех предыдущих инкрементах. Итерации продолжаются, пока цель не будет достигнута или необходимая ценность не станет оптимальной.
Итерация – повторяющееся действие, серия шагов или процессов, как правило, приближающих к желаемой цели или результату. Каждое повторение процесса также называется итерацией, и результат одной итерации используется как стартовая точка для следующей.
Каскадный процесс – последовательный процесс проектирования, часто используемый в процессах разработки программного обеспечения, где прогресс рассматривается как стабильный поток вниз (как каскад водопадов) через фазы концепции, инициации, анализа, проектирования, разработки, тестирования, выпуска/реализации и технического обслуживания.
Команда разработки состоит из профессионалов, которые делают работу по предоставлению потенциально готового к выпуску приращения функциональных возможностей «готового» продукта к концу каждого спринта. Только члены команды разработки создают инкременты.
Качество – количество дефектов подсчитывается со дня, когда единица функционала передается владельцу продукта, и в течение трех месяцев использования функционала пользователями.
Обзор спринта проводится в конце спринта для оценки инкремента и внесения, если необходимо, изменений в бэклог продукта. Во время обзора спринта Scrum-команда и заинтересованные стороны совместно обсуждают, что было сделано в спринте. Исходя из этого и любых других изменений в бэклоге продукта, в течение спринта участники совместно работают над списком следующих действий, которые можно было бы сделать. Это ограниченное по времени (четыре часа для спринта продолжительностью один месяц, для более коротких спринтов отводится меньше времени) неофициальное мероприятие и презентация инкремента предназначены для выявления обратной связи и укрепления сотрудничества.
Планирование спринта – мероприятие, где планируется работа, которая должна быть выполнена в спринте. План создается совместными усилиями всей Scrum-команды. Время мероприятия по планированию спринта ограничивается восемью часами для спринта продолжительностью один месяц. Для более коротких спринтов время пропорционально сокращается. К примеру, для двухнедельного спринта продолжительность мероприятия составит четыре часа. Планирование спринта состоит из двух частей, каждое продолжительностью в половину общего времени. Две части планирования спринта отвечают на следующие вопросы соответственно.
Поделиться книгой: