Agile. Процессы, проекты, компании

Citation preview

Валерий Фунтов

Agile. Процессы, проекты, компании

© ООО Издательство «Питер», 2020 © Серия «IT для бизнеса», 2020 © В. Фунтов, 2018

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

Данная книга подробно рассказывает об особенностях разнообразного использования Agile, дает многочисленные примеры его применения за пределами ИТ-отрасли. Она не для айтишников. Им не надо ее читать. У книги конкретная аудитория – это все те, кто работает за пределами разработки программного обеспечения. Соответственно перестроен и язык, по возможности используется обычная (не айтишная) лексика. Фокус не только на Скраме, но и на всем Agile-мышлении и подходе. Знания сформированы разными практиками (в том числе практикой автора) и многочисленными источниками. Цитируется много фактов и примеров, даны аккуратные ссылки. Все, что описано, можно немедленно применять на практике, также по Agile, мелкими итерациями, анализируя эффекты и проводя корректировки. Надо просто пробовать. Главы книги оформлены в спринты, в начале каждой главы – кратко о тех ценностях, которые эти спринты дают. Оглавление выглядит как план спринтов. Изучение книги превращается в движение по спринтам с наращиванием ценности в виде знаний. Представлены основные зоны интереса в Agile (по мнению автора), читать можно с любого раздела, а также возвращаться. В книге 15 рисунков и более 100 примеров. Интернет-ссылки даны прямо в тексте – это поможет тем, кто будет использовать электронную версию, тут же изучить материал, не набирая ссылку вручную. В тексте всей книги термины Agile и Lean даются на английском языке. Scrum и Kanban, если они упоминаются отдельно, русифицированы как Скрам и Канбан. Это вызвано уже сложившейся практикой в России. В комбинации с другими терминами или практиками сохранены англоязычные написания. В книге четыре приложения, включающие пример Agile-договора, чек-лист для выбора жизненного цикла проекта, пример устава команды и короткий тест с вопросами, похожими на те, которые дают при сертификации ACP. Успехов вам в постижении Agile, дорогие читатели! С уважением, В. Н. Фунтов, доктор экономических наук, PMP. СанктПетербургский международный институт менеджмента. Санкт-Петербург, 2019

От издательства Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция). Мы будем рады узнать ваше мнение! На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Введение …Нет никаких сомнений в том, что Agile стал основным направлением движения, но реальность такова, что самый большой сегмент команд, 40 процентов, не являются последователями какой-либо одной предписываемой методологии. Не существует ни одного совершенного процесса – серебряной

пули – Waterfall, Agile (Скрам), RUP или иного… Вместо этого большинство команд использует гибридный, постоянно развивающийся процесс, который наилучшим образом соответствует потребностям именно их проекта. Джон Симпсон, вице-президент по маркетингу компании Jama Software, 2011

71 % организаций хотя бы иногда применяют гибкие методы управления проектами. Agile, «эджил», «эджайл», «гибкие (или подвижные) методологии» и другие подобные термины уже давно вошли в практику и лексику участников проектного и процессного управления в мире. Cемейство фреймворков (рамочных правил, или каркасов) под общим зонтиком Agile («гибкий», «подвижный») появилось в практике управления ИТ-проектами еще в начале 1990-х гг. Одновременно возник и термин Agile manufacturing, или «гибкое производство», позже было введено понятие «гибкость предприятия». Сейчас крайне важно, что Agile уже давно признается не только и не столько практикой или методологией управления или какими-то формализованными правилами, сколько субкультурой, отношением, поведением, способом мышления или просто жизнью. Сегодня управлять по Agile, «играть» или применять Agile, быть Agile – модно, популярно, ново, современно и на слуху во многих компаниях. Появились даже термины «Agile-компания», «Agileкультура», «Agile-менеджеры», «Agile-люди», «Agile – руководитель проекта», «Agile – проектный офис» и т. п. В то же время есть и осторожность, фрагментарность использования, некоторый негатив – в общем, самая разная практика. Чем является Agile – подходом, методологией, практикой, методикой или фреймворком, – не так важно. В конкретной ситуации можно применять любое из этих понятий. Главное, что Agile позволяет обеспечить очень быструю реакцию заказчика или потребителя на характеристики создаваемого продукта или результата, дает возможность компании или проектной команде учесть их замечания и предложения, немедленно внедряя это на последующем шаге и минимизируя потери на изменения. А сочетание Agile-фреймворков и бережливого управления (Lean Management) дает сильнейший синергетический эффект, поскольку бережливость основана на цепочке создания ценности и минимизации потерь времени или ресурсов. Объявляемая в проекте или компании гибкость заключается в достижении ценности для заказчика, правильном построении жизненного цикла проекта, в создаваемом продукте или результате, во взаимодействии с заказчиком или потребителями, в выборе только необходимой документации, применении только тех процессов и только в таком объеме, при которых создается ценность и минимизируются потери, и т. д. Суть Agile изложена в многочисленных публикациях (в конце книги есть список литературы). В подавляющем большинстве использование Agile связано с ИТотраслью. Задействование же в других отраслях является достаточно нетипичным и фрагментарным, хотя и происходит относительно давно. Но, как отмечается, даже при таком частичном его применении компании,

использующие Agile в своем бизнесе (примеры приведены дальше в книге), добиваются очень неплохих результатов в виде быстрого обновления или расширения своего ассортимента услуг или продуктов; дисциплинированной и систематизированной работы своих исполнителей, вовлеченных в постоянное совершенствование предложений клиентам; тесной и продуктивной связи с конечными потребителями услуг/продуктов, выражающейся в постоянном тестировании нововведений. В недавнем опросе 4452 членов Scrum Alliance более половины респондентов сообщили, что их организации используют Скрам не в ИТ-направлениях. В список вошли разработки продуктов (11 %), операционный менеджмент (3 %), продажи и маркетинг (2 %) и даже работа руководителей высшего звена (1 %). Данная книга посвящена современному состоянию применения Agile с фокусом за пределами ИТ-отрасли. Кратко рассмотрены история Agile, ценности, принципы и подходы, которые являются эффективными и универсальными и прямо или с адаптацией переносятся на неайтишные проекты. Даются примеры использования в самых разных отраслях. Описаны гибкие стандарты и системы сертификации. Уделено внимание влиянию корпоративной культуры, приведены описания культур, эффективно поддерживающих Agile. Очерчена роль Agile-руководителя проекта и проектного офиса. Даны рекомендации к использованию Agile. Для понимания некоторых аббревиатур и терминов приведу небольшой справочник.

Спринт 1 История Нельзя держать все в голове. Для управления крупным проектом просто необходимы инструменты контроля.

Льюис Фрид

Введение При прохождении этого спринта вы узнаете об истории Agile и курьезных примерах его применения. В качестве ценного результата сможете использовать знания в споре, на корпоративной вечеринке или на семинаре. Без истории не узнать настоящего.

1.1. Первый Agile Творческий подход может означать всего лишь то, что больше нет возможности поступать так, как обычно. Рудольф Флеш

Кто был в начале? В ИТ-проектах у истоков Agile стояли Даррелл Ригби, Джефф Сазерленд (автономная исследовательская группа Skunk works в LockheedMartin Corporation, см. врезку на с. 19), Хиротака Такеучи и др. Эта первая тройка известна и сейчас. Д. Ригби – партнер бостонского офиса консалтинговой компании Bain & Company (www.bain.com), входящей в большую тройку консалтинговых компаний вместе с McKinsey & Company и Boston Consulting Group. Он возглавляет глобальные экспертные группы компании по инновациям и розничной торговле и публикует статьи. Дж. Сазерленд – генеральный директор, основатель, тренер, консультант консалтинговой и образовательной фирмы Scrum Inc. (www.scruminc.com). Х. Такеучи преподает на кафедре стратегии Гарвардской школы бизнеса. Сама история… Еще в 1990-х гг. в ответ на преобладающие в то время неповоротливые (по мнению пользователей) методы управления разработками ПО был создан ряд «гибких» подходов: RAD (быстрая разработка приложений, 1991 г.); DSDM (метод разработки динамических систем, 1994 г.); Скрам (1995), Crystal Clear и экстремальное программирование (XP) (1996); FDD (Feature driven development, 1997 г.) и др. Их уже тогда называли гибкими, хотя все они возникли до публикации Agile-манифеста, официально объявившего миру об Agile. Как родился Agile-манифест? 11–13 февраля 2001 г. на лыжном курорте The Lodge at Snowbird в горах Юты 17 «организационных анархистов» и одновременно авторитетнейших разработчиков ПО собрались, чтобы просто пообщаться, покататься на лыжах, поесть, расслабиться и попытаться прийти к

общему знаменателю в поисках альтернативы негибким процессам и основанным на документации разработкам ПО. Почему Snowbird в горах Юты? Джим Хайсмит – президент компании Information Architects, Inc., автор книги Adaptive Software Development: A Collaborative Approach to Managing Complex Systems («Адаптивная разработка ПО: совместный подход к управлению сложными системами»), а также один из отцов-основателей Agileманифеста, вспоминал, что «очень серьезные баталии проходили при обсуждении места проведения! Были серьезные возражения против Чикаго в зимнее время года: холодно и нечего делать. В Юте тоже холодно, но есть чем заняться, по крайней мере тем, кто катается на лыжах. В Ангилье на Карибских островах жарко и весело, но дорого добираться. В конечном счете Snowbird и катание на лыжах победили». Почему Agile? Почему Agile, а не, например, Light? Потому что Алистер Коберн, также один из участников, счел неподходящим термин light («легкий»): «Я не возражаю, что методологии могут называться легкими или тяжелыми, но я не уверен, что хочу, чтобы на меня ссылались как на легковесного участника конференции легковесных методологов. Это как-то ассоциируется с горсткой худых, дистрофичных, легковесных людей, пытающихся вспомнить, какое сегодня число». Гибкость за пределами ИТ Термин Agile manufacturing появился также в начале 1990-х, когда представители промышленности, правительства и научных кругов США собрались вместе (и конечно, не на горнолыжном мероприятии), чтобы выяснить, как сделать Штаты конкурентоспособными в производстве. Озвученные идеи первоначально были описаны как «гибкое производство», а позже как «гибкость предприятия». В 1991 г. группа в составе 15 руководителей из 13 компаний разработала стратегию 21st Century Manufacturing Enterprise Strategy и создала Agile Manufacturing Enterprise Forum. В 2001 г., в год создания Agile-манифеста, Рик Доув, один из участников форума, публикует Response Ability: The Language, Structure, and Culture of the Agile Enterprise, где описывается, как подготовить организации к реагированию на меняющуюся среду. Skunk works Авиастроительная компания LockheedMartin Corporation создала около завода пластмассы исследовательскую лабораторию с очень сильным запахом. Сотрудники лаборатории сами назвали себя Skunk works, дословно «скунсодельня», «вонючая фабрика», и впоследствии это имя было формально закреплено за лабораторией. Skunk works – одна из первых автономных исследовательских групп, созданная внутри компании для сложной творческой задачи – проекта радикальных инноваций в области конструкции самолетов. Группа работала практически без контроля сверху, со своим бюджетом, в состоянии секретности по отношению ко всей организации, и стала одной из первых гибких команд.

1.2. Agile: ценности и принципы Обыденная, повторяющаяся, знакомая с давних пор текущая производственная деятельность стремится вытеснить новую, эпизодическую стратегическую деятельность. Закон планирования Грешема

Agile-манифест К моменту своего рождения Agile-манифест закрепил уже накопившуюся массу знаний и подходов к управлению разработками в виде четырех ценностей. 1. Люди и взаимодействие гораздо важнее процессов и инструментов. 2. Работающее ПО важнее исчерпывающей документации. 3. Сотрудничество с заказчиком важнее согласования условий контракта. 4. Готовность к изменениям важнее следования первоначальному плану. Таким образом, не отрицая важности того, что справа, все-таки больше ценится то, что слева. Такое замечание сопровождает все варианты Agileманифестов в других разделах. В своих дополнительно разработанных 12 принципах Agile-манифест провозгласил следующее. 1. Наивысший приоритет – удовлетворение потребностей заказчика с помощью регулярной и ранней поставки ценного ПО. 2. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. 3. Работающее ПО следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. 4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. 5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. 6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри нее. 7. Работающее ПО – основной показатель прогресса. 8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. 9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. 10. Простота как искусство минимизации лишней работы крайне необходима.

11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. 12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Примечания автора 1. Перевод Agile-манифеста на русский язык разный, поэтому не удивляйтесь некоторым различиям с теми версиями, к которым, возможно, вы уже привыкли. Как источник было выбрано официальное издание Agile Practice Guide от PMI®, опубликованное на русском языке в начале 2018 г. 2. В тексте Agile-манифеста упоминается ПО. Как уже говорилось выше, данная книга посвящена Agile за пределами ИТ-отрасли. Поэтому в дальнейшем будем использовать более широкий термин – «продукт». Просто мысленно замените «ПО» на «продукт» – и звучание манифеста будет не только айтишным. Agile и Lean C 2001 г. все фреймворки, практики и разработки, разделяющие вышеприведенные ценности и принципы, стали называться гибкими. Спустя год даже появилась рабочая группа, объединенная затем в Agile-альянс. Позже, после ряда разногласий и обсуждений о связи Agile и Lean-подходов, Agile-апологеты приняли Lean, Канбан и их комбинации, что, несомненно, дало сильнейший синергетический эффект. Появились такие термины, как Scrumban, Lean Scrum и др. Сейчас устоялась позиция, которая помещает зонтик, или семейство, Agile в область Lean Management. Апгрейд Agile-манифеста В 2011 г. были опубликованы видоизмененные и усиленные ценности Agile (свободный перевод автора книги): • команда и ответственность важнее индивидуумов и их взаимодействия; • передаваемая бизнес-ценность важнее работающего продукта; • развитие партнерства (с заказчиком) важнее сотрудничества с заказчиком; • готовность к изменениям важнее реакции на изменения. Что сейчас? Д. Ригби, Дж. Сазерленд и Х. Такеучи написали в Harvard Business Review: «С помощью Agile удалось достичь радикальных улучшений в решении задач в ИТ-отрасли. Возможности, которые несет внедрение Agile в других корпоративных подразделениях (и направлениях), огромны». И в то же время график ажиотажа относительно Agile (рис. 1.1) показал, что мир уже находится в точке после «пика завышенных ожиданий» и продвигается ближе к «впадине разочарования». Возможным подтверждением этого являются оценки компании Standish Group в отчетах CHAOS Manifesto 2013–2015 гг., где она неожиданно снизила рейтинг

использования Agile в проектах, сведя его применение к «малым проектам».

Рис. 1.1. Кривая разочарований

1.3. Интересное про Agile Из всех трудностей, с которыми столкнулось NASA, отправляя человека на Луну, управление было, наверное, самой сложной задачей. Роджер Лаунис, историк NASA

Agile и автомобиль Практически Agile реализовывался уже давно – при «кустарном» или «ручном» производстве автомобилей, когда малой многофункциональной группе работников со смешанными навыками проектирования, подгонки и даже машинных операций давали машину для сборки от начала до конца. Детали были не слишком совершенны, но с помощью подручных средств они подгонялись и приспосабливались друг к другу. В итоге автомобиль после ряда переделок выпускался. Это было недешево, не все позволяли себе подобное в то время. При введении Генри Фордом на сборочных линиях Ford Motors конвейера с четким разделением труда и последовательностью работ с различными ресурсами, специализирующимися на различных задачах сборки, стоимость изготовления автомобиля значительно снизилась и он стал доступен для всех. Фактически отрасль отказалась от Agile и добилась огромных успехов в производительности. Однако успешность такого конвейера требует важных критических условий: 1) минимизации обратного движения, переделок и доработок, высокой стандартизации деталей, подходящих к любому автомобилю, без подгонки и корректировки; 2) немногочисленности переходящих партий (в идеале единичного потока), поскольку переход больших партий увеличивает время выполнения на каждом этапе и приводит к позднему обнаружению проблем качества (Satyashri Mohanty,

http://tocpeople.com/). В отсутствие этих условий оптимальным становится Agile. Ниже, в разделе 6.7, мы вернемся к Agile-проекту уникального автомобиля и еще раз проиллюстрируем преимущества Agile на инновационных направлениях. Провалы Agile 1. Крупнейший проект по разработке ПО с использованием «как бы гибких» подходов и бюджетом 2 млрд фунтов стерлингов в Британской флагманской правительственной программе реформы социального обеспечения Universal Credit провалился с треском. И хотя Agile был объявлен тогда универсальным инструментом, конфликты между премьер-министром и министрами, отсутствие непрерывной связи с заказчиком, который отмалчивался или отписывался, корпоративная культура Департамента по труду и пенсиям, «водопадные» контракты с HP, Accenture, Capgemini и IBM, формирование гигантской Agile-команды из 1500 человек (!) и использование таких же гигантских итераций в два года были в полном противоречии с Agile. В итоге укрепилось мнение, что Agile и государственный бюрократизм совмещаются с трудом. Почему был выбран Agile, так и осталось непонятным, возможно, как дань моде[1]. 2. В США наиболее громкий провал Agile был связан с запуском системы медстрахования Obama Care. Программа включала предоставление определенным категориям американских граждан бесплатных полисов страхования. Для этого надо было заполнить анкету на сайте и дождаться решения определенных служб. Миллионы бросились заполнять анкеты, и это им удавалось сделать, а вот отправить – нет. Возникал какой-то сбой сервера. Система умерла через шесть месяцев после старта. Был привлечен внешний эксперт, который, оценив ситуацию, проделал весь путь с конца, собрал все вместе и добился корректного функционирования системы. Agile и летное искусство Майк Кон, ведущий консультант и практик Agile, один из основателей Agile- и Scrum-альянсов, организаций, развивающих, поддерживающих и популяризующих Agile и Скрам в мире, писал: «В 1960-х гг. в США был летчик, военный стратег Джон Бойд. Он придумал теорию OODA (петля Observe – Orient – Decide – Act (“Наблюдение – Ориентация – Решение – Действие”)), по которой воздушный бой выигрывает не самый лучший самолет с технической точки зрения, а пилот, принимающий максимальное количество решений за определенный отрезок времени и моментально реагирующий на изменяющиеся обстоятельства. Бойд заслужил прозвище Сорокасекундный Бойд, так как в воздушном бою мог победить любого пилота менее чем за 40 секунд. В общем, побеждает наиболее быстрый и гибко мыслящий (Agile. – Примеч. авт.). Теория Бойда активно применялась в те времена в военной сфере»[2].

1.4. Agile: процессы, кейсы, проекты

Операционный менеджмент – это освещение тоннеля, стратегический менеджмент обеспечивает наличие света в конце тоннеля, а проектный менеджмент – это двигатель поезда, который и движет организацию вперед. Джой Гамз, директор Project Auditors LLC

Agile и процессы Процессы в компании – это обычно повторяющиеся действия, исполнение типовых должностных инструкций, регламентов или процедур, типовые ситуации с низкой неопределенностью и постоянными участниками. Примерами процессного менеджмента как способа организации однородного труда являются, например, серийное и типовое производство, обслуживание, банковские услуги, регулярные продажи и т. п. Agile, фокусирующийся на гибкости и снижении потерь, для повышения эффективности рутинных процессов может предложить, например, следующее: ♦ максимальный визуальный контроль, цвет, карточки, доски, общий вид и доступность информации для всех участников; ♦ работу исполнителей в процессах вместе и рядом, в одном помещении или использование, например, «аквариумных» видеоокон при удаленной работе; ♦ работу внутреннего владельца процесса, его участников, внутреннего заказчика процесса сообща, снижение потерь информации; ♦ внимание к постоянно формируемой ценности создаваемых результатов для внутреннего заказчика, коммуникации с помощью встреч, моментальные и эффективные решения, постоянное общение; ♦ лидерство и поддержку (далее введем термин «обслуживающее лидерство») владельца процесса, который задает направление и определяет правила сотрудничества и работы; ♦ разделение всего процесса на еще более мелкие шаги, процедуры или операции с получением быстрых новых знаний и немедленным анализом ошибок. Business agility, или бизнес-гибкость Если говорить о компании в целом и управлении ею, то Agile дает ей способность понимать и реализовывать изменения внутри или снаружи и соответствующим образом реагировать, чтобы обеспечить ценность для своих внутренних потребителей и внешних клиентов. Agile – это: ♦ корпоративное мышление, формирующее гибкость бизнеса (способность компании адаптироваться к меняющейся ситуации, сохраняя при этом свое видение или стратегию), ценность людей и их взаимодействия, укрепляющее сотрудничество, стремление к результату и постоянное обучение; ♦ уход от последовательного цикла планирования, реализация итераций для обучения и обратной связи и адаптация как продукта, так и процессов. Бизнес-гибкость

Исследования показали, что в руководстве компаний, с которым проводили беседы, большинство были хорошо осведомлены о том, как быть гибкими в процессах бизнес-аналитики, архитектуры процессов и эластичности инфраструктуры, но не смогли сами быть таковыми в выполнении этих процессов. С подачи гендиректора и сооснователя компании Systematic Майкла Хольма была реорганизована работа руководства, юридического и финансового отделов, отделов продаж и персонала в виде следующих шагов: ✓ пересмотрена деятельность заместителей генерального директора, от многих из них отказались; ✓ вице-президенты покинули свои кабинеты и стали работать со своим персоналом как Agile-команды; ✓ кабинеты стали комнатами осведомленности (situational awareness room – SIT) о ситуации с продажами и прогрессом разработок, были вывешены белые доски с актуальной информацией и инфопанели; ✓ почти вдвое сократили количество периодических отчетов, остальные данные вносили в цифровом виде; ✓ стала применяться приоритизация важнейших для бизнеса вопросов: коммерческие предложения и удовлетворенность клиентов; ✓ использовались ежедневные 20-минутные утренние летучки – что было сделано вчера, чем заняться сегодня, какая и кому нужна помощь; ✓ проводились еженедельные (и даже ежемесячные) встречи вицепрезидентов с подчиненными; ✓ был организован онлайн- и видеодоступ ко всем сотрудникам. Бизнес-гибкость проявляется в следующих направлениях: ♦ рынок: это оперативность или отклик рынка и оптимальные каналы, работа с большими данными, дизайн-мышление (сервис-дизайн); ♦ организационные моменты: распространение корпоративных знаний, цифровая культура и психология и управление изменениями; ♦ процессы: постоянная бизнес-аналитика, эластичность решений, организации и процессов, инновации в ПО и поиск/цепочка поставок. Agile и управление кейсами Кейс – это управление «решением конкретной задачи» для VIP-клиента или в особых условиях, например в работе врачей, юристов, консалтинге, исследованиях, проектировании или в общественных инициативах. Кейс включает описание конкретной исходной ситуации и способ ее разрешения, пути, выбранные участниками, их действия, материалы, относящиеся к делу, и полученный результат. К характеристикам кейса относится следующее [3]: ♦ объектом управления является проблема (задача), а не собственно процесс; ♦ кейс объединяет участников, бизнес-процессы, контент;

♦ в ходе исполнения происходят (или вероятны) изменения процессов, подзадач, участников; ♦ высокий уровень неопределенности задач, недостаточно информации на старте; ♦ в ходе выполнения происходит накопление полезных и применимых в дальнейшем знаний (история решений, лучшие практики, шаблоны); эти знания и информацию можно передать другим. Процесс работы с кейсом может включать шесть этапов. 1. Ассесмент (выяснение ситуации клиента кейса и ее оценка). 2. Планинг (планирование необходимых шагов). 3. Вмешательство (принятие мер). 4. Мониторинг (контроль, наблюдение за исполнением мер). 5. Оценка (оценка результатов, планирование помощи даже в случае неблагоприятного развития). 6. Реассесмент с повторением этапов 1–5. Когда управление кейсом учится на прошлых ситуациях и формирует «лучшие практики», вводится термин «адаптивный кейс-менеджмент» (Adaptive Case Management, ACM, предложен в 2010 г. компанией Workflow Management Coalition). Такая технология позволяет гибко управлять решением задачи в зависимости от развития ситуации. Оформляют кейс, только если это имеет ценность в дальнейшем. Agile и проекты Управление проектами находится на более высоком уровне иерархии, чем процессы или кейсы, хотя некоторые кейсы вполне могут быть полноценными проектами, например уникальные проекты разработки, трансформация организаций и т. п. Проекты, возможно, потребуют больше компетенций, организации, опыта, особых методологий, и их жизненные циклы формально делятся на предиктивные («водопадные», или последовательные) и адаптивные (Agile-) виды. Адаптивные циклы включают инкрементные и итерационные варианты, которые по своей природе и являются гибкими. Каждый инкремент или итерация – это возможность внести изменения, провести анализ пройденного периода, установить приоритеты. Agile-подходы разработаны именно для того, чтобы приспособиться и адаптироваться к неизбежным изменениям, которые происходят в проектах. В начале Agileпроекта нужны не детализированные требования, а требования высокого уровня. Для старта достаточно лишь небольшого планирования. Именно об Agile-проектах и пойдет речь дальше.

Спринт 2 Жизненный цикл проекта Введение

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

Второй спринт информирует читателя о видах жизненных циклов проектов. По итогам спринта вы сможете различать «Водопад» и Agile, консультировать свою команду или генерального директора, сделать правильный выбор жизненного цикла при запуске нового проекта. Условное деление проектов на предиктивный и адаптивный варианты предполагает, что успех проекта в первом случае определяется полной проработанностью будущего результата и пути его достижения, следованием управленческим регламентам и зафиксированным договоренностям. Другие же проекты – уникальные и инновационные, где гарантий заранее нет, успех определяют люди, их взаимодействие и мнение заказчика. Выбор варианта реализации проекта во многом связан с понятием жизненного цикла как набора временных итераций, через которые проходит проект со старта до достижения результата. Подобный цикл может включать в себя отдельные фазы, непосредственно связанные с разработкой какого-либо продукта, например сервиса или ИТ-решения. Такой вложенный цикл называют жизненным циклом разработки.

2.1. Предиктивный цикл Проект без критического пути – как корабль без руля. Н. Деан Мейер, автор работ по экономике и управлению

Представим проект, где содержание, сроки и стоимость определены и зафиксированы на начальной фазе договором или техническим заданием. Заказчик обещал не вмешиваться в реализацию и прийти только в конце. Любые изменения объявлены не слишком желательными и будут требовать управления по документарным запросам. Примером может быть следующий цикл. 1. Разработка концепции: назначение руководителя проекта и формирование ключевой команды; сбор исходных данных; выявление и фиксация требований; определение целей, задач, результатов, ограничений, рисков, сроков, ресурсов, средств, утверждение ТЗ. 2. Подготовка к реализации: разработка полного содержания проекта и календарного плана работ; составление сметы на весь проект; определение и снижение рисков; заключение договоров с подрядчиками. 3. Организация основных работ: оперативное планирование; контроль за ходом работ; организация обеспечения; руководство, прогноз состояния; контроль основных KPI проекта (объем, качество, сроки, стоимость).

4. Завершение: сдача заказчику, подготовка документации и отчета, сбор уроков реализации проекта. Циклы Интересны сравнения таких циклов с баллистической траекторией и конусом. Баллистическая траектория: точно прицелились в начале проекта, спустили «курок», подписывая договор, и внимательно следим за траекторией снаряда, ограничивая влияние ветра или других препятствий. Изменения вносить нельзя, от точности попадания в мишень зависит приемка результата проекта заказчиком. Конус. Реализация проекта – это множество маршрутов от вершины к основанию, среди которых выделена область допустимых траекторий его развития. Управление рассматривается как деятельность, препятствующая выходу траектории из области их допустимости. Такие и подобные циклы, которые подразумевают последовательный переход с фазы на фазу без пропусков и возвращений, еще называют последовательными, «водопадными» (Waterfall), прогнозируемыми, предсказуемыми, классическими, типовыми или каскадными. Первое их официальное упоминание приписывается статье Винстона Ройса, вышедшей в 1970 г., хотя сам автор и не использовал термин «Водопад», который, как считается, появился только в 1976 г. При моделировании обсуждаемых циклов часто используют корпоративные или отраслевые шаблоны, или библиотеки фрагментов, иную регламентирующую документацию, которые формализуют управление, облегчают контроль и понимание статуса проекта, помогают обучаться и подбирать команду, типизируют риски и организацию проекта. По данным исследования PMI®, 12 % компаний применяют методологию Waterfall постоянно, 40 % респондентов утверждают, что часто к ней обращаются. А по данным LiquidPlanner, каскадную модель используют 25 % организаций[4]. Такие предпочтения имеют свои основания, поскольку предиктивный цикл характеризуется рядом положительных моментов: ♦ иногда очень важно, чтобы переход от одной фазы к другой происходил только после полного и успешного завершения предыдущей фазы (подход Stage-Gate), например при передаче технической информации или сдаче технического элемента; ♦ в проекте объявлена жесткая необходимость обязательного расчета затрат и сроков при фиксированном содержании; ♦ лучше всего подходит для проектов, где создаются физические объекты, – от строительных до проектов по установке оборудования; ♦ требования заказчика непротиворечивы, известны, понятны и зафиксированы; ♦ все стороны хорошо понимают, какой продукт они создают, и этот продукт важен именно полностью и в конце проекта; ♦ проект не очень масштабный;

♦ графики и алгоритмы проектов можно использовать в будущем для идентичных или аналогичных проектов; ♦ проект типовой, существует понятное ТЗ, заказчик не хочет управлять проектом и похожие ситуации. Гибкость на практике Руководство компании Toyota, знаменитое созданием Lean и Канбан, часто критикуют за недостаток гибкости: до конца 2000-х для нужд производства компания пользовалась каскадной моделью разработки ПО. Анализ разработки сайта в компании Ericsson AB показал, что предиктивный вариант привел к путанице и 26 % изначальных требований оказались просто бесполезными. Оплот классического подхода сейчас – строительные и инженерные проекты, в которых содержание остается практически неизменным на протяжении всего времени, а также проекты с материальными выходами.

2.2. ИНКРЕМЕНТНЫЙ ЦИКЛ Прежде чем создать что-то повторяемое и многоразовое, сначала нужно создать что-то одноразовое. Вуди Уильямс

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

Фавелы Фавелы в Латинской Америке строятся по комнатам. У жителей времени много, зимы нет, как и денег. Они строят свою первую комнату из кирпичей, пока не кончатся или сколько есть. Потом достраивают, ставят окна, накрывают крышу и иногда даже штукатурят и красят. Когда семья растет, пристраивают следующую комнату.

2.3. Итеративный цикл Нам не нужны повторяющиеся процессы, нам нужны повторяющиеся результаты. Канадский программист Скотт Амблер

Итеративность определяет разработку продукта также путем выполнения ряда повторяющихся итераций, когда основная цель и требования к конечному результату определены, разработано высокоуровневое видение, но детали реализации могут меняться с течением итераций, как и оценки сроков и стоимости, в рабочем порядке, по мере расширения понимания командой продукта. Планирование следующей итерации происходит по мере выполнения работ в рамках предыдущей. Команда проекта может меняться между итерациями или во время них. Так можно написать объемный аналитический отчет. Сначала согласовать содержание, потом, на следующей итерации, разработать разделы, затем добавить материал внутрь разделов, после этого итерационно создать несколько последовательных редакций. Кино В проекте создания фильма сначала пишут сценарий. Его можно откорректировать, положить на полку, продать. На следующей итерации отснимут видеоматериалы. В них также можно вносить изменения. Потом провести технический просмотр. Далее смонтировать и озвучить. На каждом шаге принимается решение о движении дальше. Выхода итерации достаточно, чтобы запланировать следующую. Работают разные участники. У итеративных циклов есть свои зоны предпочтений. Они применяются, если содержание проекта подвержено изменениям, а требования к конечной системе заранее четко определены, ресурсы понятны и сроки не являются ключевыми ограничениями. Можно управлять изменением целей и содержания, уменьшить сложность проекта. Крупные и сложные проекты часто выполняются в итеративном цикле с целью сокращения риска, позволяя команде использовать отзывы и извлеченные уроки, полученные между итерациями.

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

Скотт М. Граффиус. Agile Scrum: краткое руководство с пошаговыми инструкциями

По результатам итераций разрабатывается продукт с минимально необходимым набором возможностей или функций. Заказчик его оценивает, давая свои новые требования и по возможности начиная использовать этот продукт уже в своей деятельности. Такая версия продукта называется MVP – Minimum Viable Product (минимально ценный продукт) (исполнительный директор SyncDev Фрэнк Робинсон, 2001 г., позже Эрик Райс, основатель IMVU) или PSPI – Potentially Shippable Product Increment (готовое к поставке приращение продукта). Например, это базовая функциональность продукта, первый тестовый продукт для рынка. В MVP нужно закладывать одну основную ценность, чтобы получить идеи по ее развитию или отказ. Не надо делать ничего лишнего, только главную ценность для пользователя. На красоту не тратят времени, все должно быть простым, без тяжелой и долгой разработки. Тестировать MVP с заказчиком надо как можно раньше, чтобы иметь преимущество в проекте или быстро выбросить неудачный MVP и заняться новым. Для проверки новой функциональности на существующем продукте можно повесить баннер или кнопку, измерить число нажатий и понять первый интерес к данной идее. В проекте комплексной типовой застройки это может быть первое здание, введенное в эксплуатацию, в проектах создания программы туров – первый пробный тур и т. д. Zappos – интернет-магазин обуви Когда этот магазин запускался, в нем не было собственного товара. Ник Суинморн фотографировал обувь в обычных магазинах и вешал фотографии на сайт. Если товар нравился, он ехал в магазин, покупал эту обувь и доставлял ее клиенту. Покупатели не догадывались об отсутствии у Zappos собственного товара.

2.5. Agile: комбинация итеративных и инкрементных циклов – Начни с начала, – торжественно произнес Король, – и продолжай, пока не дойдешь до конца. Тогда остановись! Льюис Кэрролл

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

Agile – «реакция на изменения важнее следования плану». Итеративные и инкрементные подходы обеспечивают обратную связь, которая позволяет лучше планировать следующие шаги проекта. Контроль рисков и стоимости осуществляется с учетом поступления информации о требованиях и ограничениях. Именно быстрая и относительно безболезненная реакция на изменения является причиной того, что многие крупные компании полностью перестраивают свои системы управления проектами. Agile также отлично подходит для проектов с «открытым концом» – например, запуска сервиса или блога. Agile лучше применять, когда: ♦ потребности пользователей постоянно меняются; ♦ изменения реализуются за меньшую цену из-за частых инкрементов; ♦ проекты имеют дело с сервисноориентированными и нематериальными результатами, например изменения, копирайтинг или проектирование; ♦ надо быстро стартовать; ♦ значение ценности проекта в приоритете, а сроки и стоимость могут варьироваться; ♦ заказчик хочет активно участвовать в проекте на всем его протяжении; ♦ заказчик, проектировщик и исполнители находятся рядом и постоянно общаются; ♦ возможна пошаговая разработка, основанная на инкрементах, версиях (MVP); ♦ допустимы простые визуальные способы отслеживания (карточки на стене, а не формальные документы) и т. п. К недостаткам Agile относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Необходимы регулярная вовлеченность заказчика и выделенная команда. Гибкость может приводить к потере фокуса. Отсутствие четкого процесса и процедур, разбиение проекта на подпроекты и частые изменения при отсутствии четкого направления со стороны руководства могут привести к потере ориентиров и понимания того, что важно, а что – вторично.

2.6. Гибридный цикл Вы можете уговорить человека подписаться на нереалистичные сроки, но вы не сможете заставить его выполнить проект в такие сроки. Джон Эдвардс, Джим Батлер, Барри Хилл, Сандра Расселл

Правильное сочетание предиктивных и адаптивных циклов может комбинировать преимущества и тех и других и называется гибридным или смешанным циклом. Вариантов совмещения «Водопада» с элементами Agile много.

♦ Команда может реализовывать инкрементный цикл, использовать короткие итерации, ежедневные летучки и ретроспективный анализ, однако в то же время ряд других этапов проекта, таких как стартовая предварительная оценка, распределение работ и отслеживание хода работ, осуществляется на основе предиктивных подходов. ♦ В другом варианте сначала происходят проработка и согласование бизнестребований, планирование, финансирование, оценка затрат всего проекта в предиктивном варианте. Потом включаются параллельные виды работ: проектирование и разработка продукта, создание документации по адаптивным правилам. Здесь даже могут быть организованы несколько одновременно работающих команд. Испытания, сдача проходят также в «водопадном» варианте. Такое сочетание называют сэндвичем, или Water Scrum Fall, или както иначе. Возможны и другие термины – Iterative Agile, ScrummerFall, WaterScrum, AgileFall, Water-Agile-Fall. Water Scrum Fall Независимая исследовательская компания Forrester Research опубликовала отчет Дейва Уэста (тогда главного аналитика компании, а через два месяца ее вице-президента и директора по исследованиям) и его команды аналитиков, который называется «Water-Scrum-Fall – реальность Agile для большинства организаций сегодня». ♦ Интересны и перспективны гибридные варианты, например, в крупных проектах, где чисто «водопадное» мышление с высокой вероятностью ведет к неуспеху. Даже если на стадии детальной проработки и согласования ТЗ удастся избежать недопонимания и неправильной трактовки требований, к завершению полученный результат может уже устареть. ♦ В рамках предиктивного цикла можно заранее в конце ключевых фаз заложить дополнительные бюджеты на статистически вероятные риски (такие риски часто заранее известны и предсказуемы) и тем самым снизить влияние рискованности такого цикла и конфликта с клиентом, если что-то идет не так. Это также дает некоторую гибкость в учете дополнительных требований заказчика, решении проблем и реализации новых идей. В России же принята практика фиксации цены, да еще с ее снижением, что вызывает трудности применения такого цикла. ♦ Возможен вариант заключить рамочный договор, отказавшись от фиксирования содержания и фиксированного бюджета. После завершения каждого этапа, например после проектирования, смета уточняется, включая новые объемы с согласия заказчика, что оформляется дополнительным соглашением к первоначальному договору. Бюджет становится изменяемым, но заказчик получит то, что ему на самом деле нужно и влияет на объем и содержание работ. ♦ Некоторая гибкость в предиктивном проекте с жесткими сроками может быть создана путем переоценки остающегося к концу проекта объема вместе с заказчиком. Оставшиеся фактические объемы, которые невозможно закончить целиком, делятся на три части: то, что обязательно должно быть выполнено (исполнитель берет это как жесткое обязательство); то, что заказчик может назвать важным, но несрочным (это переносится в будущее и выполняется ресурсами исполнителя или в рамках нового проекта по договоренности с

заказчиком), и то, что заказчик уже может счесть неактуальным и от чего может отказаться (этот объем не делается совсем). Переносимый на будущее объем работ называется в ИТ-отрасли техническим долгом. ♦ Может быть организован цикл, когда заказчик практически сам ставит задачи либо наблюдает за работой команды и контролирует сроки. Оплачивается только отработанное время (Time & Materials). Некоторые риски опасений в нетрудолюбии исполнителя могут быть сняты, если заказчик рядом, постоянно наблюдает за развитием и результатами, в том числе через систему листа учета рабочего времени. Этот подход довольно распространен за рубежом. ♦ Ряд «водопадных» шагов выполняется и Agile-командами на старте проекта, в начальных итерациях для создания общего видения проекта, оценки конфигурации или архитектуры, начального проектирования работ, создания дизайна решения. Далее запускается адаптивный цикл. Также формируется некоторая «водопадная» интеграция параллельных работ в финальной и промежуточных вехах и, естественно, «водопадное» закрытие проекта. ♦ Возможна гибкость и в EPC-договорах (фиксированных договорах, включающих проектирование, поставки и строительство), хотя такой договор – это классический «Водопад» с большим количеством промежуточных этапов, или итераций, где для каждой итерации установлены жесткие ограничения по срокам, затратам и ресурсам и предусмотрены заранее оговоренные действия при возможных нарушениях. Внутрь всего «водопадного» цикла можно вложить внутренний Agile-цикл с перечнем требований и перечнем задач. Формируется роль владельца продукта как внутреннего (от исполнителя) менеджера, контролирующего общую концепцию проекта. Вводится роль администратора по поддержке работы команды (скрам-мастер). Работа команды ведется по коротким итерациям. Для заказчика «снаружи» в этом случае сохраняется приемлемая для него схема фиксированной цены. Для исполнителей обеспечивается использование Agile, но с жестким контролем концепции и заранее продуманными ограничениями на каждую итерацию. Возможный пример организации проекта При наличии заказчика, который хорошо понимает свой бизнес и что такое «водопадные» проекты, но совсем не воспринимает Agile, возможен следующий гибридный цикл. В начале проекта вместе с заказчиком определяются верхнеуровневые требования и очертания проекта (по аналогу, экспертным оценкам, интуиции, с учетом базовых требований). Понимаются его бизнес-задачи и базовые требования. Формируются рамочный бюджет проекта, масштаб работ, сроки, вехи и договор. Начинается реализация, и на первой итерации (несколько недель) вместе с заказчиком требования уточняются, происходят детализация, приоритизация и согласование результатов. Далее работа разбивается на итерации (возможно, с разной длиной), в конце каждой из них заказчику демонстрируются промежуточные результаты. В рамках выстроенного взаимодействия с заказчиком оговаривается принятие возможных изменений либо в рамках бюджета, либо отдельными соглашениями. По мере расширения знаний о проекте формируются более точные оценки и требования. ♦ Гибкие гибриды (без применения «Водопада») также возможны, например, в виде распространенной комбинации: Скрам, Канбан и ХР. Скрам дает

представление о журнале требований продукта, владельце продукта, скраммастере и кросс-функциональной команде разработки, включая планирование спринта, ежедневные летучки, анализ спринта и ретроспективные сессии спринта. Канбан-доска улучшает визуализацию потока работы, обеспечивая хорошую наглядность препятствий и позволяя управлять потоком с помощью регулирования работы в рамках процесса. Инструменты ХР, такие как использование карточек историй (story cards), непрерывная интеграция, рефакторинг, автоматизированное тестирование и разработка на основе тестов, еще больше повышают результативность работы Agile-команды. Подводя итог, можно сказать, что комбинирование различных циклов и практик часто дает очень интересные эффекты с более высокими показателями исполнения, чем у каждого варианта цикла в отдельности.

2.7. Как выбрать «правильный» цикл? Проектный менеджмент – это способ развития структуры сложного проекта, в котором сходятся вместе такие независимые переменные, как время, стоимость, ресурсы и человеческое поведение. Рори Бурк, Enterprise Enablement

Когда в проекте применить адаптивный (Agile-) цикл, а когда – каскадный вид, зависит от целого ряда моментов, таких как тип проекта, ограничения заказчика, культура компании, сложившиеся практики и др. Предпочтительному использованию Agile способствуют такие факторы, как: ♦ начальная высокая неопределенность в содержании проекта; непонятная скорость появления новых требований; ♦ сложное наполнение проекта; ♦ постоянно изменяющиеся потребности заказчика или пользователей; ♦ желание реализовывать изменения за меньшую цену из-за частых инкрементов или итераций; ♦ непростые требования заказчика или невозможность их согласовать; ♦ новые, непроверенные технологии. Дополнительными благоприятствующими условиями являются поддержка руководства компании-исполнителя, желание заказчика работать по Agile и возможность выделенной команды. Agile-подходы помогают приспособиться и адаптироваться к неизбежным изменениям, которые происходят в проектах, поэтому в начале таких проектов не документируются детализированные требования. Вместо этого используются приоритизированные требования высокого уровня в виде журнала требований продукта. Если в проектах: ♦ полная предсказуемость с начала и до конца;

♦ четкие вводные и малоизменяемые цели, поддающиеся полному планированию; ♦ типовые технологии в знакомых комбинациях; ♦ ценность видна и нужна только при завершении проекта; ♦ ключевые заинтересованные стороны точно понимают, что именно будет поставлено в самом конце проекта, тогда лучше применение Waterfall, или «водопадных» технологий, но при условии, что заказчик не участвует в проекте и не подразумеваются изменения. В приложении 1 приведен чек-лист для более точного выбора подхода.

Спринт 3 Фокус на Agile Введение Проект считается завершенным, когда он начинает работать на вас, а не вы на него. Скотт Аллен, Microsoft

В рамках спринта под номером 3 вы получите всю основную информацию о том, что такое Agile. Это позволит понять, если ли Agile у вас в компании, правильно ли он определен и применяется, а также что надо объяснить руководству, если возникнет вопрос об Agile.

3.1. Преимущества Высокая скорость движения не имеет смысла, если неизвестен пункт назначения. Не путайте процесс с результатом. Мэйбел Ньюкомбер

Заметим, что гибкость (здесь и далее я часто буду использовать Agile и «гибкость» как синонимы) применима не всегда. Даниэль Пинк в своей книге «Драйв, или Что нас на самом деле мотивирует» (см. список литературы) разделил человеческую деятельность на два типа задач: ♦ эвристические задачи, где нет заранее известной инструкции, алгоритма решения, нет точно обозначенной цели. Есть примерные очертания: нарисовать такую рекламу, чтобы все ахнули, определить непонятную причину поломки оборудования, разработать уникальный способ обучения, удивить подарком близких и т. д. От исполнителя требуется самостоятельно найти решение; ♦ алгоритмические задачи, где исполнителю требуется максимально точно выполнить заранее определенную инструкцию или алгоритм. Примерами таких

задач могут быть: покрасить стену в конкретный цвет, поменять колесо автомобиля, заполнить типовую налоговую декларацию, вырыть яму нужных размеров и т. д. Здесь думать не надо, надо действовать. В этом смысле гибкость имеет наибольший потенциал именно в области эвристических задач или в их комбинациях с алгоритмическими. Кроме эвристичности, в основе Agile-мышления лежат: ♦ фокус на создании ценности для заказчика, куда направляются все время и усилия, которые расходуются в проекте. Но также минимизируется то, что ценности не несет; ♦ разделение рисков между исполнителем и заказчиком; ♦ регулярная обратная связь; ♦ легкая и быстрая реакция заказчика на изменения как функциональных требований, так и приоритетов уже сразу после первой итерации в виде комментариев и поправок; ♦ самоорганизация команды, включающей представителя заказчика, выражающего интересы бизнеса; ♦ команда разработчиков, которая сама распределяет задачи, имеет внутреннюю ответственность и, соответственно, будет гарантировать производительность труда и качество продукта; ♦ и возможный администратор, активно помогающий команде и выполняющий те задачи, которые ей делать не надо. К применению Agile ведут и внешние факторы: ♦ высочайшая конкуренция, и не столько в продуктах и сервисах, сколько в моделях доставки их до клиента или в моделях управления желаниями клиентов, когда клиенты хотят все сразу, качественно, быстро и дешевле, чем у других; 30 % опрошенных мечтают об ускорении выпуска продуктов на рынок, то есть об улучшении Time-To-Market; ♦ уход от долгосрочного прогнозирования (когда надо забыть «пятилетки», «трехлетки» или жесткие стратегические программы) в VUCA-мире, когда темпы изменения экономической среды настолько высоки, что неизвестно, что будет актуально на рынке уже сегодня вечером; ♦ 29 % опрошенных хотят управлять постоянно меняющимися приоритетами; ♦ исторически или ментально сформированная и абсурдная бюрократия, затянутость и сложность принятия решений, неповоротливость компаний с решениями, которые не принимаются, а растворяются… и многое другое; 23 % опрошенных хотят улучшить взаимодействие бизнеса, сервиса, ИТ-решений, больших данных. Если руководство вас спрашивает, в чем разница между хаосом или бардаком (а именно такие понятия несведущие часто отождествляют с Agile) и гибкими подходами, то можно дополнительно использовать и другие аргументы:

♦ увеличение продуктивности предприятия за счет более частого выпуска желаемой клиентом продукции (топинги в пиццах можно делать по желанию посетителей и экспериментировать вместе); ♦ улучшение качества продукции за счет быстрой реакции клиента (в конечном продукте число дефектов минимизируется, поскольку проверка качества проводится по завершении каждой итерации); ♦ Agile-проект быстро запускается, не надо ждать всех согласований; ♦ наглядность ситуации в проекте за счет визуализации, прозрачности работы команды и постоянных встреч; ♦ уменьшение рисков переделок опять же за счет постоянной реакции клиента; ♦ упрощение процессов (не делаем лишнего, все делают то, что должны, сложное разбито на простое); ♦ уменьшение стоимости проектов (конечно, не всегда, но за счет снижения числа переделок, повышения качества, раннего включения продукта в рынок такой эффект есть); ♦ лучшая поддержка проектов в дальнейшем (общее понимание выходов проекта исполнителем и заказчиком, более высокая лояльность к совместной работе); ♦ улучшение работы и морального климата в случае постоянной команды и даже распределенных команд. Финансисты также жалуют Agile, который дает возможность: ♦ экономить средства, не прорабатывая проектные документы в течение длительного времени; ♦ в полной мере контролировать бюджет проекта в той части, которая запущена как первые спринты; ♦ вносить коррективы без существенных финансовых потерь для предприятия; ♦ осуществлять ранний запуск продукции и получать первые доходы.

3.2. Ограничения Нельзя держать все в голове. Для управления крупным проектом просто необходимы инструменты контроля. Льюис Фрид

Выше прозвучали похвалы в адрес Agile. Нельзя не остановиться и на ограничениях, хотя все относительно. ♦ Agile мало способствует предсказуемости в сроках, затратах, поскольку не позволяет в полной мере количественно оценить требуемые усилия, особенно в начале жизненного цикла. Это так, однако всегда ли мы уверены в том, что оцененный в сроках и затратах продукт к концу проекта будет нужен комунибудь?

♦ Agile требует большей физической вовлеченности исполнителей, затраченных усилий на взаимодействие, больше приверженности. Участники должны постоянно взаимодействовать друг с другом через многочисленные устные коммуникации и выполнение ежедневной активной работы. Но именно это способствует тому, что продукт будет гораздо лучше соответствовать ожиданиям пользователей! ♦ В Agile повышенные требования к заказчику. Почти регулярно заказчик или клиенты могут привлекаться для быстрого реагирования и утверждения, чтобы был возможен переход к следующей итерации. Клиентов полезно учить и консультировать по вопросам разработки продукта, поскольку нехватка участия клиента будет влиять на качество продукта и конечный успех. Но ведь именно взаимодействие с заказчиком, его обучение делают его лояльным к направлению, гибкому циклу и будущим проектам! ♦ В Agile возможно отсутствие необходимой и полной документации. Поскольку требования постоянно уточняются, документация действительно часто не слишком подробна и больше визуально организована, чем написана. В случае изменения команды новые участники не смогут получить информацию, узнать подробности. Чтобы это не создало недоразумений и трудностей, можно провести короткую устную вводную сессию по проекту для новых членов команды. ♦ И наконец, Agile-проекты легко уходят в сторону неправильного направления, поскольку потребности заказчика будут постоянно меняться. Кроме того, имеется опасность неконтролируемого расширения границ проекта, и постоянно меняющийся продукт становится бесконечным. Может, просто больше сотрудничать с заказчиком?

3.3. Agile или «Водопад»? «Водопад» – это проект по правилам, Agile – это проект без правил. Российские менеджеры крупной международной компании

При использовании предиктивных циклов формируются следующие особенности. Команда: ♦ создается под проект и расформировывается после; ♦ состав может меняться, и даже часто; ♦ допустимы узкопрофильные специалисты. Руководитель проекта: ♦ акцент на развитии навыков подчинения себе команды; ♦ важность внимания развитию зрелости и эффективности его роли в проекте; ♦ заинтересованность в точном соблюдении сроков и бюджета;

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

♦ при появлении проблемы – исследование ее корневых причин и способов противодействия им; ♦ для избавления от проблем – проведение экспериментов и в случае успеха экспериментов – проведение улучшений; ♦ поддержание стабильно высокого качества продукта; ♦ короткие итерации с выходом на потребителей; ♦ валидация результатов в конце итерации после обратной связи от заказчика; ♦ коммуникация лицом к лицу; ♦ регулярная поставка улучшений продукта; ♦ переход от согласования требований к приемке улучшений продукта; ♦ фиксация бюджета под итерации и поток ценности.

3.4. Ключевые компоненты Agile Еще ни один крупный проект не закончился вовремя, в рамках бюджета и с той же командой, которая его начинала. Джон Эдвардс, Джим Батлер, Барри Хилл, Сандра Расселл

Напомню еще раз, что такое Agile. Это система идей и принципов гибкого управления проектами, ключевой принцип которого – разработка через короткие итерации (циклы), в конце каждого из которых заказчик (пользователь) получает рабочую версию продукта. Компонентами Agile является следующее. ♦ Визуализация коммуникаций, планирования и контроля, скрам- или канбандоски, военные комнаты (Обея), инфопанели с электронными данными и многое другое. Канбан-доска В одном проекте команда расположила на стене карточки различных цветов и видов, которые обозначали элементы конечного продукта. Спланированные, разработанные, протестированные и уже выпущенные элементы были одного цвета, а спланированные, разработанные, протестированные, но еще не выпущенные (однако уже готовые к выпуску) – другого. Команда смогла с легкостью изучить положение дел для каждого набора элементов. ♦ Высокопроизводительные команды, работающие вместе или рядом, желательно в одной комнате или используя «аквариумное окно» (видеопоток от части команды, работающей удаленно). Это значительно улучшает коммуникации, позволяет изучать лучшие практики и получать конкретные знания, формирует возможность локальной замены или помощи. ♦ Применение гибкого планирования. Например, модель М. Кона, «луковица планирования» (The Planning Onion, 2005), которая последовательно описывает слои, или уровни, планирования: стратегия, портфель, продукт, релиз (выпуск), итерация, день. Команда Agile в основном связана с тремя самыми внутренними слоями: релизом, итерацией и дневным горизонтом. При

первоначальном планировании релиза основное внимание уделяется объему, срокам и ресурсам, и этот план постепенно обновляется. Компоненты планирования релиза иногда называются историями или темами. Планирование итераций проводится в начале новой итерации. Их можно назвать задачами. Самый низкий уровень – ежедневное планирование с помощью летучек, на которых координируется работа и синхронизируются ежедневные усилия. Более высокие три уровня – стратегия, портфель, продукт – обычно не касаются Agile-команд, хотя при планировании продукта его владелец смотрит дальше, чем только на отдельный релиз. Для планирования всего продукта и/или даже комплекса продуктов также используется термин «дорожная карта». ♦ Применение командных оценок. Поскольку вся команда будет выполнять работу, все члены команды будут давать оценки. Рабочие элементы часто называются пользовательскими историями, а оценки, применяемые для выражения общего размера истории пользователя, часто называются относительными «стори пойнтами» (story points) или пунктами. История пользователя размером два «стори пойнта» должна быть в два раза больше истории размером один «стори пойнт». Нет какой-то формулы для определения размеров истории; оценка – это смесь усилий, сложности и риска и т. д. ♦ Разработка, учитывающая будущее тестирование. В случаях, когда заказчику сложно определить свои требования, команда работает над тестами, которые четче обозначают проработанность требований или продукта. Это обусловливает необходимость шагов между определением потребностей, планированием, разработкой и тестированием и может быть использовано в предиктивных циклах, что сделает требования полными, точными и тестируемыми. ♦ Адаптация управления. Команда постоянно адаптируется под возникающие условия на протяжении всего проекта, при этом руководитель проекта – лидер и помощник, а не лицо, отдающее поручения. Его задача – установить и поддерживать командные рабочие отношения, определяя основные правила и направления сотрудничества. Участники команды улучшают управление за счет полученных на предыдущей итерации знаний. Суть Agile «Agile базируется на трех вещах: 1) принципы, не методики; 2) внимание к людям и 3) всегда приспосабливайся»[5]. Майк Кон (2005): «Рассматривайте проект как быстро и надежно генерирующий поток полезных новых возможностей и новых знаний. Новые возможности поставляются в продукте; новые знания используются, чтобы сделать продукт лучше, чем он может быть». ♦ Совместная работа и сотрудничество всей команды для получения хороших результатов, объективных мнений и реализации всех полученных знаний на следующей итерации. Одновременно постоянство объективных мнений и улучшений. Тесное сотрудничество с клиентом. ♦ Реализация проекта, основанная на инкрементах разрабатываемого продукта и их приоритетах, что значительно снижает сложность проекта и позволяет команде сфокусироваться на каждом инкременте в отдельности. Об

интеграции всех элементов беспокоится руководитель проекта, который обеспечивает, чтобы следующий инкремент в списке имел наивысший приоритет, основываясь на его ценности в бизнесе и уровне риска. ♦ Руководство и сотрудничество в противовес административным указам и жесткому контролю. Agile тесно связан с лидерством. Руководитель проекта работает с клиентами, специалистами и участниками проекта, чтобы обеспечить их осведомленность о статусе проекта и исключить все барьеры в нем. ♦ Фокус на бизнесе. Оценка приоритетов на основе значимости в бизнесе позволяет не допустить чрезмерного углубления команды только в разработку нового продукта. Если это произойдет, то проект может превысить запланированные затраты и стоить больше своей ценности. ♦ Усвоение полученных уроков. После каждой итерации команда оценивает все полученные навыки и знания для того, чтобы улучшить процесс на следующей итерации. Обучаясь, участники адаптируются к деятельности других коллег и работают вместе над улучшением производительности команды.

3.5. Связь Lean, Agile и других практик Наши технические команды учатся Agile. Наши продуктовые команды учатся Lean, а наши команды дизайнеров учатся дизайн-мышлению. Кто из них прав? Джефф Готхельф. Lean vs Agile vs Design Thinking

Самой общей надстройкой семейства гибких практик является Lean, или бережливость. Основной смысл Lean – максимизация ценности для заказчика при минимизации любых потерь (время, ошибки, замечания, лишнее производство и т. д.). Требования стандартов серии ISO 9001 уточняют: «Все, что не добавляет ценности для потребителя, с точки зрения Lean-производства классифицируется как потери и должно быть устранено». Здесь существует много инструментов и подсистем, как, например, производственная система Lean (системный подход к выявлению и устранению потерь путем непрерывного совершенствования, настройка производственных процессов в зависимости от потребности заказчика и стремление к безупречности во всем – определение Национального института стандартов и технологий (NIST)). Lean может быть отраслевым – Lean-логистика, Lean-здравоохранение, Lean-офис, Lean-строительство и т. п. В этом смысле Agile как мышление и семейство гибких практик напрямую связан с концепциями бережливого подхода или мышления и входит в состав Lean. Суть Agile как итеративного или инкрементного подхода (разработка итерациями, результаты поставляются инкрементами, команды самоорганизованы, фокус на ценности и сотрудничестве) полностью отвечает целям минимизации затрат и увеличения ценности.

Канбан, с одной стороны, является инструментом Lean как система карточек Канбан для синхронизации передачи продукта с одной производственной стадии на другую, с другой – одной из разновидностей Agile-практик, визуализацией текущего потока работ с контролем ограничений на канбандосках. Он появился в середине 2000-х гг. в качестве альтернативы преобладающим в то время Agile-практикам и является менее директивным в сравнении с некоторыми практиками Agile и менее «дезорганизующим», поскольку это подход, основанный на принципе «начинай прямо там, где находишься». Более подробно Канбан будет описан в разделе 5.1. Скрам, о котором пойдет речь дальше, выступает одной из практик Agile (более подходящий термин – фреймворк, но он не очень привычен для читателей из не ИТ-сферы). В целом все вышеперечисленное весьма схоже и сосредоточено на поставке ценности, уважении к людям, сокращении потерь, обеспечении прозрачности, адаптации к изменениям и непрерывном совершенствовании. В некоторых случаях команда проекта может счесть полезным объединить различные методы: все то, что может принести пользу организации или команде, следует сделать, независимо от его природы.

Спринт 4 Скрам Введение Никто не может в одиночку сыграть симфонию. Для этого нужен целый оркестр. Х. Э. Лаккок, профессор теологии

Спринт 4 будет связан с самым популярным гибким фреймворком, про который знают почти все. Он и очень известный, и, на первый взгляд, несложный. Кажется, что повторить Скрам легко, но вот добиться постоянного и эффективного применения гораздо сложнее. В ходе спринта вы сможете пока просто обновить свои знания о нем. Откуда появился Скрам Скрам – самый известный и структурированный Agile-фреймворк. Что-то похожее на него в 1986 г. впервые описали Хиротака Такуэти (см. раздел 1.1) и профессор Икуджиро Нонака. Название «Скрам» (сокращенное от scrummage – «схватка») появилось от названия схватки в регби (способа возобновления игры, вовлекающего игроков в тесную группу с опущенными головами для овладения мячом). Официально Скрам получил свое название на конференции OOPSLA 95. Идеи доразвили Джефф Сазерленд и Кен Швабер в начале 1990-х гг. Джеффу принадлежит изначальная идея. Кен описал, формализовал и развил эту идею в то, что мы сегодня понимаем под словом «Скрам». Самым первым в мире скрам-мастером был Джефф Маккенна. Классика и адаптация

Классический (иногда применяют термин «ванильный») Скрам использует для разработки единую команду. В случае нескольких команд применяют масштабирование Скрама (об этом пойдет речь позже, в разделе 5.5). Апологеты, или евангелисты, Скрама строго запрещают нарушать утвержденные правила, роли, ритуалы, артефакты. Они считают, что Скрам существует только в своей целостности и при использовании отдельных его компонентов измененный фреймворк уже не является Скрамом. На практике же многое подвергается необходимой настройке и адаптации, что связано и с отраслью применения, и с типами проектов, и с корпоративной культурой, и с учетом ограничений: ♦ стали активно использоваться «аквариумные окна» (когда идет видеотрансляция работы одной части команды на стену в комнате, где работает другая часть), позволяющие разделять команду на части, что категорически запрещается авторами Скрама; ♦ используются летучки по телефону; ♦ в конце спринта демонстрация комбинируется с ретроспективой; ♦ ретроспектива переносится на начало следующего спринта и комбинируется с его планированием; ♦ команда работает по Скраму в течение фиксированной части дня, а не полного дня, и т. д. Особенно большая возможность для подобных настроек или изменений лежит за пределами ИТ-отрасли (этому и посвящена данная книга). Удобным термином для такого избирательного применения компонентов Скрама может быть «скрамность». Ниже (находясь пока, впрочем, в рамках классического Скрама) поговорим о следующем: что такое скрам-команда и как организовать ее работу? каковы ритуалы Скрама, формиру емые артефакты, правила, особенности планирования и работы в рамках спринта (итерации)? и т. п.

4.1. Классический Скрам Скрам – это другое. На работе все по-другому. Руководство чувствует себя подругому. В Скраме работа становится простой, актуальной и продуктивной. К. Швабер, М. Бидл. Agile Software Development With Scrum

При Скраме разработка делится на временные итерации – спринты, по окончании каждого из которых заказчик получает изменение или улучшение в продукте или создаваемом решении (MVP). Спринты строго фиксированы по длительности, выбранной командой вначале, исходя из особенностей проекта, командного решения и собственной производительности. Классический («ванильный») Скрам включает три роли (команду разработчиков, владельца продукта и скрам-мастера), артефакты (журнал требований продукта, журнал требований спринта, инкремент или версию

продукта) и ритуалы-процессы (планирование спринта, причесывание, обзор спринта, ретроспективу, летучку и собственно сам спринт). Также используются скрам-доска для визуализации потока задач в спринте и диаграммы сгорания и сжигания, показывающие сделанные или оставшиеся объемы задач. Правила в спринте: ♦ командой самостоятельно определяются и фиксируются конкретные объемы работ на спринт; ♦ каждый день проводятся 15-минутные утренние летучки для корректировки работы и подведения промежуточных итогов; ♦ в последний день спринта заказчику демонстрируются полученные результаты, узнается его мнение, уточняется весь список требований и их приоритеты для планирования нового спринта; ♦ по завершении спринта проводится ретроспектива, обсуждаются удачные и неудачные условия работы команды и делаются возможные корректировки; ♦ после всего запускается новая итерация и т. д. до финальной готовности. Циклы В большинстве случаев в Скраме применяют инкрементные или итеративные жизненные циклы. Скрам полезен: ♦ для проектов с «быстрыми победами» в сочетании с высокой толерантностью к изменениям; ♦ для ситуаций, когда не все члены команды имеют достаточный опыт в сфере проекта; тогда постоянные коммуникации в команде позволяют компенсировать недостаток опыта или квалификации одних сотрудников за счет информации и помощи от коллег. Ценности Скрама ♦ Приверженность: имея большой контроль над судьбой проекта, команда более привержена проекту и мотивирована на успех. Онлайн-телеканал Netflix Сайт ресурса обновляется каждые две недели благодаря Скраму, который не просто позволяет работать с высокой скоростью, но и аккумулирует пользовательский опыт и дает возможность выявить самое главное для клиентов. В ходе спринта разработчики добавляют и тестируют новые функции сайта и убирают те, которыми не пользовались клиенты. По словам команды Netflix, основное преимущество Скрама в том, что он позволяет «быстро и недорого ошибаться». Вместо того чтобы долго и с большими затратами готовить крупный релиз, поставки раз в две недели по Скраму имеют небольшой размер. Их легко отслеживать и, если что-то идет не так, быстро исправлять.

♦ Фокус: фокусирование одновременно только на немногих вещах – на хорошем сотрудничестве и производстве превосходной работы. Ценность продукта доставляется заказчику раньше. ♦ Открытость: когда люди работают вместе, они делятся методами своей работы и теми препятствиями, что у них на пути. Формируется понимание, что можно было бы быстро устранить. ♦ Уважение: разделяя неудачи и успехи, работая вместе, люди начинают уважать друг друга и помогать друг другу. ♦ Смелость: поскольку люди неодиноки, они чувствуют поддержку и имеют в своем распоряжении больше ресурсов. Это придает смелости для решения более сложных задач[6]. Ограничения Скрама ♦ Расстроенные и демотивированные исполнители, чьи результаты и функции были признаны по итогам спринта ненужными или некачественными. ♦ Командам, привыкшим к длительным предиктивным рабочим циклам, будет сложно перестроиться на работу по Скраму. ♦ Существует опасность увлечься встречами и артефактами Скрама в ущерб реальной работе над проектом. Netflix (см. врезку на с. 72) испытал эти слабые стороны Скрама в полной мере.

4.2. Роли Абсолютная уверенность игроков друг в друге, полная согласованность действий и целей – вот что представляет собой величие. Джефф Сазерленд. Скрам. Революционный метод управления проектами

Трудно с тремя, а потом число не имеет значения. Из кинофильма «Москва слезам не верит»

Скрам-команда Скрам-команда в наиболее распространенном понимании – это владелец продукта, команда исполнителей-разработчиков и скрам-мастер. Такая команда принимает, разделяет все принципы Скрама и выражает готовность с ними работать. Владелец продукта (Product Owner) В «водопадных» подходах руководитель проекта сочетает предметные профессиональные знания (правда, чем комплекснее проект, тем меньше это

требуется) и управленческие «софтовые» навыки, что часто затруднено. В Скраме есть руководитель-предметник (владелец продукта) и руководительадминистратор (скрам-мастер). Речь о последнем пойдет немного ниже. Владелец продукта – технический и бизнес-лидер разработки, задача которого – работать с заказчиком и командой, совместно с заказчиком наполнять журнал требований продукта (product backlog) и постоянно и жестко выделять в нем приоритеты, представлять заказчику промежуточные результаты, обладающие для последнего ценностью и возможностью использования. Команда вместе с владельцем продукта по журналу требований выбирает самые важные на текущий спринт задачи, делает план спринта, формируя журнал требований спринта. Владелец продукта: ♦ по сути, управляет созданием продукта; ♦ является единственным владельцем (возможны варианты, когда их, например, два, но кто-то все равно главный); ♦ выступает представителем заказчика в проекте или в отсутствие конкретного заказчика олицетворяет всех потребителей – пользователей продукта; ♦ может нести финансовую ответственность за продукт; ♦ отвечает за максимизацию ценности создаваемого продукта для заказчика и для бизнеса (business value); ♦ должен досконально знать потребности и образ мышления заказчика, потребителей/пользователей, а также разбираться в продукте и технологии его изготовления; ♦ представляет и описывает обобщенное видение конечного продукта; ♦ совместно с заказчиком (если у него есть полномочия) или без него принимает промежуточные результаты спринтов; ♦ отвечает за максимальную ценность продукта и работы, исполняемые командой разработчиков; ♦ единолично управляет журналом требований продукта, включая создание и упорядочение его элементов; приоритизацию и часто создание элементов журнала; выработку прозрачности и понимания элементов журнала у команды; ♦ связывает и осуществляет взаимодействие между командой разработчиков и скрам-мастером, с одной стороны, и пользователями и другими заинтересованными сторонами – с другой; ♦ отвечает за бизнес-риски, коммуникацию с заинтересованными сторонами проекта, стоимость и границы проекта; ♦ работает не в команде разработчиков, но с этой командой; ♦ может работать с несколькими командами при условии определения приоритетов между их проектами. Скрам-мастер (Scrum master) Член команды или свободный участник, играющий роль руководителя – администратора команды разработчиков и обеспечивающий ее работу в

течение спринтов. За пределами ИТ-отрасли легко приживается вариант «администратор». Скрам-мастер: ♦ следит, чтобы никто не мешал команде разработчиков самостоятельно и комфортно работать над задачами; ♦ отвечает за процессы, координацию и улучшение работы команды разработчиков и поддержку социальной атмосферы в ней; ♦ сфокусирован на команде, преодолении разногласий, фактически выполняя для нее роль «обслуживающего лидера»; ♦ помогает участникам лучше понять и принять ценности, принципы и нормы практики Скрама, соблюдать практики и правила; ♦ обучает команду способам преодоления препятствий; ♦ помогает команде проводить планирование и запуск спринта в части выполнения правил Скрама; ♦ проводит утренние летучки, на которых анализируется предыдущий день, описывается текущий и снимаются вопросы, так называемые блокеры, следит за качеством этих летучек; ♦ во время спринта следит, чтобы команду ничего не отвлекало, помогает ей пользоваться коллективным разумом, в конце организует демонстрацию результатов спринта и проводит ретроспективу при участии команды; ♦ помогает участникам, не входящим в состав команды, понять, какие из их взаимодействий с командой являются полезными, а какие – нет, содействует изменению таких взаимодействий для увеличения ценности продукта, создаваемого командой; ♦ помогает знаниями о новых практиках, учит команду Скраму, самоуправлению и кросс-функциональности; ♦ устраняет помехи, которые возникают в процессе работы команды; ♦ выступает инициатором изменений, усиливающих продуктивность команды; сотрудничает с другими скрам-мастерами для более эффективного использования Скрама; ♦ не возглавляет команду и не руководит ею, скорее «склеивает» ее; ♦ выполняет свою работу так, чтобы команда имела возможность делать то, что она делает лучше всего; ♦ как правило, работает одновременно не более чем с 1–2 командами для избежания большого числа переключений между проектами и конфликта приоритетов. Команда исполнителей (разработчиков) Для создания решения или продукта проекта формируется и наделяется полномочиями небольшая автономная команда разработчиков – специалистов по всем необходимым направлениям работы. За счет полного вовлечения членов команды достигается высокая производительность ее работы. Оптимальный размер команды – от трех до девяти человек, иногда для обозначения конкретных участников используют табличку 3 х 3.

Это кросс-функциональная самоорганизующаяся, самоуправляемая, не зависящая ни от кого извне (с некоторыми исключениями) команда специалистов, которая: ♦ быстро создает вариант решения или продукта (MVP) для получения обратной связи от заказчика; ♦ отвечает за то, чтобы в конце спринта все запланированные задачи были сделаны, а представления заказчику MVP выполнены; ♦ целиком несет ответственность за качество продукта, коммуникации в проекте и технические риски своей работы; ♦ не имеет никаких других должностей в команде, кроме роли члена команды или исполнителя, невзирая на вид выполняемой работы; ♦ может включать объявленные роли, но в целом является самоорганизующейся системой из кросс-функциональных мотивированных профессионалов; ♦ сама (никто не может указывать команде) превращает элементы журнала требований продукта в инкременты или итерации работающей функциональности в задачи спринта; ♦ все рабочее время полностью посвящает работе, располагается в одном месте или использует «аквариумные окна» (видеоэкраны со звуком); ♦ включает членов с «Т-образной квалификацией», когда в дополнение к экспертному знанию в одной области сформированы владение вспомогательными, хоть и менее развитыми, навыками в смежных областях и хорошие навыки совместной работы. (Противоположностью «T-людям» являются характерные для «водопадных» циклов специалисты с «I-образной квалификацией», которые имеют глубокую специализацию в какой-то одной области и редко вносят вклад в работу в других областях.) Говоря о мотивации команды, важно отметить, что система мотивации в первую очередь направлена на достижение общих целей. Этому должна способствовать корпоративная культура, поддерживающая командную работу, командные KPI. Как говорят практики, условия должны быть такими, чтобы члены команды «не думали о деньгах». Желательно, чтобы члены команды имели высокий EQ. Скрам-команды Члены команды чувствуют себя полностью вовлеченными в проект, когда участвуют в распределении задач во время планирования спринта, а не в ходе выполнения задания. Если сотрудники действительно испытывают чувство ответственности, то в начале спринта нет необходимости распределять задания между ними. В эффективных скрам-командах персонал сам распределяет задачи на основании имеющихся навыков и опыта. Это один из ключей к пониманию того, как работают самоорганизующиеся команды. (Из книги Эндрю Стеллмана и Дженнифер Грин «Постигая Agile» (см. список литературы)). Скрам/Agile-наставник или консультант:

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

4.3. Артефакты Не концентрируйтесь на том, чтобы осуществить весь список задач – все подряд, нужное и ненужное, – лучше уделите максимум внимания самому ценному, что действительно нужно людям. Джефф Сазерленд. Scrum. Революционный метод управления проектами

Журнал требований продукта Журнал требований продукта (Product Backlog, бэклог продукта) – это упорядоченный по приоритетам (важности, срочности) список пользовательских историй (требований), которые получены от заказчика и потребителей и должны принести конкретную бизнес-ценность создаваемому продукту. Этот список является единственным источником требований для любых изменений, которые могут потребоваться в продукте. Ответственность за журнал требований продукта несет его владелец, включая содержание продукта, доступность, редактирование и упорядочение. Как правило, этот список оформляется в виде таблицы (в MS Excel или иных форматах) или с использованием ПО, например JIRA и т. п. Истории пользователей или требования в этом документе обычно описаны на понятном для заказчика или пользователей языке, в соответствии с концепцией или целью всего проекта, пронумерованы и оценены в объемах работы в условных единицах (стори пойнтах или иногда в часах, с применением экспертных оценок, числа Фибоначчи или покерных карт, введенных Джеймсом Греннингом в 2002 г.). Комментарий к оценке с помощью покерных карт (один из вариантов) Каждый член команды имеет колоду карт с диапазоном чисел: 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Модератор совещания по планированию спринта читает описание каждого оцениваемого рабочего элемента, а владелец продукта отвечает на вопросы, которые могут возникнуть. После ответов каждый оценщик выбирает карту с числом. Все одновременно показывают свои

карты. Если отдельные оценки существенно различаются, тогда участники объясняют оценки с самыми низкими и самыми высокими показателями и может быть проведено дополнительное обсуждение содержания рабочего элемента. После обсуждения все оценщики делают переоценку и процесс повторяется. Наиболее важные требования обрабатываются в первую очередь. Чем выше приоритет требования и чем сильнее необходимость в его разработке, тем больше согласованности должно быть по поводу этого требования и его значимости. Используется метод набегающей волны, когда требования с высоким уровнем приоритетности, которые будут достигаться в ближайшее время, детализируются подробно, а более поздние и менее приоритетные – укрупненно. Журнал требований продукта никогда не может быть полным. При старте проекта он содержит только первоначально известные и наиболее понятные требования, а затем постоянно обновляется по мере появления идей заказчика, обновления самого продукта и среды, в которой он разрабатывается. Журнал требований продукта существует одновременно с разработкой продукта. Требования журнала, над которыми команда будет работать во время наступающего спринта, детализированы и разбиты на части так, что любое из этих требований может быть выполнено и «готово» в рамках данного спринта. Время, потраченное на работу над требованиями журнала в Скраме, специально не выделяется. Они вносятся командой в план следующего спринта во время процесса его планирования. Команда несет всю ответственность за оценку объемов работы на следующий спринт. Владелец продукта может помочь команде осмыслить требования и выбрать альтернативы, но конечная оценка зависит только от команды. Если над одним продуктом работают несколько команд, все равно используется только один общий журнал требований продукта, чтобы определить работу на ближайший период. Журнал требований спринта Журнал требований спринта – это набор элементов из журнала требований продукта, выбранных для выполнения в планируемом спринте, и одновременно план действий по разработке инкремента или итерации продукта в рамках цели спринта. Журнал требований спринта визуализирует работу, которую команда считает необходимой для достижения цели спринта, и достаточно детализирован, чтобы прогресс в его реализации можно было бы видеть ежедневно на утренних летучках и чтобы команда могла вносить изменения в него на протяжении всего спринта. В процессе команда узнает новые детали о работе, которую нужно выполнить для достижения цели спринта, и, соответственно, журнал требований спринта постоянно изменяется. Если работы выполнены или возникают дополнительные либо ненужные объемы работ, команда добавляет или убирает их в журнале. Только команда может изменять свой журнал требований спринта во время спринта. Аспекты создания хорошего журнала требований продукта Журнал требований продукта должен:

✓ быть соответствующе детализирован. Истории пользователей вверху журнала должны быть достаточно хорошо прописаны, чтобы их можно было закончить в ближайшем спринте. Истории, задачи которых не будут выполняться в ближайшие пару спринтов, не нуждаются в большом количестве деталей; ✓ иметь оценку. Журнал – это больше, чем список пожеланий; это еще и инструмент планирования. Учитывая, что чем ниже элемент, тем менее он пока продуман, оценки могут быть менее точными, чем у элементов сверху; ✓ быть изменяющимся. Журнал не статичен, а изменяется с течением времени. По мере того как мы больше узнаем о продукте, истории в журнал добавляются, удаляются или изменяются их приоритеты; ✓ быть приоритизирован. Журнал должен быть отсортирован так, чтобы наверху находились наиболее ценные элементы, а менее ценные были внизу. Всегда работая в соответствии с приоритетами, команда может максимизировать ценность системы или продукта, который разрабатывает. (Из книги Майка Кона «Scrum. Гибкая разработка ПО») Диаграммы сгорания и сжигания Для оценки прогресса работ внутри спринта и в проекте в целом используются графики типа «сколько осталось» (burndown) и «сколько сделано» (burnup), которые называются «диаграммой сгорания» и «диаграммой сжигания» соответственно. По горизонтальной оси откладывается число дней спринта, по вертикали – объем работы в условных единицах. В любое время можно увидеть количество работы, которую осталось проделать для достижения цели проекта или которая сделана. Скрам-мастер отслеживает эти графики как минимум на каждой летучке, сравнивая текущее количество работы с плановым, чтобы оценить прогресс в работе и успевает ли команда достичь цели спринта в рамках запланированного времени. Эта информация должна быть доступной и открытой для всех членов команды. Используются и укрупненные по всему циклу спринтов диаграммы, когда по горизонтальной оси откладывается число запланированных спринтов, а по вертикальной отслеживается весь объем работ проекта. Это крайне важная информация для понимания владельцем продукта, успевает ли команда достичь цели проекта в рамках запланированного числа спринтов. Скрам-доска Для визуализации процесса исполняемых задач используется скрам-доска (рис. 4.1). Это либо реальная доска с вертикальными столбцами и со стикерами-карточками, на которых компактно помещается вся нужная информация по задачам (кто выполняет задачу, когда завершит, сколько времени затратит), или виртуальная, в случае если команда работает удаленно (например, с применением программных решений Trello или JIRA). В самом простом виде названия столбцов могут быть: «Журнал требований», «Нужно сделать» (To do), «В процессе» (In process), «На рассмотрении/оценке качества» (In review/Quality assurance) и «Сделано» (Done). По вертикали размещаются истории пользователей (user story). При условии работы команды в одной комнате физические доски лучше, они позволяют

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

Рис. 4.1. Пример скрам-доски 1

Можно разбить процессы работы на спринте на составные части, тогда скрамдоска может выглядеть так (рис. 4.2).

Рис. 4.2. Пример скрам-доски 2

В процессе утренней летучки команда, рассказывая о проделанной и предстоящей работе, переклеивает стикеры-задачи из одного столбца в другой, тем самым визуализируя те моменты, которые могут затруднять ее работу. На основании такого наглядного анализа могут вырисовываться срочные задачи, которые тормозят проект в целом. Такие задачи выносятся в отдельную графу на доске визуализации (см. рис. 4.2). В процессе работы с доской становится понятно, успевает спринт быть выполненным в заданные сроки или нужно что-то делать, чтобы успеть. Может, придется заранее предупредить заказчика о предстоящей корректировке сроков, а не сообщать об этом в последний момент.

4.4. Ритуалы Средних менеджеров волнует, делалось ли так раньше и что подумают люди? Для хороших важно, чтобы проблема была решена. Неизвестный источник

Спринт Спринт – это временная итерация (time-box) размером от одной недели до нескольких, в результате которой создается ценный и потенциально готовый к выпуску (MVP) инкремент или итерация продукта. Временные рамки спринта не должны быть слишком длинными, поскольку могут меняться цели, возникнуть новые условия, которые приведут к риску лишней работы. Регулярные спринты вносят прогнозируемость, ритмичность в процесс разработки, обеспечивая проверку и адаптацию на пути к общей цели. В классическом Скраме срок спринта является постоянным на протяжении всего периода проекта. Спринты идут последовательно, один начинается сразу же после окончания предыдущего. Спринт состоит из процесса его планирования, ежедневных

летучек, «причесывания» журнала требований, самой деятельности по разработке, итоговой встречи по обзору спринта и его ретроспективы. Во время спринта не допускается внесение никаких изменений, которые бы повлияли на цель спринта; состав команды и цели остаются неизменными. Если в силу каких-то важных причин появляются новые требования, их рассмотрение и внесение в объем работ желательно перенести на конец текущего спринта. При форс-мажорных обстоятельствах под влиянием заинтересованных лиц, команды или же скрам-мастера только владелец продукта может остановить спринт до окончания его временных рамок. Спринт также отменяют и в том случае, если его цели перестают быть актуальными. Это может произойти вследствие смены направления работы компании, изменения технологий или рыночных условий либо когда в силу некоторых обстоятельств в нем уже нет необходимости. При отмене спринта все выполненные и «готовые» элементы из журнала требований продукта пересматриваются. Их принимают при условии, что они представляют потенциально готовый к выпуску инкремент функциональности. Все остальные требования переоцениваются и возвращаются в журнал требований продукта. Члены команды должны перегруппироваться при планировании нового спринта и приступить к нему. Встреча по упорядочению журнала требований продукта (Backlog Refinement Meeting, Backlog Grooming) Эта встреча, которую еще называют «причесыванием» журнала требований, похожа на планирование в «водопадном» управлении и проводится в любой день каждого спринта. На ней рассматривается, что уже выполнено по проекту в целом, что еще осталось выполнить, и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на текущем этапе являются наиболее приоритетными. Данный процесс формирует эффективность спринта, и от него зависит, какую ценность получит заказчик по итогам спринта. Процесс планирования спринта и встреча по его планированию Встреча по планированию спринта проводится в самом его начале, после встречи по «причесыванию» или одновременно. Условием ее качественного проведения является определение владельцем продукта приоритетов на следующий спринт. Тогда команда совместно решает, какой план действий и что же конкретно они будут делать во время этого спринта, как достигнуть его цели. Планирование занимает обычно несколько часов и состоит из двух одинаковых по длительности частей. При планировании спринта команда отвечает на следу ющие вопросы: 1) что будет сделано в этом спринте, что будет разработано в инкременте продукта по результатам работы в следующем спринте и 2) как максимально эффективно выполнить работу по созданию этого инкремента, как будет проделана выбранная работа? При ответе на первый вопрос команда планирует функциональность, которая будет разработана во время спринта. Владелец продукта представляет команде упорядоченный журнал требований продукта, и вся команда старается достичь единого понимания работы в спринте. Используются сам журнал

требований продукта, последний разработанный инкремент продукта, возможности команды исполнителей, а также последние показатели ее производительности. Число элементов из журнала требований продукта, которые команда способна выполнить до окончания спринта, определяется только самой командой – она одна может реально оценить объем работы, который она в состоянии завершить до окончания спринта. После прогнозирования элементов журнала требований продукта, которые она выполнит в данном спринте, команда приступает к формированию цели спринта, которая будет достигнута в его конце. Отвечая на второй вопрос, команда решает, каким образом воплотить отдельную функциональность в готовый инкремент продукта, формируя журнал требований спринта. Команда планирует именно такой объем работы, который она в состоянии выполнить за спринт. Запланированная работа разбивается на требования, которые можно выполнить за день или менее. Команда сама организует свою работу, планируя поэтапность выполнения требований из журнала требований спринта. Владелец продукта может присутствовать на второй части планирования спринта, чтобы иметь возможность объяснить задания из журнала требований продукта и при необходимости помочь найти альтернативы. Если же команда исполнителей по результатам планирования решает, что у нее слишком много либо слишком мало работы, она может повторно обсудить требования журнала требований спринта с владельцем продукта. Команда может пригласить экспертов. После встречи по планированию спринта команда должна быть в состоянии объяснить владельцу продукта и скрам-мастеру, каким образом она собирается работать в качестве самоуправляемой команды, чтобы достичь цели спринта и создать ожидаемый инкремент продукта. Самоуправляемость придает работе команды некоторую гибкость в отношении разработки функциональности во время спринта. Если же работа оказывается сложнее, чем ожидалось, тогда команда договаривается с владельцем продукта об изменении объема журнала требований спринта в текущем спринте. Цель спринта обязательно связана с целью всего проекта. Летучка Ежедневные летучки (стэндапы, Скрамы, daily scrum и т. д.) – это 15-минутные встречи команды с участием скрам-мастера с целью синхронизации действий на ближайший день. Они проводятся утром каждый день спринта, в идеале – в одно и то же время и в одном и том же месте и стоя. На самой встрече не происходит обсуждений проблем или принятия решений (за исключением очень быстрых решений), только обмен информацией и поддержание всей команды в курсе состояния спринта. Если после встречи возникают вопросы и конфликты, скрам-мастер обсуждает их отдельно с соответствующими заинтересованными сторонами. Для синхронизации деятельности команды и обозначения проблем иногда возможно приглашение владельца продукта. Краткий план встречи по планированию спринта С 09:00 до 12:30 (после каждого часа – перерыв 10 минут).

09:00–09:30. Владелец продукта разъясняет цель спринта, рассказывает про бизнес-процессы и требования из журнала требований продукта. Фиксируются время и место проведения демонстрации заказчику. 09:30–10:30. Команда проводит оценку времени, которое потребуется на разработку бизнес-процессов, и при необходимости дробит их на более мелкие. Иногда владелец продукта может изменить приоритет их исполнения. Выясняются все вопросы. Для наиболее важных заполняется поле «Как продемонстрировать сделанное заказчику». 10:30–11:30. Команда определяет набор, который войдет в спринт. Для оценки реальности обсуждается производительность команды. 11:30–12:30. Фиксируются время и место проведения ежедневной летучки. Отобранный набор историй разбивается на задачи, которые распределяются внутри спринта. Во время летучки каждый член команды отвечает по кругу на три вопроса: 1) «Что было сделано мною после предыдущей встречи?»; 2) «Что будет сделано мною к следующей встрече?»; 3) «Какие есть проблемы или вопросы, что мне мешает продвигаться вперед?». Участники команды рассказывают друг другу о проделанной и планируемой работе, повышая свою ответственность. Обсуждается только самое важное, то, что будет двигать процесс реализации проекта вперед. Летучки усиливают вероятность достижения командой цели спринта. Интересной особенностью данных встреч является то, что они проводятся стоя (и даже иногда лежа с вытянутыми руками). Этим снижается риск затянуть мероприятие. За активность и участие команды в летучках отвечает скрам-мастер, однако ответственность за содержательное проведение встречи лежит на команде. Поскольку скрам-мастер как ведущий встречи не наделен функцией руководителя, то он не имеет права раздавать задачи членам команды, а это значит, что они сами выбирают себе задачи к исполнению, отвечая на вопрос: «Что я планирую сделать?» Скрам-мастер обучает команду проведению такой встречи и контролирует ее срок. Иногда используется мячик или ручка и правило, что говорит тот, кто держит эти предметы. Летучки улучшают процесс общения внутри команды, сводя к минимуму другие совещания, помогают определять и устранять препятствия на пути к успешной работе, способствуют быстрому принятию решений, а также повышают знания по проекту команды. «Во время своих ежедневных встреч команды ограничивают горизонт планирования, чтобы быть не дальше, чем на следующий день, когда они встретятся снова. В связи с этим они сосредоточены на планировании задач и координации отдельных мероприятий, которые ведут к завершению задачи» (Кон, 2005). Демонстрация Цель демонстрации итогов работы команды заказчику – представить результаты деятельности в течение спринта всем заинтересованным лицам, включая заказчика, получить обратную связь и убедиться, что продукт спринта соответствует их ожиданиям и согласуется с целями проекта. Демонстрация

иногда называется встречей по обзору спринта, sprint review или демо. Обязательно участвует вся команда. Не проводится никаких формальных презентаций, которые требуют затрат времени и усилий. Все быстро, предметно, по существу, в течение 2–3 часов. Помимо проверки созданного MVP, демонстрация способствует адаптации журнала требований продукта. Демонстрация включает в себя следующие элементы: ♦ владелец продукта определяет, что готово, а что – нет; ♦ команда вспоминает, что прошло гладко во время спринта и с чем возникли трудности, а также то, как она с ними справилась; ♦ команда проводит демонстрацию того, что было сделано, и отвечает на вопросы по инкременту; ♦ владелец продукта обсуждает состояние журнала требований продукта и при необходимости делает предположения касательно возможной даты окончания проекта, принимая во внимание скорость продвижения работы над ним; ♦ вся скрам-команда обсуждает то, что делать в дальнейшем, для того чтобы данный обзор спринта предоставлял важную входную информацию для последующей встречи по планирования спринта. Результатом демонстрации является пересмотренный и исправленный («причесанный») журнал требований продукта, определяющий вероятные элементы журнала для следующего спринта. Журнал требований продукта может также быть пересмотрен, чтобы соответствовать новым обстоятельствам. Ретроспектива Ретроспектива – это встреча команды и скрам-мастера сразу после демонстрации и до планирования следующего спринта. На ретроспективу рекомендуется приглашать владельца продукта для получения дополнительной обратной связи. На ней команда выясняет, насколько четко и слаженно проходил процесс реализации спринта. Ретроспектива – это механизм постоянной адаптации с использованием цикла PDCA Деминга – Шухарта. Обследованию подвергаются возникшие про блемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде осуществить рефлексию и следующий спринт провести эффективнее. Ретроспектива дает команде возможность проверить себя и создать план улучшений, которые можно было бы внести во время следующего спринта. Скрам-мастер поощряет команду пересмотреть свои процессы разработки в рамках процессов и практик Скрама, чтобы сделать ее более эффективной в следующем спринте. Во время каждой ретроспективы команда ищет пути улучшения качества разрабатываемого продукта, при необходимости уточняя определение готовности. Ретроспектива спринта является специализированным совещанием, посвященным исключительно проверке и адаптации. Ретроспектива в действии Норм Керт, лидер ХР, рекомендует задавать следующие вопросы: что было сделано хорошо; что можно улучшить; чему мы научились; что поставило нас в тупик?

Длительность ретроспективы – от одного до трех часов. Критерии готовности Когда элемент журнала требований продукта или инкремент называют готовым, все должны понимать, что это означает. Разные команды и заказчики могут интерпретировать данный факт по-разному. Команда должна иметь общее единое определение того, что работа сделана. Без него Agile работать не будет. Это помогает команде в понимании того, сколько требований выбрать из журнала требований продукта во время планирования спринта, поскольку целью каждого спринта является разработка инкремента потенциально готовой к выпуску функциональности, отвечающей текущему определению готовности. Критерий готовности определяется владельцем продукта совместно с заказчиком и/или командой, помогает владельцу продукта принимать работу и избежать синдрома «готово на 90 %». Примерами таких критериев могут быть: «продукт установлен», «документация написана», «все найденные ошибки исправлены» и т. д. По окончании каждого спринта команда разработчиков представляет инкремент функциональности продукта или его версию. Они могут быть пригодными к эксплуатации, и поэтому заказчик может решить сразу же их выпустить в использование. Каждый последующий инкремент или версия будут дополнять все предыдущие инкременты.

Спринт 5 Другие Agile-фреймворки Введение Даже плохо реализованный Agile работает. Применение в небольшом количестве помогает. Мартин Роу, колледж Петрок, Корнуолл

В спринте 5 будут представлены некоторые другие популярные фреймворки семейства Agile. Они тоже очень интересны и часто применяются. Что лучше использовать, вы сможете определить по результатам этого спринта. Чаще начинают с Канбана.

5.1. Канбан Когда местность не совпадает с картой – ориентируйтесь по местности, а не по карте. Инструкция швейцарской армии

Канбан как инструмент контроля времени и пополнения ресурсов «точно в срок» (just in time) в бережливом производстве (lean) уже упоминался выше.

Термин «Канбан» (сначала был «камбан») в переводе с японского буквально означает «рекламный щит» или «карточка» и возник в супермаркетах, где пополнение продуктов на полках производилось по мере появления свободного места, а не в зависимости от запасов у поставщика (принцип «держи на полках только то, что нужно клиенту»). На примере такого решения по принципу «точно в срок» Тайити Оно разработал метод Канбан, который был применен в 1953 г. на главном производственном объекте компании Toyota. В Agile-подходах Канбан обрел популярность намного позже, чем Скрам, и стал востребован как в ИТ-области, так и за ее пределами (Андерсон, 2010). Стали широко использоваться информационные канбан-доски, похожие на скрамдоски и состоящие из колонок с состояниями процесса или цикла разработки, через которые должен пройти поток работы (рис. 5.1). Самые простые доски имеют три колонки («Нужно сделать», «В работе» и «Сделано»), но их можно адаптировать с указанием состояний, которые, по мнению применяющих их команд, необходимы. Для продвижения работы в рамках процесса используется принцип «вытягивающая система» (pull system) – по завершении командой отдельного элемента она может вытянуть другой элемент в данный шаг (столбец). Карточки задач (индивидуальные карточки со всей необходимой информацией о задачах), передвигаемые по колонкам, способствуют визуализации и потоку работы через систему так, чтобы поток был представлен наглядно для всех. Количество карточек в каждой колонке фиксируется для ограничения объемов незавершенных работ (WIP) и оптимизации потока. Новая задача не может быть перемещена из одного столбца в другой, пока в нем не будут завершены задачи. Именно это отличает канбан-доски от скрам-досок. Такое ограничение повышает производительность и качество работы команды, а также позволяет ей сосредоточить усилия на непосредственно выполняемой работе.

Рис. 5.1. Канбан-доска

Как и в случае со скрам-досками, можно применять физические или электронные доски (например, облачные решения Trello, позволяющие отображать доску у всех, даже удаленно работающих членов команды). Канбан использует десять базовых принципов (часть из них аналогична принципам Скрама, часть является собственной). 1. Максимальная прозрачность – визуализация потока задач, что позволяет видеть узкие места, очереди задач, отклонения и потери процесса и активно их устранять; равномерное распределение нагрузки среди участников проекта внутри итерации. 2. Работа должна вестись одновременно всей командой – это помогает сбалансировать усилия и получаемые результаты, исключает неравномерное распределение нагрузки. 3. Время на выполнение каждой задачи и всех задач строго контролируется, благодаря чему оптимизируется процесс и экономится время. 4. Точный расчет нагрузки на команду, правильная расстановка ограничений и концентрация на постоянном улучшении. 5. Среднее время выполнения одной задачи измеряется, и оптимизируется процесс для уменьшения этого времени. 6. Непрерывный поток: задачи из журнала требований продукта, полученные от владельца продукта, попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается. 7. Команды считают главным фокусом непрерывную поставку и организацию потока работы через систему до ее завершения и не начинают новую работу до завершения текущих работ. 8. Проверка каждого задания на предмет наличия добавляющих ценность операций и устранение операций, которые ценность не добавляют. 9. Вариативность рабочей нагрузки: когда существует непредсказуемость в порядке поступления работы и у команд больше нет возможности принимать прогнозируемые обязательства, даже на короткие периоды времени. 10. Мотивация людей на постоянное сотрудничество, совершенствование и обучение, сплоченная, замотивированная, опытная команда с хорошей коммуникацией и пересекаемыми навыками (участники с «Т-образной квалификацией», см. раздел 4.2). Agile на практике 1. Марни Андес является директором по обучению и развитию в авиатранспортной компании скорой помощи Air Methods, работает с персоналом, включающим около 6500 медицинских и других сотрудников. До ее прихода компания не понимала, как быстро создаются все необходимые тренинги или проекты. Андес со своей командой начали использовать журналы требований продукта и их приоритизацию на доске в Trello, где перечислялись запросы на обучение, создаваемые тренинги и многое другое. При появлении нового запроса ему присваивают зеленый (сигнал к выполнению) или красный код (попадает в очередь). Каждый месяц заинтересованные стороны собираются для расстановки приоритетов, «голосуя демократически за то, что необходимо передвинуть в топ очереди». По словам Андес, применение таких

журналов помогает «сотрудничать и работать с ожиданиями бизнеса относительно того, почему и как мы делаем то, что делаем». Она также говорит, что это создало синергию внутри группы. «Они видят, что делают другие группы, они не делают работу друг друга, так как всегда в курсе, что чтото уже создано… Все это повышает эффективность». 2. Традиционный издательский дом также применял Agile и итеративно разрабатывал печатные учебные продукты, используя обратную связь от клиентов для создания и улучшения продукта до и после выпуска. Каждую неделю разрабатывалось одно улучшение продукта, после чего оно сразу отправлялось группе альфа-тестеров, которые применяли его во взаимодействии с детьми (как реальными потребителями) и давали отзывы о том, что получилось, а что – нет. Отрабатывалась обратная связь, а затем новая версия отправлялась группе бета-тестеров, которые делали то же самое. Даже в такой консервативной отрасли, как печатное издательство, удалось передать первую версию продукта в руки реальных пользователей так быстро, как только возможно, чтобы сразу начать собирать отзывы о том, как ее можно еще улучшить. Это помогло выявить недостатки и исправить их до публикации. 3. Об опыте повышения эффективности рекрутинговой команды, использовавшей канбан-доску для упорядочения телефонного скрининга кандидатов (рис. 5.2), рассказал Уильям Каммерселл (бывший тренер Agile, а сейчас старший менеджер по продуктам в CA Technologies). Обычно рекрутинговый процесс движется довольно стандартно от начала до конца, но на деле всегда существуют изменения. Рекрутинговая команда должна быть гибкой и эффективной, а также поддерживать прозрачность внутри и с заинтересованными сторонами. Если это не так, команда увязнет в процессах, кандидаты исчезнут, заказчики потеряют терпение или стоимость найма значительно возрастет. Команда стала использовать публичную физическую канбан-доску, размещая и демонстрируя работу, которую они вели для своих членов и других заинтересованных сторон. Это помогло понять, кто из команды перегружен, кто чем занят, как кто работает и как они могут помочь друг другу[7].

Рис. 5.2. Канбан-доска рекрутинговой компании

В Канбане, в отличие от Скрама: ♦ команды, как правило, не связаны жесткими временными рамками и применяют итерации разной продолжительности; ♦ есть только роль владельца продукта (правда, не всегда); О члену команды можно вести несколько задач одновременно; ♦ никак не регламентированы встречи по статусу проекта, их можно проводить как удобно, где удобно или не делать вообще; ♦ каждое задание визуализируется – на какой оно стадии – и ограничивается НЗР («НеЗавершенной Работой») или WIP (Work-In-Progress); ♦ выше предсказуемость оперативного времени и большая надежность срока поставки; ♦ разрешается оставить неоконченную задачу (что-то ^отредактированное или недописанное) на одном из этапов, если ее приоритет изменился и есть другие срочные задачи. ScrumBan/Скрамбан Широко используется комбинация Скрама и Канбана, когда команды применяют Скрам в качестве рабочего фреймворка, а Канбан – в целях совершенствования процесса. При этом: 33 могут отсутствовать предварительно определенные роли – команда сохраняет свои текущие позиции; ✓ работа организована в небольших спринтах; ✓ истории (требования) помещаются на канбан-доску, и коман да организует свою работу с учетом ограничений на объемы текущей работы; ✓ для поддержания сотрудничества и устранения препятствий проводятся ежедневные летучки; ✓ определяется «триггер планирования», чтобы команда знала, когда снова заниматься планированием (например, когда уровень текущей работы опускается ниже предварительно установленного ограничения).

5.2. Lean Нельзя позволять функциональным группам растягивать проект ради улучшений, усовершенствований или более глубокого анализа ключевого риска. Сэмюэл Дж. Мантел, Джек Р. Мерединт

Часть Lean-идей компании Toyota, предполагающих внесение только полезных изменений, требующих минимума затрат и отнимающих не более трети запланированного времени, были применены для процессов разработки программного обеспечения Мэри и Томом Поппендик. Они создали Lean

Software Development как набор принципов бережливой разработки, который направлен на повышение ее эффективности и минимизацию затрат. Были предложены следующие принципы Lean Software Development: ♦ устранение того, что не приносит пользы, не прибавляет ценности продукту для конечного потребителя; ♦ упор на обучение: цикличность разработки, обратная связь с клиентом, непрерывное развитие команды увеличивают возможности эффективного выполнения задач; ♦ принятие решений на основе фактов, а не прогнозов. Приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний; ♦ целостность и качество во всем: от информирования заказчика до рефакторинга (см. врезку на с. 110–111). Нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от ошибок; ♦ усиление команды: проектная команда – основа успешного завершения задач; ♦ быстрая доставка конечному потребителю; ♦ полномасштабное видение: важно оценивать проект как целое, а не по частям. Разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и ее стратегии. Lean По данным исследования PMI®, 8 % компаний постоянно используют принципы Lean, а 26 % часто к ним обращаются. Джо Фоли, менеджер подразделения Intel Fab Operations в Лейкслипе, утверждает, что пять лет назад их компании требовалось 14 недель, чтобы начать производство новых чипов. Благодаря принципам Lean этот процесс теперь занимает десять дней. В своем исследовании компания ВВС обнаружила, что Lean повышает скорость разработки на 37 % и снижает количество ошибок на 24 %. Cогласно исследованию Lean Business Report, в числе десяти преимуществ подхода указано снижение стоимости проектов – 27 %. Достоинствами Lean считают быстрый релиз продукта и то, что команда не просто выполняет задачи, а стремится сделать продукт с наименьшим количеством ошибок. Однако Lean стоит применять, только если в проекте опытные участники (обучение во время проекта невозможно и ставит создание продукта под угрозу) и решения основаны на правильных данных и результатах мониторинга процессов (иначе может быть слишком большое количество изменений и есть риск забыть о главной цели проекта).

5.3. Экстремальное программирование (XP) Работа в команде очень важна. Она позволяет свалить вину на другого. Восьмое правило Фингейла

Ни один крупный проект не заканчивается вовремя, в рамках бюджета и с тем же составом команды, с каким начинался. Гаральд Керцнер

Кент Бек, Уорд Каннингем, Мартин Фаулер и другие авторы этого фреймворка применили полезные традиционные методы и практики разработки ПО на «экстремальном» уровне, создав экстремальное программирование (eXtreme Programming, ХР) как еще один вид семейства Agile. В состав XP-решений вошли: – в организационной области: совместное размещение команды; объединение ее; информативное визуальное рабочее пространство с досками, информационными панелями; привлечение реального заказчика, который должен быть на постоянной связи, доступен для любых вопросов и брать ответственность за принятие решений; преемственность в команде («T-люди»), устойчивый темп работы, ежедневные летучки; – в технической области: парное программирование (код создается парами программистов, работающих за одним компьютером, когда один кодирует, а другой в это же время непрерывно просматривает только что написанный код); программирование с первоначальным фокусом на тестах, проектирование по инкрементам, формирование общего кода и коллективное владение им, общая документация по коду и тестам, постоянный рефакторинг; Когда лучше вносить изменения Рефакторинг за пределами ИТ-отрасли сводится к безжалостной непрерывной переделке написанного или сделанного ранее в целях улучшения. Вдруг у вас изменилось настроение или восприятие или захотели новое и вам надоел висящий рисунок или книжная полочка, цвет рамки или висящая лампа? Или на кухне отвалилось немного кафеля? Можно подклеить, а можно и оставить на потом. Подклейка или смена рисунка, лампы займет час. И лучше сделать это немедленно. Если настроение станет постоянно меняться и все надоест, то изменения будут касаться многого. А небольшие перемены будут недорогими и не займут времени. К тому же сразу после изменения и настроение улучшится, и будет видно, что еще не нравится. А если затеять капитальный ремонт, который будет гораздо дольше и дороже текущего? Вплоть до его окончания в квартире жить будет невозможно, она будет разбита и неустроена. А вдруг после такого ремонта что-то опять не понравится, захочется картинку перевесить или лампу… В процессе текущего ремонта это было бы и быстрее, и дешевле, и комфортнее. – в области планирования: задействование пользовательских историй, недельный спринт, частые небольшие выпуски продукта в эксплуатацию (чем раньше выпускается первая достаточно осмысленная с точки зрения полезности для бизнеса рабочая версия продукта, тем раньше заказчик начинает получать прибыль).

Принципы экстремального программирования Важнейшие мысли от автора XP Кента Бека в книге «Экстремальное программирование. Разработка через тестирование» (см. список литературы): ✓ бо́льшая часть проблем и ошибок всегда связана с недостатком общения; ✓ останавливайся на самом простом решении, которое позволяет выполнить задачу; ✓ лучшие инструменты обратной связи – это непосредственное общение с заказчиком; ✓ смелость и кураж – мощнейший инструмент для осуществления больших изменений в системе; ✓ уважение членов команды друг к другу; ✓ чувство собственной полезности в работе; ✓ способность понимать других и быть понятым; ✓ ценность продукта на текущий момент и ценность будущих возможностей; ✓ деятельность должна быть выгодна участвующим людям и организациям; ✓ каждый день работать лучше и придумывать новые способы сделать работу еще более эффективной; ✓ лучше, когда в команде разные знания и разные характеры. Они спрашивают себя, как они работают и почему они делают данную систему именно так, а не иначе; ✓ в проблемах, которые неизбежны, надо видеть прежде всего возможность для улучшения; ✓ действительно сложные или критические проблемы надо решать несколькими способами одновременно; ✓ из неудач выносим ценные уроки; ✓ гораздо надежнее продвигаться вперед маленькими шажками. Некоторые принципы XP-разработок, которые легко применяются и за пределами ИТ: ♦ DTSTTCPW (Do the simplest thing that could possibly work) – «Делай самое простое, что могло бы работать». Чтобы показать заказчику в конце спринта промежуточный продукт, не надо сутками до этого готовить презентации, достаточно самых простых иллюстраций; ♦ KISS (Keep it simple, stupid) – «Сохранять вещи максимально простыми». Аниматор Ричард Уильямс писал, что неопытные аниматоры «чрезмерно одушевляют» роли в своих работах, показывая, что персонаж может двигаться и делать излишне много; ♦ YAGNI (You aren’t gonna need it) – «Тебе это не понадобится». В качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, в которой нет непосредственной надобности;

♦ DRY (Don’t repeat yourself) – «Не повторяйся». В книге The Pragmatic Programmer формулируется, что каждый элемент или часть системы должны иметь единственное непротиворечивое и авторитетное представление в рамках системы.

5.4. Разработка, управляемая функциональностью (FDD) Начало – половина любого дела. Греческая пословица

Разработка, управляемая функциональностью (feature driven development, FDD), как итеративная методология разработки была изначально предложена Джеффом Де Люкой для проекта, рассчитанного на 15 месяцев и 50 человек по разработке ПО для одного из банков в 1997 г. За основу берут важнейший для заказчика набор функциональности (свойств) разрабатываемого продукта. Организация проекта осуществляется на основе пяти действий, которые выполняются итеративно с частыми выпусками (раз в две недели): ♦ разработки общей модели; ♦ создания и ведения набора функциональности, важнейшего для заказчика; ♦ планирования по этим свойствам; ♦ проектирования по ним; ♦ создания продукта по этому же набору функциональности или свойств. Первые два действия осуществляются в начале проекта. Последние три повторяются для каждого разрабатываемого свойства. Разработчики в FDD делятся на «хозяев» классов функций и главных программистов. Последние привлекают «хозяев» классов к работе над очередным свойством. В связи с этим очень важна роль главного программиста, который является и руководителем разработки, и наставником, и аналитиком. Работа над проектом включает частые сборки и делится на итерации, каждая из которых предполагает реализацию. Регулярно организуется общение с заказчиком, ведутся учет изменяющихся требований к проекту и подробная документация. Feature driven development Согласно исследованиям, 11 % компаний постоянно используют feature driven development, а 31 % прибегают к этой методологии время от времени. Достоинствами FDD можно считать: ♦ первоначальное моделирование объекта и предметной области, границ, определение общего каркаса, который можно в дальнейшем дополнять функциями;

♦ разработку и разбиение по функциям, которые могут быть реализованы за пару недель, что облегчает создание корректно работающих функций, расширение и модификацию системы; ♦ индивидуальное владение классом функций в виде закрепления за конкретным владельцем-разработчиком; ♦ команду по разработке функций (свойств) как небольшую, динамически формируемую команду разработчиков, занимающуюся небольшой подзадачей; ♦ постоянное составление отчетов о проделанной работе на всех уровнях, что позволяет отслеживать прогресс и результаты, обновлять проект, выявлять ошибки и предоставлять заказчику информацию в любое время. FDD используется в масштабных проектах, поскольку на первом этапе ведется разработка общей модели, позволяющей разобраться в продукте. Глубокое понимание проектных требований и ожиданий заказчика снижает риск нежелательных «сюрпризов».

5.5. Масштабирование Скрама Не бойтесь сделать один большой шаг, если вы его определили. Нельзя преодолеть пропасть в два маленьких прыжка. Дэвид Ллойд Джорж, политик

Классическая Agile-команда обычно включает не более десяти участников. Практика показала, что это максимальное число людей, при котором возможно гибкое и эффективное взаимодействие. При дальнейшем увеличении команды резко возрастают издержки на коммуникации (количество возможных коммуникаций находится в квадратной зависимости от количества участников коммуникации). Если быть корректнее, число коммуникаций равно N(N – 1) / 2, где N – число участников. Как быть, если в проекте необходимо участие большего числа исполнителей? Что делать, если у двух и более команд в составе до десяти членов в каждой возникает необходимость в координации своей работы и устранении препятствий для того, чтобы оптимизировать их эффективность и не создавать одну большую команду? В этом случае используется масштабирование Скрама, например, в виде так называемого Скрама Скрамов (Scrum of Scrums, SoS), известного также под названием «Метаскрам» (meta Scrum). Русификация этого термина достаточно непревычна, поэтому в разделе будем использовать оригинальное наименование на английском – Scrum of Scrums. При Scrum of Scrums формируется ряд направлений или потоков (stream), связанных с различной функциональностью продукта или его элементов. Каждый из потоков выполняется параллельно одной типовой Скрам-командой. Скрам-мастера от каждой команды участвуют в общих встречах с назначенным старшим скрам-мастером (Chief Scrum Master, иногда эту роль называют руководителем программы – Program Manager, PM). Такие встречи аналогичны ежедневным летучкам в Скраме, когда выступающий докладывает о выполненных работах в потоке, предстоящей работе на следующий спринт

потока, а также о потенциальных предстоящих препятствиях, которые могут помешать работе других команд. На практике они проходят 2–3 раза в неделю или реже. Похожим образом организуются встречи владельцев продуктов команд со старшим владельцем продукта (Chief Product Owner, CPO). Ведутся отдельные журналы требований по потокам (BL) и один общий журнал требований всего продукта (рис. 5.3). Пример применения SoS в одном из проектов приведен в разделе 6.6. В еще более крупных проектах с участием нескольких уровней команд организуют вариант Scrum of Scrum of Scrums, который имеет ту же идею, что и Scrum of Scrums, только добавляется еще один уровень. Менеджеры программ или потоков (из каждого SoS) встречаются на координационной встрече с топменеджером верхнего уровня (TOP) (рис. 5.4). Обсуждаются вопросы координации программ и потоков. Частота встреч – реже, чем в случае отдельных SoS. Из проблем обсуждаются только самые крупные, которые команда нижнего уровня не может решить сама и вынуждена эскалировать. Кроме того, проводятся встречи CPO (старших владельцев продуктов) с топменеджером верхнего уровня по продукту.

Рис. 5.3. Scrum of Scrums[8]

Рис. 5.4. Scrum of Scrum of Scrums[9]

Спринт 6 Agile в инструментах, процессах, проектах Введение Я почти захотел, чтобы мы называли это «работающие продукты». И Джим Хайсмит действительно спустя месяц начал говорить «работающие продукты» вместо «работающее ПО», потому что он очень быстро обратил внимание на распространение манифеста на другие области. Алистер Коберн

Польза этого спринта несомненна. Изучив его материал, вы узнаете, что Agile вездесущ и проник в разные процессы и проекты за пределами ИТ. Конечно, примеров применения в мире гораздо больше, чем описано в рамках спринта, но настойчивый читатель обязательно их найдет на просторах Интернета или на профильных семинарах. Гибкость Agile, несмотря на тавтологию этой комбинации слов, еще и в том, что применять Agile можно полностью или частично, как отдельные инструменты или как процессы, во всей организации или только в одном подразделении и, конечно, в разных отраслях. Можно и нужно говорить о внедрении Agileкультуры или мышления (mindset). Ниже более по дробно поговорим о самом разнообразном применении Agile, начиная с разных гибких и бережливых инструментов. Часть примеров просто упоминаются, некоторые анализируются. Во всех случаях дотошный читатель может пройти по ссылке и узнать детали.

6.1. Agile в инструментах Если это (требования, отчет, план) не помещается на одной странице – никто этого не поймет.

Марк Ардис, Stevens Institute of Technology

6.1.1. Утренние летучки В любом бизнесе очень полезны утренние микросовещания или встречи (по аналогии с летучками из Скрама) в виде интенсивного обсуждения предварительно сделанной и предстоящей на текущий день работы. Как показали опросы, такие совещания и летучки проводят в 88 % компаний, внедряющих инструменты Agile. У совещания должен быть модератор, который проводит опрос каждого по тем же вопросам, которые используются в Скраме. Здесь основная опасность – не свалиться в какую-то внезапно объявленную проблему и не потратить на ее решение слишком много времени. Любую проблему (если, конечно, она не может быть решена в течение нескольких секунд) модератор фиксирует и решает с необходимыми участниками за пределами встречи. Если что-то не может быть обсуждено в рамках плана, в целях вынужденной замены можно сформировать альтернативные вопросы для повестки заранее. Это также придаст гибкость и бережливость утренней встрече. Прозрачность обсуждаемых тем, активная вовлеченность участников, минимизация неважной информации, повышенное внимание, использование talkball (мячиков, мягких игрушек, иных предметов, которые дают право на высказывание) являются Agile-атрибутами таких совещаний. При необходимости можно задействовать подходящее оборудование и технологии: вместо ненужной поездки – видеоокна с удаленными участниками или видеоконференц-связь; вместо специальных комнат – рабочие столы, которые могут быть подняты на уровень барной стойки, чтобы при проведении летучки можно было облокотиться; вместо специальной скрам-доски – поверхность стола, бумагу и др. Летучка, проведенная в начале дня, дает старт дню, не позволяет сотрудникам медленно втягиваться в рабочий режим. Можно использовать систему утренних летучек (цели на день), еженедельных, в понедельник (цели на неделю), и ежемесячных совещаний, например в первый понедельник месяца (цели на месяц).

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

♦ кто нужен для проекта как участник; ♦ какова роль каждого и как распределяются доли, если это бизнес-стартап; ♦ будет ли стартап основной занятостью; ♦ сколько нужно ресурсов и денег и в какие сроки; ♦ кто в проекте уникален; ♦ что, по идее, есть уже сегодня? Или другой набор вопросов о самой идее создаваемого в проекте продукта: ♦ что это такое; ♦ зачем мне оно; ♦ что я получаю от него; ♦ что отличает это от других; ♦ что может стать причиной отказа от него? Модель SCORE. Можно использовать универсальную модель SCORE (применяется в НЛП и не только для проектов, а также для бизнес-планов, продающих текстов, бытовых вопросов и т. п.) (Роберт Дилтс и Тодд Эпштейн, 1987), помогающую описывать новый замысел по аспектам: ♦ Symptom – симптом, актуальное состояние, «что сейчас происходит»; ♦ Cause – причина этого состояния, «что привело к тому, что происходит сейчас»; ♦ Outcome – желаемое будущее состояние, «к какому результату стремиться»; ♦ Resource – необходимый ресурс, «что нужно, чтобы перейти к желаемому результату»; ♦ Effect – будущие эффекты и последствия, «что даст переход к желаемому состоянию». Рисунки. При обсуждении идеи ее лучше рисовать и обсуждать в виде графических символов. Есть не менее шести аспектов, которые можно для этого использовать: ♦ «кто?» или «что?» рисуется фигурками, рожицами или коробочками, квадратиками; ♦ количественные характеристики иллюстрируются в виде гистограмм (столбики, горизонтальные отсечки); ♦ показать «где?» можно с помощью простой карты или схемы; ♦ оценка времени или срока удобно указывается с помощью горизонтального временного вектора; ♦ технологию или алгоритм можно изобразить в виде блок-схемы; ♦ зависимости и связи удобно представить в виде графиков. Возможны комбинации этих символов.

Метод PCDM (picture card design method), предложенный в Университете Кеплера, г. Линц. Моделирование проекта или новой инициативы с помощью наклеивания на доску или лист бумаги стикеров или карточек из четырех категорий (задачи или процессы, участники, документы и ресурсы/инструменты) и их взаимоувязывание. Можно ввести дополнительные категории, можно начинать с любой карточки. Типовые шаги такой работы: начальное изучение идеи, детальное изучение, дизайн идеи, дальнейшее изучение. Канва проекта. По образу шаблонов бизнес-модели (business model canvas от Александра Остервальдера и Ива Пинье) или «бережливого шаблона» (Lean Canvas от Эша Маурья) может быть использована и канва проекта, например игрового (game project canvas от Martin Pichlmair) или похожая. По сути, это страница с ячейками-разделами, в которые заносятся все основные аспекты планируемого проекта. Лифт-тест. Широко используется лифт-тест (elevator pitch) – очень короткое представление (100–150 слов) об идее, продукте, проекте, которыми надо заинтересовать потенциального инвестора, клиента, покупателя за время поездки на лифте (30–60 секунд). Любой соискатель финансирования в свой проект должен уметь провести такую краткую содержательную самопрезентацию. Среди элементов представления могут быть следующие: «Кто я?», «Чего хочу?» (проблема), «Что предлагаю?» (решение); «Что мне нужно?» (заключение). Гарвардской школой бизнеса разработан продукт HBS Elevator Pitch Builder (http://www.alumni.hbs.edu/careers/pitch/), помогающий создать такую короткую «презентацию для лифта». Компания Procter & Gamble требует от своих сотрудников описания их предложений на одном листке.

6.1.3. Комната Обея, или боевая комната Обея (яп. Oobeya) – это большая комната или конференц-зал, в котором организуется работа гибкой проектной или процессной команды. Она напоминает военный штаб, где висят карты, доски и графики, показывающие ключевые вехи проекта, ход его реализации, описание открытых вопросов и различных технических проблем. Дополнительно можно разместить проектную миссию, цели, задачи, дорожную карту, организационную структуру; информацию по участникам, флипчарты, карту рисков; понедельные планы команды; доску изменений; KPI, показатели, результаты и др. В центре стоит стол или организуется свободное пространство для обсуждения и работы. Иное название такого штаба – комната исполнения, performance room (https://tcmuklimited.co.uk/manufacturing-blog/ performance-rooms-a-powerfulvisual-management-tool/). Лифт-тест Представьте, что наступило время окончательной презентации результатов большого проекта. Вы вместе со своей командой не спали до двух часов ночи, брошюруя голубые книжки, проверяя, чтобы все было в полном порядке. Вы все надели свои лучшие костюмы, чтобы выглядеть на миллион. Высший менеджмент компании, входящей в Fortune 50, собравшись за круглым столом в зале заседаний совета директоров в небоскребе, принадлежащем компании,

озабоченно ожидает, когда McKinsey изречет истину. В зал стремительно заходит СЕО и говорит: «Извините, ребята. Я не могу остаться, у нас случился кризис и я спешу на встречу с нашими юристами». Затем он поворачивается к вам и говорит: «Почему бы вам не спуститься со мной в лифте и не рассказать мне, что вам удалось обнаружить?» Спуск на лифте занимает 30 секунд. Можете ли вы преподнести свои рекомендации за это время? Можете ли вы продать ваши предложения? Это и есть лифт-тест[10]. Комната Обея Некоторые характеристики комнаты Обея: ✓ простая для внедрения, гибкая, перестраиваемая и обновляемая; ✓ поощряет кросс-функциональное планирование и решение проблем; ✓ создает самоуправление и ответственность с помощью командной работы[11].

6.1.4. Сервис-дизайн, или дизайн-мышление (Service design, Design-thinking) Идея дизайн-мышления как способа решения задач, ориентированных в максимальной степени и в первую очередь на реальные интересы пользователя, клиента или потребителя, была представлена Гербертом Саймоном в книге «Науки об искусственном» (The Sciences of the Artificial, 1969). Позже она проникла в менеджмент и стала активно задействовать наблюдения, эксперименты, прототипирование и быстрые изменения, почти весь арсенал Agile. А в 1990-х гг. Дэвидом Келли была основана дизайнерская компания IDEO (ideo.com) (девизом которой стал «Мы создаем позитивное влияние через дизайн»), создавшая компьютерную мышку, «невыжимаемый» тюбик для зубной пасты, стоящий вертикально на широкой крышечке, наладонник Palm PDA и т. д. Логика дизайн-мышления как универсального процесса (а оно применимо к любой задаче: от строительства здания до разработки электронного магазина) в том, что потенциальные клиенты, для которых что-то делается, вовлекаются в процесс дизайна, разработки, проектирования с самого начала и до конца. Основой подхода является так называемая модель двойного алмаза (double diamond model), созданная в 2005 г. британским Советом по дизайну. Модель фокусируется на глубоком изучении проблемы заказчика, поскольку часто он не обладает полноценным пониманием своих потребностей. И исполнитель совместно с заказчиком после фазы исследования фактически формулирует техническое задание на работу. Модель подразумевает плотное взаимодействие с заказчиком. С ним уточняется проблема, с ним же создаются варианты решений, которые впоследствии с ним и тестируются. Важно обеспечить командную работу, так как деятельность подразумевает совместное обсуждение, критику и представление различных точек зрения. Ниже кратко приведены фазы и этапы модели и некоторые возможные инструменты (подбираются строго индивидуально под каждый проект). Фаза дивергенции (определение задачи и создание идей).

1. Этап исследования в виде максимально точного определения потребностей клиента и формирования широкого набора идей для решений, которые в дальнейшем можно тестировать. Среди инструментов и методов: различные интервью со всеми стейкхолдерами проекта, онлайн-опросы, интервью в виде фокус-групп или индивидуальные глубинные интервью, наблюдения, использование эмпатии (empathy) («влезть в шкуру» клиента, отождествление личности одного человека с личностью другого, когда пытаются мысленно поставить себя в положение другого, слушать, как говорится, «между строк», чтобы понимать чувства), «вопросы о возможностях», диаграммы сходства (affinity diagrams), рабочие сессии, визуализация. 2. Этап определения задачи и генерации решений, в конце которого у исполнителя формируется согласованная с клиентом точная формулировка проблемы, а также набор идей, в том числе и «безумных», для решения. Среди инструментов и методов: создание персон конечного пользователя (personas creation); картирование и описание «пути клиента» для каждой персоны (customer journeys mapping); метод дизайн-спринта (design sprint), подразумевающий начало создания концепта и прототипирования решения еще до того, когда задача точно определена, а также сессия с клиентом с целью генерации идей для решения поставленной проблемы. Примеры решений В результате проведенных исследований для Samsung было предложено руководство по телефону в виде набора книг, что позволило пожилым людям чувствовать себя комфортно и охотнее пользоваться смартфонами[12]. В госпитале Питтсбурга кабинеты и МРТ-сканеры были гейми-фицированы (приключения, сказки, путешествия) для детей без переделки самого аппарата[13]. Разработка сервисов Учебный центр Университета Аальто в Отаниеми, Эспоо (Финляндия), проектировался агентством Kuudes Oy с использованием дизайн-мышления. Были сформированы следующие персоны (представители потребителей): ✓ «одиночки», те, кто предпочитает заниматься в одиночестве, не любит шумные, открытые пространства; ✓ студенты, которые могут работать только в группах. Передвигаются всегда коллективами, им нужны доски, чтобы фиксировать то, что они обсуждают, нужны кафе и различная мебель, в том числе диваны и кресла; ✓ смешанный тип, посетители центра, у которых нет особого требования к сервисам, кроме посадочных мест, соблюдения общих норм эргономики и комфорта. Для них по результатам интервью был разработан предварительный список сервисов из 12 позиций, например: ✓ видеозаписывающая комната; ✓ небольшие камеры хранения, также с зарядками для гаджетов; ✓ медиастена с информацией: объявления и периодика;

✓ кафе внутри пространства библиотеки, работающее два часа и после закрытия университета; ✓ событийное пространство, которое трансформируется в зависимости от мероприятия; ✓ выставочная зона с временными тематическими выставками; ✓ пространство для стартапов и др. Сервисы, пока строился центр, тестировались в старой библиотеке университета, расположенной в здании бизнес-школы в Хельсинки. Были выбраны и реализованы наиболее популярные[14]. Фаза конвергенции (разработка, тестирование и выбор решения). 1. Этап тестирования и прототипирования как быстрое прототипирование различных вариантов решений и их тестирование. Среди инструментов и методов: визуализация в скетчах; прототипы с ограниченным количеством функций и не до конца проработанным графическим дизайном; «проигрывание» процессов предоставления услуги; «выстраивание» прототипа с помощью подручных средств; инструменты виртуальной или дополненной реальности. Циклы прототипирования или улучшения прототипа, а потом тестирования на конечных пользователях повторяются до тех пор, пока не будет получено решение, которое с точностью удовлетворяет нужды пользователей. Здесь очень подходит Скрам. 2. Этап внедрения. Техническое задание на продукт, а также детальный концепт решения с описанием всех необходимых функций и дизайн предпочтений передаются техническому исполнителю. Последний претворяет поставленную задачу в объект, готовый к промышленному тиражированию. Идет разработка маркетингового продвижения продукта, часто основанного на историях тех конечных пользователей, которые участвовали в поиске проблемы, в разработке и тестировании решения.

6.1.5. Ментальная карта (карта памяти, интеллект-карта, Mind Map) Удобная визуализированная форма мышления, моделирования, анализа была предложена Тони Бьюзеном, психологом из Англии, и применяется для создания новых идей, фиксации идей, анализа и упорядочения информации, принятия решений. Главная обсуждаемая тема или объект находятся в центре листа бумаги или доски; понятия и аспекты, связанные с ней, располагаются вокруг в виде лучей или древовидных образов. Можно использовать яркие цвета, стили, изображения, заметки. Карту можно нарисовать на столе, в облаке или на экране компьютера. Ее можно наращивать и изменять, оставлять на время и работать с ней постоянно. Из удобного софта можно применять MindMeister, iMindMap и др. Это позволяет удаленно работать, легко добавлять и убирать, хранить, импортировать в другие программные продукты, например Trello MS Project и др.

6.1.6. Установочное совещание, или Kick-off meeting Это первая перед началом проекта встреча утвержденного состава исполнителей, заказчика, иных заинтересованных сторон стартовавшего проекта. Среди задач – формирование одинакового понимания целей, понимание и уточнение ожиданий, знакомство участников. Нужно познакомиться, обсудить цели и ожидаемые результаты проекта, проговорить риски проекта, уже имеющийся опыт по похожим проектам. Желательны напутственные слова спонсора и неформальное проведение.

6.1.7. Виды мозгового штурма Среди Agile-инструментов – различные формы и виды мозгового штурма, «атаки» и «осады», «атака разносом» с использованием диаграммы сходства (или метода KJ, Kawakita Jiro), метода номинальных карт и др. «Мозговая атака» Массовая «мозговая атака», предложенная Дж. Дональдом Филлипсом (США), позволяет существенно увеличить эффективность генерирования новых идей в большой аудитории (число участников – от 20 до 60 человек). Особенность этой модификации заключается в том, что присутствующих делят на малые группы численностью 5–6 человек. После этого они проводят самостоятельную сессию прямой «мозговой атаки». Деятельность работы малых групп может быть разной, но четко определенной, например 15 минут. После генерирования идей в малых группах проводится их оценка, затем выбирают наиболее оригинальную.

6.1.8. Концентрация работы команды только над одним проектом Как показали исследования, мультизадачность убивает продуктивность. Одновременное выполнение двух задач снижает продуктивность на 20 %, трех – на 40 %, а пяти – на 75 %. Наиболее эффективны команды, полностью выделенные на проект[15].

6.1.9. Визуализация текущего состояния проекта или процесса Чрезвычайно эффективно использование скрам-досок, даже не в скрампроекте. Подробнее см. в разделе 4.3. Примеры Lonely Planet: юридическая команда этого бренда путеводителей сразу приняла Agile и использовала доску с карточками задач, летучки, еженедельные итерации и определение приоритетов. Она оценивала свою работу, измеряла поток задач и проводила ретроспективы. GSM Association: команда применяла Agile для написания большой технической спецификации. Несмотря на то что команда была распределена по всей Европе, ее участники проводили еженедельные встречи по понедельникам, которые включали планирование итераций и проведение

некоторых работ. Позже физическую доску заменил софт и работа была структурирована как набор историй. Команда представила требуемую спецификацию к сроку, и в итоговой ретроспективе все подтвердили, что Agile помог. Shamrock Foods Co (дистрибьютор продуктов питания в Аризоне): группа топменеджеров проводила ежеквартальные недельные выездные совещания с участием региональных менеджеров со всей Америки. Оценивались прогресс и выполнение, рассматривалась и корректировалась стратегия, определялись приоритеты и принимались решения о следующих шагах. Потом руководители возвращались и выполняли согласованные задачи.

6.2. Agile в бизнес-процессах Все вещи создаются дважды. Первый раз ментально, второй раз – физически. Ключ к креативности в том, чтобы начинать работу, зная заранее результат, который хочешь получить. Стивен Кови

Agile можно и нужно использовать в виде не только отдельных инструментов или их комбинаций, но и некоторых бизнес-процессов. Применение Agile эффективно, если: • не удается организовать обычные «водопадные» процессы; происходит частое изменение процессов; • нужна особая кастомизация с особыми клиентами, которых не хочется терять; • надо постоянно экспериментировать с продуктом или услугой. Agile в действии Agile неплохо применяется, например, во внутренней работе отделов компании. Бухгалтеры, юристы, бизнес-ассистенты и даже хозяйственный персонал проводят десятиминутные встречи, стоя утром и вечером, планируют двухнедельные итерации, используют стикеры, доски и другую атрибутику. Отрабатываются формальные документы, отчеты, создаются новые решения[16]. Например, это может быть операционная работа офиса, обслуживающего клиентов через применение небольших шагов, или итераций, визуализацию состояния работы, тесный контакт с клиентом, простое внесение изменений в этапы работы, упрощение документов. Проект улучшения процесса управления цепочками поставок готовой продукции РУСАЛа, 2016 г. В проекте были задействованы представители всех подразделений – участников анализируемого процесса (сбыта, производства, логистики и финансов), которые вместе искали решение, решали конфликты и двигались к общей цели. Кросс-функциональная команда включала участников, выделенных на 100 % времени. Они знали текущий бизнес-процесс и обладали достаточной компетенцией, чтобы разработать и внедрить его обновление.

Команде дали карт-бланш на изменения в определенных областях в тестовом режиме, и при этом не требовалось получения согласований по новым методикам, регламентам, которые обычно требуют много времени. Благодаря этому удалось очень быстро тестировать новые подходы и находить подходящие решения. Каждый этап длился не дольше месяца, за который нужно было получить результаты, представляемые заказчикам. Сложным был поиск баланса между интересами задействованных подразделений и темпами выдачи результата каждый месяц[17]. Внедрение Agile-процессов 1. Американское Национальное общественное радио, исполь зуя Agile, создает новые вещательные программы. Одна команда применила Agile при создании цифрового архива из более чем 750 000 записей, другая группа – для оптимизации распределения эфирного времени между национальными новостями и местной информацией. 2. John Deere (сельхозтехника). Agile внедрили в компании в 2004 г., сначала в ИТ-отделе, потом среди программистов в других подразделениях. Это упростило внедрение Agile-процессов в отделах развития бизнеса и маркетинга. В 2012 г. Agile стал применяться в подразделениях НИОКР, работающих с инновационной продукцией John Deere. Было проведено специальное обучение с использованием Agile-коуча, сумевшего объяснить суть непрограммистам, и, кроме того, создана база Agile-знаний с учетом специ фики Deere. Благодаря Agile в подразделении Enterprise Advanced Marketing существенно, иногда более чем на 75 %, сократились сроки выполнения инновационных проектов (c 1,5–3 лет до 8 месяцев). Сейчас почти во всех подразделениях John Deere кто-нибудь либо осваивает адаптивную модель, либо размышляет, как перейти на нее. 3. Mission Bell Winery (виноделие). Эрик Мартелла, вице-президент и генеральный менеджер, ввел Agile во всей компании – от производства вина до хранения на складах и организации работы своих топ-менеджеров. Начав с проекта сертификации, который благодаря Скраму прошел очень быстро, он организовал обучение 45 человек. Мартелла призвал всех давать заметки с идеями по улучшению работы. Он сгруппировал эти идеи и создал единый упорядоченный приоритизированный список, в соответствии с которым был создан список первоочередных пилотных Agile-проектов в каждом отделе: виноделие и специализированные продукты, операции по хранению, дистрибуция, качество, розлив, даже технический ремонт и обслуживание. В итоге увеличилась производительность, сертификат ISO 9001 был получен с нулевыми замечаниями, аккуратность в работе с готовой продукцией выросла до 90 % и т. д.[18] С применением элементов Agile хорошо реализуются внутренние проекты по разработке стратегии и управлению ею (см. врезки на с. 134 и 140), когда во время спринтов отрабатываются инкременты или итерации стратегического плана. Участвует модератор (скрам-мастер), рабочая группа распараллеливает работу с регулярной синхронизацией и корректировкой. Природа внутренних проектов развития в условиях изменяющейся внешней и внутренней среды, изменения намерений руководства, постадийной разработки идей сама по себе способствует применению Agile.

Ниже, в разделе 6.10, будут описаны маркетинговые Agile-процессы.

6.3. Agile в стройке Неважно, насколько хороша ваша команда или как эффективна методология, если вы не решаете правильную проблему, то проект провалится. Вуди Уильямс, w3src Consultingt

Применение Agile в строительной отрасли также возможно (и даже иногда необходимо), поскольку объект и производственный процесс строительства являются уникальными, в сильной степени ориентированными на заказчика, подверженными частым изменениям (например, на стадии проектирования). Стройка иногда ведется с учетом разного физического окружения, функционального назначения здания, индивидуальных потребностей заказчика, его финансового состояния и множества других влияющих факторов. Заказчик может изменять свои требования по мере проведения работ, например ремонтируя или строя объект по частям. В этом случае все ремонтируемые инкременты (части) объекта могут планироваться, подвергаться последовательному изменению и оцениваться в рамках спринтов. Начальник участка или бригадир (как человек-оркестр) будут играть роль скрам-мастера, а прораб или инженер – роль владельца продукта. Заказчик будет приходить в конце спринта для приемки сделанного и озвучивания новых пожеланий. MVP – та готовая для обратной связи часть объекта, которую можно оценивать для выдачи новых требований к следующему спринту. В некоторых ситуациях отремонтированный или построенный инкремент даже может использоваться заказчиком. Ремонт или стройка будут продолжаться до самого конца проекта, хотя могут быть риски «вечного ремонта». Заказчик может изменять свои требования, осуществляя стройку в пределах имеющегося финансирования. В этом случае стройка или ремонт идут в размере имеющейся у заказчика суммы, а MVP – та часть объекта, которая будет построена или отремонтирована в рамках этого финансирования и которую можно будет немедленно эксплуатировать. Однако получение заказчиком выгоды от использования инкрементов объекта, введение изменений не всегда возможны, поэтому Agile не очень широко применяется в строительстве. Тем не менее можно выделить некоторые элементы Agile (и отчасти Lean), применимые на стройке: ♦ близкое взаимодействие с заказчиком; ♦ несение заказчиком ответственности за вносимые изменения; ♦ создание потоков материалов и информации;

♦ максимизация ценности путем избавления от любых потерь, не только производственных. И в этой связи, как уже упоминалось, просматриваются такие аналогии: ♦ начальник участка, бригадир – скрам-мастер. Постоянно контактирует с командой, руководит ее работой, отвечает за результаты работы, формирует коммуникации и управляет ими – например, летучкой; ♦ главный инженер (или просто инженер) проекта или прораб, менеджер проекта – владелец продукта, обладают всей необходимой информацией о стройке, принимают решения по требованиям и спецификациям, взаимодействуют с заказчиком, надзором и другими заинтересованными сторонами; ♦ непродолжительный этап работ – спринт; ♦ план на неделю – планирование спринта или его части; ♦ ежедневные встречи по статусу проекта (бригады и отдельные специалисты координируют свои действия, а начальник участка собирает информацию и устраняет конфликты и противоречия) – летучки со скрам-мастером; ♦ проверка заказчиком объекта и площадки строительства – демонстрация клиенту; ♦ обзор недели или этапа – уроки и ретроспектива. А также более инновационные решения: ♦ скрам- или канбан-доска с планом на неделю; ♦ увеличение вовлеченности заказчика, стимулирование участия его и потребителей в определении результатов проекта; ♦ поощрение постоянного улучшения работ; ♦ назначение на проекты уже готовых команд, а не формирование новых команд под проекты; ♦ включение прораба в команду, где он не указывает, а становится лидером и выполняет такую же работу. Эффективность применения Agile в крупных строительных проектах с повышенной сложностью показывает следующий пример. В качестве интересного технологического Agile-решения отмечу систему «Последний проектировщик» (The Last Planner System, также известную как Collaborative Planning, Lean Planning), которая максимально соответствует Agile. Термин Last Planner зарегистрирован как торговая марка Института бережливого строительства. Система позволяет улучшить качество строительно-монтажных работ, уменьшает число дефектов, сокращает сроки и затраты строительства. План разбивается на небольшие отрезки в одну неделю для итеративной реализации. LPS была использована при строительстве пятого терминала аэропорта Хитроу в Лондоне с бюджетом около $8 млрд и больницы North Staffs Hospital PFI с бюджетом около $400 млн[19].

Пример компании Centrus Energy Corp Компания Centrus Energy Corp. (поставщик топлива из обогащенного урана для международных и американских коммерческих атомных электростанций) реализовала НИОКР-программу стоимостью $350 млн, включавшую строительство, установку, эксплуатацию и испытания промышленной установки и каскада из 120 блоков, которые могут быть включены в полноценный коммерческий завод по обогащению в Piketon, штат Огайо, планировавший эксплуатировать 96 идентичных каскадов. Программа использовала 169 компаний из 28 государств, повысив общую численность трудовых ресурсов проекта на более чем 1100 работников. Успех программы отразился в том, что Департамент энергетики сертифицировал завершение всех десяти технических этапов программы и достижение всех пяти показателей эффективности, а также в соблюдении бюджета и графика. Особенности программы заключались в сжатых сроках и ограниченном финансировании. Программа задействовала целый набор Agile-решений: 3 деление систем на инкременты, создание их параллельно (при возможности); ✓ интегрированную команду управления, включающую пользователей, которая работала с первого дня; ✓ принятие даже поздних изменений, но с анализом их необходимости; ✓ постоянные встречи по статусу проекта; ✓ полноценные и круглосуточные проектные офисы во всех географических точках работ; ✓ дисциплину, мотивацию, визуализацию степени достижения целей; ✓ внимание к продуктивности на рабочих местах, соответствующее оборудование и снабжение; ✓ каждую неделю сбор уроков, в том числе и в конце программы[20]. Кратко из публикации Тома Ричерта What is the Last Planner System? Часть I. Подготовка «Общего графика строительства объекта (master plan)» – планирование основных этапов и вех (начала и завершения каждой из фаз и даты начала закупки строительных компонентов с длительным циклом производства), выполняется в начале проекта (рис. 6.1, 6.2). Часть II. Планирование фазы (phase planning) осуществляется за 2–3 месяца до начала каждой из них. Определяется условие завершения фазы, далее выстраивается последовательность операций через запросы заказчиков и обязательства исполнителей. Это позволяет определить, как работа будет продвигаться от одной операции к другой для такой ее организации, чтобы она выполнялась равномерно с минимальными отклонениями.

Рис. 6.1. Состав LPS

Часть III. Предвидящее планирование (lookahead planning) необходимо для проверки, есть ли препятствия для выполнения предстоящих работ, определенных при планировании фазы. Фокусирование внимания команды на работах сменного/недельного среза и уточнение состава тех из них, которые должны быть готовы к выполнению в ближайшее время, а также стартовых работ. Охватываются работы на ближайшие шесть недель, хотя в сложных проектах можно сдвигать горизонт оценки дальше. К препятствиям относится то, что мешает выполнить запланированную работу, например отсутствие необходимых трудовых ресурсов или материалов, недоступность оборудования и др. Они фиксируются в журнале с указанием ответственного за устранение препятствия к определенной дате. Часть IV. Недельное планирование (weekly work planning) включает подготовку недельного плана с определением выполнимости задач для завершения в каждый день следующей недели.

Рис. 6.2. Оценка и работа с препятствиями

Часть V. Совершенствование (learning) – ежедневная работа команды на ежедневном координационном совещании, часто называемом «ежедневная толкучка», где планировщики сообщают, выполнила ли их команда задачи, запланированные на день. Если не выполнила, договариваются о том, что нужно сделать, чтобы, несмотря на это, выполнить недельный план. Используются и другие возможности для совершенствования. Внедрение системы LPS зависит от среды управления, предполагает уважение к людям и самоидентификацию проектных руководителей как тренеров и помощников для планировщиков, которые осуществляют основную часть планирования и внутренней настройки в проектах проектов. Это дисциплина, которая требует непрерывной ежедневной практики и взаимодействия внутри проектной команды[21].

6.4. Agile в образовании В аббревиатуре PM буква P в равной степени означает как project management (проектное управление), так и people management (управление людьми). Корнелиус Фитчер, PMP, автор статей

Реализация процесса или проекта обучения, ориентированного на клиента (обучаемого сотрудника), очень похожа на реализацию в Agile. И здесь есть и итерации, и MVP (причем эти полученные знания и умения можно сразу использовать), и плотная работа с потребителем или заказчиком, и введение изменений, и адаптивность под новые условия и т. д. Agile проникает во все уровни образовательной системы: и в разработку учебных программ, и в

ведение процессов обучения, и в организацию учебных технологий. Примерами таких Agile-проектов могут быть следующие. Разработка и реализация корпоративного обучения с необходимой для компании ценностью. • Базовая ценность после обучения – в целях монетизации правильным образом делать в компании правильные вещи. • Заказчик (компания) формирует приоритетные проблемы или потребности на весь период (журнал требований). • Командой (тренерами и слушателями) совместно строятся и реализуются короткие учебные модули, реализующие эти потребности. • Руководитель программы от провайдера – владелец продукта и скрам-мастер (хотя последний может быть и администратором обучения). • Планирование спринта – формирование ожиданий на модуль, совместное его выстраивание. • В двухнедельных учебных модулях-итерациях закрываются болевые точки и уточняются следующие приоритеты. • Используются гибкая учебная инфраструктура и средства. • Летучка (ежедневно утром) – ежедневная проверка знаний. • Демонстрация (в конце спринта) – демонстрация компании идей, навыков, решения проблем, планов на следующий модуль. • Ретроспектива (в конце спринта) – обсуждение с руководителем программы результатов модуля, улучшение. • Фактор успеха – концентрация и решение актуальных корпоративных проблем. Agile-обучение: формирование индивидуальной или групповой образовательной траектории. • Стартовая диагностика потребностей. • Совместная с представителем (-ями) заказчика разработка концепции. • Создание взаимодействующей команды. • Короткие итерации по продукту обучения. • Использование самых разных инновационных решений. • Производство микромодулей курса с немедленной реализацией и последующим совершенствованием. • Создание комплекса микромодулей с возможностью простой актуализации в последующем. Agile как педагогическая технология для применения в обучении и т. п. Agile-обучение Пионерами применения Agile-подхода, например, в школьном образовании стали голландские педагоги из Алфен-ан-ден-Рейна. Их поддержало голландское деловое сообщество, и теперь там есть специальный фонд eduScrum, информирующий об Agile учителей и школы[22].

Все такие проекты могут реализовываться в любой целевой аудитории: школьников, студентов, для корпоративного обучения и даже непрерывного самообразования. Подобный опыт возникает и в других странах. В России таким примером является проект AgileInEducation. Хорошей основой в подобных инициативах выступает Agile-манифест, специально сформулированный для школ (по аналогии с оригинальным Agile-манифестом)[23]. «Мы постоянно открываем для себя более совершенные способы обучения и воспитания детей, занимаясь этим непосредственно и помогая в этом другим. Благодаря такой работе мы смогли осознать, что: ♦ люди и взаимодействие важнее процессов и инструментов; ♦ значимое обучение важнее измерения обучения, формальных тестов; ♦ сотрудничество с заинтересованными сторонами, участниками процесса важнее постоянных согласований/сложных переговоров; ♦ готовность к изменениям важнее следования первоначальному плану. То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева». В образовании работают все те же принципы Agile, только слегка адаптированные: ♦ важность удовлетворения заказчика обучения (отсюда новые достижения, развитие); ♦ изменения приветствуются для создания ценности заказчику (программы можно относительно легко изменить в самом процессе обучения); ♦ полезный результат организовывать чаще (короткими итерациями создавать знания, которые немедленно пойдут в работу; осмысленное обучение должно осуществляться короткими, но частыми циклами); ♦ работать вместе с заказчиком (корпоративные программы всегда кастомизированы, создаются с участием экспертов компании и руководства); ♦ работать мотивированно (понимая под этим и работу разработчика программы, и само обучение; проект учебы должен создаваться мотивированными профессионалами, для работы которых необходимо создать соответствующие условия); ♦ через личное общение (самыми эффективными коммуникациями является общение внутри групп и самой группы с тренером); ♦ результат – основной показатель (уход от оценки программы по баллам экзамена или теста к производственным или проектным практическим показателям); Принципы обучения Agile Стив Пеха – президент Teaching That Makes Sense, консалтинговой компании в области образования, специализирующейся на грамотности, оценке и лидерстве в школе. Начиная с 1995 г. он обучил тысячи классов и сотни школ в Америке и Канаде. Базисом Agile являются люди, динамика и обучение, поэтому Agile может быть реализован в школе. Его внедрение позволит ей

стать некоторым инновационным центром. Ученик получит знания, актуальные на момент его обучения. В процессе образования должна присутствовать командная работа учителей, родителей и ребенка. Освоение материала улучшается при творческом подходе к процессу обучения и учете индивидуальных особенностей учеников. Заказчиками системы обучения в современной школе должны быть дети и их родители [24]. ♦ устойчивость создания результата и его самого (передаваемые умения и знания должны работать в длительном периоде, а сами программы должны быть воспроизводимы; ритм обучения должен поддерживаться постоянно; главным показателем прогресса служит усвоение материала, а не просто его запоминание); ♦ совершенство и гибкость (при обучении приветствуются лучшие тренеры, технологии, материалы, однако нет предела совершенству, и в этом его гибкость; гибкость учебного проекта должна поддерживаться за счет пристального внимания к качеству проектирования и техническому совершенству); ♦ простота – только все нужное, ничего лишнего (сокращение лишнего, неэффективного); ♦ высокопрофессиональные самоорганизующиеся команды (возможны сочетания учебных групп или сотрудников разного уровня); ♦ постоянное улучшение (модернизация программ, введение новых решений)[25].

6.5. Agile в управлении персоналом Найдите правильных людей. Потом, что бы вы ни делали, какие бы ошибки ни допускали, люди вытащат вас из любой передряги. В этом и заключается работа руководителя. Том ДеМарко, автор книги «Deadline: Роман об управлении проектами»

Примерами HR-проектов являются проекты развития HR-процессов и инфраструктуры (реорганизация, автоматизация и ИС в области HR, внедрение KPI и др.), проекты развития персонала (набор, обучение персонала, аттестация, модели компетенций), проекты развития корпоративной культуры (изменение культуры, корпоративные праздники, программы вознаграждений) и др. Эти и другие подобные HR-проекты обладают общими признаками: ♦ имеют высокоуникальные цели и задачи; ♦ у них трудноформализуемые и трудноизмеримые задачи и результаты; ♦ они характеризуются трудно и неполно собираемыми требованиями; ♦ в таких проектах люди управляют людьми; ♦ высоковероятны внимание и близость заказчика – руководства или акционеров;

♦ использование кросс-функциональных участников и ориентация результата на разные функции; ♦ часто участие только внутренней команды; ♦ тесное влияние на другие проекты и процессы компании, в том числе производственные; ♦ обязательный учет корпоративных ограничений и рисков; ♦ постоянное наличие некоторых отрицательно настроенных заинтересованных сторон. При анализе этих признаков становится ясно, что большинство из них указывает на целесообразность применения к таким проектам Agile-подходов. Аналогично Agile в образовании также был сформулирован Agile-манифест для HR. ♦ «Совместная сеть сотрудничества важнее иерархических структур. ♦ Прозрачность важнее секретности. ♦ Адаптируемость важнее норм, предписаний. ♦ Вдохновение и вовлечение важнее управления. ♦ Соответствующая мотивация важнее непонятного вознаграждения. ♦ Амбиции, стремление важнее обязательств. Не отрицая важности того, что справа, мы все-таки больше ценим то, что слева»[26]. Agile Manifesto для HR содержит также 12 принципов, адаптированных для функции HR из оригинального Agile-манифеста. ♦ Наивысший приоритет – удовлетворение потребностей клиентов путем раннего, непрерывного предоставления ценных HR-результатов (клиенты – это менеджеры, сотрудники и внешние клиенты). ♦ Приветствуется изменение требований, в том числе на позднем этапе HRразработки или проекта. ♦ Осуществлять HR-программы, инструменты, услуги часто; чем чаще, тем лучше. ♦ В HR-проектах HR-менеджер должен ежедневно работать с операционными менеджерами, другими отделами и сотрудниками (кросс-функциональные команды) на протяжении всего HR-проекта. ♦ Создавать проекты вокруг мотивированных людей, окружая их соответствующей средой и давая поддержку, в которой они нуждаются, и доверять им выполнять свою работу. ♦ Общение лицом к лицу в HR-команде – лучший и наиболее эффективный способ обмена информацией. ♦ Работающие HR-программы, инструменты и услуги являются основным показателем развития. ♦ Фокус Agile в устойчивом, постоянном и стабильном темпе HR-работы.

♦ Постоянное внимание к высокому качеству и хорошему дизайну повышает способность к адаптации. ♦ Простота важна как искусство максимизации объема незавершенной работы. ♦ Лучшая архитектура в HR-результатах возникает из самоорганизующейся команды. ♦ Через регулярные промежутки времени HR-команда размышляет о том, как она может быть более эффективной, и соответствующим образом адаптирует свое поведение. С 2012 г. понятие Agile HR (впервые употребленное в компании Deloitte) стало популярным направлением, целью которого было расширение возможностей HR-специалистов. Согласно HR Trend Institute, понятие Agile HR относится к способам работы и организации функций HR, которые облегчают реагирование и адаптивность деятельности и структур компании к изменениям и клиентам. Agile HR Agile HR утверждает, что работа в области HR заключается не только в контроле, исполнении стандартов и усилении этого исполнения, а скорее в облегчении и повышении организационной гибкости. Новая миссия и фокус HR – поддержание гибкости, что означает новые программы, которые создают адаптивность, инновации, сотрудничество и скорость [27]. Появление Agile HR и внимание к этим моделям было вызвано целым рядом явлений, происходящих в современном VUCA-мире. Это и ускоренная глобализация, и дисбаланс талантов и навыков, и появление Big Data. Человеческий капитал стал нуждаться в новых моделях для карьеры, учете особенностей поколения Y, соединенного информацией, глобального, мобильного, лояльного проекту, а не месту работы. Новые кандидаты нуждаются в новых местах для работы, которые должны быть специализированными, разнообразными, быстроизменяемыми, командоориентированными и мобильными. Тренды в Agile Примеры ярких трендов, влияющих на функции и задачи HR: ✓ рост ИС по управлению талантами (SAP-SuccessFactors, Oracle-Taleo, Saba, SumTotal Systems, CornerstoneOnDemand и др.) на рынке; ✓ увеличение найма кандидатов через мобильные устройства (топ-рекрутеры говорят, что это кандидаты наилучшей квалификации); ✓ появление мощных инструментов – MOOCs (Massively Open Online Courses) с бизнес-ориентированными решениями в обучении (поставщики курсов – Coursera, edX, Udacity, Udemy, iversity); ✓ ввод технологии обучения: «интервалы повторения» между модулями в виде вопросов, которые генерируются бесплатными инструментами через Twitter; ✓ повсеместное использование видео и др.[28]

Одним из вариантов реализации таких решений является Agile-компания как модель предприятия со следующими признаками (более детально это будет рассмотрено в разделе 9.4): ♦ высокая скорость подключения внутренних виртуальных команд; ♦ сотрудничество для быстрого удовлетворения потребностей клиентов; ♦ использование разных данных для принятия решений; ♦ новые модели управления. Такая компания формирует и новые правила, и роли в HR: ♦ традиционный фокус на контроле и согласованности смещается к более гибкой ориентации на скорость реагирования и клиентов; ♦ вместо исполнительности, порядка и контроля доминируют адаптивность, инновационность и скорость; ♦ работа HR меняется от внедрения контроля, стандартов и систем для управления согласованностью и исполнением к внедрению программ, систем и стратегий, которые могут поддерживать экспертизу, сотрудничество и принятие решений. Современные СЕО считают признаками гибкости в компаниях следующее: ✓ быстрое принятие решения; ✓ культуру совершенного исполнения; ✓ гибкое управление командами; ✓ прозрачность и доступность информации[29].

Среди современных трендов в Agile HR: ♦ обучение руководителей на всех уровнях как коучей для подчиненных, а не просто менеджеров;

♦ формирование организации в виде небольших высокоэффективных команд, которые имеют свои собственные цели; ♦ выстраивание коммуникаций с клиентами во всех группах и функциях; ♦ создание миссии и ценностей и донесение их до каждого сотрудника с тем, чтобы он сверял с ними свою деятельность; ♦ создание системы прозрачного движения информации: каковы наши цели, кто работает над каким проектом, кто наши эксперты; ♦ внедрение системы вовлечения, а не только системы отчетности, то есть кооперации, обмена информацией, проектного менеджмента; ♦ фокус на построении системы непрерывного обучения и культуры обучения; ♦ создание сильного HR-бренда компании, направленного на привлечение специалистов, необходимых вашей компании; ♦ поиск на рынке экспертов, развитие экспертов, а не специалистов по управлению; ♦ поощрение и обучение специалистов давать обратную связь друг другу; ♦ создание системы вознаграждения, где результаты работы определяются не руководителем, а коллегами, клиентами, партнерами и т. п.; ♦ содействие созданию неоднородных команд (по возрасту, опыту, компетенциям). Памятка успешных менеджеров В 2009 г. Google создал себе модель «лучшего босса», разработав список из восьми видов поведения успешных менеджеров и включив это в тренинги. 1. Будь хорошим коучем и тренером. 2. Расширяй возможности своей команды, но не микроуправление. 3. Выражай интерес к членам команды, их успеху и благополучию. 4. Не будь неженкой: будь продуктивным и ориентированным на результат. 5. Будь хорошим коммуникатором и слушай команду. 6. Помоги своим сотрудникам с карьерой и развитием. 7. Имей четкое видение и стратегию команды. 8. Имей ключевые технические навыки, чтобы помочь или что-то посоветовать команде[30]. NPM Group Компания NPM Group вдвое сократила число просроченных вакансий. Раньше в ее HR-службе работали рекрутер, кадровик, менеджер по обучению. Руководители подразделений при подборе или обучении сотрудников заполняли много заявок. Руководитель не понимал, какой специалист ему нужен, или решение принимали сотрудники сразу нескольких подразделений. Если, например, нужен кладовщик на склад инструментов, то заказчиками вакансии определялись служба логистики и производственный департамент, который пользуется услугами склада. Рекрутер старался понять требования этих подразделений к кандидату. Производственникам был нужен технический специалист с отличным знанием современного металлорежущего инструмента,

логистам – любой специалист с опытом работы в складской логистике на производстве. Заказчики еще не пришли к единому мнению, но рекрутер уже начинал поиск, изучая соискателей с минимальным знанием инструмента. Дальше он выбирал подходящего кандидата, организовывал собеседования со всеми заказчиками. И если они не приходили к единому мнению после общения с кандидатом, рекрутер менял текст вакансии. В результате Agile-трансформации за каждым отделом компании был закреплен свой HR-представитель. В командах исполнителей, работающих по Скраму, эту роль выполняет скрам-мастер. Продуктом назван кадровый сервис, а члены коллектива стали внутренними потребителями. Теперь команды договариваются, что целевая группа – технические специалисты с отличным знанием инструмента. При подборе персонала заказчик планирует работу с учетом выхода кандидата точно в срок. Рекрутер снова отбирает лучших, устраивает встречу с заказчиками, назначает обсуждение – и так до тех пор, пока не закроет вакансию. За девять двухнедельных спринтов вдвое сокращено число просроченных вакансий. Простая вакансия (литейщик, слесарь-сборщик) закрывается за 20 дней, средняя (сервисный инженер, менеджер по закупкам, слесарь-инструментальщик) – за 32 дня, редкий специалист (инженер-технолог по литью пластика, технолог-программист) ищется 51 день. Уже после первого спринта рекрутеры поняли: для руководителей подразделений главное – не скорость подбора, а прозрачность сроков закрытия вакансий и время, которое они готовы потратить на подбор и обучение сотрудника. Сейчас менеджер по подбору информирует заказчика о сроках и стадии поиска кандидата. Также рекрутеры «прокачивают» технические компетенции, которые необходимы для эффективного подбора производственных вакансий, например учатся читать чертежи [31].

6.6. Agile в проектировании Руководители проектов – самые креативные профессионалы в мире; они должны предусмотреть все, что может пойти не так, пока это еще не случилось. Фредерик Харен, писатель

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

партнерских организаций, специфику корпоративной культуры участников и др., что, безусловно, слегка «деформирует» классическое использование Agile. Преамбула и постановка проблемы. По результатам проектирования и оценки стоимости строительства одной из зарубежных атомных электростанций (АЭС) заказчик выставил претензию российскому проектировщику в связи с высокой ценой строительства будущего объекта. Проектировщик согласился с претензией и пообещал дать предложение по сокращению (оптимизации) запроектированных физических объемов зданий АЭС до 50 %. Реализация такого перепроектирования включала: (1) разработку идей, гипотез и решений по сокращению; (2) разработку ТЗ на перепроектирование; (3) само перепроектирование. Первый проект полностью отвечал всем критериям гибкого проекта, поскольку подразумевал постоянные изменения и новые вводные, предполагал использование неизвестных гипотез, а также находился под пристальным вниманием заказчика. Кроме того, были и другие причины выбора Agile: ♦ необходимость очень быстрого поиска и оптимизации проектных решений (организация этого в «водопадных» форматах работы типовых проектных институтов такой скорости не давала); ♦ прогнозирование появления множества изменений и управление ими и приоритетами оптимизации со стороны заказчика, возникающими при работе; ♦ необходимость эффективного взаимодействия между проектными командами и другими проектировщиками в целом и бизнес-целями всего проекта оптимизации. Второй и третий проекты предполагалось выполнить в следующие периоды. Описание первого проекта. Первый проект по оптимизации предполагал быстрое создание эффективных гипотез по сокращению объемов, их оценку, выбор наиболее приоритетных и разработку конкретных проектировочных решений, которые потом лягут в основу проекта (2) по ТЗ на перепроектирование. Для этого проекта заинтересованными сторонами была инициирована работа Agile-команд в течение трех месяцев. Ограничениями проекта стали следующие: ♦ необходимые ресурсы проектировщиков находились в трех проектных институтах (со всеми особенностями бюрократической закрытой организации с секретностью, допусками, функциональными взаимодействиями, сложной иерархией) в трех городах; ♦ все участники до начала проекта ничего не знали про Agile и ни до проекта, ни после не имели вовлеченности в Agile и соответствующей культуры; ♦ предполагались пять параллельных направлений работы: вентиляция, конструктивы зданий, электрика, безопасность, документация и требования; ♦ подразумевалось активное участие российского и зарубежного кураторов, представляющих заказчика; ♦ планируемое решение по АЭС должно было обладать всеми необходимыми требованиями, как и предыдущий, только иметь меньшие размеры.

В проекте были сформированы пять временных выделенных групп по выбранным направлениям со своими скрам-мастерами и владельцами продукта. Было обеспечено наличие в группах всех необходимых специалистов по направлению, но не более 9-10 участников. Было сделано масштабирование (Scrum of Scrums) в виде ролей старшего владельца продукта (технического лидера) и старшего скрам-мастера (администратора). Приглашен Agile-коуч. В начале проекта проведен ориентационный обучающий семинар по Agile и особенностям его применения. Были: ♦ определены основные задачи и требования оптимизации, сформулированы позиция заказчика и цели проекта; ♦ даны базовые правила работы в Agile с учетом ограничений отрасли (безусловно, влияющих на гибкость); ♦ по результатам коротких «мозговых атак» сформулированы первые гипотезы и возможные направления оптимизации (обсуждались любые, даже самые необычные, идеи, дающие вклад в оптимизацию). Приоритет к идеям устанавливался по параметрам: величина вклада в цели оптимизации – высокая и низкая, время работы с гипотезой – малое и значительное, высокий приоритет присваивался гипотезам с высоким и быстрым вкладом; ♦ установлены сроки ближайших двухнедельных спринтов; ♦ определены важные контрольные точки всего проекта. Концепция последующей работы заключалась в запуске и организации работы всех пяти команд, каждая располагалась в своем помещении, в течение всего рабочего дня, без отвлечения на другие виды деятельности. Ответственность за результат лежала на командах в целом. По ходу работы были сделаны небольшие корректировки в составе команд. Группы при необходимости обращались к внешним экспертам, для которых обращение от группы имело высокий приоритет. Предметный ответ от экспертов должен был быть данным немедленно или поставленным в жесткий срок. Выбранные на семинаре гипотезы легли в основу первой версии журнала требований для работы на первом спринте. Были организованы оборудование, коммуникации, единый информационный центр. Каждый первый день спринтов проводилась встреча по обзору результатов предыдущей итерации, ретроспективе и построению плана нового спринта и уточнению требований. Каждое утро каждого дня спринта команды под руководством своих скрам-мастеров проводили 15-минутную летучку по определению состояния работ и уточнению плана текущего дня. В течение проекта был проведен ряд промежуточных презентаций и встреч представителей команд с зарубежными партнерами, в результате которых уточнялись вопросы по достигаемым результатам, что очень напоминало «причесывание» журнала требований. Во время итераций происходили анализ и накопление знаний, а также выработка практических рекомендаций, которые фиксировались в соответствующих предложениях и документах.

В последний день спринта проводилась встреча со старшим владельцем продукта и при необходимости с кураторами, корректировался список требований. Скрам-мастера проводили в командах короткие ретроспективы. Были зафиксированы ритм работы и автономия команд, необходимая компетентность, единый центр знаний. В течение всего проекта осуществлялось консультационное сопровождение работы команд привлеченным Agile-коучем, который одновременно осуществлял методологическую поддержку скрам-команд при выполнении работ. Срок реализации проекта составлял три месяца, начиная с установочного семинара. Использовались скрам-доски, которые позволяли отслеживать статус каждой задачи в течение итерации. Также использовались таблицы сбора фактов, которые представляли собой интерактивный список задач с исполнителями и возможностью выбора процента выполнения. Такие таблицы значительно экономили время на ежедневную актуализацию текущих задач. Был организован информационный центр для хранения и распределения информации, который создавал возможность быстрого получения информации по необходимым вопросам. В результате выполнения проекта точно в срок была достигнута основная его цель: объем зданий АЭС был снижен в значительной степени за счет сокращения количества технологических систем и оборудования, оптимизации компоновки помещений и структуры генплана, были предложены новые меры по физической защите зданий. Указанный результат был достигнут без снижения надежности и безопасности АЭС. Таким образом, показаны широкие возможности применения Agile в рамках оптимизационных работ в проектировании[32]. Пример 2. Agile в проектировании Краткая информация по объекту. Детская больница Akron (ДБА) – это самое крупное учреждение в северо-восточном Огайо, которое включает в себя две отдельные педиатрические больницы и обслуживает почти 80 отделений. В больнице обслуживается почти полмиллиона детей, подростков и взрослых пациентов в год. Больница занимает высотное здание амбулаторной хирургии и клинического ухода, 6–8 этажей. Проект стоил $200 млн. В нем участвовали компании The Boldt Company, Appleton, Wis.; Hasenstab Architects, Inc., Akron, Ohio; KLMK Group, Richmond, Va.; HKS Inc., Dallas, Texas; а также the Welty Building Company, Akron, Ohio. Преамбула. Описываемая больница стала результатом трехгодичного сотрудничества по гибкому и бережливому проектированию и строительству между строителями, архитекторами, подрядчиками, медиками, пациентами и семьями пациентов. Проектные решения как зданий, так и будущих процедур формировались при прямом участии пациентов и людей, ухаживающих за ними. Рекомендации медсестер, врачей, терапевтов, технических специалистов и родителей пациентов учитывались в значительной мере, начиная с устройства коридоров блока интенсивной терапии, защищающих личное пространство детей – жертв преступлений, и до количества розеток в блоке неонатальной интенсивной терапии.

Проект. Больница рассматривала этот проект как возможность закрепить практику гибкого и бережливого управления и придать системе необходимую гибкость, чтобы она могла реагировать на новые модели здравоохранения и изменяющиеся потребности пациентов. Проект стал намного дешевле, чем традиционные строительные проекты. На стадии его подготовки команда проектантов уже сумела сократить стоимость на $20 млн за счет сокращения проектных площадей, и затраты в ходе реализации проекта были сокращены еще на 20 %. Процесс начался с обсуждения реализуемости с учетом существующих ограничений, а затем перешел в фазу интенсивного экспериментирования по концепции параллельного проектирования, в ходе которого межфункциональная команда начинает с создания концепции и потом экспериментальным путем отрабатывает проект с точки зрения максимальной ценности и минимальной себестоимости. Больница сформировала команды по каждому отделению, которое будет располагаться в новом здании – неотложная медицина, неонатальный интенсивный уход и амбулаторная хирургия. Команды многократно встречались для картирования текущего состояния, чтобы выстроить будущее состояние, сформировать проект концептуально, перепроектировать, испытать, снова перепроектировать, чтобы уложиться в целевую себестоимость. Испытания проходили на складе за пределами города Акрон. Для имитации стен были использованы картонные перегородки, были завезены реальная мебель, оборудование и материалы. На картонных стенах были даже размещены фотографии выводов кислорода и розетки. При испытании этих полномасштабных прототипов команды делали акцент на опробовании объекта с точки зрения обеспечения работы по бережливым принципам. Команды инсценировали многие варианты событий из реальной практики с целью опробования проектных планировок и конфигураций. Были проиграны посещения больницы от поступления до выписки с участием всех действующих лиц – врачей, медсестер, родителей пациентов и других вовлеченных персон, были проведены практические процедуры. В ходе инсценировок собраны данные для оценки эффективности операций. Далее шло обсуждение проблем, например, где хранить оборудование, как наиболее комфортно организовать пребывание пациентов и родителей, как хранить материалы и восполнять запасы, как осуществлять коммуникацию, как планировать «буферную» зону при наплыве пациентов и в других чрезвычайных ситуациях. В конце 2012 г., когда команды провели окончательные испытания проекта, изначально запланированные площади удалось сократить на 10–20 % на каждом этаже, что сэкономило больнице около $20 млн прямых затрат. Кроме экономии на себестоимости, команды старались ликвидировать другие издержки и обеспечить равномерную нагрузку на все этапы процесса. Например, команда неотложной помощи зарезервировала 10 000 кв. футов площади на «срочную помощь», где «некритические» пациенты могли бы обслуживаться рядовым врачом и/или медсестрой, а не специалистом скорой помощи.

Кроме медиков-профессионалов, в межфункциональных командах участвовали представители обеспечивающих служб – ИТ, снабженцы, ремонтные службы, социальные работники, а функциональные команды также представляли сторону, отвечающую за соблюдение сроков строительства. Например, команда стройплощадки занималась вопросами допусков и решала все вопросы по территории, такие как регулирование сточных и дождевых вод. Вся эта работа координировалась генеральным графиком работ. «Когда я начала участвовать в этом процессе, я думала, что “проект здания”, “здание” – это только бетонные стены и комнаты, – говорит врач отделения неотложной помощи Мария Ремундо. – Но потом мы поняли, что создаем новые процессы в сфере оказания срочной медицинской помощи. Мы не можем строить новые отделения скорой помощи каждые десять лет, поэтому приходилось думать, как решить текущие проблемы и одновременно учесть будущие потребности»[33].

6.7. Agile в создании новых продуктов Проектное управление – это искусство создания иллюзии, что любой исход проекта является результатом запланированных, осознанных действий, когда на самом деле все зависит от случая. Гарольд Керцнер

Применение Agile в создании новых продуктов иногда очень необычно. Начнем с таких очень необычных примеров. Пример 1. Boeing Boeing 777 разрабатывался по гибким подходам; 238 команд в 17 часовых поясах, 10 000 инженеров были объединены в киберпространстве. Организован доступ к дизайнерским инструментам и процессам. Внедрены: план нулевой сверхурочной работы, еженедельные Скрамы, исключительный фокус на качестве и 3D-моделировании, быстрое принятие решений и быстрое обучение. Самолет был предварительно собран в компьютере, что позволило избежать большого количества ошибок при производстве [34]. Пример 2. Проект Agile «Многодисциплинарная оптимизация ЛА третьего поколения». Сайт проекта – http://www.agile-project.eu/. В рамках программы Европейского союза «Горизонт-2020» был инициирован проект Agile «Многодисциплинарная оптимизация ЛА 3-го поколения в рамках инновационного сотрудничества специалистов различного профиля по созданию нового самолета». Проект внедрял многодисциплинарную оптимизацию летательных аппаратов третьего поколения с улучшенными на 40 % характеристиками (по сравнению с современными воздушными судами) для большого пассажирского самолета нестандартной конфигурации через эффективное международное многостороннее сотрудничество всех разнопрофильных проектных групп 20 партнеров из Европы, Канады и России. Параллельно создавались разные конструктивные, инженерные и программные решения, которые согласовываются со специалистами и

уточняются на последующих итерациях[35]. Пример 3. Программа CubeSat Программа CubeSat, спонсируемая NASA, позволила университету Джона Хопкинса создать два небольших спутника для использования в качестве дополнительных миссий других космических запусков. Спутники должны быть стандартизированных размеров и массы, которые позволяют сделать эти дополнительные миссии недорогими. В программе задействовались небольшие, производительные, работающие вместе команды, инкрементное тестирование, короткие итерации. Команда подсистемы имела прямой контакт с NASA, что позволило быстро принимать решения. Спонсор участвовал в основных обзорах и представлял отзывы, часто участвовал в личных встречах и в совещаниях по вопросам статуса. Менеджер программы также имел полномочия вносить любые изменения, необходимые для успеха системы. Использовалась концепция «построить немного, немного протестировать и многому научиться». Тестирование проводится мелкими шагами. Документация была минимальной. Закупка некритических деталей осуществлялась с учетом сроков и наименьших затрат. Критические детали, требующие высокой точности, были изготовлены на сертифицированных NASA производственных мощностях университетов. Ежедневные обзоры команды проводились перед вариацией скрам-доски. Доска наглядно продемонстрировала, с какой скоростью продвигается каждый программный элемент. А теперь менее масштабные примеры. Пример 4. Проект WIKISPEED В проекте была поставлена задача создать суперэкономичный автомобиль нового поколения с модульной конструкцией и доступной ценой для обычных людей и дорог, который будет потреблять 2 л на 100 км. Джо Джастис, автор проекта, выступил экспертом, так как незадолго до этого участвовал в разработке ПО для учета автомобилей. Его команда взялась собрать новый автомобиль. Участники узнали общие требования: обычная комплектация машины, комфортная для каждого, а также дополнительные требования – все необходимое для «быть пригодным к езде по обычным дорогам». Одной из проблем проекта стала распределенность команды. Однако было много инструментов, которые обеспечили ей общую среду общения: YouTube для записи демонстрации, Google Docs, онлайн-доски задач, сервис конференц-звонков и общая e-mail-рассылка на команду. Это позволило распределенной команде волонтеров чувствовать себя так же, как скрам-команда, сидящая в одной комнате. Одним из обязательных условий была прозрачность всех обсуждений и документов. Даже если они создавались «другими» командами, каждый мог посмотреть материалы соседей. Стоит добавить и большую автономность принятия решений у команд, которые работают над созданием тех или иных частей машины. В проекте участвовали 44 человека из четырех стран. Все они были волонтерами, для которых проект WIKISPEED был хобби. Все команды WIKISPEED работали по адаптированному Скраму. У них были спринты-

итерации и небольшие команды, которые фокусировались на улучшении тех или иных параметров автомобиля. В течение итерации команды ежедневно синхронизировались и активно общались. А в конце итерации собиралась новая версия автомобиля. Члены команды вместе смотрели на полученный результат и обсуждали, что можно улучшить как в продукте, так и в их способе работы над ним[36]. Принципы экстремального производства Реализуя вызов в проекте WIKISPEED и имея опыт Скрама и XP, Джо Джастис описал набор принципов экстремального производства (Extreme Manufacturing, XM), который стал известен многим и применяется, например, в Boeing и John Deere. ✓ Оптимизируйте изменения. В проекте WIKISPEED дизайн автомобиля может меняться каждую неделю за счет использования картирования потока создания ценности (value stream mapping) для уменьшения разнообразия вариаций продукта и оптимизации загрузки производственной линии на основе данного потока. Это позволяет снизить и стоимость изменений в продукте. ✓ Модульная архитектура. Автомобиль WIKISPEED был сконструирован из восьми модулей с простыми интерфейсами между ними. Благодаря такой архитектуре можно изменять модуль подвески с минимальными усилиями. ✓ Разработка через тестирование. Была создана модель для прогнозирования расхода топлива и определены более 100 известных параметров, которые помогли прогнозировать расход топлива автомобиля. Кроме этого, на основе фактических данных была создана цифровая модель симуляции краш-тестов вместо реальных тестов, которая устроила регулирующие органы. ✓ Взаимосвязи раньше элементов. Автомобиль включал восемь модулей: кузов, шасси, двигатель, подвеску, салон и т. д. Команда проекта разработала способы взаимодействия (интерфейсы) между этими модулями. ✓ Итеративная разработка элементов. Некоторые решения в рамках спринтов заменялись картонными коробками нужных размеров (но с полной гарантией, что решение войдет в эту коробку). ✓ Agile-паттерны материального производства. Гибкие шаблоны для адаптации элементов. ✓ Непрерывная интеграция. Максимальная автоматизация тестов, тесная взаимосвязь между этапами создания продукта и его производством. ✓ Непрерывная поставка. Использование гибкой линии массового производства различных продуктов, их модификаций в течение семидневного спринта за счет аддитивных технологий или оборудования для быстрого прототипирования. ✓ Координация команд. Применяется Scrum of Scrums. Скрам-команды состоят из пяти человек, включая владельца продукта и скрам-мастера. Каждый владелец продукта несет ответственность за «вытягивание» элементов из журнала требований портфеля, а также за получение командой ясности в том, что нужно создать, почему это ценно клиенту, и о влиянии данного элемента на показатель NPV. Эта ясность исходит от главного владельца продукта (Chief Product Owner, CPO), который постоянно

упорядочивает и уточняет журнал требований портфеля. CPO доступен для того, чтобы поддерживать готовность команды к работе, отвечать на ее вопросы и иметь наиболее четкое представление о видимой для клиента ценности, которую намеревается создать журнал требований портфеля. Скрам-мастер отвечает за увеличение скорости работы команды (объем работы, выполняемой в течение спринта). Скрам-мастера сотрудничают со скрам-мастерами других команд для согласования общих ресурсов: пространства, оборудования, инструментов и модулей продукта – между командами. Отсутствие ясности или объема работ устраняется владельцем продукта. Отсутствие у команды понимания тренда, своей производительности/качества создаваемого продукта/уровня вовлеченности и препятствия, связанные с ограниченными ресурсами и их координацией между командами, устраняются скрам-мастером[37]. «Сен-Гобен СНГ» В компании «Сен-Гобен СНГ» в центральном офисе была сформирована Agileкоманда, которая стала заниматься разработкой новых продуктов и сервисов. В качестве командопостроения эта команда даже собственноручно сделала ремонт в своей Agile-комнате. Эрван Дюпюи, московский офис «Сен-Гобен СНГ»

6.8. Agile в НИОКР/ОКР Предположения – мать всех проколов. Из книги «97 вещей, которые должен знать каждый»

Существует естественная и прямая связь между НИОКР/ОКР и гибким проектным менеджментом: ♦ любой результат проектов НИОКР/ОКР имеет сверхуникальный характер; ♦ каждая разработка характеризуется очень большими рисками; ♦ в каждой разработке так или иначе возникает своя временная команда со своим лидером; ♦ степень предсказуемости конечного результата крайне низкая, конечный результат в научной и творческой деятельности неизвестен в принципе; ♦ много вариантов, когда стартовая постановка задачи неэффективна, тупикова, некорректна или даже ошибочна; Agile в действии Возможности Agile в командах разработки новых механических продуктов были продемонстрированы в офисах компании Marel в Исландии, где команда, разрабатывая новый продукт, начала использовать Скрам. Эксперимент длился семь месяцев, и к концу его команда решила продолжить применение фреймворка. Коман да состояла из трех типовых ролей Скрама, вела все события и применяла большинство артефактов.

В случае компании SAAB EDS в проектах, связанных с новыми разработками, также использовалась кросс-функциональная команда. В компании Andritz Hydro в Швеции с задействованием некоторых идей и концепций Agile и Scrum была преобразована полная организационная структура [38]. В дивизионе «Северсталь Российская сталь» новые виды продукции также разрабатываются при помощи Скрама. Кросс-функциональная команда, состоящая из сотрудников разных подразделений, создает более прочную и пластичную упаковочную ленту для плоского проката [39]. ♦ этапы вывода на рынок нового инновационного продукта (от поиска идеи до пилотного экземпляра) характеризуются высокой волатильностью (изменчивостью). Именно в таких условиях методы Agile являются эффективным инструментом управления проектом. Борьба с малой предсказуемостью ведется с помощью итерационного процесса, проект разбивается на микропроекты. После завершения итерации может происходить возврат в начальную точку, где проводится пересмотр плана проекта, цели и объема работ. Пересмотр выполняется в виде совещаний, мозговых штурмов с приглашением представителя заказчика. Чем больше точек пересмотра, тем качественнее получается результат. Agile в НИОКР/ОКР-проектах реализуется в небольших коллективах в различных организационных решениях: в больших компаниях, как выделенный проект, в небольшой частной компании, в группе при вузе и т. п. В таких решениях деятельность определяется индивидуальными способностями лидеров и группы, что создает условия для гибкости.

6.9. Agile в медицинской отрасли Медицина – одно из величайших заблуждений человечества. Мольер

Подход к гибкому управлению проектами и совершенствованию процессов может помочь медицинским группам и организациям здравоохранения повысить качество, безопасность, эффективность, улучшить управление изменениями и активизировать внедрение новых систем или процессов. Agile может служить больницам, системам здравоохранения и медицинской практике в качестве еще одного потенциального инструмента наряду с Lean, Six Sigma и др. Agile полезен для проектов в медицинской отрасли, когда: ♦ потребность или цель конкретны и измеримы, но команда не полностью понимает, как их решить или достичь. Например, цель может быть такой: «Новый подход к утилизации снизит количество претензий в два раза в течение двух месяцев с момента его внедрения»; ♦ команда видит в проекте большую область неопределенности, которую можно снизить пошагово, тестируя или экспериментируя. Если цель озвучена

как «нам не хватает пациентов» или «кто наш клиент?», то пути решения точно будут пока неопределенными; ♦ надо, чтобы заинтересованные стороны проекта максимально участвовали в разработке решения; ♦ нужна оценка влияния альтернативных решений; ♦ нет четкой даты окончания и есть время на «обнаружение» решения путем пошаговых итеративных действий. Agile в варианте спринтов позволяет не тратить время на работу, которая не добавляет ценности. Результаты шагов и компоненты процесса валидируются заинтересованными сторонами на сессиях по сбору обратной связи. Не надо делать формальные запросы на изменения. Не надо тратить время на полное планирование. Не нужно принимать все решения вначале. Agile обеспечивает максимальную бизнес-ценность при ограничениях по времени и стоимости. Использование гибких методов для улучшения ухода может также помочь медицинской практике укрепить доверие своих учреждений к ним как к группе, которая обеспечивает ценность, зная, как реагировать на потребности быстро меняющейся среды и адаптироваться к ним. Однако в медицине есть некоторые ограничения: ♦ Agile требует значимого участия заинтересованных сторон (врачей, органов здравоохранения, пациентов, персонала); ♦ поскольку обычно проект ведется в области высокой неопределенности, в начале невозможно сказать, что получится в результате; ♦ Agile требует сильной команды экспертов в предметной области. Медицинские компетенции часто узко сфокусированы; ♦ в здравоохранении обычно нет никого, кто тренирует команду по Agileпрактикам; ♦ команда требует опытных членов команды с высоким уровнем профессионализма и Т-компетенциями. Управленческие навыки в медицинской среде не очень широко распространены. Обзор 60 статей, опубликованных в 2015 г. в International Journal of Health Care Quality Assurance, показал, что Agile может служить управленческим принципом для улучшения здравоохранения. В документе 2017 г. шведского Каролинского института утверждается, что Lean и Agile могут использоваться наряду друг с другом в виде дополнений, при этом Lean помогает повысить эффективность и контролировать затраты, а Agile позволяет организациям гибко реагировать на изменения, в том числе спроса. Agile в медицине 1. AAMI (Ассоциация содействия развитию медицинской техники) работает над новым руководством, чтобы связать Agile и медицинский стандарт IEC 62304 (стандарт медицинских изделий, конкретизирующий требования к ПО). Разработчикам в Agile надо часто тестировать свои продукты, но во многих случаях доступность оборудования ограничена, да и лаборатории неудобны разработчику, работающему за своим столом. В этом случае можно

использовать хорошо работающий симулятор самого оборудования, предлагаемый многими операционными системами реального времени: http://www.aami.org. 2. Итеративный и совместный процесс, который позволил медсестрам и врачам совместно думать и говорить о приобретаемых в больнице инфекциях и гигиене рук, привел к разработке клинически значимых решений для улучшения гигиены рук в операционной в шведском исследовании 2018 г. [40] 3. Руководители медицинских организаций создают, обновляют и постоянно совершенствуют процессы в соответствии с моделью «тройной цели», где главные приоритеты – обеспечение надлежащего уровня и качества ухода за пациентами; лучшее понимание, изучение групп пациентов и участников плана здравоохранения и оптимизация затрат на оказание медицинских услуг и помощи. Эти приоритеты сосредоточены на эффективности процессов и результатах управления здоровьем пациентов, руководители здравоохранения учатся и внедряют бережливые и гибкие методологии, которые сосредоточены на понимании и повышении ценности для клиентов, что означает акцент на ценности как для пациентов, так и для поставщиков услуг. В ссылке ниже предлагаются рекомендации для руководителей здравоохранения по применению Agile как основы для поддержки клинических и/или операционных проектов по улучшению процессов. Предлагается эффективная платформа для организации и управления проектами по улучшению процессов, особенно в сочетании с подходом к реинжинирингу прототипов [41]. 4. Компания Buurtzorg, по видению ее директора и сооснователя Йоса де Блока, опытного медика с управленческой подготовкой, создала модель управления, целью которой стал целостный, основанный на соседстве подход к предоставлению услуг и создание автономности пациентов через обучение самообслуживанию и профессионализм медсестер. Самоуправляемые команды из 10–12 хорошо обученных медсестер берут на себя ответственность за все аспекты ухода за 50–60 пациентами в заданном районе. Команды работают с пациентами и их семьями, оказывают медикосанитарную помощь и удовлетворяют их потребности, помогая им сохранить или восстановить свою самостоятельность. Внедрены ИТ-системы для онлайнпланирования, ведения документации по уходу, выставления счетов. Есть коучи, доступные для решения проблем каждой команды, и небольшой бэкофис, занимающийся административными вопросами. Медсестры отвечают за весь спектр услуг по уходу на дому: оценивают состояние пациентов, составляют и осуществляют планы ухода, предоставляют услуги или планируют медицинские посещения по мере необходимости, а также создают документацию, необходимую для обеспечения непрерывного ухода и выставления счетов. Buurtzorg собирает информацию об удовлетворенности пациентов по окончании курса лечения (в дополнение к обследованию пациентов, проводимому Министерством здравоохранения). Современная ИТ-система позволяет планировать, вести документацию сестринских оценок и услуг, а также выставлять счета, обмениваться информацией внутри и между командами. Для решения проблем доступны коучи, а не менеджеры. В начале 2015 г. было 15 коучей для 700 команд. Аренд Ян Цварт, коуч Buurtzorg, сказал, что большинство его работы –

это помощь команде, а не советы о лечении пациентов. Медсестры не отчитываются перед менеджерами, хотя их рабочие часы отслеживаются. Небольшой бэк-офис (менее 50 человек в начале 2015 г.) выполняет такие функции, как администрирование заработной платы, заключение контрактов для команд, финансовые вопросы. По профсоюзному соглашению медсестры получают зарплату в соответствии с их уровнем образования, со стандартным ежегодным повышением и бонусами, основанными на годах работы в Buurtzorg. Доходы направлены на обучение медсестер, командные проекты для улучшения здоровья сообщества, а также для организационного развития. Использование саморегулирующихся команд обеспечивает гибкость в организации работы, что приводит к удовлетворению и медсестер, и пациентов. Например, шесть медсестер из команды в голландском городе Хааксберген (около 19 000 человек, в нескольких милях от Алмело) работают от 16 до 24 часов в неделю (хотя обычно медсестры работают 32 часа). Две медсестры разделяют ответственность за 6–8 пациентов, посещая их в основном по утрам и вечерам. Раз в две недели группа собирается для рассмотрения кейсов пациентов, обсуждают дела и проблемы. Они разделяют небольшое офисное здание с другой командой. Две другие команды Buurtzorg, одна из которых специализируется на пациентах с деменцией, работают в комьюнити[42].

6.10. Agile в маркетинге Гибкость поможет завершить сложные и запутанные процессы. Мэтт Блумберг, исполнительный директор SaaS-компании Return Path, запись в блоге

Из «Википедии»: Agile-маркетинг (англ. Agile marketing – «гибкий маркетинг») – метод гибкого планирования маркетинговых стратегий, который заключается в отказе от классических долгосрочных планов по освоению маркетингового бюджета в пользу коротких итераций и возможности внести изменения в стратегию в любой момент времени. Сначала использовался термин A4M – «Agile для маркетинга». Потом стал использоваться Agile-маркетинг как приложение философии и ценностей Agile к стратегии и тактике маркетинга для удовлетворения потребностей клиентов и решения их проблем и трудностей. При долгосрочном планировании не удавалось оперативно реагировать на изменение интересов потребителей, поэтому Скотт Бринкер обратил внимание на Agile-методы и, переосмыслив их, первым сформулировал идеи для манифеста Agile-маркетинга, итоговая версия которого была создана участниками конференции SprintZero в 2012 г. – The Physics of Agile Marketing – и там же представлена. ♦ Обучение, аналитика, тестирование вместо мнений, условностей или догадок; как можно чаще непрерывное исследование клиента, внедрение нужных изменений и измерение результатов.

♦ Сотрудничество, ориентированное на клиента, работа в команде вместо иерархии; во главе угла – клиент и его потребности; на их удовлетворение нацелена работа всех отделов и департаментов, в итоге нет соперничества и внутренних конфликтов. ♦ Адаптивные, гибкие, недорогие и итерационные маркетинговые кампании вместо объемных, сложных или крупных, с оперативным внедрением новых рекламных инструментов. Если после проведения итерации выявляется потребность внести изменения в план, это можно сделать сразу. ♦ Постоянное изучение и исследование клиентов вместо статического прогнозирования, регулярная аналитика. Как изменились потребности клиентов за последнее время? ♦ Гибкое планирование вместо жесткого. Предпринимайте действия, исходя из только что полученных результатов. Agile-маркетинг не отказывается от планирования полностью. Но составленные в его рамках планы предполагают внесение изменений. ♦ Реакции на изменения вместо следования плану. Не бойтесь менять тактические планы. Если произошло изменение, его не нужно игнорировать. К изменениям нужно быть готовыми и при их возникновении обязательно вносить корректировки в первоначальный план. ♦ Много маленьких экспериментов вместо одного большого. Импровизируйте на разных площадках, замеряйте результаты и продолжайте вкладываться в лучшие инструменты. Лучше провести несколько небольших тестирований – их результаты будут актуальнее, чем у глобального исследования, которое проводится в течение длительного времени. Принципы Agile-маркетинга таковы. ♦ Важнейшая задача и главный приоритет – делать клиента довольным. Для этого необходимы постоянное сопровождение процесса и оперативное устранение ошибок и возникающих проблем. ♦ Приветствуются изменения и их планирование. Готовность быстро реагировать на изменения – это основное конкурентное преимущество. ♦ Выпускать маркетинговый план нужно часто, в сроки от пары недель до пары месяцев, но чем чаще – тем лучше. ♦ Хороший маркетинг получается тогда, когда исполнители, продавцы и покупатели приходят к согласию. ♦ Создание маркетингового плана вокруг мотивированных людей. Предоставление им необходимой поддержки и обстановки, чтобы они могли делать свою работу. ♦ Обучение, анализ реакции клиентов и их отзывы – это самая важная оценка прогресса. ♦ Соблюдение постоянного темпа работы и в то же время необходимые доработки или исправления. ♦ Отсутствие боязни ошибиться, стремление не повторять одну ошибку дважды. ♦ Постоянное внимание к основам маркетинга и грамотному дизайну, что повышает гибкость.

♦ Простота – основа всего. Примеры 1. Компания Return Path специализируется в области мониторинга и анализа трафика электронной почты. Компания анализирует больше информации об электронной почте, чем любая другая, и применяет эти данные для создания решений, гарантирующих получение пользователями только нужных и ожидаемых сообщений. Компания создала для себя гибкий план из шести релизов. На каждый выделялось по 1–2 главные темы и 2–3 недели времени. Команда маркетологов проводила ежедневные летучки, чтобы на ходу корректировать процессы. 2. В 2013 г. в Новом Орлеане во время Супербола (финал Лиги американского футбола, главное спортивное событие года в США) произошло отключение электроэнергии. Компания Oreo, производитель темного печенья с белой прослойкой, мгновенно отреагировала роскошным твитом: «Нет света? И не надо. И в темноте можно пожевать». 3. Aviasales работает на результат, а не ради процесса, рационально общается с пользователями, не любит слово «бюджет» и постоянно экспериментирует, сравнивая показатели тестов. В маркетинге можно начать с составления списка срочных и важнейших задач (аналог журнала требований). Команда маркетологов фокусируется на небольшом верхнем участке списка требований и на их выполнение выделяет спринт. Команда целиком отвечает за всю работу. Вызовом для многих станет умение выходить за рамки своей специальности, чтобы помочь команде выполнить задание спринта. Интернет-маркетолог c Т-образной компетенцией имеет обширные базовые знания по многим смежным дисциплинам, а также глубокие знания, опыт и возможности в одной или нескольких сферах маркетинга. Скрам-мастер (или администратор) следит за командой и корректирует ее работу. Он должен быть способным организовывать все ритуалы Скрама и контролировать, чтобы все шло правильно. Иногда скраммастер – это сам маркетолог, являющийся при этом хорошим организатором и знающий, как добиться поставленной цели. Директор по маркетингу, руководитель отдела или менеджер по продукту может ежедневно присутствовать на рабочем месте, чтобы анализировать работу команды и обеспечивать ее выполнение в духе первоначальной стратегии. В конце спринта он проводит демонстрацию итогов, потом скраммастер организует ретроспективу. Выводы и итоги помогут отбросить шаги, которые не привели к успеху. Лидогенерация Американское агентство IMPACT благодаря гибкому подходу в маркетинге для компании ReQuire увеличило лидогенерацию на 84 % за пять месяцев. Этого удалось добиться за счет постоянного обновления сайта, ведения блога и анализа полученных результатов[43]. Справка. Лид (lead, целевой лид) – потенциальный клиент, так или иначе отреагировавший на маркетинговую коммуникацию. Лидогенерация (англ. lead

generation) – маркетинговая тактика, направленная на поиск потенциальных клиентов с определенными контактными данными. 1. Дорожная карта (рис. 6.3) фокусируется на наиболее важных целях компании и отражает задачи команды на год. В ней также излагается стратегия достижения целей. Период планирования любой, но обычно 6–12 месяцев. Дорожная карта – важнейший артефакт для внутренних заинтересованных сторон компании, участвующих в процессах ее планирования и анализа.

Рис. 6.3. Дорожная карта Команда ежеквартально пересматривает карту и отражает в ней новую информацию, тенденции, непредвиденные проблемы или возможности, изменения в приоритетах и остальное, что влияет на бизнес. 2. Темы помогают расставить задачи в порядке приоритетности в зависимости от целей и определяют, как будут распределяться ресурсы. Вариант набора тем для команды Agile-маркетинга: ✓ трафик (20 %); ✓ лиды (50 %); ✓ продажи (30 %). Проценты указывают на то, сколько усилий команды должно быть направлено на тему исходя из целей. Если нужно Х % лидов, а с трафиком и конверсиями продаж все хорошо, тогда больше внимания уделяется теме лидов. Вместо работы над десятью статьями для блога копирайтер лучше сосредоточится на создании электронной книги для повышения конверсии. Если в следующем квартале коэффициент конверсии (conversion rate) вырастет, а продажи не изменятся, то можно изменить проценты и направить усилия на улучшение показателей продаж. 3. Дорожная карта состоит также из ряда стратегических инициатив, которые представляют собой тактики для реализации стратегии. Каждая инициатива подобна отдельной кампании или проекту. Это могут быть проекты по редизайну сайта, кампании контент-маркетинга или кампании в социальных сетях. Период планирования для инициатив – обычно 1–3 месяца.

4. Большинство маркетинговых тактик представлены эпиками – периодами или проектами, во время которых создается конечный продукт с определенной бизнес-стоимостью, например новый дизайн целевой страницы, который увеличивает коэффициент конверсии на 200 %. Период планирования для эпики – не больше месяца. 5. Эпики, в свою очередь, разбиваются на истории – конкретные задачи, выполняемые исполнителями во время спринта. Например, если целью эпики является создание нового оффера, то можно разбить ее на следующие истории: копирайтинг, дизайн макета, настройка конверсионного пути, публикация, продвижение. Каждая история соответствует набору задач. 6. В IMPACT как внутренние, так и клиентские спринты длятся 1–2 недели, это наиболее оптимальный период времени, чтобы успеть все сделать и при этом не «сгореть» на работе. 7. Статус «Готово». Владелец продукта должен четко определить, как должна выглядеть история, чтобы ее можно было считать выполненной. В IMPACT имеется двухступенчатый процесс приемки результатов работ для клиентов. Первоначальный исполнитель завершает историю и передает ее на проверку другому. Если этот рецензент отмечает, что все готово, он передает ее владельцу продукта для оценки со стратегической точки зрения. Только владелец продукта может назвать что-то выполненным. Двухступенчатая приемка гарантирует высокое качество. Пример процесса приемки целевой страницы электронной книги: исполнитель создает конверсионный путь целевой страницы и передает ее на проверку другому члену команды. (Справка о конверсии: https://lpgenerator.ru/blog/2012/03/06/konversionnye-puti-celevye-stranicy-novogopokoleniya/.) Внутренний рецензент следит за тем, чтобы все было сделано правильно с технической точки зрения, проверяет текст на ошибки. После этого он передает целевую страницу владельцу продукта, который проверяет ее, смотрит, чтобы текст и изображения согласовались друг с другом и способствовали конверсиям. Если все отлично, он помечает это выполненным и готовым к использованию. Любопытная статистика: ✓ Agile-маркетинг улучшает выполнение бизнес-процессов. Повышается не только уровень производительности, но также гибкость и внимание к потребностям клиентов; ✓ 93 % директоров по маркетингу, внедривших Agile-методологии, заявляют об ускорении вывода на рынок своих идей, кампаний и продукции (Forbes, 2014 г.); ✓ 80 % директоров по маркетингу, использующих Agile-подход, повышают гибкость выполнения работы (CMO.com); ✓ Agile-маркетинг улучшает мотивацию сотрудников. Совместная работа в команде и ответственность участников друг перед другом способствуют повышению морального духа и уровня мотивации и в результате усиливают удовлетворенность сотрудников своей работой;

✓ 87 % директоров по маркетингу отметили рост продуктивности в команде после перехода к Agile-маркетингу (Forbes, 2014 г.)[44]. Мэтью Стибб, генеральный директор компании Articulate Marketing, приводит секреты Agile-маркетинга[45]. ♦ Парное программирование, подразумевающее работу программистов в паре, в Articulate Marketing используется так же. Двух специалистов назначают для написания интервью или статьи: один пишет текст, а второй вносит правки. Роли часто меняют при выполнении разных частей поставленной задачи. ♦ Планирование делается на основе интенсивной, но 40-часовой рабочей недели, даже нужно сказать «нет» неожиданным жестким срокам заказчика. Авральная работа снижает продуктивность и качество. ♦ Клиенту предлагают сотрудничать и описывать свое видение результата. Маркетологи оценивают стиль, оригинальность и тему статьи, а не время, которое понадобится для ее написания. Не используют табелей рабочего времени, а оценивают конечный результат. ♦ Летучки проводят в начале недели; когда люди стоят, они стараются говорить как можно меньше и по делу!

Пример 1. Скрам-работа PR-агентства Заказчик хочет провести через два месяца масштабное мероприятие для своих партнеров и медиа. Услуги по организации мероприятия он заказал у PRагентства. Заказчика представляет PR-менеджер, который отвечает за организацию мероприятия с его стороны (владелец продукта). Со стороны PRагентства за организацию мероприятия отвечает аккаунт-менеджер (скраммастер), в подчинении которого находится команда. На планировании спринта заказчик и агентство решают, что они будут отчитываться-планировать каждые две недели (спринт). На первый спринт запланирован список задач (журнал требований спринта), однако команда оценила, что не все из этого списка они успеют выполнить. Тогда PR-менеджер (владелец продукта) приоритизирует задачи и выделяет наиболее приоритетные на ближайшие две недели. Команда берется за выполнение заданий. На момент планирования первого спринта также спланирован весь список заданий на два месяца (журнал требований продукта), чтобы не получилось так, что к моменту проведения мероприятия что-то не выполнено[46]. Agile в Zara Zara научилась проверять прототипы моделей на рынке циклом в один день и выводить новые коллекции с итерациями в две недели. Там же частично внедрили Agile для удаленных точек продаж, что привело к увеличению продаж, поскольку консультантам дали возможность гибко реагировать на запросы клиентов и так же гибко пытаться их удовлетворить. Фактически их увели от жесткого следования процедурам и перенацелили на результат. Zara использует Agile и при открытии новых магазинов, так как каждый проект уникален. Пример 2. Компания «Биг джек», event-бизнес

После исследования, выявившего девять основных претензий заказчиков к event-агентствам, компания объединила эти претензии в три смысловых блока: клиентоориентированность, контроль и качество. Для решения претензий был применен Agile. Гибкость. Проект делится на итерации в одну неделю. Ежедневно оперативно обсуждается: что сделали вчера; что будем делать сегодня; что мешает. Возникла сложность – сразу решается. На встрече в конце итерации обсуждается: что сделали; что сделали хорошо; что и как можно улучшить. Во время итерации и после вносятся коррективы и совершенствуется процесс. При планировании итерации клиент также вносит комментарии. Решены претензии к отсутствию клиентоориентированности, проблемам с гибкостью и замалчиванию проблем перед клиентом. Если, например, клиент захотел увеличить продолжительность мероприятия, вся команда узнает об этом сразу и может скорректировать работу. Контроль. Для соблюдения жестких сроков используется Client Project Systematization (CPS) – план подготовки и реализации проекта, привязанный к календарю. В CPS прописаны ключевые блоки работы, такие как бюджет, предварительное вовлечение, документооборот. Все делится на мелкие задачи: представить договор на согласование, согласовать, подписать. По каждой задаче прописывается ответственный на стороне клиента или агентства. В столбцах указываются месяцы и даты, а на пересечении строки и столбца – редлайны и дедлайны. Так решились претензии к несоблюдению сроков, невнимательности к деталям и неспособности менеджеров принимать рабочие решения. Оперативность. Используются чаты в WhatsApp и Telegram. Так была решена претензия к тому, что менеджеры медленно реагируют на сообщения. Качество. Для оценки эффективности проектов используются KPI: индекс вовлеченности сотрудников; коэффициент окупаемости инвестиций (ROI); индекс привлекательности работодателя; индекс потребительской лояльности (NPS). Появился бизнес-показатель, чтобы оценить качество проекта. Можно сравнивать, как меняется NPS из года в год у новогоднего корпоративного праздника. Измерить NPS мероприятия можно с помощью бесплатного сервиса Surveymonkey. Участникам по почте высылают онлайн-ссылку на опрос, анонимность обеспечивает откровенность. Задаются вопросы об элементах праздника. Так можно в будущем исправить ошибки. Это избавило от претензий к отсутствию стандартов качества и отсутствию критериев объективной оценки результатов мероприятия. Результат. Стало больше заказов, треть из них поступает по рекомендациям[47]. В заключение приведу пару интересных источников: ♦ «Взлом маркетинга» Скотта Бринкера (Hacking Marketing: Agile Practices to Make Marketing Smarter, Faster and More Innovative. March Wiley 21, 2016); ♦ «Agile-маркетинг. Как сочетать гибкие подходы с традиционными практиками» Роланда Смарта.

6.11. Agile в госуправлении

Планы – бесполезны, планирование – бесценно. Дуайт Эйзенхауэр

В госуправлении Agile пока преимущественно применяется в рамках проектов по цифровизации, например при разработке порталов, сервисов и т. п. Иные виды использования пока малоэффективны или малоизвестны. Agile в госуправлении 1. Министерство юстиции США – разработка унифицированного портала justice.gov. К 2014 г. сайт justice.gov вырос из простой веб-страницы в крупный портал из 450 000 веб-страниц, документов и медиафайлов. Стоимость поддержки постоянно росла. Портал поддерживался 100 различными офисами министерства со своими технологиями, подходами и процессами. Проектная команда применила для работы Скрам, разбив весь проект на 1700 пользовательских историй, которые реализовывались в 12 основных релизах. В первом релизе была представлена система управления контентом сайта и только одна из 120 секций портала. Первая версия портала (MVP) была реализована точно за четыре месяца и в рамках бюджета. Каждый последующий релиз включал в себя больше функциональности и был реализован в более короткие сроки. 2. Правительство Великобритании – разработка единого портала госуслуг gov.uk. Основой стратегии развития правительства стала цифровая трансформация, для поддержки которой требовались новые инструменты взаимодействия с гражданами. Модернизацию существующего портала госуслуг нужно было произвести быстро и в рамках выделенного бюджета. Используя Скрам, весь объем работ разбили по спринтам, в конце каждого из них был готов результат. Так появились GOV.UK alpha, GOV.UK beta и, наконец, GOV.UK. Проект по созданию портала сопровождался обширными коммуникациями с гражданами, чтобы сделать его максимально удобным и полезным для них. 3. Агентство Дании по делам предпринимательства. Деятельность Агентства сводится к ведению учета компаний, работающих в Дании. Численность штата – около 600 человек. Они участвуют: ✓ в регулировании правил бухгалтерского учета и аудита, отслеживании движения средств; ✓ регулировании денежных переводов в финансовой системе; ✓ стимулировании создания новых компаний и сборе данных о коммерческой деятельности; ✓ регулировании сектора телекоммуникаций. Для улучшения качества госуслуг была запущена программа внедрения цифровых технологий. Одной из главных задач было возобновить процесс разработки цифровой системы регистрации компаний. Для реализации

программы была необходима методология, позволяющая создавать и испытывать новые системы всего за несколько недель, а не месяцев, и учитывающая пожелания «заказчиков». Рабочая группа решила использовать Agile. В результате была разработана своя разновидность адаптивной методологии на основе таких важных составляющих, как: ✓ ориентированность на клиентов; ✓ эффективная система управления и быстрое принятие решений; ✓ ИТ-архитектура, позволяющая постепенно внедрять изменения в системе; ✓ четкий план действий по развитию систем, включающий ряд небольших, легко реализуемых проектов; ✓ организационная структура, отвечающая требованиям адаптивной методологии и поддерживающих ее процессов; ✓ аутсорсинг с привлечением сразу нескольких партнеров (не одного или двух); ✓ культура доверительных отношений. В итоге это существенно повысило эффективность регистрации компаний в Дании, оптимизировав задачи и количество процессов, введя цифровую отчетность, обучение. До внедрения использовалось множество процессов с комбинациями более чем из 100 экранов с информацией, создание дел занимало 11 экранов, требовалось более 100 вручную выбираемых дел, применялся ввод информации с бумажных документов с последующей проверкой данных, несколько систем отчетности, обучение работе с делами занимало несколько месяцев. После внедрения количество процессов свелось к 15 экранам, создание дел стало одним процессом, как и ведение реестра, дела стали вестись автоматически, проверка информации ведется конечным пользователем, заработала одна централизованная система отчетности, обучение работе с делами свелось к неделям и даже дням [48]. Информационная служба штата Вашингтон В информационной службе штата были сформированы команды и снесены внутренние стены в помещениях. Майкл де Анджело, заместитель директора службы, говорит, что они стараются каждую неделю снабжать учреждения штата пригодными для использования практическими директивами. «Мы постоянно дорабатываем процесс предоставления своих инвестиционных планов на рассмотрение учреждениями. Наша цель – каждую неделю что-то менять. Мы используем пошаговый подход. Еженедельно мы выдаем потенциально готовый к поставке продукт, который учреждения могут опробовать на практике. Представители учреждений действительно видят чтото реально сделанное. “Готовый к поставке продукт” в их случае означает некие изменения в директивах, которые могут быть применены на практике. Это не обязательно должно быть нечто материальное. Важно, чтобы это было что-то создающее ценность». Служба активно занимается внедрением Скрама во все бюрократические системы штата. Они начали с себя, чтобы показать пример всем госслужбам[49].

6.12. Agile в компании Если ты не можешь описать то, что ты делаешь как единый процесс, ты не знаешь, что ты делаешь. Уильям Эдвардс Деминг

Кроме Agile в процессах, крайне интересно его применение в части бизнеса или во всей компании. В недавнем опросе 4452 пользователей Scrum Alliance более половины респондентов сообщили, что их организации используют Скрам не в ИТ-направлениях. В список вошли разработки продуктов (11 %), операционный менеджмент (3 %), продажи и маркетинг (2 %) и даже работа руководителей высшего звена (1 %) (22). Респонденты, работающие в ИТотрасли в этом исследовании, сообщили об успешности 63 % проектов; представители не ИТ-применений рассказали о 59 %, что практически приравнивает успех Скрама в обоих направлениях. IKEA IKEA – это компания, где: ✓ сотрудники приветствуют друг друга объятиями и похлопываниями руками по спине; ✓ сотрудники становятся почти «одной семьей», и когда, покидая компанию, люди встречаются вновь, то они также обнимают друг друга, поскольку сохраняют доверие, связи и контакты на долгие годы; ✓ каталог – это основной действующий инструмент продаж в течение уже многих лет; ✓ три постоянных канала сбыта, через которые покупатель может приобрести продукцию IKEA: магазины-склады, веб-сайт компании, заказ покупок по телефону; ✓ особое отношение к посетителям магазинов, где вы никогда не будете раздражены навязчивыми менеджерами по продажам и можете ходить по магазину сколько угодно, дотронуться до любого изделия, посидеть на диване, полежать на матрасе и т. д.; ✓ при проектировании нового изделия работа начинается с создания ценника, а не исходит от затрат на изделие; ✓ ничего не производится самостоятельно, а только закупается у производителей; ✓ активно действуют различные обучающие и мотивационные программы, укрепляется корпоративный и командный дух, для того чтобы служащие IKEA, несмотря на относительно невысокую заработную плату, не покидали компанию; ✓ для описания процессов в бизнесе используют программную среду IDFO, которая была разработана американским военным ведомством в начале 1950х гг. для описания процессов снабжения и обслуживания военной инфраструктуры, а также для описания процессов ведения военных действий,

хотя считается, что среда IDFO не отличается особой наглядностью и удобством, по сравнению с ARIS; ✓ есть полная независимость трех основных подразделений – дизайна, закупки и продажи; ✓ вертикальные коммуникации работают достаточно редко, в основном исключительно для передачи наверх управленческой отчетности, для спуска вниз глобальных стратегических ориентиров и для решения возникающих рабочих конфликтов; ✓ каждый сотрудник хорошо знает свою работу, и ему нет необходимости общаться с шефом каждый день; ✓ горизонтальные коммуникации показывают реальные коммуникационные каналы, по которым ежедневно и ежечасно происходит информационный обмен; ✓ между сотрудниками, соединенными горизонтальными коммуникациями, нет прямого подчинения, однако ни один из них не может на практике выполнять свою работу без другого[50]. «Сибирикс» – первая в России студия интернет-решений, которая стала использовать Скрам в разработке клиентских проектов задолго до того, как это стало мейнстримом. «Мы считаем свой опыт крайне позитивным. Эти подходы строятся на здравом смысле. Это инструменты, и ими нужно работать. Причем они не заменяют голову», – заявил генеральный директор студии. Однако есть достаточно компаний, где полноценно адаптировать гибкие методологии пока не удается – результатов либо нет вообще, либо они не соответствуют ожиданиям бизнеса. В ING и Citibank, самых продвинутых в банковской сфере по части адаптации Agile, далеко не все отделы работают по гибким методологиям. На Agile перешли в основном те отделы, которые занимаются поверхностными оболочками, мобильными приложениями или другими передовыми разработками. Иными словами, это отделы, не связанные с основными бизнес-процессами, сбой которых может поставить под удар годовые доходы и привести к краху всей корпорации. Та же история происходит и в российских банках, где для Agile формируют даже специальные подразделения (Сбербанк – Sbergile и Альфа-банк – «Альфа Лаборатория», «Тинькофф», Ситибанк, «Райффайзен» и др.). Правда, происходит это не просто в силу «неподходящей» национальной культуры. Банковские примеры 1. Sbergile. Более 11 000 сотрудников, работающих в Sbergile, поделены на трайбы (от англ. tribe – «племя»). Каждый трайб – это агломерация команд, объединенных вокруг какой-то общей бизнес-цели, например развития карточных продуктов, хотя «карточные» в данном случае – это условное обозначение, потому что в зону этой цели входят любые способы оплаты, включая эквайринг, смартфоны, NFC-кольца и др. Цели трайба вытекают из стратегии банка и формируются лидерами трайбов при участии топменеджмента. Каждый квартал кураторы трайбов вместе с лидерами трайбов обсуждают цели на ближайшие три месяца. На этой встрече лидеры трайбов синхронизируются между собой, обсуждают результаты предыдущего квартала и планы на следующий. После этого команды декомпозируют эти цели на

конкретные задачи в журнале требований продукта и делят их на спринты (такт работы команды, в ходе которого создается новая версия продукта). Примеры трайбов, в каждом из которых работает от сотни до нескольких сотен человек (сейчас более 20 трайбов): «Эквайринг и банковские карты», «Платежи и переводы», «Занять и сберегать» – названия говорят сами за себя, Digital business Platform – «Сбербанк Онлайн», веб- и мобильное приложение для различных устройств. Это одновременно и самостоятельные продукты, и канал для других продуктов[51]. ✓ Четверка: Альфа-банк, Сбербанк, Райффайзенбанк и ВТБ – уже вложила в свои работы по Agile суммарно более 800 млн рублей. ✓ Банк России. По словам руководителя проектного офиса Банка России, в Банке были запущены три скрам-команды. Стандартные продукты, которые выпускаются в рамках этих команд, – это ИТ-сервис, нормативный документ и комплексное изменение бизнес-процесса. Также запущено семь канбанкоманд. В ближайших планах – начать работу региональной структуры подразделений, применяя Канбан с перспективой распространения его на все территории присутствия Банка России. В случае многих заказчиков трудности выделения сотрудников в команду чаще используются канбан-команды. Если заказчик у нового продукта/услуги один, команда выделена и невелика по размеру, тогда применяют Скрам. Результат при этом достигается быстро, прозрачно и эффективно. По оценке руководителя проектного офиса, результат теперь достигается примерно на 40–50 % быстрее и улучшено кроссфункциональное взаимодействие[52]. TransCanada Когда TransCanada приобрела в США National Resources Co., то она столкнулась с проблемой интеграции в свою собственную систему в течение всего двух лет американской сети газопроводов общей протяженностью 21 000 миль. Несходство правовых процедур, регулирующих работу газопроводов в двух странах, означало необходимость разработки новых процессов и процедур управления, обеспечивающих целостность объединенной сети. Команда проекта состояла из 14 инженеров и одного менеджера по ПО, причем каждый из них имел свою подгруппу, которая также занималась интеграцией газопроводов. Работа над проектом началась с составления диаграммы Ганта, наглядно показывающей календарный план выполнения задач, но, так как команда не была целиком включена в этот проект и имела также и другие обязанности, сроки выполнения задач нередко срывались. К тому же по мере того, как команда получала все больше информации, параметры и содержание проекта изменялись. Чтобы реагировать на эти постоянные изменения, команда стала использовать динамичное (Agile-) управление. Команда начала применять лишь те элементы Agile, которые были особенно необходимы для проекта. Например, ежедневно проводились 15-минутные совещания подгрупп в помещении без стульев (когда человек вынужден стоять, он меньше склонен к пустым разглагольствованиям) и еженедельные собрания всей команды. Это позволяло получать последнюю информацию об изменениях, проблемах, наличии рабочей силы, приоритетах и обо всем том, что позволяло своевременно выявлять и устранять препятствия в работе. Собрания

стимулировали коммуникации внутри команды, необходимые для продвижения проекта и реагирования на изменения. Для отслеживания фактического прогресса руководитель проекта составил список задач высшего уровня и, поскольку он верил в профессионализм руководителей, выполнявших технические подзадачи, регулярно уточнял количество часов, остающихся до завершения каждой задачи (а не количество отведенных часов). Такая ежедневная подотчетность помогала подгруппам поддерживать сосредоточенность на результатах и одновременно быть в курсе ежедневных изменений, способных повлиять на их работу. Постоянное обновление информации оказалось очень кстати, когда проект выбился из графика из-за запаздывания, допущенного одним из поставщиков, но способность руководителя проекта предупреждать его заинтересованные стороны заранее позволила избежать серьезных последствий. Несмотря на то что работа над проектом задерживалась, менеджмент позитивно воспринял возможность заранее узнать о проблеме и о причинах ее возникновения. Руководитель проекта отмечал, что гибкое управление – это просто способ иметь дело с постоянно изменяющимися проектами посредством укорачивания петли обратной связи и информирования работников об изменениях для того, чтобы они могли координировать свои усилия. Таким образом, оно лучше всего подходит для организаций, работающих в динамических, турбулентных средах. Но оно не особенно полезно для проектов, выполняемых с помощью стандартных процессов (таких как строительство нового газопровода) или имеющих в составе своей команды многих неопытных, неквалифицированных или незнакомых друг с другом работников. Члены команды проекта должны доверять друг другу, сотрудничать и координировать свои усилия[53]. Unilever В Unilever поняли: побеждать нужно не только широтой ассортимента, уровнем социальной ответственности, но и с помощью максимально полного использования потенциала сотрудников. Новая система организации работы была названа Agile Working. Подход с максимумом гибкости и минимумом ограничений, при котором ключевое значение имеют результат и производительность, а не нахождение сотрудника в офисе. «Ты можешь работать где угодно и в какое угодно время при условии, что ты выполняешь все доверенные тебе задачи точно и в срок». Конечно, есть некоторые категории сотрудников, кто все же не может работать вне офиса ввиду характера работы. Сегодня компания Unilever применяет подход Agile Working в своих подразделениях по всему миру. Для реализации Agile Working внедряются новые практики, преобразуется рабочее пространство, активно используются новые технологии. Польза подхода в следующем: ✓ работая из удобного места, сотрудник не совершает лишних передвижений, не отправляется в ненужные командировки (это очень актуально, принимая во внимание размер и географию Unilever); ✓ у сотрудника появляется выбор, где, когда и как выполнять свои обязанности;

✓ это вклад компании в сохранение окружающей среды. Сотрудники меньше используют автомобили, поскольку нет нужды ехать в офис утром и вечером; не летают на самолетах в командировки, потому что в последних нет надобности. Компания сохраняет специалистам work-life balance и решает вопрос мобильности (дистанционное руководство без необходимости переезда). В компании существует два возможных графика: стандартный и гибкий. Для снятия риска потерять сплоченность и в рамках борьбы с чувством изоляции обязательно используется хотя бы один командный день. Есть возможности и виртуального сбора коллектива. Существует пять ключевых направлений, в которых Agile Working создает ценность: ✓ производительность: Agile Working позволяет эффективнее работать в рамках стремительно расширяющихся и глобально взаимосвязанных функций. У сотрудников появляется возможность общаться с коллегами по всему миру при минимальных временных потерях; ✓ экономия: виртуальные технологии и создание мобильных мест сокращают затраты на транспорт и аренду жилья; ✓ сохранение окружающей среды: обеспечивается значительное сокращение энергозатрат, выбросов CO2 и бытовых отходов. В долгосрочной перспективе такой подход позволит существенно снизить влияние на окружающую среду, а это одна из ключевых целей плана устойчивого развития и повышения качества жизни Unilever; ✓ энергичность: поддерживается приверженность компании идее энергичной жизни, сотрудникам оказывается помощь в поиске оптимального баланса между работой и личной жизнью; ✓ талант: организации, применяющие такой подход, привлекают лучшие таланты и поддерживают многообразие, позволяя сотрудникам одинаково успешно удовлетворять требования руководства и персональные нужды. Изменения произошли и в плане организации офисного пространства. В open space была выделена отдельная зона, в которой стояли абсолютно одинаковые столы без тумбочек. Дело в том, что сотрудники склонны «персонализировать» рабочие места: размещать там фотографии близких, сувениры из отпуска и прочие милые сердцу мелочи. А суть этого эксперимента заключалась в том, что за стол может сесть любой другой сотрудник – ни за кем не было закреплено место и каждый день все работали из разных точек офиса. Это помогло специалистам абстрагироваться и понять, что работать можно не только из-за своего стола, а откуда угодно. У всех сотрудников есть возможность устраивать видеоконференции, получать доступ ко всей необходимой информации, документации, сетевым программам, приложениям и рабочей почте. Сотрудники могут прийти в ИТотдел и настроить доступ к необходимым ресурсам на ноутбуке, планшете или в смартфоне. Для того чтобы понять, насколько Agile Working приживается и нравится специалистам, в компании работает группа «шпионов»: их задача –

инициировать разговоры, касающиеся новой системы, и узнавать мнения работников[54].

6.13. Agile как Офисное пространство Не делай ничего, если не обязан. Louis Fried

Agile, гибкий фреймворк управления процессами и проектами как в одиночных проявлениях, так и в рамках компании, был описан выше. Однако также существуют гибкие возможности в организации пространства, рабочего места. Знакомы вам случаи, когда хотелось подвинуть стол, чтобы быстро провести в освободившемся пространстве короткое совещание, не заказывая специального помещения и не тратя времени на это? И это устраивало всех участников такой встречи. Или когда в рабочую комнату вносили стулья и стена превращалась в экран для презентаций? И это помогало быстро снять вопросы заказчика. Все это в совокупности приводит к Agile-офисам, которые не только возможны, но и активно строятся. На одной из фотографий (рис. 6.4) приведен пример. Фотографии предоставлены Haworth. Becar Директор департамента управления объектами NAI Becar сообщила об эффекте от переезда компании в новый Agile-офис. В течение месяца изучались рабочие места, определялись отделы, где для ведения эффективной деятельности требуется полная тишина (это, к примеру, бухгалтерия), было обращено внимание на департаменты, в которых работают специалисты, постоянно находящиеся в отъезде и проводящие в офисе не больше трех часов в день. Был получен график, где значились количество работников и специфика их обязанностей. С учетом данных сведений приступили к реконструкции офиса. Для сотрудников, деятельность которых предполагает нахождение на работе, были оборудованы постоянные места. Мобильному персоналу предоставлено временное пространство на территории open space. Туда можно прийти, занять понравившееся место и включить удаленный доступ. На количество подобных зон в рамках проекта влияло то, к какой доле бизнеса относится процесс. Уделили внимание и неформальным зонам: помещениям для отдыха, переговоров, кафе. Пространство было организовано так, чтобы у сотрудников появилась возможность в любой момент изменить расположение: ✓ если нужно, побыть в одиночестве; ✓ объединиться в мини-группы; ✓ провести совещание между отделами в любом составе. Всего за несколько месяцев функционирования Agile-пространства мы начали замечать тенденцию по переходу сотрудников на командную работу. Стало

ясно, что всем все понравилось и люди покинули кабинеты. Они стали чаще собираться для обсуждения задач и проблем в специально предусмотренных зонах, а как следствие – процесс принятия решений ускорился. Мы внедрили ряд фишек: организовали кинотеатр на территории общей зоны, где во время работы идет демонстрация презентаций, а по вечерам – фильмы, а также стену с изображением дерева, на котором написаны ценности фирмы. Новый офис необычен, но комфортен. Мы оснастили его разноуровневой мебелью: барными стульями, креслами-мешками, диванами из кожи и ткани, столами из стекла. Все помещения для переговоров мы снабдили Wi-Fi и конференцсвязью. Так мы избавились от необходимости брать в аренду конференц-залы, чтобы проводить в них внешние встречи. Несколько месяцев показали: работа стала командной, а коммуникация между специалистами разных отделов улучшилась. Удалось сэкономить на аренде. В среднем на человека в офисе масштабной организации приходится 12–40 м 2. Ранее у нас было 10 м2, и этот показатель удалось сократить до 6 м2, эффективно распределив рабочие места. Срок окупаемости проекта составил 1,5 года. Комфортные условия привлекают сотрудников, благодаря чему они проводят на работе больше времени и выполняют обязанности эффективнее[55].

Рис. 6.4. Haworth workplace

Роберт Мокош, главный архитектор: «Еще несколько лет назад в России мало кто понимал значение Agile, в то время как на международной арене данный подход применялся уже давно. За последнее время ситуация резко изменилась. Это лишний раз доказывает, что глобализация Agile неизбежна». Он подчеркивает, что ввиду жесткого контроля и «вертикального» принятия решений любые изменения в российских компаниях происходят очень медленно, поэтому в ключевой трансформации нуждается именно корпоративная культура. «Для того чтобы изменения заработали, недостаточно просто по-новому расставить мебель – важно говорить с сотрудниками, объясняя им суть происходящих изменений», – высказался г-н Мокош.

6.14. Agile в личной жизни

Сделайте расширенный лист «результатов». Сделайте колонки «необходимые» и «возможные». Представьте вторую колонку как можно более непонятной и непродуманной. Том Питерс

Agile легко применим в личной жизни, управлении личными проектами или в домашнем хозяйстве. Можно развешивать скрам-доски в квартире, проводить короткие итерации, летучки внутри семьи или группы друзей. Здесь иногда все даже гораздо гибче, чем в компании. The Agile Household: как Скрам сделал нас лучшей семьей Мартин Лапуэнт и его семья использовали Скрам и особенно скрам-доску для управления их переездом из Парижа в Монреаль. «Сначала мы сделали журнал требований. В течение минуты все записывали достоверные истории на post-it, а потом за вечер собрали более 50 семейных историй. Они не были идеальными. Не было ни критериев принятия, ни оценок, но было много эмоций и искренности. Далее мы спросили себя: что мы можем реально сделать за каждую неделю? Мама хотела добавить в список дела по уборке всего дома, девочки – все самое интересное, а я – обязательные туристические достопримечательности, которые мы еще не посетили перед отъездом. Мы взяли небольшую доску и сделали три колонки: “сделать”, “продолжается” и “сделано”. Мы вели жесткие переговоры, и в конечном итоге дети получили больше своих дел. Первая итерация началась. Мы никогда не видели, чтобы так много работы делалось так быстро, с таким счастьем, легкостью, пониманием и визуализацией! Мы договорились о недельных итерациях (спринтах), а затем в выходные дни планировали следующую итерацию. Каждое утро у нас было быстрое собрание (ежедневная летучка), и все очень хотели переместить post-it на доске. С подходом Скрам мы смогли создать и реализовать список задач по уборке квартиры, выполнить административные задачи и посетить музеи без какихлибо конфликтов. Скрам оказался отличным инструментом для нашей семьи для улучшения ясности и установления приоритетов для решения больших проблем»[56]. Agile Results, или Правило трех результатов Джей Ди Мейер, менеджер Microsoft, в книге Getting Results the Agile Way предложил систему личной эффективности, основанную на простых принципах: ✓ в начале года выберите три большие цели на год; ✓ в начале месяца – три задачи на месяц; ✓ в начале недели – три задачи на неделю; ✓ в начале дня – три задачи на день.

Все эти уровни (год, месяц, неделя, день) должны быть связаны между собой. В понедельник составляйте план. Каждый день начинайте с чистого листа и устраивайте пятничный обзор. Ключевыми особенностями подхода Agile Results являются [57] (рис. 6.5): ✓ ориентация на достижение результатов, а не на выполнение задач; ✓ гибкость, постоянная адаптация к происходящим изменениям;

Рис. 6.5. Подход Agile Results ✓ простая, но эффективная методика расстановки приоритетов; ✓ ограничение временных и энергетических ресурсов для достижения лучших результатов; ✓ непрерывное совершенствование и развитие всех аспектов личности и самой системы.

Спринт 7 Гибкие или немного гибкие стандарты Введение Условия, при которых давалось обещание, забываются, а само обещание помнится. Гарольд Керцнер

Перечень и описание стандартов, в той или иной степени описывающих Agileподходы, несомненно, принесут пользу, если встанет вопрос: что применять на практике? Применять надо не все, но всегда должно быть из чего выбрать. На вопрос: «Что вы можете посоветовать в нашем случае для использования в реальном процессе или проекте?» – читатель сможет легко ответить и даже дать консультации. Именно в этом заключается содержание данного спринта. К категории «гибких» или «отчасти гибких» руководств или стандартов можно отнести, по моему мнению, следующие: ♦ PRINCE2® (PRojects IN Controlled Environments) – Managing Successful Projects with PRINCE2, Directing Successful Projects with PRINCE2®; ♦ A Guidebook of Project and Program Management for Enterprise Innovation (Р2М), 4-е издание, 2005 г.; ♦ Руководство к своду знаний по управлению проектами (PMBOK® Guide, Project Management Institute, A Guide to the Project Management Body of Knowledge, 6 Edition; Project Management Institute, Inc. 2017 (pmi.org) и The Standard for Project Management ANSI/PMI 99-001-2017; ♦ комплиментарное к руководству PMBOK® Guide – Agile Practice Guide; ♦ A Guide to the Scrum Body of Knowledge (SBOK® GUIDE), 3-е издание, 2016. Ниже приведены их краткое описание и особенности. Более подробно ознакомиться можно, уже изучив сами стандарты и руководства.

7.1. PRINCE 2® и PRINCE2® Agile …Забавно, что большинство аналитиков считает PRINCE2® лишь дополнением к PMBOK®, хотя недавняя статистика показала, что PRINCE2® продолжает лидировать в мире, судя по количеству выданных сертификатов. Питер Хепворт, директор AXELOS с 2013 г.

Подробная информация о PRINCE2® находится на сайте https://www.axelos.com/. Стандарт, первоначально придуманный айтишниками, уже давно шагнул за пределы ИТ-отрасли и очень известен в мире. Хотя он ближе к «водопадному» и многими воспринимается именно так, в нем есть и очень интересные гибкие особенности. Ниже будет упомянут еще один вариант – PRINCE2® Agile extension module for PRINCE2 Practitioners. PRINCE 2® (версия 2009 г.) использует семь принципов, большинство из которых почти гибкие (см. мои краткие комментарии после формулирования принципа). 1. Постоянная оценка целесообразности (изменение при необходимости). 2. Учет предыдущего опыта (в том числе и гибкого опыта, использование лучшей практики).

3. Определенные (назначенные) роли и обязанности (формирование ответственности). 4. Управление по стадиям (стадии могут быть любыми, в том числе и спринтами). 5. Управление по исключениям (руководитель проекта должен иметь определенную гибкость и свободу в управлении, которыми он может пользоваться, не эскалируя вопрос с руководством). 6. Акцент на продуктах (акцент на продукте и лишь потом – на действиях). 7. Адаптация к внешним условиям проекта (немедленное изменение). Стандарт использует семь компонентов: ♦ бизнес-план. Утверждается до старта, является индикатором жизнеспособности проекта, проверяется на каждой вехе. Если бизнес-план нежизнеспособен, проект подлежит закрытию; ♦ организацию проекта. Определяются структура команды и внутренние взаимоотношения; ♦ планы. Выявляется серия необходимых уровней планирования, исходя из размеров и целей проекта; ♦ средства управления. Выделяется необходимый набор средств управления для получения ключевой информации, предотвращения проблем и быстрейшего их разрешения; ♦ управление рисками. Определяются ключевые моменты, на которых риски должны быть выявлены и пересмотрены; ♦ качество в окружении проекта. Включаются определенные подходы по обеспечению качества – от определения потребностей в нем до процедур инспекции качества; ♦ управление изменениями. Формируются техники контроля изменений и методики определения стадии, которая требует изменений. Стандарт использует семь процессов-стадий (рис. 7.1).

Рис. 7.1. Процессы-стадии стандарта PRINCE 2®

1. Запуск проекта (startup) – назначается руководитель проекта (далее – РП) и определяются все требования к характеристикам продукта. 2. Инициация проекта (initiation) – РП составляет «инициирующий документ», в котором описывает верхнеуровневый план по достижению цели. После подписания его советом проекта (см. ниже) начинается реализация фаз, которые могут длиться разное количество времени. 3. Управление проектом (direction) – установление структуры управления проектом, определяется, как должна проходить каждая фаза и что делать в случае внесения изменений в проект. 4. Контроль проекта (control) – внесение изменений. Дорожная карта для последующей фазы создается после анализа предыдущей. Изменения вносятся с согласия совета и учитываются в ходе планирования фазы, базовый план проекта корректируется. 5. Управление поставкой (delivery) – реализация операций по созданию продукта. Основные задачи РП – следить за тем, чтобы команда выполняла задачи, а задачи соответствовали целям, следить за приемкой частей проекта. 6. Управление границами стадий (boundary management) – РП должен предоставить совету проекта обзор выполнения этапа, заверить совет проекта, что все запланированные результаты завершены, обновить план проекта и бизнес-кейс, а также создать план этапа для следующего этапа. Это позволит Совету рассмотреть этап, утвердить следующий, рассмотреть обновленный план проекта и подтвердить дальнейшее обоснование деятельности. 7. Завершение проекта (closing) – проводится глубокий анализ того, как прошел проект, как он был реализован. Отчет о ходе проекта также представляется совету проекта.

Количество стадий определяется в каждом конкретном случае, главное – сохранить основную идею структуры PRINCE 2, а именно: постоянное планирование и отчетность высшему руководящему органу – совету проекта.

И наконец, идеи PRINCE 2 по организации проекта. В состав участников входят: ♦ руководитель проекта в традиционном понимании и дополнительно менеджер команды, который похож на скрам-мастера; ♦ совет проекта (Project Board), перед которым регулярно отчитывается РП. Совет включает трех человек – куратора, или заказчика (Executive), главного пользователя (Chief User) и главного поставщика решения или специалиста (Chief Supplier). Совет отвечает за общее руководство проектом и стратегические решения. РП отслеживает проблемы и предлагает совету альтернативные решения. Совет следит за тем, чтобы проект не сбился с курса; ♦ в больших проектах – служба (project assurance), цель которой – представлять независимое мнение о проекте с точки зрения тех же трех стейкхолдеров – заказчиков от бизнеса, пользователей и специалистов (в предметной области). Служба готовит три отчета: • business report – отчет о финансовом состоянии проекта и выгодности его в целом; • user report – отслеживание того, насколько хорошо выполняются требования пользователей; • technical report – насколько хорош проект в технологическом плане, туда ли он движется; ♦ возможна служба административной поддержки, ответственная за проведение встреч, доведение нужной информации до всех, сохранение информации и т. п.

PRINCE2® больше концентрируется на целях, чем на средствах их достижения. Ожидания от конечного продукта в данном подходе формируют содержание проекта и форму его планирования. В начале проекта PRINCE2® предлагает определить три основных его аспекта: ♦ бизнес-аспект (принесет ли этот проект выгоду?); ♦ потребительский аспект (будет ли он интересен пользователям?); ♦ ресурсный аспект (достаточно ли всего, чтобы достичь цели?).

У PRINCE2® более четко определенная структура персонала, чем у большинства подходов к проектному управлению, у каждого члена команды – своя четкая роль на каждом из этапов. Это связано с тем, что PRINCE2 ориентирован на масштабные государственные проекты и крупные организации. Стандарт подходит для проектов, в которых большое количество обратной связи и есть угроза задержек по политическим причинам и излишней бюрократизации из-за избыточного надзора и проверок. В отличие от Agile, который фокусируется на командах более низкого уровня, стандарт PRINCE 2 ставит во главу угла более высокие уровни управления. PRINCE 2® отвечает на такие вопросы, как «Должны ли мы делать проект?» и «Стоят ли выгоды затрат и риска?». Agile работает с вопросами «Что мы поставляем на следующей неделе?», «Как мы узнаем, что это (продукт) закончено?». PRINCE 2® – более прогнозирующий подход, Agile – более адаптивен. PRINCE2® Agile extension module for PRINCE 2 Practitioners – это расширение, предназначенное для организаций и лиц, уже пользующихся PRINCE2®. PRINCE2® Agile был разработан в 2014 г., чтобы помочь практикам PRINCE2® адаптировать элементы управления к спецификациям Agile и в то же время помочь Agile-практикам понять, как использовать PRINCE2®. Как и PRINCE2, стандарт PRINCE2® Agile предназначен для применения практиками PRINCE2® ко всем типам проектов в любых отраслях промышленности. PRINCE2 Agile поддерживается экзаменом и сертификацией и поставляется аккредитованными поставщиками обучения AXELOS. Около 50 % материалов PRINCE2 Agile – это новые описания, показывающие, как методы PRINCE2 и Agile могут взаимодействовать и адаптироваться друг к другу, чтобы принести пользу общему управлению проектами. PRINCE2 Agile применим в любом проекте, в котором мог быть применен PRINCE2 для планирования и контроля, но в котором команда предпочитает работать по Agile. Есть хорошее видео по стандарту: http://clipson.ru/clip?id=GUC1ytTJKOM.

7.2. P2M Угол зрения зависит от занимаемого места. Закон Майлса

P2M (A Guidebook of Project and Program Management for Enterprise Innovation) (управление проектами и программами) – стандарт по управлению проектами, базирующийся на опыте Японии с 1999 г. Первая редакция P2M была опубликована в 2001 г. Японской ассоциацией развития инжиниринга (ENAA). P2M поддерживается Ассоциацией проектных менеджеров Японии (PMAJ). Проект в Р2М – обязательство руководителя проекта создать не продукт, а ценность, которую продукт приносит компании, показать, как он улучшает состояние компании и общества. Участники проекта, создавая новшество, должны ориентироваться на его миссию, на ценность, которую оно принесет компании. Любой проект начинается с определения его миссии. Это отличает Р2М от других.

P2M – это система знаний, имеющая в своей основе сложность, ценность и сопротивление (Complexity, Value and Resistance). Проекты должны быть сложными и стратегически связанными друг с другом; приносить компании ценность и реализоваться вопреки сопротивлению внешней среды. Одно из основных качеств, присущих успешным компаниям, согласно стандарту, – гибкость, приспособляемость к изменениям. В результате применения стандарта формируется быстрая, гибкая, инновационная экономика, в основе которой лежат знания и новаторские идеи. Появляется большое количество рабочих мест для работников умственного труда, развиваются технологически сложные отрасли. Для уменьшения неопределенности любую миссию нужно описать в виде четких сценариев, из которых сразу же можно будет выяснить цели, задачи и контекст проекта. Происходит выбор наилучшего варианта из всех предложенных сценариев. Итоговый сценарий должен быть предельно ясным и максимально новаторским. Программа определена как объединение группы проектов, направленных на достижение миссии программы. Перед выполнением проекта нужно расписать архитектуру программы для обеспечения связки функциональной и структурной конфигурации. На сегодняшний день управление все более склоняется к гибкости, подстраивается под срочные изменения к конкретной ситуации. Стандарт представляется в виде сооружения, в фундаменте которого 11 сегментов проектного управления (управление стратегией, системами, целями, рисками, отношениями, финансированием, организацией, ресурсами, информацией, коммуникациями и ценностью). Выше сегментов – проектное управление, которое реализует один инновационный продукт; над ними – управление программой, состоящее из нескольких проектов. На уровне программы происходят формулирование миссии, управление архитектурой и стратегией программы, ценностью инновационного продукта. И на вершине сооружения находится миссия всей программы. Для ее достижения необходима стратегическая работа со всеми «этажами». Руководитель всегда должен ориентироваться на ценность, к которой стремится проект. Движение на всех этапах может происходить как вверх, так и вниз: от сегментов к программе, а дальше – к миссии и наоборот. Основные принципы[58]: ♦ суть проекта – миссия как глобальная цель, ради которой создавался инновационный продукт; ♦ должен получиться уникальный продукт, приносящий выгоду стейкхолдерам, а также улучшающий внешнюю и внутреннюю среду компании; ♦ действия участников команды взаимосвязаны; ♦ важнейшая роль у менеджеров со стратегическим мышлением, навыками к планированию, системными знаниями, которые нацелены на достижение результата; ♦ обеспечение пространства для команды, где идут постоянное взаимодействие и обмен идеями;

♦ оценка ценности продукта и разработка альтернатив идут постоянно, чтобы в условиях изменений план непрерывно развивался и программа двигалась к цели.

7.3. PMBOK® Guide 2017 Каждый успешный проект в середине его реализации кажется катастрофой. Розабет Моос Кантер, профессор Гарвардской школы бизнеса, консультант

По исследованиям Pulse of Profession®, гибкие методы используются все больше и больше, поэтому соображения для гибких и адаптивных сред в настоящий момент включены в PMBOK® Guide 6 Edition. Традиционно «водопадное» руководство включило характеристику предиктивных и адаптивных циклов, описаны виртуальные и органичные (органические) структуры и др. В разделе «Ключевые концепции управления содержанием» обсуждаются вопросы управления содержанием в адаптивных циклах. Упоминается журнал требований продукта. Определяются пользовательские истории как краткие текстовые описания требуемой функциональности. Согласно PMBOK ® Guide пользовательские истории описывают роль заинтересованной стороны, получающей выгоду от свойства продукта (роль), которую заинтересованной стороне необходимо достичь (цель), и выгоду для заинтересованной стороны (мотивация). В разделе «Управление сроками проекта» раскрыта взаимосвязь между видением продукта, планированием релиза и планированием итераций в адаптивном цикле. Там же приведена «диаграмма сгорания». В разделе «Управление ресурсами проекта» описываются самоорганизующиеся и виртуальные команды. Приводится устав команды (см. приложение 3) как документ, который устанавливает ее ценности, а также соглашения и рабочие руководящие принципы. Согласно PMBOK® Guide устав команды может включать в себя: ценности команды, руководящие указания в области коммуникаций, критерии и процесс принятия решений, процесс урегулирования конфликтов, руководящие указания по проведению совещаний, соглашения команды. В разделе «Управление коммуникациями» обсуждается польза визуальных образов. Они могут быть представлены в виде информационных панелей (dashboards), тепловых карт (heat reports), светофорных схем (stop light charts) или в другом представлении, облегчающем усвоение информации, принятие решений и выполнение действий. В разделе «Управление заинтересованными сторонами» говорится о важности активного вовлечения и участия заинтересованных сторон проекта в гибких решениях. Чтобы облегчить своевременную, продуктивную дискуссию и принятие решений, адаптивные команды вовлекают в работу заинтересованные стороны напрямую, не создавая ненужную бюрократию и лишние уровни управления. Часто обмен информацией между клиентом,

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

7.4. Agile practice Guide Когда я написал в FB, что валидирую это руководство по приглашению PMI®, то тут же получил комментарий одного из знакомых, что все плохо, PMI®, как «водопадный» апологет, не может создать Agile… Я прокомментировал, что это совместный продукт Agile Alliance® и PMI® и, видимо, роль первого была очень серьезной… От автора

Новое Agile-руководство появилось 6 сентября 2017 г. в комплекте с PMBOK® Guide 6 Edition как результат сложившегося сотрудничества PMI® (www.pmi.org) и Agile Alliance® (www.agileal-liance.org). Один из основателей Agile Alliance Алистер Коберн как-то сказал: «Действительно, например, в области управления проектами есть Институт управления проектами (Project Management Institute®), у которого есть сертификация PMP®, это основы управления проектами, но там нет ничего специфичного для Agile. Мы обсуждали с PMI® создание подмножества активностей и знаний для применения в пространстве Agile. Там проявили интерес к этому направлению, и мы стали сотрудничать…» Каждая из организаций является известнейшим специалистом в своей области. Agile Alliance, как постоянная некоммерческая организация, по сути, была создана той же группой, которая разработала Agile-манифест для гибкой разработки ПО, но немного позже. PMI® был основан в 1969 г. в Технологическом институте Джорджии и объединил на текущий момент около 900 000 членов. Среди его новых разработок – шестое издание Project Management Body of Knowledge (PMBOK), опубликованное в сентябре 2017 г. Одной из революционных особенностей нового PMBOK ® Guide является наличие в нем информации о гибких подходах, чего не было в предыдущих изданиях. Практическое руководство Agile Practice Guide готовилось тоже гибко, при его разработке использовались ритуалы и правила гибких фреймворков. Оно написано живо, с примерами, недлинно, имеет пространство для развития и совершенствования в следующих итерациях, является Agile-проектом. Обзор документа Документ четко и понятно структурирован. Он включает описание Agile на уровне конкретного проекта или команды, приводятся наиболее

распространенные фреймворки. Есть интересный раздел, описывающий факторы, применяемые при выборе того или иного подхода и/или практики Agile, а также фильтры для оценки применимости Agile- и не Agile-подходов. В основном говорится об использовании Agile вне разработки ПО. Есть раздел, связывающий данное руководство с PMBOK® Guide. Рассматривается внедрение Agile в проекты или организации. Уделяется внимание техникам масштабирования и гибридным вариантам комбинирования адаптивных и предиктивных подходов. Подробно описаны роли, включая роль Agile – проектного офиса. Приведены ссылки на интересные ИТ-практики. Очень полезен глоссарий, описывающий общепринятые термины и дающий их наименование на русском языке. Наверное, с момента появления этой русскоязычной версии руководства многие термины смогут войти в практику и заменят тот смешанный язык, который применяется в российском Agile сейчас. В руководство не входит описание внедрения Agile в масштабах всей организации или создание использующих Agile программ (проектов). Руководство избегает одобрять или критиковать конкретные подходы, оставляя этот выбор читателю. Также не приводятся какие-либо пошаговые поясняющие инструкции о порядке внедрения Agile в компанию. На мой взгляд, мало внимания вопросам управления рисками, мало рекомендаций по взаимодействию Agile- и не Agile-культур. Наверное, это будет в следующих вариантах.

7.5. Scrum body of knowledge (SBOK® Guide) Последнее руководство (2016) содержит рекомендации по успешной реализации Скрама и выпущено SCRUMstudy®. Скрам, как определено в руководстве, применим к портфелям, программам и/или проектам в любой отрасли. Это руководство может использоваться в качестве справочника и руководства по знаниям как опытными специалистами по Скраму, так и другими специалистами по разработке продуктов и услуг, а также лицами, не имеющими опыта или знаний о Скраме или о другой методологии реализации проектов. Его можно легко скачать на сайте https://www.scrumstudy.com/ sbokguide. В первой главе описываются цель и структура руководства, а также дается введение в ключевые концепции. Глава 2 раскрывает шесть принципов Скрама, к которым относятся: ♦ эмпирический контроль процессов – прозрачность, проверка и адаптация; ♦ самоорганизация – автономная самоорганизованная команда; ♦ сотрудничество – общий процесс создания ценности в команде; ♦ приоритизация на основе ценности – достижение максимальной ценности бизнеса с раннего этапа проекта; ♦ time-boxing – ограничение в виде спринтов; ♦ итеративная разработка – управление изменениями и создание продуктов, удовлетворяющих потребности клиентов.

В главах 3–7 подробно рассматриваются пять аспектов Скрама, которые должны быть изучены в рамках любого проекта: организация, бизнесобоснование, качество, изменения и риск. Главы с 8-й по 12-ю охватывают 19 процессов Скрама, участвующих в выполнении гибкого проекта, среди которых: инициирование, планирование и оценка, реализация, обзор и ретроспектива, выпуск и др. Подробно описаны соответствующие входы и выходы каждого процесса, а также различные инструменты, которые могут быть использованы в каждом из них.

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

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

8.1. ACP® от PMI® PMI® проводит программу сертификации PMI® – ACP® (Agile Certified Practitioner), стартовавшую некоторое время назад, но быстро набравшую популярность. К моменту написания этой книги таких специалистов в России уже несколько десятков. Статус сертифицированного специалиста-практика PMI® по Agile официально признает за кандидатом знание гибких принципов и навыков их применения. Сертификация PMI® – АСР охватывает многие гибкие подходы, такие как Скрам, Канбан, Lean, XP. Общие требования к опыту работы в проектах: ♦ 2000 часов работы в командах проектов в течение последних пяти лет или действующий статус PMP®/PgMP®; ♦ опыт работы в Agile-проектах – 1500 часов работы в Agile-проектах и/или проектных группах (часы считаются в дополнение к 2000 часов общей проектной практики и должны быть заработаны в течение трех последних лет); ♦ тренинги по Agile-практикам, по результатам которых кандидат получит 21 PDU (Project Development Unit). Это количество PDU можно получить и в

бизнес-школе ИМИСП, где работает автор. Экзамен включает 120 вопросов с несколькими вариантами ответов в течение трех часов. В дальнейшем для поддержания сертификации нужно получать 30 баллов PDU в области Agile каждые три года. Более подробную информацию о требованиях и стоимости сертификации можно найти на сайте pmi.org.

8.2. Scrum Alliance В 2002 г. Кен Швабер, как первый, кто описал, формализовал и развил Скрам, основал и Scrum Alliance (вместе с Майком Коном и др.) – организацию, призванную продвигать Скрам в мире. В этом же году Кен создал и провел первый курс Certified Scrum Master (CSM) – курс начального уровня для желающих использовать Скрам в своих проектах. Сегодня Scrum Alliance – большая известная организация, которая является самой узнаваемой организацией, занимающейся скрам-сертификациями, включает в качестве членов около 150 сертифицированных и весьма уважаемых тренеров по всему миру. Критики, правда, отмечают, что тренеры имеют большую свободу в формировании содержания курса CSM, в результате чего его качество может сильно варьироваться от тренера к тренеру. В 2009 г. Кен Швабер предпринял попытку реформировать Scrum Alliance. Причиной был слабый уровень понимания Скрама даже теми людьми, которые окончили официальный курс Scrum Alliance. Одна из ключевых проблем была с «технической составляющей» в Скраме. В большинстве команд он «не взлетал» просто потому, что рядовым разработчикам не хватало понимания инженерных практик (таких как TDD, непрерывная интеграция и т. п.), без которых воплотить принципы Скрама на практике малореально. Нужен был специальный курс для разработчиков, причем читать его должны были отдельные люди, так как у большинства действующих тренеров просто не было соответствующих технических навыков. Таким образом, планируемые Швабером реформы вступили в противоречие с финансовыми интересами членов Scrum Alliance, в результате чего Кен был вынужден оставить место председателя совета директоров Scrum Alliance и покинуть созданную им организацию. Оставаясь в рамках своих принципов, после ухода он создал Scrum.org. Вот как описывает это сам Кен: «Я создал Scrum.org (см. раздел 8.3), чтобы перенаправить свои усилия (c зарабатывания денег) на создание правильных вещей». Сертификат Scrum Master от Scrum Allience можно получить после очного обучения от официального тренера Scrum Alliance, заплатив в среднем от $800 до 2000 за обучение. Сертификаты от Scrum Alliance бывают трех видов для начального уровня: Certified Scrum Master, Certified Scrum Product Owner и Certified Scrum Developer, продвинутый сертификат Certified Scrum Professional требует опыта работы в Скраме. CSM (Certified Scrum Master) – это самая востребованная сертификация от Scrum Alliance. После обучения надо пройти официальный онлайн-тест, который высылается участникам сразу же после тренинга. Тест рассчитан на базовые знания по Скраму и имеет несколько вопросов, относящихся к роли скрам-мастера. Scrum

Alliance при этом аргументирует простоту теста тем, что своих тренеров они очень хорошо проверяют и уверены в том, что знания будут донесены качественно. Scrum Alliance также недавно объявил об изменениях в CSM-тесте, который стал обязательным для сертификации с октября 2009 г. Тест останется обязательным, но будет значительно улучшен. Вместо простой оценки («Вы дали 89 % правильных ответов») всем, кто сдает тест, показываются правильные ответы на те вопросы, на которые они не смогли дать ответ, чтобы продемонстрировать, в какой области у них не хватает знаний, и они могли продолжить обучение по этим темам.

8.3. Scrum.org Scrum.org еще не так популярен, как Scrum Alliance, но это меняется. Scrum.org так же, как и Scrum Alliance, занимается продвижением Скрама и организацией обучения и сертификации. Был опубликовал Scrum Guide – «спецификация Скрама», 16-страничный документ, который в сжатом виде определяет, что является частью Скрама, а что – нет. Из руководства ничего не выкинешь, и при каждом новом прочтении обнаруживаешь что-то новое и суперважное. Была создана новая версия учебного курса – Professional Scrum Master (PSM). По сути, это обновленная и углубленная версия курса Certified Scrum Master, но фишкой Scrum.org является то, что абсолютно все тренеры данной организации обязаны использовать одну и ту же версию курса для своих тренингов. Этим должны обеспечиваться качество курса и его независимость от тренера. Конечно, у медали есть и обратная сторона – тренеру сложнее адаптировать курс в случае специфической аудитории. Для того чтобы получить сертификат Scrum.org, не обязательно участвовать в обучении (хотя это приветствуется). Сертификация была отделена от обучения. Можно спокойно готовиться, сколько нужно, изучать материалы и требования и сдать экзамен в любое удобное время без всяких ограничений. Стоимость экзамена – $150. Сертификации от Scrum.org для скрам-мастеров бывают трех видов: PSM I, PSM II и PSM III. Это разные степени сертификаций, требующие разного уровня знаний. PSM I – самая первая из сертификаций и самая сложная из существующих. Экзамен проходит онлайн и включает 80 вопросов за 60 минут. Проходной балл – 85 %. Подготовку лучше вести по четырем направлениям: ♦ ScrumGuide. Читать его лучше через день, 6–7 раз, выделяя важные выводы и мысли; ♦ литература. На scrum.org можно найти список рекомендуемой литературы и темы для изучения; ♦ прохождение Open Assessment. Пока стабильно не будет более 90 % в результатах, не рекомендуется приступать к экзамену; ♦ отзывы, YouTube-видео и т. д. Вся релевантная к сертификации и сдаче экзамена информация. Важно помнить, что содержание экзамена и Scrum Guide постоянно обновляются.

Ссылки: ♦ почитать: http://www.scrumguides.org/scrum-guide.html и https:// gurtejpsingh.wordpress.com/category/time-boxing/; ♦ потренироваться: https://www.classmarker.com/onlinetest/start/?quiz=vek54a6ec10658ef. Желательно сдавать тренировочный тест без ошибок (некоторые вопросы повторяются в самом экзамене).

8.4. ICAgile ICAgile (International Consortium for Agile) (https://icagile.com/) – Международный консорциум по Agile – это организация, управляемая сообществом, которая состоит из Agile-пионеров, экспертов и доверенных консультантов. ICAgile не просто еще один орган по сертификации. «Мы меняем то, как люди делают Agile, помогая им самим стать гибкими» (перевод части миссии). Требования ICAgile разработаны соавтором Agile-манифеста А. Коберном. ICAgile отличается от прочих консорциумов тем, что проводится аккредитация курсов (в основном) и сертификация тематических дисциплин, а не отдельных ролей в команде. ICAgile не обучает. Консорциум строит учебные дорожные карты, аккредитует курсы и инструкторов, информирует об этом кандидатов, предлагает сертификацию и признание участникам по мере их продвижения. Аккредитованные курсы (ICAgile Accredited Course) содержат знания, которые надо освоить слушателю в области Agile. Программа курсов охватывает все основные принципы и практики Agile и позволяет начать работу членом команды исполнителей, владельцем продукта и скрам-мастером. Курсы созданы в результате совместных усилий команд со всего мира. ICagile не оценивает и не сравнивает курсы друг с другом, а также не предлагает сами курсы. Сертификат ICAgile Certified Professional (ICP) – это базовый уровень сертификации. ICP выдается слушателям, завершившим аккредитованный курс Fundamentals of Agile (основы Agile), концентрирующийся на Agile mindset. Получение ICP показывает готовность кандидата стать профессионалом в сообществе Agile. Более 60 000 человек прошли обучение по этой программе в 20 странах мира. В заключение стоит отметить наличие и других сертификаций, например, Scaled Agile запустила свою сертификацию для скрам-мастеров при масштабировании – SAFe 4.0 Scrum Master (SSM, scaledagile.com), ISI Certified Scrum Master и др.

Спринт 9 Agile-трансформация Введение

Нет смысла искать плохих людей, ищите плохие системы. Джефф Сазерленд. Scrum. Революционный метод управления проектами

В рамках спринта 9 пойдет разговор о превращении компании в Agileкомпанию. Конечно, это грозит не всем. Но те, кто решится, должны знать, что это и к чему приводит. Ценностью спринта может быть знание этого пути. Вдруг вы решитесь?..

9.1. Холакратия Начнем с форм организаций или объединений людей, которые способствуют гибкости процессов или проектов по самой своей сути. В 2007 г. Брайан Робертсон с Томом Томисоном создали организацию HolacracyOne, описав такую децентрализацию власти, чтобы каждый сотрудник влиял на ее жизнь и обладал полной властью в рамках своей роли или ролей, которых может быть несколько в зависимости от компетенций и возложенных на роль ожиданий. Предложенная в 2009 г. «Конституция холакратии» призывала убрать вертикальные иерархии с начальниками и подчиненными, управлять общей целью компании, прозрачным процессом, ожиданиями и метриками, формально отменить руководителей (занимающихся контролем), дать право любому сотруднику знать, чем занимается другой и насколько он эффективен и т. п. Эффективность холакратии подтвердил опыт крупного интернет-магазина Zappos в 2015 г. Основатель Zappos Тони Шей объявил о ликвидации иерархии и переходе к холакратии путем замены должностей на роли и возможности каждому сотруднику устанавливать себе обязанности. Полторы тысячи сотрудников были организованы в примерно 400 кругов (рис. 9.1). Вертикальная связь обеспечивается двумя ролями: leadlink и replink. ♦ Leadlink (ведущая связь, направленная сверху вниз) – это сотрудник, обладающий правом перераспределять роли между сотрудниками для лучшего выполнения ожиданий, вплоть до увольнения и найма, назначается в круг внешним кругом и передает в него информацию извне. Это не начальник, его задача – либо заполнить круг участниками с релевантными компетенциями, либо самому выполнять их функции. Leadlink из более крупного круга назначает на роль leadlink более мелкого круга. Руководитель предприятия – это leadlink круга «вся корпорация». ♦ Replink (представительская связь, направленная снизу вверх) – это сотрудник, который выбирается голосованием круга и выражает или передает внутренние проблемы круга во внешний на встречах любого уровня, вплоть до совета директоров. Главное, чтобы replinks выносили наверх проблемы бизнеса, а не защищали интересы небольшой группы людей. ♦ Secretary. Участник круга, который координирует встречи и собирает их результаты.

♦ Facilitator. Лидер встреч круга – как и secretary, он выбирается другими участниками круга.

Рис. 9.1. Роли в холакратии

Сторонниками холакратии стали технологические компании, которые постоянно внедряют инновации не только для своих продуктов, но и для внутренних процессов (блог-платформа Medium, GitHub, коучинговая компания David Allen Company и др.). Список компаний, приходящих к холакратии, находится по адресу http://structureprocess.com/holacracy-cases/. В России это скорее экзотика с непонятными перспективами ввиду исторического постоянного уважения условного «начальства», хотя в кризис, в котором мы находимся постоянно, холакратия (или ее упрощенные формы) позволила бы сократить персонал за счет руководителей, повысить ответственность за результат и быстрее реагировать на изменения. Холакратия очень много позаимствовала от Agile, фокусируясь на самоуправляемых командах из разнопрофильных.

Medium 1. В Medium нет руководителей. Каждый член команды работает автономно и в рамках своего круга. Но круги могут пересекаться. Когда возникает проблема, руководитель (Эван Уильямс) уделяет внимание не ей, а сотрудникам, которые могут ее решить. Неожиданно все проблемы исчезают. Уильямс также использует подход SCARF (Status, Certainty, Autonomy, Relatedness, Fairness) из книги Your Brain at Work. Согласно SCARF сотрудников можно разделить на пять групп в зависимости от того, что их мотивирует [59]:

✓ статус – таким сотрудникам важна их должность и, например, то, что их имя указано в важном проекте; ✓ уверенность – сотрудники мотивированы тем, что они делают важную работу; ✓ автономия – таким сотрудникам важно работать из дома или свести к минимуму общение с коллегами; ✓ связанность – экстраверты, которым нравится социум и общение с другими людьми; ✓ честность – сотрудники, которым нужно постоянно напоминать о том, что в компании все справедливо и честно. 2. Компания Neti, которая занимается внедрением ERP-систем, внедрила холакратию как систему управления организацией, где управленческую иерархию заменяют самоорганизующиеся команды. «Мы честно рассказываем клиентам, что теперь не пишем большие технические задания, работаем по изменениям и быстро реагируем. Сначала это вызывает вопросы, ведь раньше они так никогда не работали. Но со временем вовлекаются и становятся клиентами на всю жизнь», – говорит один из сооснователей. 3. Компания «Кнопка» (http://knopka.com/about). Бизнес-сервис «Кнопка» был готов к холакратии – применялись Agile-подходы, формировались ценности, культивировался предпринимательский подход, но с ростом штата поддерживать культуру становилось сложнее. Компания использует многие элементы холакратии: круги, метрики для ролей и кругов, управленческие роли и т. д., частично подвергшиеся адаптации в том виде, который команда назвала «кнопкократией». 4. Райффайзенбанк (https://rb.ru/opinion/holakratiya/). ИТ-команда в банке успешно экспериментирует с двумя практиками холакратии.

Первая – процесс принятия решений. Проблемы: решения принимаются долго, теми, кто часто не понимает предметную область, и без учета мнения исполнителей. Команда решает эту проблему исключением условного «начальника» из принятия финального решения. Ответственность за решение несет его автор после доработки с учетом претензий и рекомендаций заинтересованных лиц. Вторая – разрешение конфликтов. Проблемы – конфликты неконструктивны, они замалчиваются и механизма их решения нет. Команда решает эту проблему, привлекая медиатора. Он линейно с конфликтующими сотрудниками не связан, но пользуется авторитетом. Его задача – задавать вопросы и делиться знаниями, как такие конфликты решаются у других. Если выход не найден, несколько таких медиаторов организуют панельную дискуссию. Однако права решить конфликт ни у кого из них нет, оно остается за конфликтующими сторонами. специалистов, работающих на общий итог. Координация работы происходит с использованием governance meeting (собрание команды по результатам итерации, похожее на ретроспективу). Описание ролей (policy) напоминает правила, по которым живет Agile-команда. Описание ролей

постоянно пересматривается и дорабатывается. Оно формируется теми людьми, которые входят в тот же круг. Это позволяет людям контролировать выполнение возложенных друг на друга функций в рамках каждого круга. И это работает лучше, чем контроль сверху вниз. Гибкость, как быстрая реакция на изменения, также связывает Agile и холакратию. Авторы холакратии не рекомендуют внедрять ее элементами. Она не работает частями. Опыт Spotify, Valve и GitHub показывает, что холакратия тоже может быть гибкой. В том же Medium заявляют, что они не строят компанию без менеджеров, а создают компанию с «новыми типами менеджеров». Холакратия требует высокой самоорганизации сотрудников, поскольку в результате отмены контроля могут срываться сроки и возникать проблемы с карьерным ростом кадров. Из Zappos, к примеру, после внедрения холакратии ушла шестая часть сотрудников. Может возникнуть непонимание со стороны сотрудников и нехватка времени на их обучение. В этом смысле стартапам внедрять холакратию проще – небольшому числу сотрудников донести идеи легче.

9.2. «Бирюзовые» организации Фредерик Лалу, в прошлом партнер компании McKinsey & Company, в своей книге «Открывая организации будущего» описал организации различных типов, или «оттенков». Не уходя в далекое прошлое, приведем лишь те, которые в той или иной степени встречаются в настоящее время в мировой практике. Конформистская, или «янтарная», стадия. Статичная стабильная организация: есть законы, вещи делятся на правильные и неправильные. Сотрудники строго следуют приказам, не задавая лишних вопросов. Доминирует мораль. Подразумевается жесткий контроль. Планирование происходит на верхнем уровне, а исполнение – на нижнем. Главное – отдавать распоряжение и контролировать исполнение. Полномочия строго распределены, как и ответственность. Сотрудники воспринимаются как ленивые и нечестные, за которыми требуется присмотр. Доминируют люди X (согласно теории мотивации Макгрегора). Такие организации приводятся в действие процессами. Типичные представители – большинство государственных учреждений, школа, церковь и армия. Конкурентная, или «оранжевая», стадия. Каждый сотрудник может добиваться любых целей и чего захочет, если будет обладать соответствующими навыками: вахтер может стать руководителем. Конкуренция воспринимается как норма. Главное – победа во внутренней и внешней конкурентной борьбе, предвидеть изменения и контролировать ситуацию. В основу всего заложена эффективность. Мораль не на первом месте. Человек начинает подвергать сомнению общие принципы. Тот, кто лучше всех приспособлен к системе, добьется многого. Приветствуется новаторство, поощряется личная ответственность и движение по карьерной лестнице. Присутствует меритократия – возможность добиться чего-либо согласно способностям. Мерило успеха – материальное благосостояние или деньги. Организация приводится в действие процессами и проектами. Она руководствуется пирамидой как базовой структурой, но выстраивает

горизонтальные связи в своих жестких функциональных и иерархических связях с помощью проектных групп, виртуальных команд, кроссфункциональных рабочих групп, штатных экспертов и внутренних консультантов. Представители – большинство крупных компаний: «Найк», «Филипп Морис», «Кока-Кола», банки и др. Плюралистическая, или «зеленая», организация. В такой компании внимательно относятся к чувствам и уважают разные точки зрения. Люди стремятся к справедливости, равенству, гармонии, добрососедству и консенсусу. Мнение каждого заслуживает уважения. Решения могут принимать сами сотрудники на своем уровне, без участия руководителя. Лидеры организаций служат тем, для кого они лидеры. Личные отношения внутри группы ценнее результата, а польза для общества важнее личной выгоды. Отношения становятся превыше результата. Приоритет интересов одних заинтересованных лиц перед другими не имеет права на существование. Бизнес несет ответственность не только перед инвесторами, но и перед менеджерами, сотрудниками, клиентами, поставщиками, обществом в целом и окружающей средой. Эволюционная, или «бирюзовая», организация (холакратия). Появилась 30 лет назад, когда люди устали от тотального контроля руководства и внутренней конкуренции. Они больше не хотят заниматься бессмысленной деятельностью: делать отчеты, которые нужны только руководителю. Люди хотят быть эффективными и перестают бояться ошибок. Главное – делать максимум на пределе возможностей ради общей цели компании. Соответствует самореализации согласно теории мотивации А. Маслоу. От «оранжевых» этот тип отличает желание конкурировать с внешними компаниями, от «зеленых» – стремление быть командой. В «бирюзовой» организации существует самоуправление, руководитель – наставник, обучает и дает рекомендации. Работа каждого зависит от работы других и влияет на нее. Используется внутреннее консультирование, в котором принимает участие вся команда. Характерно стремление к целостности, работники раскрываются, поддерживают друг друга внутри компании и одновременно выполняют внешнюю работу ради общей цели организации. Собеседование при приеме на работу проводят будущие коллеги. Они же помогают новичку адаптироваться в коллективе. В «бирюзовой» организации отчетность может сдавать не только бухгалтер, но и сами учредители (или даже другие участники объединения), вопрос повышения квалификации может быть решен путем создания отдельной рабочей единицы, которая будет внутренним преподавателем, или взаимного обучения. В России признаки «бирюзовости» можно увидеть у компаний «ВкусВилл», «Фабрика Окон», «Аскона», Mindbox, проводит эксперименты в некоторых отделениях даже Сбербанк.

9.3. Условия внедрения Agile Встать на путь полного обновления не так страшно, как принято считать, – это гораздо страшнее. Морт Майерсон. Perot Systems

Сегодня «управлять по Agile», «играть в Agile», «использовать Agile» популярно и ассоциируется с новизной, современностью, но есть и осторожность, фрагментарность, негативные отзывы и самая разная практика. Нельзя не отметить проблемы, связанные с «неправильным» внедрением или формальным использованием Agile. Внедрение Agile в традиционной компании – это первый спринт на длинном пути к самоуправлению и самоорганизованным командам. И если в результате внедрения команды работают успешно, то самоорганизация начинает проникать во всю структуру компании. Ниже поговорим об условиях внедрения Agile в компанию. Их концептуально можно разделить на три группы. В идеальном случае все это должно быть учтено одновременно. 1. Характеристики проектов компании. Лучшие кандидаты в Agile – это проекты, у которых: начальная высокая неопределенность, непонятная скорость появления новых требований, сложное наполнение, постоянное изменение потребностей заказчика или пользователей; возможность реализации изменений за меньшую цену из-за частых инкрементов или итераций; требования непростые или их невозможно согласовать; технологии новые, непроверенные, а проекты – сложные, возможность тесного сотрудничества и частая обратная связь, рост понимания заказчиком, чего они хотят от проекта; важность срока выхода в работу; межфункциональная кооперация. Лучшие кандидаты для «водопадных» технологий: понятная технология реализации проекта и маловероятность ее изменения; желание или требование заказчика по выполнению последовательного цикла; фиксация сроков и сметы; маловероятность изменений; невысокая сложность; четкие вводные и малоизменяемые цели; развернутые спецификации и проведенное на входе детальное планирование; понимание всеми заинтересованными сторонами, что именно будет поставлено, прежде чем оно будет создано. 2. Окружение. Наличие благоприятного внешнего (в том числе и корпоративного) окружения, юридических факторов и оснований, форм Agile-контрактов или договоров (см. приложение 2), способствующих использованию Agile во внешних проектах. 3. Необходимые нововведения, которые могут вызывать сопротивление или быть просто невозможными. В изменении компании и работе по Agile важно следующее: • должны участвовать Agile-люди; • наличие предварительного и постоянного обучения Agile-команд; • руководить проектами и работами в целом должен не старший по должности, а старший по компетенции (сильный лидер, опытный консультант и т. п.). В то же время многие компании демонстрируют противоположное; • работа в Agile-командах/проектах предполагает высокие требования к качеству труда участников, их лояльности, энтузиазму и работу на лучшие решения. Эти качества не часты во многих компаниях; • Agile предполагает контроль за результатом, быструю обратную связь. В традиционных бизнесах (банки, розница, услуги) сбор и анализ обратной связи от клиентов – задача непростая и часто нерешенная;

• Agile используется для разработки уже готового концепта продукта. Нет этого – нет разработки[60]. Agile и стандарты В США финансовый учет и отчетность проектов ведутся в соответствии с установленными FASB (Financial Accounting Standards Board) и FASAB (Federal Accounting Standards Advisory Board) – стандартами для государственных и частных компаний. Их правила финансового учета и отчетности не конфликтуют с Agile. В то же время есть юридические факторы, препятствующие использованию Agile во внешних проектах. В США финансирование таких проектов попадает под правила учета для капитальных вложений (CAPEX), где действуют правила: финансистам заказчика ПО необходимо предварительно рассчитать стоимость проекта и предполагаемый доход от его создания и внедрения. Они это могут сделать только на основе разработанных требований к создаваемому ПО. Точность расчета стоимости проекта и дохода от его реализации прямо связана с детальностью разработанных требований и их качества. Философия Agile и Скрам напрямую не согласуется с этим подходом. В ней не предусматривается выделенных этапов проектирования, согласования его результатов, оценки стоимости всего проекта и формирования плана выпуска, поставки и внедрения ПО. Кроме этого, итерационные поставки ПО в Скрам попадают под категорию постоянных эксплуатационных расходов (OPEX) и должны так и учитываться, а это опять вступает в противоречие с правилами регулятора. Таким образом, в США «чистый» Agile конфликтует с требованиями финансового учета и правилами управления бизнесом[61]. Обучение Данные Standish Group показали, что каждый раз, когда команда повышает уровень знаний, вероятность успешной реализации проекта увеличивается на 23 %[62]. Особые принципиальные ограничения для внедрения Agile в российских условиях: сезонность финансирования; авторитарность и иерархия коммуникаций, бюрократия и формализация процессов; неконтролируемое увеличение бюджетов и сроков; использование несовременных подходов к управлению и др.

9.4. Agile-трансформация Порвите свои визитки, избавьтесь от званий и титулов, от руководителей и иерархических структур, дайте людям свободу делать то, что они считают правильным, и возможность нести за это ответственность. Результаты вас поразят. Джефф Сазерленд. Scrum. Революционный метод управления проектами

Множественные примеры внедрения Agile в деятельность компаний показывают, что оно требует целого комплекса важных мероприятий. В целом возможны подходы снизу вверх и сверху вниз. Подход снизу вверх. В организации создается одна Agile-команда. В зависимости от условий проекта и компании выбирается конкретный фреймворк или их комбинация. Затем формируются архитектура гибкого проекта, задачи и цели, вектор движения, первоначально объявленный срок, первое число и размер спринтов и другие компоненты работы над проектом. Если команда не владеет базовыми идеями и принципами Agile, ее надо обучить. Если часть знаний уже есть, можно проверить на их достаточность. Правильного скрам-мастера лучше подобрать заранее, возможно, ему стоит поучаствовать в обучении или «подкачке» знаний. В отсутствие компетентов компании придется обратиться к специалисту по Agile. Он продемонстрирует суть Agile, разъяснит смысл работы, состав спринтов и действий, функции команды, особенности взаимодействия между ними и другие вопросы. Следующим шагом будут первые опыты с Agile, то есть первые спринты или проекты. Абсолютно нормальны и неизбежны ошибки, недочеты, нестыковки, отставания. Членам команды придется, возможно, отказаться от одних привычек или правил и заменить их другими, возможно, менять роли и взаимодействие между людьми в команде или самих участников. Остальные сотрудники компании, увидев довольных жизнью коллег с горящими глазами, скажут: «Мы тоже так хотим!» И постепенно, по цепочке, по проекту, по подразделению вся организация становится Agile. Этот путь более органичный, но долгий. Реализация масштабирования также будет напоминать Agile с внесением изменений и обратной связью. При такой адаптации компания привыкает к Agile, а Agile подстраивается под нее. Но руководство компании, решившей перейти к Agile, также должно четко понимать, готова ли организация к изменениям, можно ли применять систему к своим проектам и т. д. Подход сверху вниз. Это Agile-трансформация компании целиком, фактически превращение ее в Agile-компанию и связанное с этим изменение организационной структуры на холакратию и «бирюзовость». Руководители организации решают жить по-новому. Они садятся – с консультантом или без – и планируют заново всю структуру. Делят людей на команды, объединяют их в племена, звенья, группы, обучают сразу всех сотрудников новому подходу к работе, «подкручивают» корпоративные процессы во всех областях – от HR до финансирования. Этот подход хорош тем, что предполагает масштабные изменения, которые могут дать быстрый результат. Вся организация делает большой скачок, не возникает проблем с тем, что кто-то уже перешел на Agileрельсы, кто-то – еще нет. При таком подходе и при одновременном проведении изменений в организационной структуре, процессах, общении с внешними заказчиками, упрощении и оптимизации коммуникаций, повышении мотивированности сотрудников важнейшее значение имеет внедрение Agile-культуры. Это фактически полностью изменяет компанию, превращая ее в Agile-компанию, что добавляет ей уникальное преимущество по сравнению с ее конкурентами, поскольку такие компании:

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

9.5. Что помогает и мешает внедрению Agile Почему столько людей утверждают, что они занимаются управлением проектами, хотя на самом деле они занимаются «тушением пожаров»? Колин Бентли, автор книг и статей по PRINCE2®

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

равноправием всех. Руководству надо передать полномочия и ответственность сотрудникам, членам команды, которым, в свою очередь, это надо принять и уже не ждать постоянных указаний сверху. Сотрудникам нужно научиться доверять друг другу и общаться как роли, а не как функции или должности. Восемь правил проведения изменений Джон П. Коттер в своей книге «Впереди перемен» привел восемь правил проведения перемен, которые в полном объеме могут быть применены к Agileтрансформации. Достаточно просто вставить эти два слова в текст. 1. Создать атмосферу безотлагательности действий по трансформации вследствие реальных угроз и потери благоприятных возможностей. 2. Сформировать влиятельные и полномочные команды для трансформации (объединив усилия влиятельных сотрудников, агентов перемен; поощряя деятельность участников сформированной команды). 3. Создать видение желаемого будущего и пути перехода. 4. Пропагандировать новое видение и культуру (используя доступность изложения, метафоры, аналогии, примеры таких моделей и новое Agileповедение команды реформаторов). 5. Создать условия для претворения видения в жизнь (устраняя блокирующие новое поведение препятствия; изменяя структуры и обязанности, противоречащие новому видению; поощряя творческий подход и готовность рисковать). 6. Спланировать ближайшие результаты и достичь их (планируя обязательные первые шаги; вознаграждая и пропагандируя первые успехи). 7. Закрепить достижения и расширить преобразования (создавая атмосферу доверия к новым подходам; меняя кадровый состав и проводя кадровые перестановки; распространяя успешный опыт по всей организации). 8. Институциализировать новые подходы (формализуя правила поведения; выстраивая взаимосвязь между результатами и вознаграждениями; создавая условия развития для новых качеств сотрудников). Что может препятствовать внедрению: ✓ трудно интегрировать Agile в уже существующую жесткую вертикальную систему контроля и длинные циклы бюджетирования, функционально организованную структуру. Влияние отрасли, партнеров, поставщиков также может создать трудности с внедрением; ✓ Agile внедряется больше не как метод повышения эффективности проектов, а как культура повышения ценности результатов путем правильного выбора проекта и способа его реализации. Иными словами, с появлением Agile проекты не обязательно будут лучше, возможно, будут выбраны другие проекты, но с гораздо большей ценностью в итоге; ✓ обучение персонала идет по функциональным принципам, вопросам взаимодействия, делегирования, лидерства, командной работе не уделяется внимания. А иногда не происходит никакого обучения персонала вообще;

✓ отсутствие у руководства понимания и целей внедрения. Потеря его интереса и участия в середине процесса; ✓ нежелание проводить кадровые изменения, перестроения, замены. Доминирование «водопадного» мышления. Сложности внедрения 1. Исследования Scrum Alliance показали: более 70 % специалистов, работающих по Agile, сообщают о непростых отношениях между своими группами и организацией. Отмечались реализация разных планов и разная скорость. 2. Крупная финансовая компания в качестве пилотного проекта начала разработку нового мобильного приложения по Agile. Для набора группы была подана заявка на утверждение и финансирование проекта, которая вместе с другими пошла по инстанциям, чтобы ее одобрили и включили в план на следующий год. Спустя три месяца ее наконец утвердили. Проект был реализован, получилось удачное приложение, сразу же оцененное пользователями. Группа проекта была удовлетворена этим промежуточным результатом. Для выпуска приложения на рынок его стали тестировать на «уязвимость», но с применением традиционной «водопадной» модели в порядке общей длинной очереди. Затем в виде «Водопада» за 6–9 месяцев реализовали интеграцию приложения в основные ИТ-системы. В общем итоге время проекта от начала разработки до выпуска почти не сократилось. 3. Среди основных проблем внедрения Agile (отчет о применении Agile за 2016 г. и тенденциях в мире от VersionOne): 33 культура и философия компаний противоречат основным ценностям Agile – 63 %; ✓ недостаток опыта в Agile – 47 %; ✓ недостаток в поддержке менеджмента – 45 %; ✓ общая сопротивляемость организаций к изменениям – 43 %; ✓ недостаточность обратной связи от бизнеса/заказчиков/владельца продукта – 41 %; ✓ недостаточность подготовки/знаний – 34 %[63].

9.6. Как влияет корпоративная культура Проектные менеджеры действуют как лидеры рок-группы: собирают вокруг себя музыкантов, играющих на разных инструментах, и заставляют играть в едином ритме. Под руководством лидера они играют одну песню. Леонард Р. Сейлс. The Rise of Rogue Executive

Agile не живет там, где доминирует бюрократическая культура, нет открытости. Agile крайне затруднен в глобальных корпорациях с иерархическими матричными организациями, где гибкому подходу сложно, например, в связи с отсутствием планирования в Agile в классическом его понимании. Agile малоприменим в сильно зарегулированных организациях с высоким уровнем

стандартизации и госрегулирования – фармацевтике, аэрокосмической отрасли или производстве медицинского оборудования. Тут смогут жить отдельные команды, но весь процесс идет по «Водопаду» – для возможности его отслеживать, контролировать и вовремя формировать отчетность. Пространство для маневра немного выше при разработке сложных интегрированных продуктов со множеством различных компонентов, которые зачастую производятся по жестким предопределенным требованиям заказчика, но оно все равно невелико. И наконец, также немного свободы для Agile в ИТдепартаментах, в организациях, осуществляющих поддержку функционирования организации в областях, связанных с ИТ. Вильям Шнейдер в книге «Реинжиниринговая альтернатива» дал свою классификацию культур (рис. 9.2) (https://scrumtrek.ru/ blog/agile-transformatsiyai-korporativnaya-kultura).

Рис. 9.2. Классификация культур по Шнейдеру

Культура контроля. Мы все контролируем, мы всегда знаем планы наперед и следим за прогрессом их исполнения. Важны стандарты и процессы. Менеджеры говорят: добиваться объективных результатов по утвержденным

процессам невозможно – реальное их исполнение как итальянская забастовка. С другой стороны, сотрудники требуют утвержденного регламента, не понимая, что им делать без четкой инструкции. Жесткая вертикальная иерархия, часто избыточная. Руководство не доверяет сотрудникам принятие ключевых решений. Подчиненные не берут на себя инициативу. Очень похоже на «янтарную» структуру Ф. Лалу (см. раздел 9.2). Культура компетенций. Культ профессионализма. Эти компании предпочитают нанимать готовых опытных специалистов вместо новичков, не умеют развивать новичков до необходимой компетенции: новых сотрудников собеседует только начальник или ведущий эксперт, о привлечении коллег к принятию решения о вознаграждении или увольнении речи не идет, нет или слабо выражены процессы кураторства и ввода в строй новичков – нет соответствующих инструментов. Четкая сетка грейдов. Каждый сотрудник понимает свою роль и компетенцию в сравнении с коллегами. От компетенций зависит заработная плата. Культуры взаимодействия и развития. Ориентир на потребности настоящего и важность людей. Люди достигают успеха, стараясь любую работу выполнять сообща, командой. Это основная область применения Agile, где он работает. Инвестирование в будущее компании с пониманием, что компания – это и есть люди. Взращивается культура развития. Компания стремится не только к бизнес-результатам, но и к созданию комфортной среды для развития и самореализации своих сотрудников. А это уже ближе к «бирюзовости» Ф. Лалу (см. раздел 9.2). Корпоративные культуры в различных подразделениях, функциях и командах предприятия, особенно крупного, могут различаться. Системные администраторы, работающие в технической поддержке, – это культура контроля. Команды разработки сервисов в своем подразделении или сотрудники R&D – это культура взаимодействия. Культурные различия на стыке функций вызывают конфликты и, как следствие, замедляют компании, приводя иногда к невозможности внедрения Agile в целом. Так, например, руководитель отдела с культурой взаимодействия и развития будет защищать свое подразделение от авторитарного стиля управления всей крупной компании. И если он уходит, то в отсутствие лидера внешняя корпоративная культура убивает внутреннюю – люди разбегаются или принимают новые правила. Значимую поддержку окажет Agile – проектный офис (см. раздел 9.8). В условиях российских предприятий и длительного и позднего перехода к новой для России культуре управления также есть ряд моментов. Например, это сложившаяся культура управления, основанная на жесткой иерархии или принципе «я – начальник, ты – дурак», что очень сложно изменить, поскольку требует изменения мышления первых лиц компаний или ряда радикальных шагов по ее перестройке. Особенно это сложно в условиях отсутствия у первого лица какой-то значимой оппозиции. Поменять же для ускорения трансформации большую часть руководящего звена в компании вряд ли удастся. В качестве другого примера – крайне низкий уровень ответственности и осознанности у большинства сотрудников в больших среднестатистических российских компаниях, что связано не с тем, что люди плохие, а со сложившимися привычками и правилами. Огромное значение играет и довольно низкий уровень доверия, что противоречит Agile-культуре, которая

основана на взаимном уважении и доверии. Крупные производственные структуры, многопрофильные холдинги, добывающие компании пока крайне недоверчиво относятся к Agile, и, возможно, к Agile они придут последними. Внедрение на практике 1. Интересный процесс внедрения в банковской группе ING описан в статье «Agile-трансформация в банковской группе ING» по ссылке http://shsrus.com/blog/posts/agile-transformatsiya-v-bankovskoy-gruppe-ing-perevod-stati-otshs. 2. Скрам, портфельное управление и отчетность. В глобальной компании, разрабатывающей мобильные технологии, был замечен отрыв Agile-команд, занимающихся в основном разработкой ПО, от остальной организации и стратегических целей. Они практически не взаимодействовали с подразделениями, разрабатывавшими оборудование и аппаратное обеспечение. Это сказывалось на качестве конечного продукта и приводило к необходимости переделывать код, что, в свою очередь, влияло на сроки, перерасход бюджета и соответствие изначальным требованиям. Для решения проблемы организовали совещание с участием 16 стейкхолдеров: владельцев продуктов и проектных менеджеров. По их словам, аудиторию, где все собрались, разделяла невидимая, но ощутимая стена, отделявшая владельцев продуктов и скрам-мастеров от проектных менеджеров и членов проектного офиса. Во время встречи каждая группа критиковала другую и обвиняла во всех проблемах. Члены Agile-команд обвиняли «водопадников» во вмешательстве в их работу: в изменении требований, переводе людей из команды проекта, изменении процесса контроля, а также в появлении на ежедневных летучках и уличении их в недостижении результатов. Проектные менеджеры и члены проектного офиса, в свою очередь, винили «Agile-фанатиков» в срывах сроков, неготовности к изменениям, отсутствии прогресса и отчетов о состоянии проекта. Было решено реализовать интеграцию культур и методов. В проектном офисе был найден лидер, которого признавали и которому доверяли члены обеих групп. Увеличили прозрачность и измеримость еженедельных достижений Agile-команд и защитили их от вмешательства во время спринтов. Это вызвало недовольство со стороны «водопадников». Они боялись потерять контроль над проектом. Увеличили адаптивность и продолжительность спринтов для синхронизации и интеграции с процессом разработки аппаратного обеспечения. Такое решение вызвало негативный отклик со стороны лидеров Agile-команд, однако с этим тоже смирились. После данных изменений вместе с руководителем проектного офиса был налажен процесс формирования проектным офисом отчетности по проектам. Для этого перевели документацию в Agile-форму, применяемую всей остальной организацией: «диаграммы сгорания», пользовательские истории и журнал требований. После того как эти и многие другие функции принял на себя проектный офис, он стал полноценным Agile – проектным офисом. На следующем этапе усилили интеграцию между разработчиками ПО и аппаратного обеспечения. Для этого были созданы мультидисциплинарные команды по внедрению элементов Скрама и Канбана в командах аппаратного обеспечения. В итоге в течение года удалось существенно сократить издержки и время, необходимое для

создания продукта. Agile – проектный офис стал проводником изменений и привел к достижению результатов проектов[64].

9.7. Обучение Agile Складывай малое с малым и получишь большую кучу. Овидий

Обучение Agile даже при кратковременном применении является ключевым фактором успеха любого Agile-проекта и Agile-трансформации. Обучение может быть проведено опытным скрам-мастером для конкретной команды или Agile-тренером либо коучем для ряда команд или всего предприятия. Agile-коучи – это специалисты, которые помогают компаниям изменить мышление и перейти на Agile. Они строят новую культуру в компании, объясняют смысл изменений, советуют, как эффективно организовать работу. Хороший Agile-коуч вдохновит коллектив на изучение нового, поможет справиться с сопротивлением, инициирует и доведет до конца Agileтрансформацию. Обучение может быть направлено на конкретную специфику проектов, например маркетинговые проекты, проекты разработки, проекты развития бизнес-процессов и т. п. Обучение Agile подходу в верхнеуровневом управлении проходят сейчас не только сотрудники и лидеры крупных компаний, но даже представители правительств (Норвегии, Новой Зеландии). В системе управления образованием Agile внедрен в университетах Cornell University и Northern Arizona University, в России изучение Agile как методологии управления проектами уже входит в ряд учебных программ. Программы обучения обычно формируются по классическим типовым («водопадным») правилам: оценка потребностей, оценка умений и знаний, формирование контента и формата программы, проведение самого обучения, оценка на выходе, последующий контроль и поддержка в течение рабочих процессов. Однако при обучении Agile можно и нужно использовать его же подходы: ♦ сформировать роль владельца продукта из: а) руководителя подразделения, где впоследствии будет работать команда, или б) руководителя будущего проекта, или в) скрам-мастера, который потом примет команду в свои руки; ♦ собрать пользовательские истории и оформить журнал требований; ♦ на первом спринте рассказать про базовые ценности и принципы Agile, создать терминологию, сформировать понятия; ♦ провести ряд обучающих спринтов с итоговой оценкой, сбором обратной связи, оптимизируя при необходимости содержание последующих спринтов; ♦ по окончании цикла сформировать спринты поддержки знаний в дальнейшем. Обучение Agile, помимо «теории», должно наполняться живыми, игровыми упражнениями, в основе которых также будут Скрам или Agile. Ниже приведены примеры подобных игровых решений.

1. Игра в Скрам. Игра по созданию важного для компании продукта или результата, например отчета, сценария корпоративного Нового года, юбилейного вечера для руководителя, нового брендбука. Для участников формируется легенда компании, или они используют свою корпоративную ситуацию. Формулируются очертания (направление) проекта: «Что сделать?» Указывается, что надо представлять по итогам работы. Слушателям дается уже приоритизированный и записанный в формате пользовательских историй журнал требований к продукту (product backlog). Лучше ограничиться 5–10 историями. И далее объявляется расписание работы по нескольким спринтам, которое включает: • напоминание правил, чтение легенды; • планирование спринтов; • сами спринты; • летучки; • обзоры спринтов в виде демонстрации от каждой команды; • ретроспективы; • финальную демонстрацию всего итога. 2. Игра с кирпичами Lego. (Alexey Krivitsky, info@lego4scrum. com). 3. Игра в пиццу Kanban Pizza Game (www.agile42.com/training/ kanban-pizzagame). 4. Игра по сортировке терминов. Участники делятся на группы по 2–4 человека и сортируют пачку терминов, которые относятся либо к ролям в Скраме, либо к ритуалам, либо к артефактам. Берется роль или ритуал, и каждый участник или группа по очереди называет характеристику, функцию или аспект, который они отнесли к названному. Если остальные группы тоже отнесли термин к этой роли, они кричат «Подтверждаю!» или «Бинго!». Если нет единства в группах – начинается обсуждение. После работы в группах материал лучше закрепить общим обсуждением и уточнением, чтобы не было ошибок в понимании и разницы в трактовке. Можно просить участников привести практические примеры (https://tim.com.ua/2016/11/ scrum-roles-exercise-with-agile-topicscards/). 5. Карточки Джимми Джанлена, шведская консалтинговая группа Crisp. Создать карточки с терминами, ритуалами, артефактами, ролями. Карты могут быть трех типов: «Практика, методы и инструменты» (зеленые), «Темы для обсуждения» (синие), «Абстрактные модели и теории» (красные). Джимми предлагает на своем сайте и сами карточки[65]. Вариант 1. Выбор темы для обсуждения в формате Lean Coffee. Формат описан во врезке на с. 273. Перетасовать колоду. Раздать каждому по три карты, из которых участник должен выбрать одну. Голосуем. Запускаем Lean Coffee с наиболее важными темами. Вариант 2. Обсуждение один на один – отличный вариант для парного коучинга. Нарисовать пять карт каждому. Каждый выбирает по две. Обсудите эти темы в течение следующего периода.

Вариант 3. Аудит/оценка состояния команды или организации: выберите определенные карточки и проанализируйте, знают или не знают про эти термины в команде, делают/не делают и т. п. В группе предварительно выберите 30 карт. Нарисуйте оси координат Х и Y. Для каждой карты оцените, насколько вы осведомлены о теме, «да» или «нет» (ось Х), и делаете это «правильно» или «неправильно» (ось Y). Затем обсудите, что вы хотите улучшить. Вариант 4. Обед Lunch’n’Learn. Кто-то из волонтеров проводит короткий семинар за обедом по одной из тем. Вариант можно повторять. Вариант 5. Личное развитие: выберите карточку и за 20 минут попробуйте найти в Google как можно больше информации на эту тему. Вариант 6. Тема недели: выберите карточку и повесьте ее на видном месте, чтобы в течение недели побуждать обсуждение этой темы командой. Вариант 7. Рассказ историй: произвольно выберите 4–5 карточек и рассказывайте с их помощью истории. 6. Работа с карточками[66]. • Всем участникам раздаются выбранные карточки, и каждый по очереди рассказывает своему соседу о том, что знает на эту тему. Затем один ряд участников сдвигается и новые пары повторяют обсуждение. • Можно договориться о практиках и принципах, которые будет применять команда по группам: необходимые, полезные и просто интересные. • Сортировка связанных терминов в виде пазла. • Сортировка карточек по категориям «прекратить», «начать» и «продолжить», что хорошо подойдет для ретроспективы или просто командного обсуждения совместной работы. • Карточки можно использовать для игры в «крокодила». Первая команда передает игроку второй команды карточку с термином, а он должен изобразить его только знаками, без слов, или хотя бы не используя ключевые слова. Члены второй команды должны угадать, что это за термин. LEAN COFFEE Структурированная встреча с гибкой повесткой дня. Стартовала в 2009 г. в Сиэттле[67]. Участники собираются, создают повестку дня и начинают обсуждение. Беседа направленна и продуктивна, поскольку повестка сгенерирована самими участниками самостоятельно и демократично. Сегодня десятки встреч проходят в разных городах мира. 1. Накидываем вопросы для обсуждения. Создаем простую канбан-доску: «Обсудить», «В процессе обсуждения», «Обсуждено». Участники пишут на стикерах вопросы, которые им интересно обсудить или рассказать в рамках темы встречи. 2. Выбираем вопросы, которые будем обсуждать. Путем общего голосования выбираются вопросы, наиболее интересные всем участникам. Вопросы с наибольшим количеством голосов обсуждаются в первую очередь.

Например, тема: как повысить конверсию целевой страницы? И все участники обсуждают свой опыт или проблемы при работе с конверсиями целевых страниц. 3. Голосуем и обсуждаем. После обсуждения одного вопроса происходит быстрое переголосование приоритета тем для обсуждения. Время обсуждения темы оговаривается участниками.

9.8. Гибкий проектный офис Чем более смешными являются сроки, тем больше стоят попытки выполнить их. Гарольд Керцнер

В одном банке меня как-то спросили, как решить конфликт между «водопадным» правлением и Agile-подразделениями, занимающимися разработкой сервисов. Я сказал: попробуйте гибкий (Agile) проектный офис. Такое решение выглядит как посредник между независимыми Agile-командами и остальной организацией, работающей по классической «водопадной» методологии. Гибкий проектный офис в разных корпоративных форматах может играть разные роли. ♦ Он может быть ценностноориентированным и существовать для курирования создания бизнес-ценности в масштабах всей компании, консультировать руководство об относительной бизнес-ценности конкретного проекта или группы проектов, создавать необходимые условия для достижения этой цели. Офис формирует мышление сотрудничества с заказчиком, работает как консультант, адаптирующий свою работу для удовлетворения особых нужд, заявленных проектом, помогая инструментами и шаблонами или стратегическим коучингом. Офис стремится к поставке всего необходимого и следит за нуждами заказчиков, будучи уверенным в том, что он знает их нужды и способен адаптировать свою работу для их удовлетворения. Эти действия офиса считаются наиболее ценными для поддерживаемых им проектов. ♦ Офис может быть ориентирован на вовлечение. В соответствии с основанной на ценности концепции у гибкого проектного офиса могут появиться функции сделать обязательными определенные решения или подходы, например обязать всех делать что-то одинаково, чтобы добиваться быстрых результатов. Также важно стремление к вовлечению сотрудников. Это достигается на первом шаге за счет привлечения только тех, кто заинтересован в использовании услуг гибкого проектного офиса. А дальше чем шире участие в практиках офиса, тем легче данные практики становятся привычными. Если при этом офис поставляет своим клиентам ценность, то вероятность, что клиенты будут обращаться за его услугами и принимать его практики, будет выше.

♦ Гибкий проектный офис может быть многопрофильным. Для обеспечения поддержки особых потребностей конкретного проекта офису необходимо обладать компетенцией в нескольких областях, помимо собственно управления проектом, так как разные проекты требуют особых возможностей. Например, в одном проекте может быть необходимо разработать организационную структуру для решения кадровых вопросов, а в другом могут потребоваться методы управления организационными изменениями для привлечения заинтересованных сторон или уникальные бизнес-модели для поддержки целей заказчика. ♦ Офис как центры компетенций. Он может оказывать помощь командам проектов в достижении стоящих перед ними целей или обучать команды (или организовывать обучение), а также осуществлять поддержку проектов. Изменения, вызванные внедрением Agile, также могут управляться таким офисом, включая изменения и в нем самом. В этом случае они оказывают среди прочих следующие услуги: • разработку и внедрение стандартов; • подготовку шаблонов для пользовательских историй, тестовых заданий, «диаграмм сжигания» и др.; • предложение инструментов Agile; • координацию обучения, самого обучения и коучинга; • координацию перехода к Agile, содействие в переходе к образу Agileмышления; • поощрение и обеспечение участия людей в локальных Agile-мероприятиях; • управление некоторыми проектами; • координацию работы нескольких Agile-команд; • обмен информацией по ходу исполнения проектов, по проблемам и результатам ретроспектив, а также эксперименты по совершенствованию; • помощь в организации крупных релизов для заказчиков на уровне программы и направлений инвестирования на уровне портфеля с использованием соответствующего фреймворка; • анализ профилей скоростей проектов, а также получение, хранение результатов ретроспектив; • управление заинтересованными сторонами; • обучение владельца продукта и консультирование по вопросам тестирования, оценки и осуществления обратной связи; • рекомендации по выбору экспертов по предметным областям для проектов; • набор, отбор и оценку лидеров команд; • разработку указаний по проведению собеседований с теми, кто использует Agile; • исполнение специальных задач для проектов. В большой глобальной корпорации с жестким контролем работы проектов, применением «водопадной» методики такой офис будет буфером между Agile-

командой и организацией. Основной задачей его станет подготовка отчетности необходимой формы, перевод документации в нужный компании формат, а также оценка выполнения планов. Владелец продукта может быть членом офиса, процесс инициации и закрытия проекта также можно передать в офис. В сильно зарегулированных отраслях со строгим контролем и необходимостью документации всего, включая риски продукта, гибкий проектный офис может играть административные функции, заниматься документацией. Управление рисками продукта, основанными на жизненном цикле, проводится вместе с командой проекта. В журнал продукта добавляются нефункциональные данные, требуемые для контроля и отчетности. Журнал ведет гибкий проектный офис. Персонал офиса отслеживает соответствие продукта требованиям. Административные функции позволяют офису действовать гибче. Административный персонал проектного офиса может также выступать в качестве дополнительного владельца продукта, чтобы отслеживать соответствие своим требованиям. Разработка комплексных продуктов с жесткими требованиями может иметь проблему в том, что гибкость ограничена описанием продукта (product scope) и не дает реализовать гибкость Agile. Разработка аппаратного обеспечения не всегда укладывается в философию Agile. Гибкий проектный офис ведет журнал продукта, взаимодействуя с его различными компонентами. Основная цель – поддержка гибридного процесса разработки Agile и традиционного линейного. Это наиболее сложный сценарий, поскольку необходим широкий набор технических и административных компетенций, а также лидерство. Практика показывает, что при креативном подходе даже в «жестких» продуктах применение Agile возможно. Жесткие требования обычно допускают изменения показателей в рамках 20 %. Максимум ценности при таком сценарии – в разработке индивидуального гибридного подхода. Итеративный подход позволит повысить гибкость процесса разработки, однако это не всегда возможно. И наконец, в ИТ-департаментах организаций, где присутствуют постоянные изменения в плане работ, затруднение планирования из-за появления частых экстренных задач и отсутствия настоящего владельца продукта, офис берет на себя роль владельца продукта – собирает заявки от функциональных подразделений, планируя работу и распределяя нагрузку команд. Неудачные попытки применения методологии привели к изматыванию команд и формированию у них образа Agile как манипулятора командами ради повышения производительности без реальной административной поддержки. Для таких условий лучше подходит Канбан. Итеративная схема работы может дать положительный результат, однако необходимо внедрить определенный буфер для решения экстренных задач в каждом спринте. Длина спринта может меняться.

9.9. Гибкий руководитель проекта Если вам никогда не приходилось закрывать проект, вы не были эффективным руководителем проектов. Вуди Уильямс

Ранее в основном речь шла о четырех ролях: заказчике, владельце продукта, скрам-мастере и команде разработки. Есть ли в Agile-проектах руководитель проекта? Или его функции выполняет кто-то из играющих перечисленные роли? Кен Швабер говорит нам о том, что менеджеры проекта нарочно не были добавлены в Скрам. По его мнению, они пагубно влияют на умственную работу, а также снижают творческий потенциал и интеллект команды. Назначение руководителя классического проекта – успешно завершить проект. Он ориентирован на выполнение всего объема работ в срок и в рамках бюджета. Заказчик может вносить изменения в объем через управление изменениями. Такому руководителю требуются навыки в управлении процессами разработки, в работе с людьми и ресурсами, в работе с требованиями, в контроле качества и рисков. Треугольник талантов от PMI ® как совокупность компетенций руководителя проекта – технические навыки управления проектами, лидерство, навыки стратегического управления и управления бизнесом (см. PMBOK® Guide 2017) – также предполагает наличие понимания бизнес-потребностей проекта и стратегии компании в целом. Руководитель Agile-проекта (далее Agile РП) действует несколько за рамками тактического управления командой, занимается общей стратегией и координацией проекта. Однако Agile РП дополняет свои навыки РП в классике уникальным умением принимать решения и действовать в контексте стремительных, изменчивых проектов в условиях разработки по Agile. Он ориентирован на ценности. Он – уникальный специалист с весьма специфическим набором навыков, которые позволяют ему владеть по мере необходимости частью обязанностей двух или нескольких ролей одновременно. Он направлен на достижение цели, но не через выполнение всего объема требований, а через минимизацию этого объема для приближения сроков получения прибыли. Agile РП становится критически важным в обеспечении прогресса и успеха распределенных проектов. Типы Agile-менеджера по Х. Книбергу Агент изменений – будучи в центре между скрам-командами и другими отделами, Agile-менеджер может и должен объяснять другим отделам выгоды от следования Agile-принципам. Заполнитель ролей – берет на себя невзятые активности, например: поиски стратегических партнеров; координацию нескольких команд или продуктов; устранение высокоуровневых препятствий. Супервладелец продукта – если у вас ведется разработка нескольких продуктов, то, возможно, он возьмет на себя работу с журналом требований на уровне компании, который послужит источником для менеджеров конкретных продуктов. Координатор ресурсов – если у вас несколько команд, то его функция, например, обмен опытом или ресурсами. Мотиватор, «смазка», «пожарный» – тренер, устранитель препятствий на уровне компании или защитник команд от «внешнего шума»[68]. Agile РП может дополнительно помогать скрам-мастеру решать вопросы размещения команды; проводить обучение и наставничество проектной команды; вместе с владельцем продукта наполняет журнал требований, стараясь глубже понять бизнес заказчика и факторы, которые на него могут повлиять; участвует в создании бэклога спринта с проектной командой;

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

9.10. Документация и отчетность в Agile Команды проекта ненавидят отчеты по прогрессу проекта, поскольку они наглядно демонстрируют отсутствие прогресса. Гарольд Керцнер

В каскадных подходах документирование – это предопределенная и обязательная деятельность, которая отнимает массу времени. Переход к Agile означает, что надо переосмыслить способ документирования, дабы избежать траты времени на то, ценность чего неочевидна. Но это не означает, что документировать не надо вообще. Адаптация к изменениям, применяемая в Agile, также говорит о том, что, чтобы избежать ненужных трат времени, документация в Agile должна создаваться, только когда это необходимо. Для лучшего понимания необходимости можно создать чек-лист с рядом вопросов и проработать его с ключевыми заинтересованными сторонами. Среди таких вопросов могут быть следующие. ♦ Для чего нужна эта документация? Для поддержки разработки? В качестве функционального справочника? ♦ Что за целевая аудитория у данной документации? Какой именно человек? Какой отдел? Или это заказчик? Или будущие команды поддержки? ♦ Как целевая аудитория будет использовать данную документацию? Как справочник? Как руководство? ♦ Сколько стоит создание указанной документации? Сколько времени займет ее создание? Кто это будет делать? По итогам определяется «необходимая и достаточная» документация. Далее, уяснив, почему и сколько документировать, определяется сама документация – учебники, методички, руководство по эксплуатации, описание бизнес-правил, описание системы, техническая и функциональная информация, Конкретные документы надо привязать к каждой стадии проекта: что перед началом проекта, что во время проекта, что после того, когда продукт будет разработан и выпущен? Также документация должна создаваться по мере того, как появляются новые разработанные функции. Основное место хранения документации – в постоянно обновляющемся репозитории, доступном своей целевой аудитории на всем протяжении проекта и при его последующей поддержке. Примерами документации в Agile могут быть:

♦ стартовая документация в начале проекта – простой устав, дорожная карта, диаграмма высокоуровневой архитектуры проекта с высокоуровневыми компонентами решения, критерии приемки продукта (критерии, согласованные между командой и владельцем продукта, по которым можно будет определить, что проект завершен), описание главных характеристик разрабатываемого продукта, журнал требований продукта, устав команды, ее состав и т. п.; ♦ во время проекта – пользовательские истории на спринты (Я, , хочу , чтобы ); критерии приемки пользовательских историй, версии журнала требований продукта, журнала требований спринта, создаваемые для заказчика документы в конце спринта; скрам-доски; «диаграммы сгорания и сжигания»; актуальная функциональная и техническая документация и т. п.; ♦ постпроектная документация – техническая и функциональная документация для заказчика, отчеты, итоги финальной ретроспективы. Метрики Популярны четыре направления метрик в Agile-проекте. 1. Производительность. Velocity: измеряется количеством выполненных задач в итерацию. WIP (work-in-progress): определяет лимит задач на разных стадиях, и чем он выше, тем хуже. 2. Прогнозирование. Capacity: определение количества идеальных часов, доступных в следующем спринте, чтобы понять, сколько времени есть на работу, насколько эффективно выполнение задач и как спланировать количество задач для спринта. 3. Качество. Индекс стабильности требований рассчитывается по формуле: индекс стабильности требований = (общее количество оригинальных бизнестребований + число требований, которые изменились к этому времени + число добавленных требований + число убранных требований) / общее число оригинальных требований. Количество времени, затраченное на переделывание задач. 4. Ценности. Просчитывается индивидуально в зависимости от проекта. Например, стартап AirBnb в качестве метрики, определяющей конечную ценность продукта для пользователей, выбрал количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей[69]. Немаловажен также вопрос юридического оформления Agile-деятельности и взаимодействия с внешней командой разработки, а именно важность в ряде случаев так называемого Agile-договора или контракта, пример которого приведен в приложении 2.

9.11. Программные продукты для Agile Среди основных и наиболее популярных продуктов можно отметить следующие. 1. Trello. Это популярное решение для управления задачами в режиме онлайн, особенно для небольших компаний и стартапов, которое позволяет эффективно организовывать работу со скрам- и канбан-досками. Три элемента, на которых держится структура организации проектов в Trello, – это: • доска (board) – один рабочий экран, который логически разделен на списки; • списки (list) – вертикальные ряды для хранения карточек; • карточки (card) – специальные формы для описания задач. Карточки можно как двигать внутри одного списка, так и свободно перемещать между списками или досками. Списки тоже можно перемещать. Для любой задачи можно назначить людей, ответственных за ее выполнение. Trello предлагает множество полезных возможностей для оформления, настройки и управления своими функциональными элементами. К недостаткам можно отнести слабость функционала Trello для действительно крупных компаний; неудобство работы на маленьких экранах; сложность автоматизации, повторения и быстрого добавления задач. Среди достоинств Trello: • облачное решение, электронные доски с карточками могут отображаться у всех участников; • есть приложение для смартфона или планшета, можно пользоваться системой в дороге; • простой интерфейс; • неограниченный бесплатный доступ к урезанному функционалу; • возможность параллельно отслеживать статус разных задач на одном экране; • удобство в работе и возможность интеграции с другими популярными инструментами для онлайн-работы; • универсальность и гибкость, комфортность работы; • простой инструмент, который легко внедрить в рабочий процесс без долгой адаптации со стороны персонала; • доступность; • возможность быстро оценить прогресс по всем основным процессам сразу, в режиме реального времени и на одном экране; • его можно использовать как личный органайзер, дневник, список, коллективный to-do-менеджер. 2. Jira. Atlassian Jira Project Management Software – одна из наиболее совершенных систем управления проектами на рынке, позволяющая отслеживать выполнение задач. Продукт позволяет представить текущий рабочий процесс как набор задач и удобно оперировать ими вместе и по

отдельности. Каждая задача – отдельно созданный элемент с настраиваемыми параметрами. Приблизительная форма может выглядеть так: • название – к какому проекту относится задача (должно кратко и четко отображать суть); • тип задачи; • приоритет – насколько критическим является выполнение или невыполнение этой задачи; • компоненты; • статус; • содержание – подробное и детальное описание. Дополнительно к задаче можно приложить картинку или скриншот, а также оставить комментарий для уточнения деталей. Создав задачу, можно указать, какой участник проекта должен ее выполнить. В свою очередь, тот, на кого поставлено задание, может отказаться от его выполнения и перенаправить обратно или же согласиться – и тогда отправить уже выполненное задание для проверки. Электронная скрам-доска позволяет быстро увидеть, какие из задач еще только запланированы, работа над какими уже реализовывается, а какие уже сделаны. Среди характеристик Jira: • программа не бесплатная, хотя есть бесплатная пробная версия и для проектов open-source; • для крупных предприятий применяется Atlassian Jira Enterprise (до 100 000 пользователей одновременно, мощная производительность и постоянный доступ к данным); • для больших компаний есть эксклюзивная техническая поддержка – 24 часа в сутки или консультирующий специалист; • универсальность, совершенство; • контроль и планирование проекта; • работа в Agile, Скраме или Канбане; • система учета ошибок; • возможность кастомизации рабочего процесса; • составление отчетности; • уведомления по электронной почте; • есть бесплатные аналоги – Mantis, BugTracker.NET, Track, Redmine, The Bug Genie; • возможности построения пространства проектов (confluence); • неудобное мобильное приложение. 3. Google Docs. Удобный инструмент для небольших команд со сравнительно простыми процессами. Основное преимущество (кроме бесплатности) – легкость в использовании и интуитивно понятный интерфейс. Особенности Google Docs:

• специально созданные скрам-шаблоны помогают управлять небольшим проектом; • простота, не требуется никакой дополнительной установки и настройки; • хорошо подходит для распределенных команд. Интересны также PlanHammer (управление проектами), MIRO (виртуальный рабочий стол команды проекта), Asana, Zoho Projects и др. В России в категории управления проектами можно использовать бесплатные «Планфикс», «Мегаплан», «Простой Бизнес» и лицензионный «Битрикс 24».

Заключение Применение гибких подходов не в ИТ-отраслях приносит свои плоды. Говорить о полном «классическом» следовании всем ритуалам, конечно, не приходится, что убедительно доказывают описанные выше примеры. В то же время использование некоторой части инструментов, некоторых базовых принципов и подходов крайне целесообразно, и этим надо далее заниматься. В любых процессах, кейсах, проектах или компаниях, которые сталкиваются с неопределенностью, сложностью, волатильностью и риском, есть место для гибких практик и принципов. Ключевые идеи применимы везде. Они включают следующее (но не ограничиваются им): ♦ установление непосредственного контакта с людьми, имеющими потребности, и теми, кто способен удовлетворить эти потребности; ♦ производство строительных работ постепенно и проверку хода проекта; ♦ подготовку к будущему и влияние на него, но не предсказание будущего; ♦ возможность делать задачи конкретными и быстро заканчивать их; ♦ возможность давать людям задачи и знания, но не толкать их, как пешки на шахматной доске; ♦ фокус на обеспечении ценности часто и быстро. В заключение еще раз перечислю основные преимущества Agile и сформулирую самые простые рекомендации. Преимущества и условия: ♦ возможность адаптации под любое изменение в деятельности или проекте, которое приносит ценность заказчику; ♦ постепенное формирование и актуализация приоритетных требований; ♦ постоянная обратная связь с заказчиком; ♦ минимизация любых потерь в процессах, документации, инструментах; ♦ работа малыми итерациями (с планированием, контролем и ретроспективой – анализом уроков) и в составе автономных команд специалистов различного профиля; ♦ немедленное использование создаваемых функциональностей (MVP) в работе;

♦ обучение, поддержка, делегирование, самоуправление; ♦ фокус на устных коммуникациях; ♦ единое информационное пространство, организация общих баз знаний для проектов; ♦ правильная реализация правил Скрама, Канбана и др. К рекомендациям по применению избирательного Agile можно отнести: ♦ гибкую работу с идеями и ее согласование; ♦ простоту в документации; ♦ фокус на устном общении; ♦ максимальную визуализацию процессов и результатов; ♦ вовлечение заказчика; ♦ принятие внутренних решений по разработке на основе меньшего (не необходимого, а достаточного) числа согласований, планирование внешних обязательных согласований с опережением; ♦ электронное и мобильное согласование, сначала устное «да», потом подпись; ♦ мобилизацию совещаний, сокращение их числа и длительности; ♦ автономизацию проектных групп, правильные роли и вовлеченность; ♦ снижение административных проблем проектной группы путем назначения администратора (скрам-мастера); ♦ обсуждение документов совместно в виде схем, рисунков, макетов, создание единой обзорной картинки у участников; ♦ планирование на 2-3-недельные итерации, управление приоритетами; ♦ актуализацию требований перед началом итерации (планирование спринта); ♦ частые микроотчеты руководителю проекта для обратной связи; ♦ анализ итерации (ретроспектива – анализ уроков) и др.

Приложения Приложение 1. Чек-лист для выбора Agile или «Водопада» По материалам Agile Practice Guide (PMI®). Третий и четвертый столбцы формируют вопросы, большинство положительных ответов на которые ведут к применению Agile или «Водопада» соответственно. Баланс положительных ответов заставляет задуматься о гибридном варианте. 1. Культура, окружающая проект

2. Команда

3. Проект

Приложение 2. Agile-контракт Пример должен быть адаптирован под конкретное предприятие.

Договор на выполнение работ № __ г. __ «__» 20__ г. ООО «» в лице Генерального директора (Ф. И. О.), именуемое в дальнейшем «Подрядчик», с одной стороны, и ООО «», именуемое в дальнейшем «Заказчик», в лице Управляющего директора, действующего на основании доверенности от, с другой стороны, совместно именуемые «Стороны», заключили настоящий Договор о нижеследующем. Предмет Договора. Подрядчик обязуется в рамках настоящего Договора выполнять Заказчику Работы по (разработке, созданию… и технической поддержке…) по требованиям Заказчика (далее – Работы). Объем Работ, сроки их выполнения и стоимость Работ определяются Сторонами в

соответствующих дополнительных соглашениях к Договору. Заказчик обязуется принимать и оплачивать оказанные Подрядчиком Работы. Работы выполняются в соответствии с Регламентом выполнения Работ (Приложение № 1). Права и обязанности Сторон. Подрядчик обязуется: выполнять принятые на себя обязательства по оказанию Работ качественно и в сроки, согласованные с Заказчиком; выполнять Работы в порядке, объеме и в соответствии с требованиями, изложенными в настоящем Договоре и дополнительных соглашениях к нему; предупредить Заказчика о неблагоприятных последствиях выполнения его указаний, а также о любых обстоятельствах, способных повлиять на качество Работ (в том случае, если Подрядчик нарушил обязательство, предусмотренное настоящим пунктом, для него наступают последствия, предусмотренные положениями статьи 716 ГК РФ); размещать в своем портфолио только ту информацию, связанную с выполнением Работ по данному Договору, которая не представляет собой коммерческую тайну Заказчика. В случае необходимости Подрядчик имеет право привлекать для исполнения обязательств по Договору третьих лиц, за действия которых он несет ответственность перед Заказчиком. Заказчик обязуется своевременно принимать оказанные Подрядчиком Работы в соответствии с пунктом 4 Договора и оплачивать Работы Подрядчика в соответствии с пунктом 3 Договора. Размер и порядок оплаты. Стоимость Работ и сроки оплаты определяются Сторонами в соответствующих дополнительных соглашениях к Договору. Оплата Работ по настоящему Договору производится Заказчиком на расчетный счет Подрядчика в течение____ (______) рабочих банковских дней со дня получения счета. Все расчеты по настоящему Договору осуществляются исключительно в безналичной форме, в рублях Российской Федерации. Датой платежа считается дата списания денежных средств с расчетного счета Заказчика. Следующие разделы обычно типовые и используют типовые фразы: Порядок приемки и сдачи работ. Авторские права. Форс-мажор. Ответственность сторон. Порядок рассмотрения споров. Прочие условия. Список приложений. К договору прилагается и является его неотъемлемой частью: Приложение № 1 – Регламент выполнения Работ; Приложение № 2 – образец Акта сдачи-приема Работ. Реквизиты сторон. Приложение № 1 к договору № от «__» августа 20… г. Правила выполнения Работ. Введение. В данном Приложении определены основные термины и положения, согласно которым Заказчик привлекает Подрядчика к предоставлению Работ по … (далее – Работы). Общее описание процесса. Проект будет выполняться в соответствии с принципами Agile-разработки на основе фреймворка Скрам и иных инженерных практик, экстремального программирования. Подрядчик предоставляет рабочую команду и оказывает Работы итерациями фиксированной длительности, равными пяти рабочим дням, исключая выходные дни и включая праздничные дни согласно производственному календарю РФ (за исключением праздничных дней, выпадающих на январь).

Требования формулируются в виде Пользовательских историй с критериями приемки, объединенных в упорядоченный список историй (по аналогии с журналом требований продукта). По каждой Пользовательской истории Подрядчик дает оценку в условных единицах сложности (относительная оценка Пользовательских историй). В конце каждой итерации Подрядчик демонстрирует Заказчику выполненные в итерации Пользовательские истории, а Заказчик предоставляет Подрядчику обратную связь по ним. При этом обратная связь может являться новыми Пользовательскими историями. В конце каждой итерации Заказчик предоставляет Подрядчику актуальные приоритеты по невыполненным Пользовательским историям. Подрядчик сообщает, сколько Пользовательских историй он сможет выполнить за следующую итерацию, а также предоставляет Заказчику информацию о Пользовательских историях, которые могут быть выполнены до даты окончания предоставления Работ. Помимо планирования Пользовательских историй на итерации, Подрядчик совместно с Заказчиком ежемесячно проводит сессии целеполагания на следующий месяц. Задача такой сессии – определить цель разработки на следующий месяц, а также выработать средства ее достижения (Пользовательские истории, маркетинговые активности и т. п.).

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

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

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

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

♦ Формально принимать или не принимать у Подрядчика завершенные Пользовательские истории.

Обязанности Менеджера проекта Заказчика ♦ Предоставлять общий статус по Работам руководству Заказчика и другим заинтересованным лицам. ♦ Обеспечивать выполнение обязательств Заказчика, касающихся оказываемых Работ. ♦ Координировать активности между сотрудниками, участвующими в оказании Работ со стороны Заказчика и Подрядчика.

Обязанности Подрядчика ♦ Выделить со своей стороны Менеджера проекта как единую точку входа для обсуждения и устранения проблем, планирования работ, сбора информации и т. п. ♦ Выделить со своей стороны рабочую команду для выполнения Работ Заказчику. ♦ Осуществлять сбор и анализ ожиданий и требований Заказчика к результатам выполнения Работ. ♦ В конце каждой итерации (кроме нулевой) предоставлять Заказчику на демонстрации работающий продукт, содержащий инкремент функциональности, соответствующий выполненным в итерации Пользовательским историям.

Обязанности Менеджера проекта Подрядчика ♦ Координация работ команды Подрядчика. ♦ Обеспечение соответствия процесса выполнения Работ принципам гибкой разработки (Agile). ♦ Взаимодействие с Заказчиком и управление его ожиданиями. ♦ Обеспечение наличия оценки у каждой Пользовательской истории в журнале требований продукта. ♦ Ответственность за решение вопросов, связанных с оказанием Работ. ♦ Приемка Пользовательских историй. ♦ Описание требований к оказываемым Работам в виде Пользовательских историй и приемочных критериев к ним, которые должны быть утверждены Менеджером проекта со стороны Подрядчика и Владельцем продукта со стороны Заказчика.

♦ Пользовательская история считается выполненной, если все описанные в ней приемочные критерии реализованы Подрядчиком и на момент приемки нет незавершенных критических дефектов, связанных с этой Пользовательской историей. ♦ Приемка Истории осуществляется Владельцем продукта Заказчика на тестовом стенде Заказчика в течение двух рабочих дней с даты окончания итерации, в которой Пользовательская история была выполнена Подрядчиком.

Гарантийные обязательства Устранение дефектов, найденных в разработанном Подрядчиком ПО во время промышленной эксплуатации, осуществляется Подрядчиком без дополнительной оплаты в течение гарантийного срока 45 (сорок пять) календарных дней с даты подписания последней из Сторон Акта сдачиприемки Работ по последней итерации соответствующего дополнительного соглашения. Устранение дефектов включает в себя работы по фактическому устранению дефекта в ПО, созданном Подрядчиком, и выпуску соответствующего обновления на серверах Заказчика. Подрядчик обязуется реагировать на поступившие запросы в указанные сроки в соответствии с уровнем критичности запроса. Уровень критичности запроса определяется на основе описания запроса и согласуется Сторонами. Запрос должен быть направлен Заказчиком на адрес электронной почты службы поддержки Подрядчика. Работы, связанные с гарантийными обязательствами, выполняются Подрядчиком в рабочие дни согласно производственному календарю РФ, с 10:00 до 19:00 (GMT+4). В случае если дефект вызван внешними по отношению к разработанному Подрядчиком ПО факторами (проблемы в инфраструктуре Заказчика, проблемы со смежным ПО и т. п.), устранение такого дефекта не входит в рамки гарантийных обязательств, а Заказчик обязуется оплатить фактически затраченное время сотрудников Подрядчика на исследование такого дефекта. Все запросы классифицируются по пяти уровням критичности.

Приложение 3. Устав команды Устав помогает сплотить команду и создать доверие, дает быстрый старт, позволяет объединить всех – членов команды и управления.

Устав команды – это общее понимание того, как команда получает свой проект, почему она существует, в чем ее предназначение и как будет происходить работа. Хорошо разработанный устав команды создает четкие ожидания. Это может помочь эффективно решать проблемы, которые часто возникают во время проекта, и сохранить проект от появления проблем. Эффективный устав команды должен включать в себя следующие элементы. 1. Базовая информация. 2. Миссия и цели. 3. Бюджет и ресурсы. 4. Роли и обязанности. 5. Действия команды. 6. Оценка команды. 7. Подписи и утверждения. 1. Базовая информация. Почему была сформирована команда, какую проблему просят решить, как эта проблема влияет на цели и задачи организации и какие были бы последствия, если бы проблема не решалась. 2. Миссия и цели. Чего команда стремится достичь? Желательно сделать это ясным и запоминающимся и достаточно конкретным. ♦ Кто что делает и для кого? ♦ Как выглядит успешное завершение проекта? ♦ Бизнес-обоснование и ожидаемые результаты работы. ♦ Каковы промежуточные цели и задачи проекта? ♦ Имеют ли цель SMART-признаки? ♦ Все ли в команде находятся в согласии? ♦ Если мы достигнем данной цели, будет ли это измеримо и приведет ли к успеху? 3. Бюджет и ресурсы. Указать, как финансируется проект, границы изменения и возможности менять цели проекта (или сроки) соответственно. Кто управляет средствами, отвечает за подписание документов, знает, что деньги доступны, и платит? 4. Роли и обязанности. Определение ответственности – как для проекта в целом, так и в поддержку конкретных целей – является важным компонентом устава команды. Кто отвечает за деятельность по управлению проектом? Кто из ключевых сторон заинтересован в каких областях, кто выступает спонсором? Кто отдельные члены группы, ответственные за ключевые результаты? Ниже приведены некоторые вопросы для работы с матрицей. ♦ Существуют ли дополнительные навыки или знания, необходимые для успеха проекта? ♦ Есть ли какие-то другие группы или отдельные лица, которые должны быть представлены или проконсультированы в ходе проекта?

♦ Достаточно ли сильна ваша команда для работы и сроков? ♦ Есть ли какие-то тренинги, которые члены команды должны будут успешно завершить? ♦ Есть ли хоть одна компетенция, которую вы, возможно, упустили из виду? ♦ Насколько адаптивны члены команды к изменениям? 5. Действия команды. Это раздел, в котором разъясняется, как выполняется работа. Описываются последовательный процесс и согласованные со всеми процедуры. Для начала определите частые и периодические мероприятия, которые выиграли бы от четко определенного документированного процесса. Обычно это следующие элементы: ♦ руководящие принципы проведения совещаний; ♦ руководящие принципы принятия решений; ♦ процесс урегулирования конфликта; ♦ как распределяется работа между членами команды; ♦ коммуникации внутри и вне команды; ♦ как обновляется статус проекта. 6. Оценка команды. ♦ Насколько эффективно сотрудничество команды? Причина? ♦ Большинство членов команды регулярно участвуют в работе? Если нет, то почему? ♦ Пришли ли члены команды на встречу? Готовы внести свой вклад? ♦ Что конкретно из того, что вы узнали благодаря своему участию в команде, вы бы не узнали иначе? ♦ Что конкретно из того, что члены вашей команды узнали от вас и благодаря вашему участию в команде, они, вероятно, не узнали бы иначе? ♦ Имели ли вы и команда в целом необходимые ресурсы (включая поддержку управления проектами, связь, бюджет, лидерство, навыки, время) для достижения целей команды? ♦ Есть ли у вас какие-либо предложения по улучшению следующей команды проекта? 7. Подписи и утверждения. И последнее, но не менее важное: устав команды должен быть подписан командой. Подпись гарантирует, что каждый участник понимает положения Устава и соглашается с ними. Официальное утверждение устава спонсором проекта дает официальное благословение командным целям, результатам и определению успеха.

Приложение 4. Итоговый тест «Ваш мини-ACP» 1. Кто несет ответственность за определение последовательности и оценку задач в спринте: 1) команда исполнителей (разработки);

2) владелец продукта; 3) скрам-мастер; 4) заказчик? 2. В ходе проекта по разработке бизнес-процессов вы с остальными сотрудниками, работающими по проекту, потратили три дня на документирование инструкций разного приоритета, прежде чем ввести их в эксплуатацию. Законченные документы были переданы на рассмотрение и отклонены. В результате их пришлось переделывать. Эта операция наилучшим образом описывается как: 1) негибкое управление; 2) разумный подход; 3) небережливое управление; 4) бюрократизация управления. 3. Кто несет ответственность за расстановку приоритетов в журнале требований: 1) команда исполнителей; 2) владелец продукта; 3) скрам-мастер; 4) владелец продукта и заказчик? 4. Стейкхолдеры формируют Agile-команду. Что важнее узнать о ней: 1) компетенции, роли и тип (Т или I) каждого члена команды; 2) любимый кофе каждого члена команды; 3) личные предложения каждого члена команды по мотивации в проекте; 4) пожелания по оптимизации работы? 5. Кто несет ответственность за проведение ежедневных летучек: 1) команда исполнителей; 2) владелец продукта; 3) скрам-мастер; 4) тот, кто свободен? 6. Как долго длятся спринты в Скраме: 1) по-разному, по мере получения критериев готовности; 2) обычно в пределах месяца; 3) идеальная длина одного спринта составляет от одной до четырех недель, при этом наиболее широко используется двухнедельный спринт; 4) по-разному, на усмотрение скрам-мастера? 7. Кто несет ответственность за техническую реализацию в проекте: 1) команда исполнителей; 2) владелец продукта; 3) скрам-мастер;

4) руководитель проекта? 8. Что из перечисленного ниже не является частью Agile: 1) реагирование на изменения важнее, чем следование плану; 2) сотрудничество с клиентом менее важно, чем следование плану; 3) личности и их взаимодействия важнее, чем процессы и инструменты; 4) сотрудничество с клиентом важнее, чем переговоры по контрактам? 9. В Agile-проектах: 1) изменения в функциональности должны быть пройдены через строгие процедуры контроля изменений; 2) изменения считаются проблемой и их следует избегать; 3) изменения принимаются и адекватно воспринимаются; 4) изменения принимаются, только если они имеют наивысший приоритет. 10. Все в порядке, если кто-то хочет изменить требование: 1) да, но изменение должно пройти цикл согласования в компании, включая ее руководство, и с ним не надо торопиться. Agile поощряет обратную связь; 2) да, Agile поощряет обратную связь, чтобы продукт можно было улучшить. Мы должны уметь принимать изменения; 3) нет, Agile не поощряет обратную связь; 4) нет, Agile поощряет обратную связь, но в очень редких случаях. Мы не должны принимать изменения. 11. Ретроспективы используют: 1) в Скраме; 2) в Скраме и XP; 3) в Канбане; 4) во всех гибких подходах. 12. Объясните суть Agile: 1) Agile – это основа гибких подходов и моделей поведения, которые стимулируют производство «точно в срок», что позволяет клиентам быстрее получать качественный продукт; 2) Agile – это гибкая основа подходов и моделей поведения в проекте; 3) Agile – это основа подходов и моделей гибкого поведения, которые стимулируют производство качественного продукта; 4) Agile – это модель гибкого управления, которые стимулируют производство качественного продукта в любой срок. 13. Какое из следующих утверждений лучше всего описывает ретроспективы в спринте: 1) владелец продукта обсуждает журнал требований продукта; 2) команда обсуждает то, что будет сделано в следующем спринте и как эта работа будет достигнута;

3) ретроспектива проводится в конце спринта, чтобы продемонстрировать новый разработанный функционал в продукте; 4) команда размышляет над спринтом и ищет возможности для его улучшения? 14. Что такое ежедневная летучка: 1) в конце каждой недели команда организует короткие встречи (примерно по 15 минут), чтобы ответить на три вопроса: «Что вы делали в течение недели?»; «Что вы планируете делать на следующей?»; «Есть ли какие-либо препятствия, которые мешают вам выполнять свою работу?»; 2) в конце каждой итерации, желательно вечером, команда организует короткие встречи (примерно по 15 минут), чтобы ответить на три вопроса: «Что вы делали в течение итерации?»; «Что вы планируете делать на следующей?»; «Есть ли какие-либо препятствия, которые мешают вам выполнять свою работу?»; 3) каждый день, желательно утром, команда организует короткие встречи (примерно по 15 минут), чтобы ответить на три вопроса: «Что вы делали вчера?»; «Что вы планируете делать сегодня?»; «Есть ли какие-либо препятствия, которые мешают вам выполнять свою работу?»; 4) каждый вечер команда с владельцем продукта организует короткие встречи (примерно по 15 минут), чтобы ответить на три вопроса: «Что вы делали вчера?»; «Что вы планируете делать сегодня?»; «Есть ли какие-либо препятствия, которые мешают вам выполнять свою работу?» 15. Что является предпочтительным способом общения в гибких проектах и почему: 1) видеосвязь, потому что она позволяет контактировать с распределенными членами команды, как если бы они сидели рядом друг с другом; 2) личный контакт (лицом к лицу), потому что он имеет самую высокую пропускную способность всех форм коммуникации; 3) электронная почта, потому что члены гибких команд – это работники умственного труда и они более квалифицированны в использовании именно технологии, а не в работе с людьми; 4) бумажная документация, потому что она сохраняет запись часто меняющихся процессов, чтобы помочь управлять будущим проектом? 16. Есть ли разница между Agile и Скрамом: 1) да. Agile – это семейство, к которому относится Скрам. Скрам, в отличие от Agile, не имеет ценностей и принципов; 2) нет. Это одно и то же; 3) да. Agile – это методология, к которой относится Скрам. Agile имеет четыре основные ценности и 12 принципов. Скрам обладает своим собственным набором ценностей и принципов и обеспечивает легкую структуру, помогающую командам освоить Agile; 4) да. Agile – это методология, к которой относится Скрам. Agile имеет четыре основные ценности и 12 принципов. Скрам обладает тем же набором ценностей и принципов и обеспечивает облегченный Agile? 17. Agile Manifesto – это документ, который фиксирует:

1) отношение некоторых разработчиков к управлению проектами; 2) четыре ценности (положения) и 12 принципов управления проектами; 3) перечень требований к Agile-трансформации; 4) лозунги, заявления сторонников хаотичного управления. 18. Что из нижеперечисленного может являться оценкой длительности задач в Agile-проектах: 1) задача оценивается два месяца; 2) задача оценивается от 40 до 50 часов; 3) задача должна быть реализована к концу этого финансового года; 4) задача будет завершена к 15 марта? 19. При Agile: 1) формирование команд вокруг продуктов, а не проектов; стабильные, сильные команды, которым передаются проекты на реализацию; развитие навыков работы в команде; развитие зрелости и эффективности команд; планирование работы целых команд; 2) формирование команд под проект; расформирование команды после проекта; развитие навыков подчинения РП; развитие зрелости и эффективности РП; планирование работы ресурсных пулов, работы различных подразделений координируются через РП; 3) формирование команд вокруг проектов; нестабильные команды, которым передаются проекты на реализацию; развитие навыков работы в команде; развитие зрелости и эффективности команд; планирование работы отдельных исполнителей; 4) абсолютно любые варианты. 20. Что больше похоже на Agile-проекты: 1) строительство дома с фиксированным назначением; 2) разработка бизнес-процессов для растущей компании; 3) вывод на рынок типового продукта; 4) проведение контролируемой аттестации персонала? Ответы к тесту: 1–1, 2–1, 3–4, 4–1, 5–3, 6–3, 7–2, 8–2, 9–3, 10–2, 11–4, 12–1, 13– 4, 14–3, 15–2, 16–3, 17–2, 18–2, 19–1, 20–2.

Литература Книги на русском языке 1. Андерсон Д. Канбан. Альтернативный путь в Agile. – М.: Манн, 2010. 2. Апелло Ю. Agile-менеджмент. Лидерство и управление командами. – М.: Альпина Паблишер, 2019. 3. Бек К. Экстремальное программирование. Разработка через тестирование. – СПб.: Питер, 2017. 4. Беркун С. Искусство управления ИТ-проектами. – СПб.: Питер, 2007.

5. Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. – М.: Символ-Плюс, 2000. 6. Демарко Т. Deadline. Роман об управлении проектами / Пер. с англ. А. Максимовой. – М.: Вершина, 2006. 7. Демарко Т., Листер Т. Вальсируя с медведями. Управление рисками в проектах по разработке программного обеспечения / Пер. с англ. Ю. М. Яновской; науч. ред. А. Д. Баженов, А. О. Арефьев. – М.: Компания p.m. Office, 2005. 8. Йордон Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. – М.: Лори, 2001. 9. Йордон Э. Управление сложными интернет-проектами. – М.: Лори, 2003. 10. Кантор М. Управление программными проектами. – М.: Вильямс, 2002. 11. Клайм Р., Лудин И. Ноев проект. Экономический роман. Секреты практического проектного менеджмента: Пер. с англ. – СПб.: ИД «Весь», 2002. 12. Книберг Х. Scrum и XP: заметки с передовой [Электронный ресурс]. – Режим доступа: http://scrum.org.ua/wp-content/ uploads/2008/12/scrum_xp-fromthe-trenches-rus-final.pdf. 13. Книберг Х., Скарин М. Scrum и Kanban: выжимаем максимум [Электронный ресурс]. – Режим доступа: http://scrum. org.ua/wpcontent/uploads/ScrumAndKanbanRuFinal.pdf. 14. Коберн А. Быстрая разработка программного обеспечения. – М.: Лори, 2002. 15. Ковалев А., Курдюмов И. Управление проектом по созданию интернетсайта. – М.: Альпина Паблишер, 2001. 16. Кон М. Пользовательские истории. Гибкая разработка программного обеспечения. – М.: Вильямс, 2012. 17. Кон М. Agile: Оценка и планирование проектов. – М.: Альпина Паблишер, 2018. 18. Кон М. Scrum. Гибкая разработка ПО. – М.: Вильямс, 2015. 19. Коттер Дж. П. Впереди перемен. – М.: Олимп-Бизнес, 2014. 20. Коул Р., Скотчер Э. Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban. – СПб.: Питер, 2019. 21. Лалу Ф. Открывая организации будущего. – М.: Манн, Иванов и Фербер, 2018. 22. Парамонов Д., Фунтов В., Малоземов С., Прусова Ж. Agile в проектировании: эффективнее, дешевле, безопаснее // Атомный эксперт, 2017. – № 3–4. 23. Паттон Дж. Пользовательские истории. Искусство гибкой разработки ПО. – СПб.: Питер, 2019. 24. Пинк Д. Драйв: что на самом деле нас мотивирует. – М.: Альпина Паблишер, 2013. 25. Пихлер Р. Управление продуктом в Scrum: Agile-методы для вашего бизнеса: Пер. с англ. – М.: Манн, Иванов и Фербер, 2017.

26. Ригби Д., Сазерленд Дж., Такеучи Хиротака. Новый рецепт инноваций: модель agile [Электронный ресурс]. – Режим доступа: http://hbrrussia.ru/management/strategiya/a17966/. 27. Ройс У. Управление проектами по созданию программного обеспечения. – М.: Лори, 2002. 28. Рубин К. С. Основы Scrum. Практическое руководство по гибкой разработке ПО. – М.: Вильямс, 2016. 29. Руководство к Своду знаний по управлению проектам (Project Management Body of Knowledge – PMBOK), 6-е издание. – Project Management Institute, 2017. 30. Сазерленд Дж. Scrum. Революционный метод управления проектами. – М.: Манн, Иванов и Фербер, 2019. 31. Салливан Э. Время – деньги. Создание команды разработчиков программного обеспечения. – М.: Русская редакция, 2002. 32. Стеллман Э., Грин Дж. Постигая Agile: ценности, принципы, методологии. – М.: Манн, Иванов и Фербер, 2018. 33. Уилсон С., Мейплс Б., Лендгрейв Т. MCSD. Принципы проектирования и разработки программного обеспечения. – М.: Русская редакция, 2000. 34. Управление проектами: / Под ред. Дж. К. Пинто; Пер. с англ. под ред. В. Н. Фунтова. – СПб.: Питер, 2004. 35. Фатрелл Р. T., Шафер Д. Ф., Шафер Л. И. Управление программными проектами. Достижение оптимального качества при минимуме затрат. – М.: Вильямс, 2003. 36. Филлипс Дж. Менеджмент ИТ-проектов. На пути от старта до финиша: Пер. с англ. – М.: Лори, 2005. 37. Филлипс Дж. Управление проектами в области информационных технологий (+CD-ROM). – М.: Лори, 2006. 38. Фунтов В. Н. Основы управления проектами в компании: Учеб. пособие. 4-е изд. – СПб.: Питер, 2018. 39. Фунтов В. Н. Управление проектами развития фирмы. Теория и практика: Монография. – СПб.: Питер, 2009. 40. Фунтов В. Н., Парамонов Д. В., Малоземов С. Н. Применение гибких методов в негибкой отрасли // Российский журнал управления проектами, 2017. – № 1. – С. 23–36. 41. Фунтов В. Н. Сенько А. А. «Бережливое» управление проектами // Управление проектами, 2009. – № 1 (14). 42. Шмальтц Д. Слепые и слон: Пер. с англ. – М.: Нippo, 2005. Некоторые ресурсы на английском языке 1. Agile Marketing Principles (proposed) // http://agilemarketingmanifesto.org/principles/. 2. Carlson R., Turner R. Review of Agile Case Studies for Applicability to Aircraft Systems Integration // Procedia Computer Science, 2013. № 16. Pp. 469–474.

3. Cicmil S., Cooke-Davies T., Crawford L. Exploring the Complexity of Projects: Implications of Complexity Theory for Project Management Practice. Project Management Institute, 2017. 4. Cohn M. Agile estimating and planning. Pearson Education, 2005. 5. Grenning J. Planning poker or how to avoid analysis paralysis while Release planning [online] // Hawthorn Woods: Renaissance Software Consulting, 2002. № 3. 6. Takeuchi H., Nonaka I. The New New Product Development Game, Harvard Business Review // HARVARD BUSINESS REVIEW, January-February 1986 // http://www.sao.corval-lis.or.us/drupal/files/The%20New%20New%20Product%20 Development%20Game.pdf. 7. MoreAgile Manifesto, Xebia, 23.12.2013 // http://blog.xebia. com/moreagilemanifesto. 8. Schwaber K., Beedle M. Agile software development with Scrum. Prentice Hall Upper Saddle River, 2002. 9. Scrum in Mechanical Product Development Case Study of a Mechanical Product Development Team using Scrum. Chalmers University of Technology Gothenburg, Sweden, 2013 // http://publications.lib.chalmers.se/records/fulltext/191951/191951.pdf. 10. Statement of Position 98-1. Accounting for the Costs of Computer Software Developed or Obtained for Internal Use // FASAB, 1998.